Although this white paper was discussed amongst the full group of kernel
developers who participated in the informal poll, as you can expect from
Linux Kernel Developers, there was a wide crossection of opinion. This
document is really only for discussion, and represents only the views of
the people listed as authors (not the full voting pool).
James
----------
The Dangers and Problems with GPLv3
James E.J. Bottomley Mauro Carvalho Chehab
Thomas Gleixner Christoph Hellwig Dave Jones
Greg Kroah-Hartman Tony Luck Andrew Morton
Trond Myklebust David Woodhouse
15 September 2006
Abstract
This document is a position statement on the GNU General Public
License version 3 (in its current Draft 2 form) and its surrounding
process issued by some of the Maintainers of the Linux Kernel
speaking purely in their role as kernel maintainers. In no regard
should any opinion expressed herein be construed to represent the
views of any entities employing or being associated with any of the
authors.
1 Linux and GPLv2
Over the past decade, the Linux Operating System has shown itself to be far
and away the most successful Open Source operating system in history.
However, it certainly wasn't the first such open source operating system
and neither is it currently the only such operating system. We believe that
the pre-eminent success of Linux owes a great part to the dynamism and
diversity of its community of contributors, and that one of the catalysts
for creating and maintaining this community is the development contract as
expressed by GPLv2.
Since GPLv2 has served us so well for so long, and since it is the
foundation of our developer contract which has helped propel Linux to the
successes it enjoys today, we are extremely reluctant to contemplate
tampering with that licence except as bug fixes to correct exposed problems
or updates counter imminent dangers. So far, in the whole history of GPLv2,
including notable successes both injunctively and at trial, we have not
found any bugs significant enough to warrant such corrections.
2 Linux, the Kernel and the Open Source Universe
Linux Distributions, as the Free Software Foundation (FSF) has often
observed, don't only contain the kernel; they are composed of a
distribution of disparate open source components of which the kernel is
only a part (albeit a significant and indispensable part) which
collectively make up a useful and usable system. Thus, Linux as installed
by the end user, is critically dependent on entities, known as
distributions, who collect all of the necessary components together and
deliver them in a tested, stable form. The vast proliferation of Open
Source Licences complicates the job of these distributions and forces them
to spend time checking and assessing the ramifications of combining
software packages distributed under different (and often mutually
incompatible) licences--indeed, sometimes licensing consideration will be
sufficient to exclude a potential package from a distribution altogether.
In deference to the critical role of distributions, we regard reducing
the Open Source licensing profusion as a primary objective. GPLv2 has
played an important role in moving towards this objective by becoming the
dominant Licence in the space today, making it possible to put together a
Linux Distribution from entirely GPLv2 components and thus simplify the
life of a distributor. Therefore, we believe that any update to GPLv2 must
be so compelling as to cause all projects currently licensed under it to
switch as expediently as possible and thus not fragment the currently
unified GPLv2 licensed ecosystem.
3 Linux and Freedom
Another of the planks of Linux's success rests squarely on the breadth and
diversity of its community of contributors and users, without whom we
wouldn't have the steady stream of innovation which drives our movement
forward. However, an essential element of this is the fact that individuals
with disparate (and sometimes even competing) objectives can still march
together a considerable distance to their mutual benefit. This synergy of
effort, while not compromising dissimilar aims, is one of the reasons Linux
manages to harness the efforts of not only motivated developers but also
corporate and commercial interests. This in turn is brought about by a
peculiar freedom enshrined in the developer contract as represented by
GPLv2, namely the freedom from binding the end use of the project. Without
this freedom, it would be much more difficult to satisfy the objectives of
the contributors, since those objectives often have expression in terms of
the end use to which they wish to put the particular project. Therefore, in
order to maintain the essential development synergy and consequent
innovation stream it provides to Linux, we could not countenance any change
to the GPL which would jeopardise this fundamental freedom.
4 Pivotal Role of the Free Software Foundation
We have acknowledged before, projects controlled by the FSF (especially
gcc, binutils and glibc) are essential components of every shipping Linux
distribution. However, we also take note of the fact that the FSF operates
very differently from Linux in that it requires assignment of copyright
from each and every one of the thousands of contributors to its code
base. These contributions have been given to the FSF not as a tribute to do
with as it will but under a solemn trust, as stated in article 9 of GPLv2,
only to licence the code under versions of the GPL that "... will be
similar in spirit to the present version". We, like all the individual
contributors to GNU projects, have taken that trust at face value and
accorded the FSF a special role in the Open Source Universe because of
it. It goes without saying that any updates to GPLv2 must be completely in
accord with the execution of that trust.
5 GPLv3 and the Process to Date
The current version (Discussion Draft 2) of GPLv3 on first reading fails
the necessity test of section 1 on the grounds that there's no substantial
and identified problem with GPLv2 that it is trying to solve.
However, a deeper reading reveals several other problems with the
current FSF draft:
5.1 DRM Clauses
Also referred to as the "Tivoisation" clauses.
While we find the use of DRM by media companies in their attempts to
reach into user owned devices to control content deeply disturbing, our
belief in the essential freedoms of section 3 forbids us from ever
accepting any licence which contains end use restrictions. The existence of
DRM abuse is no excuse for curtailing freedoms.
Further, the FSF's attempts at drafting and re-drafting these
provisions have shown them to be a nasty minefield which keeps ensnaring
innocent and beneficial uses of encryption and DRM technologies so, on such
demonstrated pragmatic ground, these clauses are likewise dangerous and
difficult to get right and should have no place in a well drafted update to
GPLv2.
Finally, we recognise that defining what constitutes DRM abuse is
essentially political in nature and as such, while we may argue forcefully
for our political opinions, we may not suborn or coerce others to go along
with them. Therefore, attempting to write these type of restrictions into
GPLv3 and then relicense all FSF code under it is tantamount to co-opting
the work of all prior contributions into the service of the FSF's political
ends, and thus represents a fundamental violation of the trust outlined in
section 4.
5.2 Additional Restrictions Clause
As we stated in section 2 one of the serious issues in Open Source is too
many licences. The additional restrictions section in the current draft
makes GPLv3 a pick and choose soup of possible restrictions which is going
to be a nightmare for our distributions to sort out legally and get
right. Thus, it represents a significant and unacceptable retrograde step
over GPLv2 and its no additional restrictions clause.
Further, the additional restrictions create the possibility of
fragmentation of the licensing universes among particular chosen
restrictions, which then become difficult to combine and distribute
(because of the need for keeping track of the separate restrictions). Thus,
we think this potential for fragmentation will completely eliminate the
needed compulsion to move quickly to a new licence as outlined in section 2
5.3 Patents Provisions
As drafted, this currently looks like it would potentially jeopardise the
entire patent portfolio of a company simply by the act of placing a GPLv3
licensed programme on their website. Since the Linux software ecosystem
relies on these type of contributions from companies who have lawyers who
will take the broadest possible interpretation when assessing liability, we
find this clause unacceptable because of the chilling effect it will have
on the necessary corporate input to our innovation stream.
Further, some companies who also act as current distributors of Linux
have significant patent portfolios; thus this clause represents another
barrier to their distributing Linux and as such is unacceptable under
section 2 because of the critical reliance our ecosystem has on these
distributions.
6 Conclusions
The three key objections noted in section 5 are individually and
collectively sufficient reason for us to reject the current licence
proposal. However, we also note that the current draft with each of the
unacceptable provisions stripped out completely represents at best marginal
value over the tested and proven GPLv2. Therefore, as far as we are
concerned (and insofar as we control subsystems of the kernel) we cannot
foresee any drafts of GPLv3 coming out of the current drafting process that
would prove acceptable to us as a licence to move the current Linux Kernel
to.
Further, since the FSF is proposing to shift all of its projects to
GPLv3 and apply pressure to every other GPL licensed project to move, we
foresee the release of GPLv3 portends the Balkanisation of the entire Open
Source Universe upon which we rely. This Balkanisation, which will be
manifested by distributions being forced to fork various packages in order
to get consistent licences, has the potential to inflict massive collateral
damage upon our entire ecosystem and jeopardise the very utility and
survival of Open Source. Since we can see nothing of sufficient value in
the current drafts of the GPLv3 to justify this terrible cost, we can only
assume the FSF is unaware of the current potential for disaster of the
course on which is has embarked. Therefore, we implore the FSF to
re-examine the consequences of its actions and to abandon the current GPLv3
process before it becomes too late.
On Fri, 2006-09-22 at 11:15 -0500, James Bottomley wrote:
> Although this white paper was discussed amongst the full group of kernel
> developers who participated in the informal poll, as you can expect from
> Linux Kernel Developers, there was a wide crossection of opinion. This
> document is really only for discussion, and represents only the views of
> the people listed as authors (not the full voting pool).
And the pretty printed pdf version.
James
On Fri, Sep 22, 2006 at 11:15:50AM -0500, James Bottomley wrote:
> Although this white paper was discussed amongst the full group of kernel
> developers who participated in the informal poll, as you can expect from
> Linux Kernel Developers, there was a wide crossection of opinion. This
> document is really only for discussion, and represents only the views of
> the people listed as authors (not the full voting pool).
>
> James
>
> ----------
>
> The Dangers and Problems with GPLv3
>
>
> James E.J. Bottomley Mauro Carvalho Chehab
> Thomas Gleixner Christoph Hellwig Dave Jones
> Greg Kroah-Hartman Tony Luck Andrew Morton
> Trond Myklebust David Woodhouse
>...
> 6 Conclusions
>
>... Therefore, as far as we are
> concerned (and insofar as we control subsystems of the kernel) we cannot
> foresee any drafts of GPLv3 coming out of the current drafting process that
> would prove acceptable to us as a licence to move the current Linux Kernel
> to.
>...
Some people might wonder why kernel developers have any business
discussing the GPLv3 in their positions as kernel developers and why
10 core kernel developers put their names on a document containing this
statement.
Isn't all this complete nonsense considering that the COPYING file in
the kernel contains the following?
<-- snip -->
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
<-- snip -->
Considering that the number of people that contributed to the Linux
kernel during the last 15 years might be in the range 5.000-20.000, so
asking all contributors to agree with a licence change from GPLv2 to
GPLv3 (or any other license) and handling all the cases where
contributors do not answer, are not reachable or disagree, and doing
this in a way not creating legal issues in any jurisdiction is not a
realistic option.
So aren't all discussions about "acceptable to us as a licence to move
the current Linux Kernel to" silly since this is anyway not an option?
In the internal discussions there was one point that changes this
pictures, and I would consider it highly immoral to keep it secret since
it affects every single contributor to Linux.
Thinking about probably changing the license of the kernel makes sense
if you believe the following "nuclear option" is a real option:
1. It is a legally tenable and arguable position that the Linux
kernel is a work of joint authorship whose legal citus is that
of the USA.
2. On this basis, a single co-author can cause the kernel to be
relicensed.
3. To be legally sound, such a co-author would have to be either a
current major subsystem maintainer or a demonstrated contributor
of a significant proportion of code of the kernel.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, Sep 22, 2006 at 07:49:53PM +0200, Adrian Bunk wrote:
> Isn't all this complete nonsense considering that the COPYING file in
> the kernel contains the following?
>
> <-- snip -->
In a way, it is, but no one else is standing up in the free software
community becides Linus stating that they think the GPLv3 is bad. So we
wanted to make our statement also known.
> In the internal discussions there was one point that changes this
> pictures, and I would consider it highly immoral to keep it secret since
> it affects every single contributor to Linux.
>
> Thinking about probably changing the license of the kernel makes sense
> if you believe the following "nuclear option" is a real option:
>
> 1. It is a legally tenable and arguable position that the Linux
> kernel is a work of joint authorship whose legal citus is that
> of the USA.
> 2. On this basis, a single co-author can cause the kernel to be
> relicensed.
> 3. To be legally sound, such a co-author would have to be either a
> current major subsystem maintainer or a demonstrated contributor
> of a significant proportion of code of the kernel.
Note that almost no lawyer that I have spoken to about this believes
this is an option. However, one lawyer I have talked to does believe
this, luckily, that lawyer does not have a client who is a co-author in
the current Linux kernel :)
Anyway, this is arguing a legal point on lkml that even the lawyers
don't all agree apon. I don't think it will get very far here either.
And don't let it detract from the main issue here, the GPLv3 as drafted
has some major issues that a number of us publicly object to, and feel
it will cause great harm if it becomes ratified as drafted.
thanks,
greg k-h
Adrian Bunk wrote:
> On Fri, Sep 22, 2006 at 11:15:50AM -0500, James Bottomley wrote:
>
>> Although this white paper was discussed amongst the full group of kernel
>> developers who participated in the informal poll, as you can expect from
>> Linux Kernel Developers, there was a wide crossection of opinion. This
>> document is really only for discussion, and represents only the views of
>> the people listed as authors (not the full voting pool).
>>
>> James
>>
>> ----------
>>
>> The Dangers and Problems with GPLv3
>>
>>
>> James E.J. Bottomley Mauro Carvalho Chehab
>> Thomas Gleixner Christoph Hellwig Dave Jones
>> Greg Kroah-Hartman Tony Luck Andrew Morton
>> Trond Myklebust David Woodhouse
>> ...
>> 6 Conclusions
>>
>> ... Therefore, as far as we are
>> concerned (and insofar as we control subsystems of the kernel) we cannot
>> foresee any drafts of GPLv3 coming out of the current drafting process that
>> would prove acceptable to us as a licence to move the current Linux Kernel
>> to.
>> ...
>
>
> Some people might wonder why kernel developers have any business
> discussing the GPLv3 in their positions as kernel developers and why
> 10 core kernel developers put their names on a document containing this
> statement.
>
>
> Isn't all this complete nonsense considering that the COPYING file in
> the kernel contains the following?
>
> <-- snip -->
>
> Also note that the only valid version of the GPL as far as the kernel
> is concerned is _this_ particular version of the license (ie v2, not
> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>
> <-- snip -->
>
>
> Considering that the number of people that contributed to the Linux
> kernel during the last 15 years might be in the range 5.000-20.000, so
> asking all contributors to agree with a licence change from GPLv2 to
> GPLv3 (or any other license) and handling all the cases where
> contributors do not answer, are not reachable or disagree, and doing
> this in a way not creating legal issues in any jurisdiction is not a
> realistic option.
>
More than that the people who are classified as the top ten are just
MAINTAINERS.
a MAINTAINER collects patches from various people.
So eventually a MAINTAINER is the top most contributor ? this might be
valid in certain cases, but not be applicable in all cases.
>
> So aren't all discussions about "acceptable to us as a licence to move
> the current Linux Kernel to" silly since this is anyway not an option?
>
>
> In the internal discussions there was one point that changes this
> pictures, and I would consider it highly immoral to keep it secret since
> it affects every single contributor to Linux.
>
ACK. cent per cent
Talking about openness and still closed ?
>
> Thinking about probably changing the license of the kernel makes sense
> if you believe the following "nuclear option" is a real option:
>
> 1. It is a legally tenable and arguable position that the Linux
> kernel is a work of joint authorship whose legal citus is that
> of the USA.
> 2. On this basis, a single co-author can cause the kernel to be
> relicensed.
> 3. To be legally sound, such a co-author would have to be either a
> current major subsystem maintainer or a demonstrated contributor
> of a significant proportion of code of the kernel.
>
>
> cu
> Adrian
>
Manu
On Fri, 2006-09-22 at 13:59 -0400, Gene Heskett wrote:
> James, I'm most definitely NOT a kernel developer, just a lurker who
> occasionally exhibits his lack of knowledge with (usually) dumb questions.
>
> But, while I can't say the above any better than you have, I do have one
> question:
>
> Why is the FSF and RMS not included in the Cc: line of all messages on this
> subject, so they can have first hand, the benefit of the remarks this
> group makes by reading about them from the first person? You folks are,
> as a group, the movers and shakers in the advancement of linux, and would
> continue to do so without the gnu trying to claim they invented linux,
> which we all know is a prevarication.
Basically because this is a discussion document, not an open letter.
We had some discussion amongst a small group of kernel developers. Now
we're opening it up to the linux community---which we can't do without
effectively going public as well.
James
On Friday 22 September 2006 14:08, James Bottomley wrote:
>On Fri, 2006-09-22 at 13:59 -0400, Gene Heskett wrote:
>> James, I'm most definitely NOT a kernel developer, just a lurker who
>> occasionally exhibits his lack of knowledge with (usually) dumb
>> questions.
>>
>> But, while I can't say the above any better than you have, I do have
>> one question:
>>
>> Why is the FSF and RMS not included in the Cc: line of all messages on
>> this subject, so they can have first hand, the benefit of the remarks
>> this group makes by reading about them from the first person? You
>> folks are, as a group, the movers and shakers in the advancement of
>> linux, and would continue to do so without the gnu trying to claim they
>> invented linux, which we all know is a prevarication.
>
>Basically because this is a discussion document, not an open letter.
>
>We had some discussion amongst a small group of kernel developers. Now
>we're opening it up to the linux community---which we can't do without
>effectively going public as well.
>
>James
Well, since this document states the general consensus quite well, and is
not likely to be edited other than crossing all the t's, I think including
them (FSF & RMS) would show them just how concerned the major developers
are with the deviciveness that the proposed V3, as worded say a month ago
the last time I read it and was appalled, will cause. You, nor the rest
of the fans of a great os, will ever be properly served.
You need to remind RMS that he is not a majority when the vote shows
otherwise by a quite resounding margin, and that he and the FSF may well
become irrevalent if the V2 is not going to be supported after V3 is
final. Let me put it this way, I would be willing to become a paying
member of a new organization dedicated to preserving the V2 status if the
due weren't too onnerous. If V3 becomes the defacto, then my membership
in the FSF will get dropped like a hot potato. I'm just one person, but
how many other paying members will do likewise? Enough to cause a serious
hurt to the FSF's finances I'd think.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett wrote:
> You need to remind RMS that he is not a majority when the vote shows
> otherwise by a quite resounding margin, and that he and the FSF may well
> become irrevalent if the V2 is not going to be supported after V3 is
> final.
Pretty much.
Also consider the "v3 probably won't be compatible with v2" license
compatibility headaches that will abound, given the number of people
that oppose GPL v3 so far.
Jeff
Ar Gwe, 2006-09-22 am 14:30 -0400, ysgrifennodd Gene Heskett:
> final. Let me put it this way, I would be willing to become a paying
> member of a new organization dedicated to preserving the V2 status if the
> due weren't too onnerous.
What probably matters more in that situation, and I hope its one that
doesn't arise - v3 is in draft and there is fixing time left for many
issues - is people to maintain the other projects which will get forked
from the FSF if it were to happen: glibc, gcc, etc. My guess is many of
these projects would effectively leave the FSF if this happened.
On Friday 22 September 2006 14:34, Jeff Garzik wrote:
>Gene Heskett wrote:
>> You need to remind RMS that he is not a majority when the vote shows
>> otherwise by a quite resounding margin, and that he and the FSF may
>> well become irrevalent if the V2 is not going to be supported after V3
>> is final.
>
>Pretty much.
>
>Also consider the "v3 probably won't be compatible with v2" license
>compatibility headaches that will abound, given the number of people
>that oppose GPL v3 so far.
>
> Jeff
>
The question then Jeff, is: Since when is this os a democracy, where there
are voting rights? The ultimate big red veto for the kernel at least, is
for Linus to stamp on it, and thats the one that many, if not all, will
follow. If the top 50 contributors were to lean on Linus to change his
mind, giving lucid arguments, he, haveing an open mind might consider it.
OTOH, given this vote tally, he'd not be foolish enough to buck that, its
a confirmation of his own feelings.
Unforch, here we all stand (0r sit), preaching to the choir, when its the
FSF and RMS we need to be subjecting to the sermon by giving them the
chapter and verse of the book we generally follow. YMMV of course.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Friday 22 September 2006 15:05, Alan Cox wrote:
>Ar Gwe, 2006-09-22 am 14:30 -0400, ysgrifennodd Gene Heskett:
>> final. Let me put it this way, I would be willing to become a paying
>> member of a new organization dedicated to preserving the V2 status if
>> the due weren't too onnerous.
>
>What probably matters more in that situation, and I hope its one that
>doesn't arise - v3 is in draft and there is fixing time left for many
>issues - is people to maintain the other projects which will get forked
>from the FSF if it were to happen: glibc, gcc, etc. My guess is many of
>these projects would effectively leave the FSF if this happened.
I'd almost place bets on that list, Alan.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
> Isn't all this complete nonsense considering that the COPYING file in
> the kernel contains the following?
>
> <-- snip -->
>
> Also note that the only valid version of the GPL as far as the kernel
> is concerned is _this_ particular version of the license (ie v2, not
> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>
> <-- snip -->
First of all, I want to congratulate the Linux kernel developers on getting
it right. I never would have imagined a near-consensus could have emerged on
an even stronger position than my own.
Second, I should point out again that it is unfortunate that Linus did not
retain for himself the exclusive right to modify the Linux kernel license.
If some real problem ever does emerge in the GPLv2 as applies to Linux, it
will be extremely difficult to resolve.
This is probably going to be controversial, but Linus should seriously
consider adding a clause that those who contribute to the kernel from now on
consent to allow him to modify the license on their current contributions
and all past contributions, amending the Linux kernel license as
appropriate. This would at least begin to reduce this problem over the next
few years, leaving fewer and fewer people with claim to less and less code
who would have legal standing to object.
I agree there is no pressing need now and the Linus is unlikely to want to
or need to change the Linux kernel license any time soon, but there could be
an issue of some kind in the next few years, and it would be nice to start
on a solution.
DS
James Bottomley wrote:
> Although this white paper was discussed amongst the full group of kernel
> developers who participated in the informal poll, as you can expect from
> Linux Kernel Developers, there was a wide crossection of opinion. This
> document is really only for discussion, and represents only the views of
> the people listed as authors (not the full voting pool).
> ----------
>
> The Dangers and Problems with GPLv3
>
>
> James E.J. Bottomley Mauro Carvalho Chehab
> Thomas Gleixner Christoph Hellwig Dave Jones
> Greg Kroah-Hartman Tony Luck Andrew Morton
> Trond Myklebust David Woodhouse
To the slashdot, LWN, etc. crowd: please re-read the first paragraph,
quoted above.
The whitepaper only represents the views of the people listed as authors.
That is distinct from the people who voted against GPL v3 in its current
form (for some or even none of the whitepaper-listed reasons).
Jeff
[ Sorry if this shows up twice - the first post to linux-kernel was
apparently eaten by an over-eager spam filter with an agenda ;^]
On Fri, 22 Sep 2006, David Schwartz wrote:
>
> This is probably going to be controversial, but Linus should seriously
> consider adding a clause that those who contribute to the kernel from now on
> consent to allow him to modify the license on their current contributions
> and all past contributions, amending the Linux kernel license as
> appropriate. This would at least begin to reduce this problem over the next
> few years, leaving fewer and fewer people with claim to less and less code
> who would have legal standing to object.
It's the last thing I'd ever want to do, for all the same reasons the
kernel doesn't have the "or later versions" language wrt licenses.
I don't actually want people to need to trust anybody - and that very much
includes me - implicitly.
I think people can generally trust me, but they can trust me exactly
because they know they don't _have_ to.
The reason the poll and the whitepaper got started was that I've obviously
not been all that happy with the GPLv3, and while I was pretty sure I was
not alone in that opinion, I also realize that _everybody_ thinks that
they are right, and that they are supported by all other right-thinking
people. That's just how people work. We all think we're better than
average.
So while I personally thought it was pretty clear that the GPLv2 was the
better license for the kernel, I didn't want to just depend on my own
personal opinion, but I wanted to feel that I had actually made my best to
ask people.
Now, I could have done it all directly on the Linux-kernel mailing list,
but let's face it, that would just have caused a long discussion and we'd
not have really been any better off anyway. So instead, I did
git log | grep -i signed-off-by: |
cut -d: -f2- | sort | uniq -c | sort -nr | less -S
which anybody else can do on their copy of their git repository, and I
just picked the first screenful of people (and Alan. And later we added
three more people after somebody pointed out that some top people use
multiple email addresses so my initial filtering hadn't counted for them
properly).
[ I also double-checked by just checking the same numbers for authorship.
I'll very openly admit to thinking that the maintainership that goes
with forwarding other peoples patches to me counts as almost as
important as the authorship itself, which is why I started out with the
signed-off-by count, but I also wanted to verify that the list of people
makes sense either way. It did. ]
In other words, maybe some people thought that the 29 names were somehow
"selected" to get that particular answer. Nope. The only selection was
just an arbitrary cut-off-point (and the fact that I think two people
didn't actually vote).
It wasn't meant to be really "definitive" - the poll was literally meant
to get _some_ kind of view into how the top developers feel. I think the
end result ended up being more definitive (just thanks to the very clear
voting pattern) than we migth have expected.
So, to anybody not on the list - don't feel bad. This was about getting a
good _feeling_ for how the top kernel maintainers - judging purely by an
admittedly fairly arbitrary, but also very neutral, measure - felt about
the license.
If the result had turned out very differently, I would probably have had
to seriously re-think my stance on the license. I don't guarantee that I
always change my mind, but I _can_ guarantee that if most of the people I
trust tell me I'm a dick-head, I'll at least give it a passing thought.
[ Chorus: "You're a dick-head, Linus" ]
Anyway, nobody got voted off the island. This was a poll, to get a view
into what people thought. Take it as such, and I think people will happily
discuss issues.
Different people had different issues with the GPLv3, so the separate
white-paper that was written was done by a different group, and is meant
for a different reason - it talks about some of the issues those
particular people wanted to point out.
My personal opinion is that a lot of the public discussion has been driven
by people who are motivated by the politics of the discussion. So you have
a lot of very vocal GPLv3 supporters. But I think that the people who
actually end up doing a lot of the development are usually not as vocal,
and haev actually not been heard very much at all.
In some sense, the poll is a way for the people who actually do a lot of
the work to show that the FSF doesn't speak for necessarily even a very
big portion of actual developers.
Linus
> On Fri, 22 Sep 2006, David Schwartz wrote:
> > This is probably going to be controversial, but Linus should seriously
> > consider adding a clause that those who contribute to the
> > kernel from now on
> > consent to allow him to modify the license on their current
> > contributions
> > and all past contributions, amending the Linux kernel license as
> > appropriate. This would at least begin to reduce this problem
> > over the next
> > few years, leaving fewer and fewer people with claim to less
> > and less code
> > who would have legal standing to object.
> It's the last thing I'd ever want to do, for all the same reasons the
> kernel doesn't have the "or later versions" language wrt licenses.
> I don't actually want people to need to trust anybody - and that
> very much includes me - implicitly.
> I think people can generally trust me, but they can trust me exactly
> because they know they don't _have_ to.
Yeah, I see your point. However, what happens if three years from now, there
is some reason that the Linux kernel license really does need to be changed
to fix a serious problem? We're basically just screwed.
While it is true that people don't have to trust you now. They do have to
trust/hope that there won't come a future time when some license problem or
change in law significantly impairs their ability to use Linux.
I can think of procedural safeguards against the "Linus sells out" or "Linus
goes insane" potential problems, but I don't have a perfect solution. I'm
not even sure I have a good one, other than hoping there never is such a
problem and/or that there's some good way to deal with one should one arise.
Suppose hypothetically GPLv3 had been really, really good and there was a
general consensus that it would provide siginficant benefits if it could be
applied to Linux. It might be nice to be able to apply it.
DS
On Fri, 22 Sep 2006, David Schwartz wrote:
>
> I can think of procedural safeguards against the "Linus sells out" or "Linus
> goes insane" potential problems, but I don't have a perfect solution.
I don't think one exists.
The thing is, there's an entirely non-legal reason to never do something
like that, namely just the psychology of the thing.
Licenses are important for legal reasons (because problems can arise), but
I would say that licenses are even *more* important as to how developers
see them.
And I know that I'm personally very much turned off by any license that
grants any particular party any special powers. It doesn't matter _how_
much I respect or trust the party in question, I wouldn't want to use that
license.
So any license wording that said that I have any special powers would, I'm
sure, alienate a large portion of the people who matter - the developers.
So the thing is, we're _much_ better off with nobody that firmly "in
charge", over the alternative. Everybody feels safer. Nobody needs to
worry about me or anybody else suddenly going crazy.
Remember: the perfect is the enemy of the good. Asking for things that are
perfect "in theory" usually just results in things that are horrible "in
practice".
So not having anybody in charge could _in_theory_ cause problems. But
_in_practice_ it's a hell of a lot better than somebody that people need
to worry about.
Linus
> However, what happens if three years from now, ...
Yes - the asteroid may destroy us all. But the greater, almost
inevitable, risk comes from the centralization of too much power.
Once an authority exists to unilaterally impose a license change on
Linux, it becomes like the ring in The Lord of the Rings, a thing of
evil potential.
Best not to create the ring in the first place.
Besides, I suspect my company's lawyer might discourage me from
submitting patches to the kernel if its license could be unilaterally
changed by some third party, whether Linus or even the esteemed David S.
To the top 30 maintainers who performed this GPLv3 analysis - nice job.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
Linus Torvalds wrote:
> [ Sorry if this shows up twice - the first post to linux-kernel was
> apparently eaten by an over-eager spam filter with an agenda ;^]
>
> On Fri, 22 Sep 2006, David Schwartz wrote:
>> This is probably going to be controversial, but Linus should seriously
>> consider adding a clause that those who contribute to the kernel from now on
>> consent to allow him to modify the license on their current contributions
>> and all past contributions, amending the Linux kernel license as
>> appropriate. This would at least begin to reduce this problem over the next
>> few years, leaving fewer and fewer people with claim to less and less code
>> who would have legal standing to object.
>
> It's the last thing I'd ever want to do, for all the same reasons the
> kernel doesn't have the "or later versions" language wrt licenses.
>
> I don't actually want people to need to trust anybody - and that very much
> includes me - implicitly.
>
> I think people can generally trust me, but they can trust me exactly
> because they know they don't _have_ to.
>
> The reason the poll and the whitepaper got started was that I've obviously
> not been all that happy with the GPLv3, and while I was pretty sure I was
> not alone in that opinion, I also realize that _everybody_ thinks that
> they are right, and that they are supported by all other right-thinking
> people. That's just how people work. We all think we're better than
> average.
>
> So while I personally thought it was pretty clear that the GPLv2 was the
> better license for the kernel, I didn't want to just depend on my own
> personal opinion, but I wanted to feel that I had actually made my best to
> ask people.
Regarding the GPLv2 vs v3 debate, i don't think anyone is in favour of a
different view, but ..
> Now, I could have done it all directly on the Linux-kernel mailing list,
> but let's face it, that would just have caused a long discussion and we'd
> not have really been any better off anyway. So instead, I did
>
> git log | grep -i signed-off-by: |
> cut -d: -f2- | sort | uniq -c | sort -nr | less -S
When applied to subsystems, the patch author "A" applies his/her patch
to the repo, the MAINTAINER cherry picks the patches for submitting to
the kernel.
In such a case, it becomes,
Signed-off-by: A
Signed-off-by: MAINTAINER
in a subsystem there are indeed many contributors, eventually it is indeed
Signed-off-by: "x"
Signed-off-by: MAINTAINER
So it is indeed incorrect to term that the MAINTAINER is the most
popular Contributor, because the CONTRIBUTOR is the PATCH AUTHOR
himself, not the MAINTAINER.
Manu
>
>Second, I should point out again that it is unfortunate that Linus did not
>retain for himself the exclusive right to modify the Linux kernel license.
>If some real problem ever does emerge in the GPLv2 as applies to Linux, it
>will be extremely difficult to resolve.
>
Easy to resolve, but difficult to implement:
remove the offending code (and rewrite).
>This is probably going to be controversial, but Linus should seriously
>consider adding a clause that those who contribute to the kernel from
>now on consent to allow him to modify the license on their current
>contributions and all past contributions, amending the Linux kernel
>license as appropriate.
Now that you raise it: I think developers can already have done that
if they wish - properly name author and conditions who may possibly
change the license to what. Not that I have seen such code yet, but you
never know.
Jan Engelhardt
--
* James Bottomley:
> Further, the FSF's attempts at drafting and re-drafting these
> provisions have shown them to be a nasty minefield which keeps ensnaring
> innocent and beneficial uses of encryption and DRM technologies so, on such
> demonstrated pragmatic ground, these clauses are likewise dangerous and
> difficult to get right and should have no place in a well drafted update to
> GPLv2.
There is a very simple litmus test for DRM code: code that cannot be
altered or removed, according to applicable law or other agreements.
The GPLv3 could forbid the addition of such code to a covered code
base, I suppose. However, this runs contrary to the DRM-like optional
clauses in the GPLv3 (mandatory access through sources over a
communication channel, certain forms of copyright notices).
I think several of these optional clauses are bad. Even the copyright
notices can be annoying (although it's already in GPLv2). For
instance, if I run
emacs somefile.c
from the command line, somefile.c doesn't show up on in the editor,
but the copyright notice. Of course, you can put
(defun display-splash-screen () (interactive))
in a startup file, but if you do this as a distributor, it might be a
GPLv2 violation.
On Fri, 22 Sep 2006, David Schwartz wrote:
>
> This is probably going to be controversial, but Linus should seriously
> consider adding a clause that those who contribute to the kernel from now on
> consent to allow him to modify the license on their current contributions
> and all past contributions, amending the Linux kernel license as
> appropriate. This would at least begin to reduce this problem over the next
> few years, leaving fewer and fewer people with claim to less and less code
> who would have legal standing to object.
It's the last thing I'd ever want to do, for all the same reasons the
kernel doesn't have the "or later versions" language wrt licenses.
I don't actually want people to need to trust anybody - and that
very much includes me - implicitly.
I think people can generally trust me, but they can trust me exactly
because they know they don't _have_ to.
The reason the poll and the whitepaper got started was that I've obviously
not been all that happy with the GPLv3, and while I was pretty sure I was
not alone in that opinion, I also realize that _everybody_ thinks that
they are right, and that they are supported by all other right-thinking
people. That's just how people work. We all think we're better than
average.
So while I personally thought it was pretty clear that the GPLv2 was the
better license for the kernel, I didn't want to just depend on my own
personal opinion, but I wanted to feel that I had actually made my best to
ask people.
Now, I could have done it all directly on the Linux-kernel mailing list,
but let's face it, that would just have caused a long discussion and we'd
not have really been any better off anyway. So instead, I did
git log | grep -i signed-off-by: |
cut -d: -f2- | sort | uniq -c | sort -nr | less -S
which anybody else can do on their copy of their git repository, and I
just picked the first screenful of people (and Alan. And later we added
three more people after somebody pointed out that some top people use
multiple email addresses so my initial filtering hadn't counted for them
properly).
[ I also double-checked by just checking the same numbers for authorship.
I'll very openly admit to thinking that the maintainership that goes
with forwarding other peoples patches to me counts as almost as
important as the authorship itself, which is why I started out with the
signed-off-by count, but I also wanted to verify that the list of people
makes sense either way. It did. ]
In other words, maybe some people thought that the 29 names were somehow
"selected" to get that particular answer. Nope. The only selection was
just an arbitrary cut-off-point (and the fact that I think two people
didn't actually vote).
It wasn't meant to be really "definitive" - the poll was literally meant
to get _some_ kind of view into how the top developers feel. I think the
end result ended up being more definitive (just thanks to the very clear
voting pattern) than we migth have expected.
So, to anybody not on the list - don't feel bad. This was about getting a
good _feeling_ for how the top kernel maintainers - judging purely by an
admittedly fairly arbitrary, but also very neutral, measure - felt about
the license.
If the result had turned out very differently, I would probably have had
to seriously re-think my stance on the license. I don't guarantee that I
always change my mind, but I _can_ guarantee that if most of the people I
trust tell me I'm a dick-head, I'll at least give it a passing thought.
[ Chorus: "You're a dick-head, Linus" ]
Anyway, nobody got voted off the island. This was a poll, to get a view
into what people thought. Take it as such, and I think people will happily
discuss issues.
Different people had different issues with the GPLv3, so the separate
white-paper that was written was done by a different group, and is meant
for a different reason - it talks about some of the issues those
particular people wanted to point out.
My personal opinion is that a lot of the public discussion has been driven
by people who are motivated by the politics of the discussion. So you have
a lot of very vocal GPLv3 supporters. But I think that the people who
actually end up doing a lot of the development are usually not as vocal,
and haev actually not been heard very much at all.
In some sense, the poll is a way for the people who actually do a lot of
the work to show that the FSF doesn't speak for necessarily even a very
big portion of actual developers.
Linus
On 2006-09-22, Linus Torvalds <[email protected]> wrote:
>
> On Fri, 22 Sep 2006, David Schwartz wrote:
>>
>> This is probably going to be controversial, but Linus should seriously
[...]
>
> I don't actually want people to need to trust anybody - and that very much
> includes me - implicitly.
>
> I think people can generally trust me, but they can trust me exactly
> because they know they don't _have_ to.
And somebody chooses anoter license, f.e see:
linux/drivers/video/aty/radeon_base.c
>
> Now, I could have done it all directly on the Linux-kernel mailing list,
> but let's face it, that would just have caused a long discussion and we'd
> not have really been any better off anyway. So instead, I did
>
> git log | grep -i signed-off-by: |
> cut -d: -f2- | sort | uniq -c | sort -nr | less -S
>
> which anybody else can do on their copy of their git repository, and I
> just picked the first screenful of people (and Alan. And later we added
> three more people after somebody pointed out that some top people use
Alan *is on top* of (old fashioned, gitless):
$ for i in `find linux/drivers/`
do dd count=1 <$i | grep @ | sed 's_[^<]*<\(.*@.*\)>[^>]*_\1_g'
done | sort | uniq -c | sort -rn | most
And what about linux/CREDITS ? Creating (even in the past) is also worth.
As Adrian Bunk noted, there are may who contibuted, still CREDITS has
reasonable size. Search above && grep in CREDITS 50 / 50 from the git
logs would be better ;D.
I would, say
H. Peter Anvin, Vojtech Pavlik, Patrick Mochel, Pavel Machek
are also major contributors. Cheers, guys !
[i usually do credit search on stuff i read in the kernel, so that is IMHO]
-o--=O`C 5 years ago TT and WTC7 were assassinated.
#oo'L O Learn more how (tm) <http://911research.com>
<___=E M
> Now that you raise it: I think developers can already have done that
> if they wish - properly name author and conditions who may possibly
> change the license to what. Not that I have seen such code yet, but you
> never know.
>
> Jan Engelhardt
That's true. Nothing prevents a kernel contributor from including with his
code an offer to license that same code under different conditions. However,
the more I think about Linus' point, the more I realize how hard it is to
write such an offer that wouldn't be likely to do more harm than good.
DS
On Sat, 23 Sep 2006, Jan Engelhardt wrote:
>
> Now that you raise it: I think developers can already have done that
> if they wish - properly name author and conditions who may possibly
> change the license to what. Not that I have seen such code yet, but you
> never know.
Side note: in "git", we kind of discussed this. And because the project
was started when the whole GPL version discussion was already in bloom,
the git project has a note at top of the COPYING file that says:
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
HOWEVER, in order to allow a migration to GPLv3 if that seems like
a good idea, I also ask that people involved with the project make
their preferences known. In particular, if you trust me to make that
decision, you might note so in your copyright message, ie something
like
This file is licensed under the GPL v2, or a later version
at the discretion of Linus.
might avoid issues. But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.
but note how it's still at the discretion of the actual developers (ie
when you add a file, you can either not specify any extensions, in which
case it's "GPLv2 only", or you can specify "GPLv2 or any later", or you
can specify the "GPLv2 or any later at the discretion of Linus Torvalds".
The silly thing, of course, is that I'm not even the maintainer any more,
and that Junio has done a kick-ass job of maintaining the thing, and is
definitely the main author by now. So the whole "discretion of Linus" is a
bit insane.
[ Although exactly _because_ Junio has been such a great maintainer, I'd
bow down to whatever decision he does, so my "discretion" would be to
let him decide, if he wanted to. At some point, you have to trust some
people, and just let go - if they do more than you do, they damn well
have more rights than you do too. "Maintainership has its privileges" ]
Anyway, I suspect the git language was a mistake. We should just have done
what the kernel did - make the version number be clear and fixed, so that
people don't even have to worry about exactly what conditions might cause
a relicensing to happen.
Linus
(Quoting in full for the git@ people.)
Dear diary, on Sat, Sep 23, 2006 at 08:00:23PM CEST, I got a letter
where Linus Torvalds <[email protected]> said that...
> On Sat, 23 Sep 2006, Jan Engelhardt wrote:
> >
> > Now that you raise it: I think developers can already have done that
> > if they wish - properly name author and conditions who may possibly
> > change the license to what. Not that I have seen such code yet, but you
> > never know.
>
> Side note: in "git", we kind of discussed this. And because the project
> was started when the whole GPL version discussion was already in bloom,
> the git project has a note at top of the COPYING file that says:
>
> Note that the only valid version of the GPL as far as this project
> is concerned is _this_ particular version of the license (ie v2, not
> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>
> HOWEVER, in order to allow a migration to GPLv3 if that seems like
> a good idea, I also ask that people involved with the project make
> their preferences known. In particular, if you trust me to make that
> decision, you might note so in your copyright message, ie something
> like
>
> This file is licensed under the GPL v2, or a later version
> at the discretion of Linus.
>
> might avoid issues. But we can also just decide to synchronize and
> contact all copyright holders on record if/when the occasion arises.
>
> but note how it's still at the discretion of the actual developers (ie
> when you add a file, you can either not specify any extensions, in which
> case it's "GPLv2 only", or you can specify "GPLv2 or any later", or you
> can specify the "GPLv2 or any later at the discretion of Linus Torvalds".
>
> The silly thing, of course, is that I'm not even the maintainer any more,
> and that Junio has done a kick-ass job of maintaining the thing, and is
> definitely the main author by now. So the whole "discretion of Linus" is a
> bit insane.
>
> [ Although exactly _because_ Junio has been such a great maintainer, I'd
> bow down to whatever decision he does, so my "discretion" would be to
> let him decide, if he wanted to. At some point, you have to trust some
> people, and just let go - if they do more than you do, they damn well
> have more rights than you do too. "Maintainership has its privileges" ]
>
> Anyway, I suspect the git language was a mistake. We should just have done
> what the kernel did - make the version number be clear and fixed, so that
> people don't even have to worry about exactly what conditions might cause
> a relicensing to happen.
Actually, this didn't catch on very well anyway, I guess because most
people just know it's GPLv2 and don't even bother to peek at COPYING, we
are a bit sloppy about copyright notices and most of them don't mention
licence at all (if there are any in the file at all), and adding
explicit copyright notices to mails isn't too popular either.
$ git grep 'discretion'
COPYING: at the discretion of Linus.
git-annotate.perl:# at the discretion of Linus Torvalds.
git-relink.perl:# Later versions of the GPL at the discretion of Linus Torvalds
git-request-pull.sh:# at the discretion of Linus Torvalds.
and I've found no patches with such special assignment.
I think people don't really want to bother with thinking too much
about licences at all unless absolutely necessary, they just want to do
the fun part (coding). :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>> Side note: in "git", we kind of discussed this. And because the project
>> was started when the whole GPL version discussion was already in bloom,
>> the git project has a note at top of the COPYING file that says:
>>
>> Note that the only valid version of the GPL as far as this project
>> is concerned is _this_ particular version of the license (ie v2, not
>> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>>
>> HOWEVER, in order to allow a migration to GPLv3 if that seems like
>> a good idea, I also ask that people involved with the project make
>> their preferences known. In particular, if you trust me to make that
>> decision, you might note so in your copyright message, ie something
>> like
>>
>> This file is licensed under the GPL v2, or a later version
>> at the discretion of Linus.
>>
>
> Actually, this didn't catch on very well anyway, I guess because most
>people just know it's GPLv2 and don't even bother to peek at COPYING, we
>are a bit sloppy about copyright notices and most of them don't mention
>licence at all (if there are any in the file at all), and adding
>explicit copyright notices to mails isn't too popular either.
Would every file that does not contain an explicit license (this
excludes MODULE_LICENSE) falls under COPYING?
> $ git grep 'discretion'
> COPYING: at the discretion of Linus.
> git-annotate.perl:# at the discretion of Linus Torvalds.
> git-relink.perl:# Later versions of the GPL at the discretion of Linus Torvalds
> git-request-pull.sh:# at the discretion of Linus Torvalds.
>
>and I've found no patches with such special assignment.
Jan Engelhardt
--
On Sun, 24 Sep 2006, Jan Engelhardt wrote:
>
> Would every file that does not contain an explicit license (this
> excludes MODULE_LICENSE) falls under COPYING?
Basically, yes. There's nothing to really say that you need to state your
copyright license in every individual file, especially if those files are
only ever distributed as a whole, together with other things (which souce
code obviously is - you generally cannot even use an individual *.c file
without the infrastructure it was written for).
If a file doesn't have a license mentioned, it doesn't mean that it's
"free for all" or not copyrighted, it just means that you need to find out
what the license is some other way (and if you can't find out, you
shouldn't be copying that file ;)
Of course, for clarity, a lot of projects end up adding at least a minimal
copyright header license everywhere, just to cover their *sses. It's not
required, but maybe it avoids some confusion, especially if that file is
later copied into some other project with other basic rules (but if you
do that, you really _should_ have added the information at that point!).
Me personally, I prefer to not see huge boiler-plate licenses at the top
of the file, so that every time I open a new file I just see the dang
license that has nothing to do with why I'm opening it. So I tend to do a
fairly minimal thing ("Copyright (C) Linus Torvalds 2006" or similar) but
sometimes I drop even that (ie I personally feel silly adding a copyright
message to a header file, so I usually don't - and sometimes I just
forget about it in real source files too)..
Others are more anal^H^H^H^Hcareful, and tend to add a few lines to tell
what the license is, the ubiqutous "all rights reserved" (which is just
idiocy), and a blinking gif advertisement for their company. Oh, and the
"no warranty" clause. And an aphorism or two.
In other words, I don't think there are any real rules. Different people
and different projects have more or less different rules. If you expect to
collect treble damages in the US, you might want to add a copyright notice
just about everywhere, "just in case", and to "show you really care".
IANAL, of course.
Linus
One of the reasons I didn't end up signing the GPLv3 position statement
that James posted (and others had signed up for), was that a few weeks ago
I had signed up for writing another kind of statement entirely: not so
much about why I dislike the GPLv3, but why I think the GPLv2 is so great.
(There were other reasons too, but never mind that.)
I didn't get my fat arse off the ground on that, partly exactly because
the developer poll of "which is better" which was related to that issue
distracted me, but mostly because I just seldom write that kind of text -
one thing the kernel work has conditioned me for is that I write _replies_
to email, I seldom start threads myself (I suspect most of my emails on
linux-kernel that aren't replies are just release announcements).
However, since there was a sub-thread on groklaw about the kernel
developers opinions on the GPLv3, and since I did try to explain it there
(as a reply to postings by PJ and others), and since some of those
explanations ended up being exactly the "why the GPLv2 is so insanely
great" that I never wrote otherwise, I thought I'd just repost that
explanation as an alternative view.
So this post is kind of another way to look at the whole GPLv3 issues: not
caring so much about why the GPLv3 is worse, but a much more positive "Why
the GPLv2 is _better_". I suspect some people may have an easier time
seeing and reading that argument, since it's not as contentious.
A lot of people seem to think that the GPLv2 is showing its age, but I
would argue otherwise. Yes, the GPLv2 is "old" for being a copyright
license, but it's not even that you don't want to mess with something that
works - it's that it very fundamentally is such a good license that
there's not a whole lot of room for fixing aside from pure wording issues.
So without further ado, here's my personal "reply" to the the GPLv3
position statement. It's obviously not meant to repudiate James' text in
any way, it's just an alternate view on the same questions..
I made other posts in the same thread on Groklaw thread, not as positive,
and not perhaps as worthy and quotable. This one may be a bit out of
context, but I do think it stands on its own, and you can see the full
thread in the "GPL Upheld in Germany Against D-Link" discussions on
Groklaw. The particular sub-thread was on what happens since we can't
easily change update the license, called "So What is the Future Then?"
(I'd like to point to the groklaw posts, but there doesn't seem to be any
way to point to a particular comment without getting "The URL from Hell",
so it's easier to just duplicate it here).
Linus
---
And thus spake PJ in response:
"GPLv2 is not compatible with the Apache license. It doesn't cover
Bitstream. It is ambiguous about web downloads. It allows Tivo to
forbid modification. It has no patent protection clause. It isn't
internationally useful everywhere, due to not matching the terms of
art used elsewhere. It has no DMCA workaround or solution. It is
silent about DRM."
Exactly!
That's why the GPLv2 is so great. Exactly because it doesn't bother or
talk about anything else than the very generic issue of "tit-for-tat".
You see it as a failure. I see it as a huge advantage. The GPLv2 covers
the only thing that really matters, and the only thing that everybody can
agree on ("tit-for-tat" is really something everybody understands, and
sees the same way - it's totally independent of any moral judgement and
any philosophical, cultural or economic background).
The thing is, exactly because the GPLv2 is not talking about the details,
but instead talks entirely about just a very simple issue, people can get
together around it. You don't have to believe in the FSF or the tooth
fairy to see the point of the GPLv2. It doesn't matter if you're black or
white, commercial or non-commercial, man or woman, an individual or a
corporation - you understand tit-or-tat.
And that's also why legal details don't matter. Changes in law won't
change the notion of "same for same". A change of language doesn't change
"Quid pro quo". We can still say "quid pro quo" two thousand years later,
in a language that has been dead for centuries, and the saying is still
known by any half-educated person in the world.
And that's exactly because the concept is so universal, and so
fundamental, and so basic.
And that is why the GPLv2 is a great license.
I can't stress that enough. Sure, other licenses can say the same thing,
but what the GPLv2 did was to be the first open-source license that made
that "tit-for-tat" a legal license that was widely deployed. That's
something that the FSF and rms should be proud of, rather than trying to
ruin by adding all these totally unnecessary things that are ephemeral,
and depend on some random worry of the day.
That's also why I ended up changing the kernel license to the GPLv2. The
original Linux source license said basically: "Give all source back, and
never charge any money". It took me a few months, but I realized that the
"never charge any money" part was just asinine. It wasn't the point.
The point was always "give back in kind".
Btw, on a personal note, I can even tell you where that "never charge any
money" requirement came from. It came from my own frustrations with Minix
as a poor student, where the cost of getting the system ($169 USD back
then) was just absolutely prohibitive. I really disliked having to spend
a huge amount of money (to me) for something that I just needed to make my
machine useful.
In other words, my original license very much had a "fear and loathing"
component to it. It was exactly that "never charge any money" part. But I
realized that in the end, it was never really about the money, and that
what I really looked for in a license was the "fairness" thing.
And that's what the GPLv2 is. It's "fair". It asks everybody -
regardless of circumstance - for the same thing. It asks for the effort
that was put into improving the software to be given back to the common
good. You can use the end result any way you want (and if you want to use
it for "bad" things, be my guest), but we ask the same exact thing of
everybody - give your modifications back.
That's true grace. Realizing that the petty concerns don't matter,
whether they are money or DRM, or patents, or anything else.
And that's why I chose the GPLv2. I did it back when the $169 I paid for
Minix still stung me, because I just decided that that wasn't what it was
all about.
And I look at the additions to the GPLv3, and I still say: "That's not
what it's all about".
My original license was petty and into details. I don't need to go back
to those days. I found a better license. And it's the GPLv2.
Linus
Hi Linus,
On Sun, Sep 24, 2006 at 07:44:59PM -0700, Linus Torvalds wrote:
[...]
> And thus spake PJ in response:
> "GPLv2 is not compatible with the Apache license. It doesn't cover
> Bitstream. It is ambiguous about web downloads. It allows Tivo to
> forbid modification. It has no patent protection clause. It isn't
> internationally useful everywhere, due to not matching the terms of
> art used elsewhere. It has no DMCA workaround or solution. It is
> silent about DRM."
>
> Exactly!
>
> That's why the GPLv2 is so great. Exactly because it doesn't bother or
> talk about anything else than the very generic issue of "tit-for-tat".
>
> You see it as a failure. I see it as a huge advantage. The GPLv2 covers
> the only thing that really matters, and the only thing that everybody can
> agree on ("tit-for-tat" is really something everybody understands, and
> sees the same way - it's totally independent of any moral judgement and
> any philosophical, cultural or economic background).
>
> The thing is, exactly because the GPLv2 is not talking about the details,
> but instead talks entirely about just a very simple issue, people can get
> together around it. You don't have to believe in the FSF or the tooth
> fairy to see the point of the GPLv2. It doesn't matter if you're black or
> white, commercial or non-commercial, man or woman, an individual or a
> corporation - you understand tit-or-tat.
[...]
> That's also why I ended up changing the kernel license to the GPLv2. The
> original Linux source license said basically: "Give all source back, and
> never charge any money". It took me a few months, but I realized that the
> "never charge any money" part was just asinine. It wasn't the point.
> The point was always "give back in kind".
[...]
> And that's what the GPLv2 is. It's "fair". It asks everybody -
> regardless of circumstance - for the same thing. It asks for the effort
> that was put into improving the software to be given back to the common
> good. You can use the end result any way you want (and if you want to use
> it for "bad" things, be my guest), but we ask the same exact thing of
> everybody - give your modifications back.
>
> That's true grace. Realizing that the petty concerns don't matter,
> whether they are money or DRM, or patents, or anything else.
>
> And that's why I chose the GPLv2. I did it back when the $169 I paid for
> Minix still stung me, because I just decided that that wasn't what it was
> all about.
>
> And I look at the additions to the GPLv3, and I still say: "That's not
> what it's all about".
>
> My original license was petty and into details. I don't need to go back
> to those days. I found a better license. And it's the GPLv2.
That's an interesting analysis, and it somehow reflects one I had to
do a few months back. After all the fuss about binary-only modules
incompatibility with GPLv2, I wanted to change the license of haproxy
to explicitly permit external binary-only code to be linked with it. It's
a TCP/HTTP load balancer and people might sometimes have to implement
algorithms under NDA for specific protocols, and I don't want to have
to decide for them if it is the right tool for them or not. I don't
either want to force them to release their code if I don't use it and
if nobody has contributed to it. I just wanted them to give back any
change they bring to the core.
I spend a full week-end reading other licenses, and many others looked
appealing but added specific clauses for patents, DRM, etc... which were
too restrictive for the end user. Others in turn did not make provisions
for feedback. I finally gave up, and decided that the GPLv2 was definitely
the best one for the job. I only changed all the interfacing headers to
LGPL and added a note to explicitly state that my intent was to allow
people to write binary-only modules as long as they gave back their
fixes or work on the core system they use.
As a result, developers are free to choose how they work, and the type
of contribution they expect from others, but they must respect the
work of others. *That* is what I consider fair use.
Just my 2 cents,
Willy
>> Would every file that does not contain an explicit license (this
>> excludes MODULE_LICENSE) falls under COPYING?
>
>[...]
>If a file doesn't have a license mentioned, it doesn't mean that it's
>"free for all" or not copyrighted, it just means that you need to find out
>what the license is some other way (and if you can't find out, you
>shouldn't be copying that file ;)
>
>Of course, for clarity, a lot of projects end up adding at least a minimal
>copyright header license everywhere, just to cover their *sses. It's not
>required, but maybe it avoids some confusion, especially if that file is
>later copied into some other project with other basic rules (but if you
>do that, you really _should_ have added the information at that point!).
>[...]
Though I strongly agree with you, some GNU folks (such as
savannah.nongnu.org) seem to explicitly require it, even for files
that do not make up a single program (i.e. like coreutils/ls.c).
Jan Engelhardt
--
I have to say for wht it's worth that you did an excellent job of
stating a very well reasons position on GPL3 and laid out in good detail
the problems and consequences in a logical manner.
James Bottomley wrote:
> Although this white paper was discussed amongst the full group of kernel
> developers who participated in the informal poll, as you can expect from
> Linux Kernel Developers, there was a wide crossection of opinion. This
> document is really only for discussion, and represents only the views of
> the people listed as authors (not the full voting pool).
>
> James
>
> ----------
>
> The Dangers and Problems with GPLv3
>
>
> James E.J. Bottomley Mauro Carvalho Chehab
> Thomas Gleixner Christoph Hellwig Dave Jones
> Greg Kroah-Hartman Tony Luck Andrew Morton
> Trond Myklebust David Woodhouse
>
> 15 September 2006
> Abstract
>
> This document is a position statement on the GNU General Public
> License version 3 (in its current Draft 2 form) and its surrounding
> process issued by some of the Maintainers of the Linux Kernel
> speaking purely in their role as kernel maintainers. In no regard
> should any opinion expressed herein be construed to represent the
> views of any entities employing or being associated with any of the
> authors.
>
> 1 Linux and GPLv2
>
> Over the past decade, the Linux Operating System has shown itself to be far
> and away the most successful Open Source operating system in history.
> However, it certainly wasn't the first such open source operating system
> and neither is it currently the only such operating system. We believe that
> the pre-eminent success of Linux owes a great part to the dynamism and
> diversity of its community of contributors, and that one of the catalysts
> for creating and maintaining this community is the development contract as
> expressed by GPLv2.
>
> ...<SNIP>....
>
> 6 Conclusions
>
> The three key objections noted in section 5 are individually and
> collectively sufficient reason for us to reject the current licence
> proposal. However, we also note that the current draft with each of the
> unacceptable provisions stripped out completely represents at best marginal
> value over the tested and proven GPLv2. Therefore, as far as we are
> concerned (and insofar as we control subsystems of the kernel) we cannot
> foresee any drafts of GPLv3 coming out of the current drafting process that
> would prove acceptable to us as a licence to move the current Linux Kernel
> to.
>
> Further, since the FSF is proposing to shift all of its projects to
> GPLv3 and apply pressure to every other GPL licensed project to move, we
> foresee the release of GPLv3 portends the Balkanisation of the entire Open
> Source Universe upon which we rely. This Balkanisation, which will be
> manifested by distributions being forced to fork various packages in order
> to get consistent licences, has the potential to inflict massive collateral
> damage upon our entire ecosystem and jeopardise the very utility and
> survival of Open Source. Since we can see nothing of sufficient value in
> the current drafts of the GPLv3 to justify this terrible cost, we can only
> assume the FSF is unaware of the current potential for disaster of the
> course on which is has embarked. Therefore, we implore the FSF to
> re-examine the consequences of its actions and to abandon the current GPLv3
>
For what it's worth, i support RMS and his fight for free software fully.
I support the current draft of the GPL version 3 and am very dissapointed
it will not be adopted as is. IMHO, Linux has the power and influence
to move mountains in the software industry, and shouldn't shy away from
the opportunity to take moral responsibility when it arises.
What is the stance of the developer team / kernel maintainers on DRM,
Trusted Computing and software patents? Does the refusal to adopt GPLv3 as
is mean that these two are more likely to emerge as supported functionality
in the Linux kernel? Are there any moral boundaries Linux kernel developers
will not cross concerning present and new U.S. laws on technology? Are they
willing to put that in writing? Will Linux support HD-DVD and BluRay by
being slightly more tolerant to closed source binary blobs? What about
the already existant problems with the Content Scrambling System for
DVD's?
Finally, i hope that the wishes of the community of people that have only
contributed to the kernel a few times but whose combined work may equal that
of the core developers, are taken into account; as well as the wishes of
the massive amount of users of the Linux kernel.
How about a public poll?
Regards, Michiel de Boer
On Mon, Sep 25, 2006 at 10:53:14AM +0200, Michiel de Boer wrote:
> For what it's worth, i support RMS and his fight for free software fully.
> I support the current draft of the GPL version 3 and am very dissapointed
> it will not be adopted as is.
Let me stop you there. The kernel has had far too many contributors
submit code under "GPLv2 only" to allow it to be universally relicensed
as GPLv3, even if we _wanted_ to do that.
So the question about adoption of GPLv3 is largely irrelevant for the
kernel.
If you think otherwise, please seek expert legal advice.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
James,
Thanks for posting this. It's obviously had a lot of thought go into
it.
I do think there are a few flaws in the arguments however. The biggest
one for me can be summed up in the question "which license better
represents the intention of the GPLv2 in the current world?"
When the GPLv2 was drafted it wasn't a legal document in a vacuum. It
came with a preamble that stated its intentions, and it came with
someone who toured the world explaining the intentions and
motivations. There were even plenty of repeat performances for anyone
who wanted to attend :-)
I think the GPLv3 does a better job of expressing legally those
intentions than GPLv2 did. In particular this part of the v2 preamble:
"For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights
that you have."
I think that recent developments (such as TiVo v2) have shown that
companies have found ways to give recipients less rights then they
have themselves.
So I think the parts of the position statement that talk about the
importance of the 'development contract as expressed/represented by
GPLv2' and the implication that this contract would be violated by the
current GPLv3 draft are not accurate. That development contract came
with a clear explanation (or at least it seems clear to me).
Similarly, the position statement states:
"This in turn is brought about by a peculiar freedom enshrined in the
developer contract as represented by GPLv2, namely the freedom from
binding the end use of the project."
but I think this particular 'freedom' comes more from the development
conventions of the Linux kernel community than from the GPLv2. I don't
see anything in the GPLv2 that actually tried to enshrine that
particular freedom. That doesn't mean it isn't a worthwhile thing to
enshrine, I just think it is inaccurate to claim that the GPLv2
attempts in any way to enshrine it.
Linus clearly values this freedom very highly, as I'm sure many kernel
developers do. So for those people the GPLv2 license may better
represent their own intentions.
For myself, I value other things more highly. One of the most
important aspects of the GPL for me is the equality between vendors
and recipients of software. I really like the symmetry between giver
and receiver, and the fact that this symmetry is passed on down the
chain, so that someone ten steps away from me as an author ends up
with the same rights that I had.
(There is an exception to this. The copyright holder is the only one
who can sue over a violation of the license, so that is an asymmetry,
but I think it is an essential asymmetry and prevents chaos. When
faced with a GPL violation of my code I have almost always chosen to
work with the violator to bring them into compliance, whereas if
anyone could sue then we'd see lawsuits far too often)
One result of this symmetry is that most GPLd software is 'free as in
beer' as well as 'free as in freedom'. If someone were to start
charging outrageous prices for GPLd software then someone else will
come along and sell it cheaper. That drives down the price to a
reasonable level.
I like the fact that I was able to distribute useful patches for the
kernel in TiVo v1. I didn't like the fact that I had to work around
the binary kernel modules used by TiVo, but I didn't complain too
loudly partly because it was a nice challenge to work around the
problem. I was delighted when TiVo incorporated some of my changes (in
particular a new driver) into their future releases. That was the GPL
working.
With v2 TiVo introduces something which had the potential to make that
impossible, at least for me. Thankfully they didn't get it quite
right, but it certainly made me aware that the symmetry I had been
taking for granted in the GPL was under threat.
So for me this symmetry is more important than the loss of the 'end
users can do what they want' freedom. From my point of view, that
freedom was never part of the 'contract' I had with the FSF, but the
symmetry freedom was, and thus I think the FSF has done well in fixing
a hole in the GPLv2 license.
Finally, I'm curious as to the legal basis of this statement:
> As drafted, this currently looks like it would potentially jeopardise the
> entire patent portfolio of a company simply by the act of placing a GPLv3
> licensed programme on their website.
I can't see anything in the current GPLv3 draft which would do
that. Could you explain how that comes about?
Cheers, Tridge
On Monday September 25, [email protected] wrote:
>
> For what it's worth, i support RMS and his fight for free software fully.
> I support the current draft of the GPL version 3 and am very dissapointed
> it will not be adopted as is. IMHO, Linux has the power and influence
> to move mountains in the software industry, and shouldn't shy away from
> the opportunity to take moral responsibility when it arises.
I think that would be against the character of Linux. Linux has
always been primarily about technology and community rather than
freedom. Doing something to improve the technology or enable the
community would be very in-character. Doing something in the name of
freedom would not.
Is that a reasonable position to take? Well, maybe.
There are (at least) two ways to change unpleasant behaviour in
others. One is through legislation. The other is through making the
pleasant behaviour more attractive.
Legislation is short term, but makes things black-and-white (or, in
the case of grey areas, very expensive).
Rewarding good behaviour is a much slower process, but deals with gray
areas much more effectively.
I think it is clear that we need a balance.
The 'legislation' of GPLv2 plus the economic benefit of hundreds of
developers have been an effective 2-prong attack to encourage people
to share their software. This has been self re-enforcing. The more
people see the benefit, the more people seem to get involved.
So Linux has done a lot for freedom by focussing on technology.
So the question is: has the balance swung far enough the wrong way to
make a change in legislation necessary?
The 'DRM' provision of the proposed GPLv3 seem to be being driven by 1
company - Tivo. Yes, what they are doing is against our spirit of
freedom. But is it enough to justify changing the legislation? Or
would that be 'the tail wagging the dog'??
The 'patent' provisions are - to me - more defensible than the DRM
provisions (fewer grey areas). But are they an actual problem, or
just a potential problem?
The GPLv2 was written based on experience of people taking code and
giving nothing back. Based on quite a lot of (unpleasant) experience,
a very effective measure was developed to combat it.
Do we have the same amount of experience with the problems that the
GPLv3 is supposed to fix? If not, fixing now might be a bit premature
and may lead to unwanted side effects.
But maybe I am just misinformed. Maybe there are dozens of different
manufacturers making devices that use DRM to prohibit freedom despite
using GPL code, and maybe there are hundreds of submarine patents
owned by distributors of GPL code and embodied in that code that the
owners are going to start suing us overs.... Is there a list of these
somewhere?
>
> What is the stance of the developer team / kernel maintainers on DRM,
While I cannot speak for other developers (and sometimes have trouble
speaking for myself), one stance I have often heard is that DRM is
simply a tool - one that is largely based on cryptography which is
just another tool. They can have good uses and bad uses just like the
TCP/IP stack (think 'spam'). So code to implement then would (if of
suitable quality) be allowed into the kernel. If you want to make DRM
illegal, speak to your member-of-parliament, not your code developers.
> Trusted Computing and software patents? Does the refusal to adopt GPLv3 as
> is mean that these two are more likely to emerge as supported functionality
> in the Linux kernel? Are there any moral boundaries Linux kernel developers
> will not cross concerning present and new U.S. laws on technology? Are they
> willing to put that in writing? Will Linux support HD-DVD and BluRay by
> being slightly more tolerant to closed source binary blobs? What about
> the already existant problems with the Content Scrambling System for
> DVD's?
Tolerance of binary blogs seems to be steadily dropping.
As far as I can tell, the DVD-CSS is purely a legal issue today - the
technical issues are solved (I can watch any-region on my Linux
computer, and in Australia, the law requires that all DVD players must
ignore region encoding as it is an anti-competitive practice).
How HD-DVD and BluRay will work on Linux is yet to be seen, but I
seriously doubt that anything in the GPLvX would have much effect on
the outcome. The greater effect would come from people writing to
their congress-person and voting with their wallet.... or just
reverse-engineering the technology:-)
>
> Finally, i hope that the wishes of the community of people that have only
> contributed to the kernel a few times but whose combined work may equal that
> of the core developers, are taken into account; as well as the wishes of
> the massive amount of users of the Linux kernel.
This isn't about anyone's wishes. The kernel is GPLv2 only and that is not
going to change - arguably is cannot change.
This is about a group of developers giving an opinion. If others
agree, it might become an argument that the FSF will choose to allow
to affect their policy making (rather than thinking it is just Linus
raving as usual). If no-one agrees, it will remain the opinion of a
few, with all the lack of force that implies.
>
> How about a public poll?
We've all see the sort of politician that get into government on the
back of a public poll... Do you really think a public poll would
provide a useful result :-)
NeilBrown
Ar Llu, 2006-09-25 am 20:51 +1000, ysgrifennodd Neil Brown:
> The 'DRM' provision of the proposed GPLv3 seem to be being driven by 1
> company - Tivo. Yes, what they are doing is against our spirit of
Actually quite a few companies have done this, and in some cases have
been involved in out of court settlements over that kind of abuse.
Let's be clear about this. The GPLv2 covers the scripts etc for
installation. The DRM keys are probably covered, and out of court
settlements lend weight to that. It has always been my publically stated
position that I reserve the right to sue anyone who uses my code and
locks it away with keys.
The GPLv3 rewords it in an attempt to be clearer but also I think rather
more over-reaching. It's not clear what for example happens with a
rented device containing GPL software but with DRM on the hardware.
Thats quite different to owned hardware. GPLv2 leaves it open for the
courts to make a sensible decision per case, GPLv3 tries to define it in
advance and its very very hard to define correctly.
Alan
>
> What is the stance of the developer team / kernel maintainers on
> DRM, Trusted Computing and software patents? Does the refusal to
> adopt GPLv3 as is mean that these two are more likely to emerge as
> supported functionality in the Linux kernel? Are there any moral
> boundaries Linux kernel developers will not cross concerning
> present and new U.S. laws on technology? Are they willing to put
> that in writing? Will Linux support HD-DVD and BluRay by being
> slightly more tolerant to closed source binary blobs? What about
> the already existant problems with the Content Scrambling System
> for DVD's?
I agree with Neil here. Supporting HD-DVD/BluRay/Other will probably
"as simple" as integrating DVD support into the CD-only source code
back when DVDs where introduced was.
I suppose that HD-DVD drives will use the same ATAPI/SATA commands as
DVD drives do (plus/minus the regular extras). In other words: Data
read from the drive arrives as bytes that are ready to be parsed
according to struct toc / whatever. There is no kernel-level
translation required right now (at least it looks that way), and to
watch a CSS-encrypted video, you need some extra userspace software
to do so. I do not see why HD-DVD/BR should suddenly require a
kernel-level CSS/Other decryptor... or did I miss something and
Windows had a kernel-level deCSS all the time?
> Finally, i hope that the wishes of the community of people that have only
> contributed to the kernel a few times but whose combined work may equal that
> of the core developers, are taken into account; as well as the wishes of
> the massive amount of users of the Linux kernel.
>
> How about a public poll?
Jan Engelhardt
--
On Mon, 2006-09-25 at 06:40 +0200, Willy Tarreau wrote:
> do a few months back. After all the fuss about binary-only modules
> incompatibility with GPLv2, I wanted to change the license of haproxy
> to explicitly permit external binary-only code to be linked with it.
LGPL is then a logical and commonly accepted choice for a license
On Mon, Sep 25, 2006 at 02:00:05PM +0200, Arjan van de Ven wrote:
> On Mon, 2006-09-25 at 06:40 +0200, Willy Tarreau wrote:
> > do a few months back. After all the fuss about binary-only modules
> > incompatibility with GPLv2, I wanted to change the license of haproxy
> > to explicitly permit external binary-only code to be linked with it.
>
> LGPL is then a logical and commonly accepted choice for a license
Not exactly, because I don't want people to include interesting parts
of my code into their binary-only programs. I just want to allow
people to link binary-only modules with my program. However, programs
that are already GPLv2 are welcome to steal part of my code.
Regards,
Willy
On Mon, 2006-09-25 at 10:53 +0200, Michiel de Boer wrote:
> For what it's worth, i support RMS and his fight for free software fully.
> I support the current draft of the GPL version 3 and am very dissapointed
> it will not be adopted as is. IMHO, Linux has the power and influence
> to move mountains in the software industry, and shouldn't shy away from
> the opportunity to take moral responsibility when it arises.
Well ... as Russell already pointed out; adopting GPLv3 was made
incredibly difficult for us by the FSF. We could easily adopt a GPLv2
compatible licence simply by going through some sort of process to
secure agreement and then altering the COPYING file of the kernel (the
point being that past contributions would still be v2, future
contributions would be the new licence and there's no distribution
problem because they're compatible).
There are definite bug fixes to v2 in the v3 draft: Bittorrent and
termination. However, we could adopt those in a v2 compatible fashion
(as additional permissions). Additionally, it does strike me that a
patent grant could be formulated in a v2 compatible manner if people
agreed on it. Obviously, the additional restrictions of v3 is
completely impossible to accommodate in a v2 compatible manner. The DRM
provisions could be disputed: if you believe they're already in v2, then
they could be adopted in a v2 compatible fashion as a clarification ...
however, they'd have to be quite a bit less broad than the current v3
language.
All in all, we could probably only switch to v3 by some type of
universal acclamation process, which, with 28 votes against already
isn't really likely.
James
On Mon, 2006-09-25 at 20:51 +1000, Neil Brown wrote:
> Tolerance of binary blogs seems to be steadily dropping.
>
> As far as I can tell, the DVD-CSS is purely a legal issue today - the
> technical issues are solved (I can watch any-region on my Linux
> computer, and in Australia, the law requires that all DVD players must
> ignore region encoding as it is an anti-competitive practice).
Tolerance by who? As far as I can tell tolerance for binary blobs by
the typical Linux desktop user is higher than ever. They consider it a
bug if their distro does not automagically install the nvidia/ATI
drivers, and immediately write you off as a GPL zealot if you even
mention that a tainted kernel cannot be debugged.
Lee
On Mon, 25 Sep 2006, Jan Engelhardt wrote:
>
> Though I strongly agree with you, some GNU folks (such as
> savannah.nongnu.org) seem to explicitly require it, even for files
> that do not make up a single program (i.e. like coreutils/ls.c).
Each project obviously has its own rules. The kernel, in many ways, these
days does something even stronger, in the sense that we now ask not that
every file be marked, but each and every change be signed-off-on. It's
more than a copyright issue, of course (it started out motivated by the
worries of tracking codeflow, but I think one reason it has worked so well
is that it's become useful for so many other things).
So lots of projects have their specific rules. I don't think the "add
notice to every file" is wrong per se, I just think it's impractical: not
only does it get unwieldly with all those messages at the top, usually an
open source project ends up being a mix of lots of different people that
own rights in it, and in many ways it's thus better to track at a change
level rather than a file level if you do tracking.
But exactly because it doesn't have any real legal rules, the rules are
from other sources, and boil down mainly to just per-project "coding
style" issues.
Linus
On Fri, 2006-09-22 at 18:15, James Bottomley wrote:
> [...] we
> foresee the release of GPLv3 portends the Balkanisation of the entire Open
> Source Universe upon which we rely. This Balkanisation, which will be
> manifested by distributions being forced to fork various packages in order
> to get consistent licences, has the potential to inflict massive collateral
> damage upon our entire ecosystem and jeopardise the very utility and
> survival of Open Source. [...]
This language looks terribly like US politician bullshit. Maybe you
should reformulate that "paper".
Xav
On Mon, 2006-09-25 at 12:31 +0100, Alan Cox wrote:
> The GPLv3 rewords it in an attempt to be clearer but also I think rather
> more over-reaching. It's not clear what for example happens with a
> rented device containing GPL software but with DRM on the hardware.
> Thats quite different to owned hardware. GPLv2 leaves it open for the
> courts to make a sensible decision per case, GPLv3 tries to define it in
> advance and its very very hard to define correctly.
Also the prevention of running modified versions is not only caused by
economic interests and business models. There are also scenarios where
it is simply necessary:
- The liability for damages, where the manufacturer of a device might
be responsible in case of damage when he abandoned the prevention. This
applies to medical devices as well as to lasers, machine tools and many
more. Device manufacturers can not necessarily escape such liabilities
as it might be considered grossly negligent to hand out the prevention
key, even if the user signed an exemption from liability.
- Regulations to prevent unauthorized access to radio frequencies, which
is what concerns e.g. cellphone manufacturers.
- ...
An ultimate definition of acceptable and unacceptable usage scenarios is
simply not possible due to the complexity of the problem. Any attempt to
create a definition will lead to loopholes and grey areas. Further it
will compulsory exclude acceptable usage scenarios.
A simple loophole example was brought up in the discussion already:
Technical limitations which do not allow modification at all, e.g. ROMs,
ASICs are apparently considered as a valid usage scenario, but it also
allows in consequence the circumvention of the intended lock down
protection by simple technical means, e.g. ROM based software
cartridges.
If you knit narrower meshes, you create more holes. This is not only
true for knitgoods, it's also a well known problem of legal systems.
tglx
On Mon, 25 Sep 2006, Michiel de Boer wrote:
>
> I support the current draft of the GPL version 3 and am very dissapointed
> it will not be adopted as is. IMHO, Linux has the power and influence
> to move mountains in the software industry, and shouldn't shy away from
> the opportunity to take moral responsibility when it arises.
Well, you do have to realize that Linux has never been an FSF project, and
in fact has never even been a "Free Software" project.
The whole "Open Source" renaming was done largely _exactly_ because people
wanted to distance themselves from the FSF. The fact that the FSF and it's
followers refused to accept the name "Open Source", and continued to call
Linux "Free Software" is not _our_ fault.
Similarly, the fact that rms and the FSF has tried to paint Linux as a GNU
project (going as far as trying to rename it "GNU/Linux" at every
opportunity they get) is their confusion, not ours.
I personally have always been very clear about this: Linux is "Open
Source". It was never a FSF project, and it was always about giving source
code back and keeping it open, not about anything else. The very first
license used for the kernel was _not_ the GPL at all, but read the release
notes for Linux 0.01, and you will see:
2. Copyrights etc
This kernel is (C) 1991 Linus Torvalds, but all or part of it may be
redistributed provided you do the following:
- Full source must be available (and free), if not with the
distribution then at least on asking for it.
- Copyright notices must be intact. (In fact, if you distribute
only parts of it you may have to add copyrights, as there aren't
(C)'s in all files.) Small partial excerpts may be copied
without bothering with copyrights.
- You may not distibute this for a fee, not even "handling"
costs.
notice? Linux from the very beginning was not about the FSF ideals, but
about "Full source must be available". It also talked about "Free", but
that very much was "Free as in beer, not as in freedom", and I decided to
drop that later on.
How much clearer can I be? I've actively tried to promote "Open Source" as
an alternative to "Free Software", so the FSF only has itself to blame
over the confusion.
Thinking that Linux has followed FSF goals is incorrect. IT NEVER DID!
I think the GPLv2 is an absolutely great license. I obviously relicensed
everything just a few months after releasing the first version of Linux.
But people who claim that that means that I (or anybody else) should care
what the FSF thinks on other issues are just being totally silly.
> What is the stance of the developer team / kernel maintainers on DRM,
> Trusted Computing and software patents?
I'm very much on record as not liking them. That changes nothing. I'm also
very much on record as saying that DRM, TPC etc have nothing at all to do
with the kernel license.
If you want to fight DRM, do so by joining the Creative Commons movement.
The problem with Disney is not that they use DRM, it's that they control
the content in the first place - and they do that because content tends to
be too monopolized.
The whole "content" discussion has _nothing_ to do with an operating
system. Trying to add that tie-in is a bad idea. It tries to link things
that aren't relevant.
So go fight the problem at the _source_ of the problem, not in my project
that has got nothing to do it.
And please, when you join that fight, use your _own_ copyrights. Not
somebody elses. I absolutely hate how the FSF has tried to use my code as
a weapon, just because I decided that their license was good.
> How about a public poll?
Here's a poll for you:
- go write your own kernel
- poll which one is more popular
It really is that simple. The kernel was released with a few rules. The
same way you can't just make your own version of it and then not release
sources, you _also_ cannot just make it GPLv3.
It's not a democracy. Copyright is a _right_. Authors matter.
Linus
On Mon, 2006-09-25 at 10:53 +0200, Michiel de Boer wrote:
> What is the stance of the developer team / kernel maintainers on DRM,
> Trusted Computing and software patents? Does the refusal to adopt GPLv3 as
> is mean that these two are more likely to emerge as supported functionality
> in the Linux kernel? Are there any moral boundaries Linux kernel developers
> will not cross concerning present and new U.S. laws on technology? Are they
> willing to put that in writing? Will Linux support HD-DVD and BluRay by
> being slightly more tolerant to closed source binary blobs? What about
> the already existant problems with the Content Scrambling System for
> DVD's?
Well, I think the email you quoted above gave the stance on DRM as used
by the content industry (in the bit you snipped):
> ... we find the use of DRM by media companies in their attempts to
> reach into user owned devices to control content deeply disturbing
I'll venture my personal opinion of replacing "deeply disturbing" with
"abhorrent". The trusted computing platform insofar as it is an agent
of that same DRM use by the media companies would thus share that
opinion. However, if it were sold as an agent at the disposal of the
user of the machine (rather than the content providers) then it
wouldn't. These technologies are not intrinsically "evil" it's the use
to which they're put that can be.
As far as the you must be able to run modifications language goes: too
many embedded devices nowadays embed linux. To demand a channel for
modification is dictating to manufacturers how they build things. Take
the case of an intelligent SCSI PCI card which happens to run embedded
linux in flash. The v3 draft requirements dictate a channel to modify
the flash image ... if that's a PCI card, the manufacturer has no
earthly way to control what happens on the platform into which its
plugged. So, if it's soldered onto a sparc motherboard and the card
manufacturer though their responsibility was discharged by producing a
dos flash floppy, who just broke the v3 requirements? should the sparc
motherboard maker care what embedded OS all the components run? should
the price for using linux to make embedded components be that you have
to provide modification toolkits for every conceivable platform they
could be used in?
Also, I just don't accept that Tivo is bad for Linux (even if I could be
persuaded that attacking Tivo would somehow help the battle against the
content providers' DRM efforts). I admit that not much useful has come
out of that one company, but the no tampering with the image requirement
came from cable companies who saw modifying a Tivo to store and
redistribute content to be a threat to them. There's a much more
clearcut example than Tivo: the Moxi (its rival), which has identical
bootloader requirements forced on it by cable companies for identical
reasons. It's produced by Digeo who, according to my personal count,
provided us with several device driver updates, a slew of filesystem
improvements and a kernel maintainer (which, I think everyone will
agree, went beyond their strict GPLv2 requirements)... how does some
perceived inequity with Tivo justify killing Digeo? or even making life
difficult for embedded hardware manufacturers? Look at it this way:
every Tivo is a potential Digeo ... we just have to persuade them.
James
>> Tolerance of binary blogs seems to be steadily dropping.
>>
>> As far as I can tell, the DVD-CSS is purely a legal issue today - the
>> technical issues are solved (I can watch any-region on my Linux
>> computer, and in Australia, the law requires that all DVD players must
>> ignore region encoding as it is an anti-competitive practice).
>
>Tolerance by who? As far as I can tell tolerance for binary blobs by
>the typical Linux desktop user is higher than ever. They consider it a
>bug if their distro does not automagically install the nvidia/ATI
>drivers, and immediately write you off as a GPL zealot if you even
>mention that a tainted kernel cannot be debugged.
It may be can [be debugged], but it is not going to be much fun.
These people just don't realize the question what they would do if the
same [segfault] happened on their Windows box. Support is not always
guaranteed from companies unless taking the more pricy support.
Jan Engelhardt
--
Neil Brown wrote:
> But maybe I am just misinformed. Maybe there are dozens of different
> manufacturers making devices that use DRM to prohibit freedom despite
> using GPL code, and maybe there are hundreds of submarine patents
> owned by distributors of GPL code and embodied in that code that the
> owners are going to start suing us overs.... Is there a list of these
> somewhere?
At least for patents, lawyers scream bloody murder if a list of patents
is posted. Once that is done, people can no longer claim ignorance of a
patent.
>> What is the stance of the developer team / kernel maintainers on DRM,
>
> While I cannot speak for other developers (and sometimes have trouble
> speaking for myself), one stance I have often heard is that DRM is
> simply a tool - one that is largely based on cryptography which is
> just another tool. They can have good uses and bad uses just like the
> TCP/IP stack (think 'spam'). So code to implement then would (if of
> suitable quality) be allowed into the kernel. If you want to make DRM
> illegal, speak to your member-of-parliament, not your code developers.
This is a KEY POINT: There can be good DRM as well as bad DRM.
Jeff
On Monday 25 September 2006 10:27, Lee Revell wrote:
>On Mon, 2006-09-25 at 20:51 +1000, Neil Brown wrote:
>> Tolerance of binary blogs seems to be steadily dropping.
>>
>> As far as I can tell, the DVD-CSS is purely a legal issue today - the
>> technical issues are solved (I can watch any-region on my Linux
>> computer, and in Australia, the law requires that all DVD players must
>> ignore region encoding as it is an anti-competitive practice).
I suspect thats history now, with the DMCA proposals now being voted on
there.
>Tolerance by who? As far as I can tell tolerance for binary blobs by
>the typical Linux desktop user is higher than ever.
Generaly speaking, from someone way up in the top level of the bleacher
seats here, thats true, as for instance the ndiswrapper scenario, required
by the rules of the various radio spectrum regulating agencies around the
planet. They would never, ever, give approval to a driver that was 100%
open source because of the ease with which the open source coder could
make them illegal, either for frequencies used, or for the Transmitter
Power Output one of these software radios COULD be made to do.
>They consider it a
>bug if their distro does not automagically install the nvidia/ATI
>drivers, and immediately write you off as a GPL zealot if you even
>mention that a tainted kernel cannot be debugged.
No, I do not, and never have said too much about it (as if anyone would
listen to me anyway) unless I was pissed because the kernels available
driver was obviously broken and caused crashes etc. We DO understand,
very well, that troubleshooting a problem just isn't possible when the
srcs are not available, meaning there is no way in hell you can certify
that the tainting driver didn't scribble all over memory it has no
business scribbling into.
Begin rant:
Yeah, we'ed be fools to say we don't have a political agenda when we're
forced to use substandard or questionably legal means for reasons related
to the above. But give us credit for understanding the reasons. What we,
the users, need in many cases, is a contact address to address our vents
to, for instance for someone at broadcom, high enough to have meaningfull
input to the discussions in the board room, that we could mail-bomb with
requests for better support. If 3000+ people who bought their stuff with
some well known makers label on it, like HP, and found they couldn't use
that builtin radio and do it 100% legal and compatibly, would email (and
Cc: your countries regulatory agency too) that chip maker and gently but
firmly bitch, that bit of 'politics' might well bring about some
constructive change in broadcoms (and the regulatory agencies involved)
attitude vis-a-vis specs release so better drivers could be written.
End rant.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Monday 25 September 2006 15:46, Jeff Garzik wrote:
>Neil Brown wrote:
>> But maybe I am just misinformed. Maybe there are dozens of different
>> manufacturers making devices that use DRM to prohibit freedom despite
>> using GPL code, and maybe there are hundreds of submarine patents
>> owned by distributors of GPL code and embodied in that code that the
>> owners are going to start suing us overs.... Is there a list of these
>> somewhere?
>
>At least for patents, lawyers scream bloody murder if a list of patents
>is posted. Once that is done, people can no longer claim ignorance of a
>patent.
Thats their problem, they created this mess in the first place. I can
recall buying, years ago, things whose makers label devoted more text area
to listing the applicable patents either pending or granted on the device
the label was attached to than was devoted to the makers logo itself. Now
it probably takes whole pages of 4 pt pica text with the patent
proliferation ad adsurdium thats taken place in the last 40 years... Bah.
All created to make sure the legal profession never starves.
>>> What is the stance of the developer team / kernel maintainers on DRM,
>>
>> While I cannot speak for other developers (and sometimes have trouble
>> speaking for myself), one stance I have often heard is that DRM is
>> simply a tool - one that is largely based on cryptography which is
>> just another tool. They can have good uses and bad uses just like the
>> TCP/IP stack (think 'spam'). So code to implement then would (if of
>> suitable quality) be allowed into the kernel. If you want to make DRM
>> illegal, speak to your member-of-parliament, not your code developers.
>
>This is a KEY POINT: There can be good DRM as well as bad DRM.
>
> Jeff
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Mon, 25 Sep 2006, Gene Heskett wrote:
> On Monday 25 September 2006 10:27, Lee Revell wrote:
>> On Mon, 2006-09-25 at 20:51 +1000, Neil Brown wrote:
>>> Tolerance of binary blogs seems to be steadily dropping.
>>>
>>> As far as I can tell, the DVD-CSS is purely a legal issue today - the
>>> technical issues are solved (I can watch any-region on my Linux
>>> computer, and in Australia, the law requires that all DVD players must
>>> ignore region encoding as it is an anti-competitive practice).
>
> I suspect thats history now, with the DMCA proposals now being voted on
> there.
>
>> Tolerance by who? As far as I can tell tolerance for binary blobs by
>> the typical Linux desktop user is higher than ever.
>
> Generaly speaking, from someone way up in the top level of the bleacher
> seats here, thats true, as for instance the ndiswrapper scenario, required
> by the rules of the various radio spectrum regulating agencies around the
> planet. They would never, ever, give approval to a driver that was 100%
> open source because of the ease with which the open source coder could
> make them illegal, either for frequencies used, or for the Transmitter
> Power Output one of these software radios COULD be made to do.
Actually no. I've now heard this false information too many times.
As somebody who has prepared over 40 applications for FCC Type
Acceptance, and submitted monitoring equipment for FCC Type
Approval, I have first-hand experience. If somebody was so dumb as
to disclose to the FCC that a hacker could make the equipment unsuitable
for its intended use, the FCC would not allow the equipment to be used.
No certification would be forthcoming. On the other hand, if part
of the "turning-on" process was to load some bits from a bucket, this
disclosure must be part of the approval process. The FCC just might
require that the bits be checked for integrity, perhaps a checksum
or CRC.
Also, you can't adjust a milliwatt transmitter to produce a megawatt,
no matter how hard you try. The power output is allowed to be reduced
by software below the authorized maximum for that class of service.
You'd do much better at getting more power out by designing a custom
antenna coupling circuit so that the fixed output voltage could be fed
to a lower output impedance. Then you'd eventually run into fold-back
and overheating of those tiny RF transistors.
It's most likely, however, that a complete disclosure of the device
to be operated has not been made at all! Disclosing that a complete
disclosure has not been made, when in fact it's required, could
result in not only the loss of approval, but in fines as well.
Further, you can look at the disclaimer (the FCC Label) on any item
that had to be approved. It states quite clearly that modifications
render the device unapproved.
As for frequencies, the pseudo-random frequency-hop needs a center-
frequency that's pretty much set in stone (actually a quartz one).
Anybody can change quartz crystals. Again, modifications remove
approval. The typical user can operate unapproved equipment at
his own peril. However, it's unlikely that they will be caught
unless they leave their modified device on the lawn of the FCC's
standards office in Laurel, MD.
It's all moot. The device manufacturers don't want the competition
to know what's in those bits so their nature is not going to be
disclosed. Further, even if they provided the FPGA "source-code"
it's unlikely that most people would be able to use it at all.
Single-seat licenses for much of that stuff costs over US$500.00 -just
a bit too much to hack a US$39.99 device.
However, if you are a (choose your country) clone manufacturer,
it would be a pretty good deal to buy a US$39.99 board as a sample,
buy a US$500.00 software license, then clone 10,000 of these, selling
them at US$29.99 a pop. That's a US$300k profit for a US$539.99
investment and that's why you are not going to get the source-code!
>
>> They consider it a
>> bug if their distro does not automagically install the nvidia/ATI
>> drivers, and immediately write you off as a GPL zealot if you even
>> mention that a tainted kernel cannot be debugged.
>
> No, I do not, and never have said too much about it (as if anyone would
> listen to me anyway) unless I was pissed because the kernels available
> driver was obviously broken and caused crashes etc. We DO understand,
> very well, that troubleshooting a problem just isn't possible when the
> srcs are not available, meaning there is no way in hell you can certify
> that the tainting driver didn't scribble all over memory it has no
> business scribbling into.
>
> Begin rant:
>
> Yeah, we'ed be fools to say we don't have a political agenda when we're
> forced to use substandard or questionably legal means for reasons related
> to the above. But give us credit for understanding the reasons. What we,
> the users, need in many cases, is a contact address to address our vents
> to, for instance for someone at broadcom, high enough to have meaningfull
> input to the discussions in the board room, that we could mail-bomb with
> requests for better support. If 3000+ people who bought their stuff with
> some well known makers label on it, like HP, and found they couldn't use
> that builtin radio and do it 100% legal and compatibly, would email (and
> Cc: your countries regulatory agency too) that chip maker and gently but
> firmly bitch, that bit of 'politics' might well bring about some
> constructive change in broadcoms (and the regulatory agencies involved)
> attitude vis-a-vis specs release so better drivers could be written.
>
> End rant.
>
> --
> Cheers, Gene
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Yahoo.com and AOL/TW attorneys please note, additions to the above
> message by Gene Heskett are:
> Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.66 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Hallo,
On 2006-09-25, Lee Revell <[email protected]> wrote:
> On Mon, 2006-09-25 at 20:51 +1000, Neil Brown wrote:
>> Tolerance of binary blogs seems to be steadily dropping.
>>
[Binary bloGs. Yea, that's future of it (and XML) ;]
>> As far as I can tell, the DVD-CSS is purely a legal issue today - the
>> technical issues are solved (I can watch any-region on my Linux
>> computer, and in Australia, the law requires that all DVD players must
>> ignore region encoding as it is an anti-competitive practice).
>
> Tolerance by who? As far as I can tell tolerance for binary blobs by
> the typical Linux desktop user is higher than ever. They consider it a
> bug if their distro does not automagically install the nvidia/ATI
> drivers, and immediately write you off as a GPL zealot if you even
> mention that a tainted kernel cannot be debugged.
This is not what Linux all about, as far as i can understand, reading lkml.
Recall, please, linuxant MODULE_LICENSE("GPL\0 if bla-bla") case.
Poor linux users, happy with stupid devices at low bandwidth and
Working Drivers (tm).
NV/ATI's driver _users_ are the same, *it's cool to be a kung-fu hacker*
fashion. And don't tell me linux is desktop / game / home theater ready,
please. It's nearly an orthogonal world by purpose and needs. (IMHO, of course)
That fashion even affects Debian with all that firmware stuff. Invalid
users (who cannot manage to have Debian installed without firmware,
but loves it, server support for free or ever freedom; last is rare
already) are in damn higher priority, than a 15 years of Social Contract.
> Lee
>
On Fri, 2006-09-22 at 11:15 -0500, James Bottomley wrote:
> Over the past decade, the Linux Operating System has shown itself to be far
> and away the most successful Open Source operating system in history.
> However, it certainly wasn't the first such open source operating system
> and neither is it currently the only such operating system.
Fuzzy (but realistic) logic:
kernel != operating_system
operating_system > kernel
operating_system - kernel = 0
kernel - (operating_system - kernel) < 0
The Q. I'd like to know the answer to is:
What part of the (operating_system - kernel) part is ready to adopt
v.3?
Another (license compatibility) Q. is:
If the (operating_system - kernel) is re-licensed under v.3 and
the kernel is still under v.2 , would it be possible to distribute
combination (kernel + (operating_system - kernel)) ?
The last Q. is how good is the almost forgotten Hurd kernel?
[ Sorry for errors with CC, and ugly forwarded message ]
[ <[email protected]>, refs had have to be added. ]
Linus,
On Sat, Sep 23, 2006 at 10:03:49AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 23 Sep 2006, Oleg Verych wrote:
>
> >
> > On 2006-09-22, Linus Torvalds <[email protected]> wrote:
> > >
> > > I don't actually want people to need to trust anybody - and that very much
> > > includes me - implicitly.
> > >
> > > I think people can generally trust me, but they can trust me exactly
> > > because they know they don't _have_ to.
> >
> > And somebody chooses anoter license, f.e see:
> > linux/drivers/video/aty/radeon_base.c
>
> We have always (and will continue to do so) accepted licenses that are
> compatible with the GPLv2 for the kernel.
just wanted to point that comment about your PETv2.
[...]
> > > just picked the first screenful of people (and Alan. And later we added
> > > three more people after somebody pointed out that some top people use
> >
> > Alan *is on top* of (old fashioned, gitless):
> >
> > $ for i in `find linux/drivers/`
> > do dd count=1 <$i | grep @ | sed 's_[^<]*<\(.*@.*\)>[^>]*_\1_g'
> > done | sort | uniq -c | sort -rn | most
>
> Well, quite frankly, I don't think the copyright messages in the source
> code is necessarily very good. Some people add them, most don't.
This is a surprise for me; big IT companies' time ?
I know about per-contribution mark-credit via sign-off, you've talked
about, but initial creating of big chunk must and, as i can see, have all that
copyrights, even from guys from big IT. It seems, that you don't care
much. Well, in case of mr. Alan Cox i do care.
>
> But yes, for obvious reasons Alan was added _regardless_ of any counts.
>
> > And what about linux/CREDITS ? Creating (even in the past) is also worth.
>
> And what about the old history from BK time? And what about a million
where's BK, and where is the kernel ?
I'm even glad to have hard proof inside of current kernel. After many
years, great job is hard to hide. For example, even nowdays ac patchset is
positively commented (some days ago i've read Russell's message about arm
tree maintainig).
>
> Btw, if it makes you feel any better, if you look at the old
> linux-historic archive (which goes back another 3+ years), and do the same
Still big IT time,
> statistics, it's quite impressive how similar the list would be (Alan
> _did_ show up on that list on his own, btw).
i thought about 5-10 years ago, actually.
> So I claim that my list of people is one of the better lists you can come
> up with.
"if it makes you feel any better" ;D
The Free Software Foundation have only toolchain as big GPLv2 product.
But it has LGPL parts. Functionality implemented in libraries, thus
GPL itself applies to small (mostly sf.net dead) pieces of application.
The Linux Kernel is pure GPL.
(all boiler-plate license blobs or binary blobs do not mater)
Thus, i think, FSF just will not have anything without it. And i don't
know why rms started all that...
-o--=O`C /. .\ (i want ...) (+)
#oo'L O o |
<___=E M ^-- | (you're barking up the wrong tree)...
>Fuzzy (but realistic) logic:
>
> kernel != operating_system
>
> operating_system > kernel
>
> operating_system - kernel = 0
>
> kernel - (operating_system - kernel) < 0
>
>Another (license compatibility) Q. is:
> If the (operating_system - kernel) is re-licensed under v.3 and
> the kernel is still under v.2 , would it be possible to distribute
> combination (kernel + (operating_system - kernel)) ?
If by operating system you mean the surrounding userland application,
then yes, why should there be a problem with a GPL2 kernel and a GPL3
userland? After all, the userland is not only GPL, but also BSD and
other stuff.
>The last Q. is how good is the almost forgotten Hurd kernel?
Wild guess: At most on par with Minix.
Jan Engelhardt
--
On Wed, 2006-09-27 at 07:55 +0200, Jan Engelhardt wrote:
> >Fuzzy (but realistic) logic:
> >
> > kernel != operating_system
> >
> > operating_system > kernel
> >
> > operating_system - kernel = 0
> >
> > kernel - (operating_system - kernel) < 0
> >
> >Another (license compatibility) Q. is:
> > If the (operating_system - kernel) is re-licensed under v.3 and
> > the kernel is still under v.2 , would it be possible to distribute
> > combination (kernel + (operating_system - kernel)) ?
>
> If by operating system you mean the surrounding userland application,
almost, surrounding_userland_applications = (operating_system - kernel)
> then yes, why should there be a problem with a GPL2 kernel and a GPL3
> userland? After all, the userland is not only GPL, but also BSD and
> other stuff.
It was not a problem with GPL[0-1]/BSD/MIT license, but is it still true
with GPL3? What is the difference between running application on the top
of the kernel "A" and linked with the library "B"?
> >The last Q. is how good is the almost forgotten Hurd kernel?
>
> Wild guess: At most on par with Minix.
... ???. I am not so sure. Kernel is really a small thing. The VMWare
proprietary hyper-visor was/is reusing Linux drivers with ease, why BSD or
Hurd can not do the same? As a former (Linux) driver writer I like to show the
following numbers to my friends:
$ du -s lib kernel net drivers
980 lib
1728 kernel
16132 net
130872 drivers
and:
$ find ./kernel -type f -exec cat {} + | wc -l
48312
$ find ./drivers -type f -exec cat {} + | wc -l
3367849
================================================================
PS. Given that some of the sub-systems (e.g SCSI) in Linux still suck
badly, other OS (not as in Operating Systems but as in Open Source)
alternatives might eventually gain some ground in the enterprise
environment.
>almost, surrounding_userland_applications = (operating_system - kernel)
>
>> then yes, why should there be a problem with a GPL2 kernel and a GPL3
>> userland? After all, the userland is not only GPL, but also BSD and
>> other stuff.
>
>It was not a problem with GPL[0-1]/BSD/MIT license, but is it still true
>with GPL3? What is the difference between running application on the top
>of the kernel "A" and linked with the library "B"?
I think Linus once said that he does not consider the kernel to
become part of a combined work when an application uses the kernel.
I tend to agree, it's gray (unless Linus explicitly colorizes it) --
IIRC the GPL allows a GPL and closed program to interact if they do so
using 'standard' interfaces, i.e. passing a file as argument, or
shell redirection, communicating over a pipe or a socket, etc.
But OTOH, linking code makes it a combined work.
And the question now is: Since the kernel is the one providing these
standard services, what would apply? Do userland and kernel communicate
by means of linking or by means of standardized interfaces (in this case -
fixed syscall numbers or thelike). I'd say the latter. An application
does not link with the kernel IMHO, no symbol resolution is done.
>> >The last Q. is how good is the almost forgotten Hurd kernel?
>>
>> Wild guess: At most on par with Minix.
>
>... ???. I am not so sure. Kernel is really a small thing. The VMWare
>proprietary hyper-visor was/is reusing Linux drivers with ease, why BSD or
>Hurd can not do the same? As a former (Linux) driver writer I like to show the
>following numbers to my friends:
Oh well I was rather interpreting the question as "What about Hurd?" and
my answer was the same from the Hurd page last time I read it.
"It's not so complete to make up a production system." or similar.
>================================================================
>
>PS. Given that some of the sub-systems (e.g SCSI) in Linux still suck
>badly, other OS (not as in Operating Systems but as in Open Source)
>alternatives might eventually gain some ground in the enterprise
>environment.
Don't tell me you like the Solaris way of naming devices. :)
Jan Engelhardt
--
> As far as the you must be able to run modifications language goes: too
> many embedded devices nowadays embed linux. To demand a channel for
> modification is dictating to manufacturers how they build things. Take
> the case of an intelligent SCSI PCI card which happens to run embedded
> linux in flash.
So just clarify GPL v3 so any GPLv3 distributor gives the same level of
access to the people he distributes his GPLed software do (ie if the code
is on a flasheable device, open the flash process ; if it's drm-protected
: give
the DRM key)
It's not as if most (all?) widespread linux-embedded devices are not
flashable nowadays. Factory recall everytime you need to fix a
security/feature bug just costs too much
(as far as I know every single Tivo-like thing *is* updateable remotely)
--
Nicolas Mailhot
Ar Mer, 2006-09-27 am 10:58 +0200, ysgrifennodd Jan Engelhardt:
> I think Linus once said that he does not consider the kernel to
> become part of a combined work when an application uses the kernel.
COPYING top of the kernel source tree.
> I tend to agree, it's gray (unless Linus explicitly colorizes it) --
> IIRC the GPL allows a GPL and closed program to interact if they do so
> using 'standard' interfaces, i.e. passing a file as argument, or
> shell redirection, communicating over a pipe or a socket, etc.
> But OTOH, linking code makes it a combined work.
No. The definition of a derivative work is a legal one and not a
technical one. Take a look at the history of the objective C compiler
front end for gcc. It is possible that linked code is not derivative or
pipe using code is derivative - consider for example RPC. Simply making
a linux device driver make the same function calls to the kernel by RPC
messages over a pipe type device would not change its status.
Alan
On Wed, Sep 27, 2006 at 07:55:41AM +0200, Jan Engelhardt wrote:
> If by operating system you mean the surrounding userland application,
> then yes, why should there be a problem with a GPL2 kernel and a GPL3
> userland? After all, the userland is not only GPL, but also BSD and
> other stuff.
Actually, the biggest problem will likely be userland applications and
shared libraries. Many people believe that the GPL infects across
shared library links. Whether or not that's true, it's never been
tested in court, and probably depends on the legal jurisdiction. In
any case, many parts of the community, and certainly distributions
like Debian, behave as if the GPL infects across shared libraries.
But if that's true, then we have a big problem, because just as the
CDDL is incompatible with GPLv2, so too is the GPLv3 incompatible with
GPLv2. (It has to be; the whole point of the GPLv3 is to fix "bugs"
such as spiking out companies considered evil like Tivo. If you're
going to make the argument that there are no differences and so the
GPLv2 and v3 are compatible, then why are we wasting all of this time
and money on GPLv3?)
And if there are additional restrictoins in GPLv3 (and I've never
heard Eben deny it), then there's nothing you can do in GPLv3 to fix
the compatibility problem, because GPLv3 has more restrictions than
GPLv2, and the GPLv2 prohibits additional restrictions. So the
incompatibility is forced from the GPLv2 side, and no textual changes
in GPLv3 can possibly hope to fix things. Hence, for userspace code
which is licensed under a GPLv2 only license, it must be strictly
incompatible with any GPLv3 shared library.
And given that Stallman has announced that the new LGPL will be (to
use programming terms) a subclass of GPLv3, it means that the LGPLv3
is by extension incompatible with the GPLv2. So that means that there
will have to be two different versions of glibc (and every other
shared library) shipped with every distributions --- one which is
GPLv2, and one which is GPLv3. And this fork is going to be forced by
the FSF!
So that brings up an interesting question --- which fork is Uhlrich
Drepper going to continue to work on? The GPLv2 or GPLv3 version? :-)
- Ted
P.S. I guess there is another alternative, which is that all shared
libraries must be dual licensed under a "your choice of LGPLv2 or
LGPLv3". Of course, then that won't prohibit CCE's (Companies
Considered as Evil) from using said code. And certainly, for people
who care more about code reuse, I would urge them to dual license
their code, since otherwise GPLv2 and GPLv3 code will not be able to
coexist, and the FSF will be making the license fragmentation problem
even worse for everyone, just to pursue their political goals.
On Tue, Sep 26, 2006 at 09:11:47PM -0400, Sergey Panov wrote:
>
> The last Q. is how good is the almost forgotten Hurd kernel?
Note that Hurd has a lot of Linux driver code in it, which probably can
not be changed to GPLv3...
thanks,
greg k-h
On Wed, 27 Sep 2006, Jan Engelhardt wrote:
>
> If by operating system you mean the surrounding userland application,
> then yes, why should there be a problem with a GPL2 kernel and a GPL3
> userland? After all, the userland is not only GPL, but also BSD and
> other stuff.
Indeed.
We have no trouble at all running programs with much worse licenses than
the GPLv3 (ie commercial programs). There is no problem with user space
being v3.
> >The last Q. is how good is the almost forgotten Hurd kernel?
>
> Wild guess: At most on par with Minix.
...and here's a thing that most people forget: good code simply doesn't
care about ideology, and ideology often does the wrong technical decisions
because it's not about practical issues.
The watch-word in Linux development has been "pragmatism". That's probably
part of what drives the FSF wild about Linux in the first place. I care
about _practical_ issues, not about wild goose chases.
If I weren't into computers, I'd be in science. And the rules in science
are the same: you simply can't do good science if you start with an
agenda. If you say that you'll never touch high-energy physics because
you find the atom bomb to be morally reprehensible, that's your right, but
you have to also realize that then you can never actually understand the
world, and do everything you may need to do.
I've often compared Open Source development vs proprietary development to
science vs witchcraft (or alchemy).
In many ways, the GPLv3 is about "religion". They limit the technology
because they are afraid of it. It's not that different from a religious
standpoint that some research is "bad" - because it undermines the
religious beliefs of the people. You'll find extremists in the US saying
that things like evolution is an affront to very basic human morals, the
exact same way that rms talks about DRM being "evil".
I want to be a "scientist". I want people to be able to repeat the
experiments, logic, and measurements (that's very much what science is
about - you don't just trust people saying that the world works some way),
but being a scientist doesn't mean that you should let other scientists
into your own laboratory or into your own home. That would be just crazy
talk.
So as a "scientist", I describe in sufficient detail my theory and the
results, so that anybody else in the world can replicate them. But they
can replicate them in their _own_ laboratories, thank you very much.
That's what open source is all about. It's about _scientific_ ideals.
It's not on a moral crusade, and it never has been.
The point behind all this: even if the Hurd didn't depend on Linux code
(and as far as I know, it does, but since I think they have their design
heads firmly up their *sses anyway with that whole microkernel thing, I've
never felt it was worth my time even looking at their code), I don't
believe a religiously motivated development community can ever generate as
good code except by pure chance.
Linus
[ This is not so much really a reply to Alan, as a rant on some of the
issues that Alan takes up ]
On Wed, 27 Sep 2006, Alan Cox wrote:
> Ar Mer, 2006-09-27 am 10:58 +0200, ysgrifennodd Jan Engelhardt:
> > I think Linus once said that he does not consider the kernel to
> > become part of a combined work when an application uses the kernel.
>
> COPYING top of the kernel source tree.
Yes. But also somethign much more fundamental:
Copyright Law - regardless of country
You can claim anything you damn well want in a license, but in the end,
it's all about "derived works". If something is not a derived work, it
doesn't matter _what_ ownership rights you have, it's simply not an issue.
So even if the kernel had a big neon sign that said "You're bound by this
license in user space too!" (or, more likely, didn't have a sign at all,
like was the case originally), that has absolutely _zero_ legal meaning
for a copyright license. A license cannot cover something just because it
"says so".
For example, I could write a copyright license that said
"This license forbids you from ever copying the kernel, or any
work made by Leo Tolstoy, which is just a pseudonym for the
easter bunny"
and the fact that the license claims to control the works of Leo "the
easter bunny" Tolstoy, claiming so simply doesn't make it so.
And yes, the above is obviously ridiculous, but the point is, it's no more
ridiculous than a license that would claim that it extends to programs
just because you can run then on Linux.
In fact, it's also no more ridiculous than a license that claims it
extends copyright the other way - to the hardware or platform that you run
a program on. From a legal standpoint, such wording is just totally
idiotic.
[ So the wording at the top of the license is a clarification of fact, not
really any kind of change of the license itself. It actually does have
some legal meaning (it shows "intent"), but most importantly it allows
people to not have to even worry about frivolous lawsuits. Nobody can
sue people for not running GPLv2 user-space through normal system calls,
because the statement of intent makes it clear that a judge would throw
out such a suit immediately.
So I think the important thing here to take away is that "frivolous"
part of the lawsuit. The language doesn't actually _change_ the legal
meaning, but it protects against idiots. And a lot of lawyers worry
about idiots and money-grubbing douchebags *cough*SCO*cough*, and
as such obvious clarifications _can_ be useful. ]
Another real-world example of this mis-understanding is that a lot of
people seem to think that the GPLv2 disallows "linking" with non-GPLv2
code. Almost everybody I ever meet say that, and the FSF has written long
pieces on shared libraries etc.
People don't have a clue!
The GPLv2 never _ever_ mentions "linking" or any other technical measure
at all. Doing so would just be stupid (another problem with the GPLv3,
btw). So people who think that the GPLv2 disallows "linking" with
non-GPLv2 code had better go back and read the license again.
Grep for it, if you want to. The word "link" simply DOES NOT EXIST IN THE
LICENSE!
(It does exist at the end of the _file_ that contains the license, but
that's not actually the license at all, it's just the "btw, this is how
you might _use_ the license", and while legally that can be used to show
"intent", it does not actually extend the copyright in the work in any
way, shape, or form).
What the GPLv2 actually talks about is _only_ about "derived work". And
whether linking (dynamically, statically, or by using an army of worker
gnomes that re-arrange the bits to their liking) means something is
"derived or not" is a totally different issue, and is not something you
can actually say one way or the other, because it will depend on the
circumstances.
I'm always surprised by how many people talk abut the GPLv2 (and, quite
frankly, about the GPLv3 draft) without actually seemingly having ever
read the damn thing, or, more likely, ever really understood any legal
stuff what-so-ever, or the difference between the _use_ of a license, and
the license itself.
For example, in the GPLv3 discussions, I've seen more than one person
claim that I've used a special magic version of the GPLv2 that doesn't
have the "v2 or any later" clause. Again, those people don't have a _clue_
about what they are talking about. They feel very free in arguing about
other peoples copyrigted works, and the fact that I'm not a lawyer, but
then they ignore the fact that I actually _do_ know what I'm talking
about, and that they don't have a stinking clue.
> No. The definition of a derivative work is a legal one and not a
> technical one.
Exactly. A lot of people don't understand this, and a lot of people think
that "derivative" means "being close". Linking doesn't make something
derivative per se - the same way _not_ linking doesn't make it not be
derivative.
Now, it is also indisputable that if you _need_ to "link", it's a damn
good sign that something is _very_likely_ to be derivative, but as Alan
points out, you could do the same thing with RPC over a socket, and the
fact that you did it technically differently really makes no real
difference. So linking per se isn't the issue, and never has been.
Linus
On Wed, 27 Sep 2006, Nicolas Mailhot wrote:
>
> It's not as if most (all?) widespread linux-embedded devices are not
> flashable nowadays. Factory recall everytime you need to fix a
> security/feature bug just costs too much
Side note: it's not even about factory recalls, it's that flash chips are
literally cheaper than masked roms for almost all applications.
Mask roms are expensive for several reasons:
- they force extra development costs on you, because you have to be
insanely careful, since you know you're stuck with it.
So it's not even just the cost of the recall itself: it's the
_opportunity_ cost of having to worry about it which tends to be the
biggest cost by far. Most devices never get recalled, and when they do
get recalled, a lot of people never bother about it. So the real cost
is seldom the recall itself, it's just the expense of worrying about
it, and wasting time on trying to make things "perfect" (which never
really works anyway)
- during development, mask roms are a big pain in the ass, so you need to
build all your development boards (even the very final one! The one
that is supposedly identical to the released version!) with a flash
anyway, even if you can only program it by setting a magic jumper or
something.
So using a mask rom means that your development platform pretty much
will never match the actual hw platform you sell. That's a DISASTER.
It's like always developing and testing with the compiler using the
"-g" flag, but then _shipping_ the binary with "-O". Nobody sane would
ever do that - it just means that all your verification was basically
useless.
- They force you to use a specialized chip. Mass production usually means
that in any kind of low volumes, specialized chips are always going to
be more expensive.
People seem to sometimes still believe that we live in the 1980's. Mask
roms used to be relatively "cheaper", because it wasn't as much about
standardized and huge volumes of chips. These people should please
realize that technology has changed in the last quarter century, and
we're not playing "pong" any more.
[ Side note: is there a good "pong" box you can buy? I want pong and the
real asteroids - the one with vector graphics. And I realize I can't
afford the real asteroids, but dang, there should be a realistic pong
somewhere? Some things are hard to improve on.. ]
So even if you don't actually want to upgrade the machine, it's likely to
have a flash in it simply because it's often _cheaper_ that way.
And it not at all uncommon to have a flash that simply cannot be upgraded
without opening the box. Even a lot of PC's have that: a lot (most?) PC's
have a flash that has a separate _hardware_ pin that says that it is
(possibly just partially) read-only. So in order to upgrade it, you'd
literally need to open the case up, set a jumper, and _then_ run the
program to reflash it.
People do things like that for fail-safe reasons. For example, a portion
of the flash is read-only, just so that if a re-flashing fails, you have
the read-only portion that verifies the signature, and if it doesn't
match, it contains enough basic logic that you can try to re-flash again.
Those kinds of fail-safes are absolutely _critical_, and I'm not talking
about some "hypothetical" device here. I'm talking very much about devices
that you and me and everybody else probably use every stinking day.
In fact, I can pretty much guarantee that pretty much everybody who is
reading this is reading it on a machine that has an upgrade facility that
is protected by cryptographic means. Your CPU. Most of the microcode
updaters have some simple crypto in them (although sometimes that crypto
is pretty weak and I think AMD relies more on just not documenting the
format).
Look into the Linux kernel microcode updater code some day, and please
realize that it talks to one of those evil "DRM-protected devices".
And dammit, this is all OK. If people want to write a GPL'd microcode
update, they damn well should be able to. Oh, but the GPLv3 forbids them
from doing that without giving out the keys used to sign the result.
"But that's ok, because the FSF is looking out for all of us, and
we know mommy knows best."
So it's all good.
Linus
On Wed, Sep 27, 2006 at 10:58:41AM +0200, Jan Engelhardt wrote:
> >... ???. I am not so sure. Kernel is really a small thing. The VMWare
> >proprietary hyper-visor was/is reusing Linux drivers with ease, why BSD or
> >Hurd can not do the same? As a former (Linux) driver writer I like to show the
> >following numbers to my friends:
>
> Oh well I was rather interpreting the question as "What about Hurd?" and
> my answer was the same from the Hurd page last time I read it.
> "It's not so complete to make up a production system." or similar.
Well, that will be very simple. If the Hurd gets relicensed to be
GPLv3, it won't be able to use Linux kernel device drivers any more,
because they will be GPLv2, and the GPLv2 and GPLv3 licenses are
incompatible. But that's the FSF's problem, not ours...
- Ted
On Wed, 27 Sep 2006, Linus Torvalds wrote:
>
> For example, I could write a copyright license that said
>
> "This license forbids you from ever copying the kernel, or any
> work made by Leo Tolstoy, which is just a pseudonym for the
> easter bunny"
>
> and the fact that the license claims to control the works of Leo "the
> easter bunny" Tolstoy, claiming so simply doesn't make it so.
>
> And yes, the above is obviously ridiculous, but the point is, it's no more
> ridiculous than a license that would claim that it extends to programs
> just because you can run then on Linux.
>
> In fact, it's also no more ridiculous than a license that claims it
> extends copyright the other way - to the hardware or platform that you run
> a program on. From a legal standpoint, such wording is just totally
> idiotic.
>
The reason a clause such as that will work is that people have no natural
right to redistribute Linux. To invoke the FSF's Tivo example, if the Tivo
company wants to stamp out 5,000 Tivo boxes, they're going to make 5,000
copies of Linux in the process. By default and by direct notice, the
pieces that make up Linux, and the compilation of Linux itself, is
copyrighted. This totally prohibits Tivo from making legal copies.
If Tivo wants to redistribute Linux, they need a license. That license is
GPLv2, but let us assume for a moment that rms spiked the punch at OLS and
the kernel became GPLv3. If GPLv3 says "You may not make copies of the
covered work unless you agree to these terms", and one term says, "You
must not use technological means to override a stated license freedom",
then Tivo redistributes Linux anyway inside a device that uses
technological means (signed code, for instance) to override a stated
freedom, Tivo is breaking the law, unless every Linux copyright holder
agreed to give Tivo a special exception (aka license).
So regardless of whether or not you think such a term is ridiculous, it is
enforceable. The only place I am aware that law might deliberately reduce
the scope of a license's requirements is to uphold fair use rights, or
along the same lines, to ensure fair treatment of a consumer that has paid
money for something and is being subjected to unreasonable coercion by the
copyright holder of what they have paid for.
If you haven't paid for a copyrighted work, and the copies you want to
make do not fall under fair use ("we needed a cheap and good operating
system for our embedded device" is not in that category), you need to obey
the license or find something else to copy.
I don't want to get ensnared in another licensing debate about code I have
no moral or legal claim to, but I do want to thank those of you behind the
position statement. I'm not sure I agree with your points but I think the
dialogue itself is important.
The last thing that I want to say is that I wish people wouldn't imply to
the press (wink wink, nudge nudge, Linus) that the FSF is evil. I've heard
at various times the following things in the press:
1. "The FSF is not going to listen to anyone about GPLv3"
2. "The FSF is not listening to anyone about the GPLv3"
3. "I don't want to participate in the GPLv3 process"
4. "The FSF knows my views because I have carbon-copied them"
...meanwhile, the FSF is allegedly trying to open up a dialogue. I think
the important distinction is that the FSF will listen to anything the
kernel people (or anyone else for that matter) say, but whatever is said
will be interpreted and balanced in the context of the FSF's original
goals of the license, Freedoms 0-3, and most certainly what they believe
those Freedoms to be.
I think one thing that should have happened a _lot_ sooner is that you and
others should have made clear to the startled community that you object
precisely to the anti-Tivoization clause, not because of any technical
reason or interpretation but because you don't see anything wrong with
Tivo's use of Linux. It would have been nice but totally optional to
engage in dialogue with the FSF. But slandering them about their license
development process, or their intentions with regard to using Linux as
leverage, is counterproductive whether true or not.
I'm one of those lefty "free software" types, though I don't disbelieve
in "open source" either. At this point, I consider it likely that I'll use
the GPLv3 for any software I independently develop, and I'll continue to
be damn thankful that I have the best operating system kernel ever in
history to freely run that code on. When I submit a patch to Linux, I'll
happily do so knowing that it will be licensed underneath the wonderful
GPLv2.
The reason I wrote this long message is that despite having never met any
of you, I consider you all friends. We're software developers working for
a common good, even if we see it a different way. I hope that's enough to
make me your friends as well. If that is the case, and we're all friends
here, let's be fair to the FSF even if we don't agree with them, and even
if some of their members haven't been fair to us in the past.
Thanks,
Chase Venters
On Wed, 27 Sep 2006, Chase Venters wrote:
>
> The reason a clause such as that will work is that people have no natural
> right to redistribute Linux.
Right. Any copyright license will basically say
"You can distribute this assuming you do so-and-so"
and a contract can actually extend on that and also limit you in other
ways than just distribution, ie you can sat
"You can buy this, but you cannot legally benchmark it"
However, none of that actually extends your "derived work" in any way.
Linus
I generally agree with you, but...
Linus Torvalds <[email protected]> writes:
> And it not at all uncommon to have a flash that simply cannot be upgraded
> without opening the box. Even a lot of PC's have that: a lot (most?) PC's
> have a flash that has a separate _hardware_ pin that says that it is
> (possibly just partially) read-only. So in order to upgrade it, you'd
> literally need to open the case up, set a jumper, and _then_ run the
> program to reflash it.
I think this is history. Yes, late 486s and Pentiums (60 and 66?)
had a jumper protecting the flash. It's not true since ca. "Pentium 75+"
days - while many boards use "bootblock" chips, it's (almost?) always
unprotected (at most it just requires setting some GPIO pin(s)). The
rest of flash obviously has to be R/W to support the ESCD etc.
I think there are systems with 2 copies of the whole BIOS, and the
user selects the copy with a jumper (probably connected directly to
the most significant address line of the flash IC) - the second
copy might theoretically use a R/O bootblock but I've never checked it.
Most VGAs, disks, PCI cards etc. have flash chips with no protection
either, and I have to say I felt much better when they used (EP)ROMs.
I think almost all hardware manufacturers use a blank flash chips,
programming them "in system" with things like JTAG.
--
Krzysztof Halasa
On Wed, 27 Sep 2006, Krzysztof Halasa wrote:
> > And it not at all uncommon to have a flash that simply cannot be upgraded
> > without opening the box. Even a lot of PC's have that: a lot (most?) PC's
> > have a flash that has a separate _hardware_ pin that says that it is
> > (possibly just partially) read-only. So in order to upgrade it, you'd
> > literally need to open the case up, set a jumper, and _then_ run the
> > program to reflash it.
>
> I think this is history. Yes, late 486s and Pentiums (60 and 66?)
> had a jumper protecting the flash. It's not true since ca. "Pentium 75+"
> days - while many boards use "bootblock" chips, it's (almost?) always
> unprotected (at most it just requires setting some GPIO pin(s)). The
> rest of flash obviously has to be R/W to support the ESCD etc.
You're probably right. The pin still exists on the flash chips, but most
of the time on PC's at least the writability is software-controlled.
I think the hatred of pins became so high that it became almost
unacceptable for motherboard designers to add them on PC's. Nobody wants
to open their case any more ;)
But the whole point was to just show how silly the whole "upgradable" vs
"not upgradable" discussion is. We're literally talking about something
where apparently it matters to the GPLv3 whether a pin on a chip is
connected to software or hardware (or not at all). Is that sane?
So if it's "hardware-controlled", it would be ok (because it's not meant
to be upgraded at all)? But if it's software-controlled it is not? A set
of rules that require this kind of nitpicking is just broken.
Linus
Linus Torvalds <[email protected]> writes:
> But the whole point was to just show how silly the whole "upgradable" vs
> "not upgradable" discussion is. We're literally talking about something
> where apparently it matters to the GPLv3 whether a pin on a chip is
> connected to software or hardware (or not at all). Is that sane?
I admit I haven't read the last GPLv3 draft, but for me the "freedom"
(=> benefit) is not the ability to alter software in some specific
existing device, but rather to take the software, perhaps modify it
and use in _my_ hardware device.
I can't use a modified kernel with their TIVO platform? No problem,
Chinese can make a better one, or maybe some mini ITX board from
VIA would do.
Though I think "upgrading" engine settings of my car could be nice,
never had time to look at it :-)
--
Krzysztof Halasa
> Many people believe that the GPL infects across
> shared library links. Whether or not that's true, it's never been
> tested in court, and probably depends on the legal jurisdiction.
It's absurd and has been thoroughly refuted many times. A program can link
with a shared library that was wholly developed *after* that program was
developed. How can a work be a derivative work of a work that was made after
it and fully independently of it?
The GPL only infects derivative works. You cannot create a work that must be
subject to the GPL unless you creatively copy significant protectable
expression from a GPL'd work when you create that work.
For example, I write a program that dynamically links to a 'malloc.so'
library. You then later write your own 'malloc.so' library with some funky
allocator in it and you GPL it. Nobody could ever sanely argue that someone
linking my program with your library changes the licensing requirements of
my program.
The law is really quite clear that one work can only be derivative work of
another if it contains significant protectable expression copied from that
work.
[from another post]
> But OTOH, linking code makes it a combined work.
Linking does not create a work, it only combines existing works. Dynamic
linking is not a creative authoring process and cannot produce a work for
copyright purposes, derivative or otherwise.
There certainly might be cases where two works dynamically link to each
other and one is also a derivative work of the other. But such a general
rule totally defies common sense. The law is clear that a derivative work is
made when you creatively take significant protected expression from another
work, beyond what is needed for interoperability.
Linking may make a work in an informal sense, but it does not create a work
for copyright purposes. Only creative expression makes a work. Linkers do
not express themselves creatively, artfully picking and choosing one among
dozens of equally-valid options.
DS
On Wed, 27 Sep 2006, Krzysztof Halasa wrote:
>
> Though I think "upgrading" engine settings of my car could be nice,
> never had time to look at it :-)
>
Depending on the model of your car, you might be surprised what the gains
could be. Lots of ECMs are shipped out with very conservative timings.
This is especially true of turbocharged cars, where the effect of the
turbocharger increasing the normal relative constant of atmospheric
pressure also tends to multiply many of the other factors as well.
Thanks,
Chase Venters
Ar Mer, 2006-09-27 am 13:41 -0700, ysgrifennodd Linus Torvalds:
> I think the hatred of pins became so high that it became almost
> unacceptable for motherboard designers to add them on PC's. Nobody wants
> to open their case any more ;)
Actually some of the smarter ones wired it to the SMM indications in the
chipset so that only BIOS controlled SMM management code can do the
update and that does checksumming or basic very crude crypto type
checks.
Fortunately the thought of a slammer equivalent that erases the firmware
isn't something most vendors want to risk their stock price and business
on.
Alan
On Wed, Sep 27, 2006 at 01:37:37PM -0500, Chase Venters wrote:
> I think one thing that should have happened a _lot_ sooner is that you and
> others should have made clear to the startled community that you object
> precisely to the anti-Tivoization clause, not because of any technical
> reason or interpretation but because you don't see anything wrong with
> Tivo's use of Linux. It would have been nice but totally optional to
> engage in dialogue with the FSF. But slandering them about their license
> development process, or their intentions with regard to using Linux as
> leverage, is counterproductive whether true or not.
This has been made clear to Eben and the FSF, for a long time. The
FSF has simply chosen not to listen to Linus and other members of the
kernel community. In fact, I've never seen any interest in a
dialogue, just a pseudo-dialogue where "input is solicited", and then
as near as far as I can tell, at least on the anti-Tivo issue, has
been simply ignored. But in any case, it should not have come as a
surprise and should not have startled anyone.
Regards,
- Ted
On Thu, 28 Sep 2006, Alan Cox wrote:
>
> Actually some of the smarter ones wired it to the SMM indications in the
> chipset so that only BIOS controlled SMM management code can do the
> update and that does checksumming or basic very crude crypto type
> checks.
>
> Fortunately the thought of a slammer equivalent that erases the firmware
> isn't something most vendors want to risk their stock price and business
> on.
Amen to that.
I'm pretty convinced that some companies sometimes go to unreasonable
lengths in their fear of liability suits (but in their defense, it's not
like the US legal environment isn't encouraging it), but I think a lot of
people end up doing things like that our of very basic prudence.
Not because they are "evil" or even mean anything bad at all, but simply
because they have their own reasons to believe strongly that people must
not upgrade their hardware.
Most technology people may _want_ to upgrade their hardware, but when you
look at all the spyware "upgrades" people get on their windows boxes, you
can certainly understand why there are reasons for things like strong
crypto upgrades with secret keys even quite apart from anything like the
RIAA.
Linus
On Thu, 2006-09-28 at 00:01 +0100, Alan Cox wrote:
> Ar Mer, 2006-09-27 am 13:41 -0700, ysgrifennodd Linus Torvalds:
> > I think the hatred of pins became so high that it became almost
> > unacceptable for motherboard designers to add them on PC's. Nobody wants
> > to open their case any more ;)
>
> Actually some of the smarter ones wired it to the SMM indications in the
> chipset so that only BIOS controlled SMM management code can do the
> update and that does checksumming or basic very crude crypto type
> checks.
>
> Fortunately the thought of a slammer equivalent that erases the firmware
> isn't something most vendors want to risk their stock price and business
> on.
This protection is treacherous and unethical! It restricts your ultimate
freedom to render your own box useless. :)
tglx
On Wed, 27 Sep 2006, Theodore Tso wrote:
> On Wed, Sep 27, 2006 at 01:37:37PM -0500, Chase Venters wrote:
>> I think one thing that should have happened a _lot_ sooner is that you and
>> others should have made clear to the startled community that you object
>> precisely to the anti-Tivoization clause, not because of any technical
>> reason or interpretation but because you don't see anything wrong with
>> Tivo's use of Linux. It would have been nice but totally optional to
>> engage in dialogue with the FSF. But slandering them about their license
>> development process, or their intentions with regard to using Linux as
>> leverage, is counterproductive whether true or not.
>
> This has been made clear to Eben and the FSF, for a long time. The
> FSF has simply chosen not to listen to Linus and other members of the
> kernel community. In fact, I've never seen any interest in a
> dialogue, just a pseudo-dialogue where "input is solicited", and then
> as near as far as I can tell, at least on the anti-Tivo issue, has
> been simply ignored. But in any case, it should not have come as a
> surprise and should not have startled anyone.
Perhaps I came off too strong, but I meant what I said, and I'm not only
talking about things being made clear with Eben and the FSF. Frankly, I
don't know what did or did not happen behind closed doors and it would be
wrong of me to make assumptions about that.
What I was really addressing here is that the whole F/OSS community
exploded over the news that Linux was not adopting the GPLv3. I think it's
fair to say that the reason why Linux is not adopting GPLv3 (aside from
the very practical matter of gaining the consensus of copyright holders)
is that Linus and other top copyright holders don't think what Tivo is
doing is wrong. But when that statement first came out, it was almost lost
in the noise of "The FSF is not going to listen to us, and what about
encryption keys?" The former probably has no place outside of LKML; the
latter is the sort of thing you'd bring up at gplv3.fsf.org if you wanted
to participate in the process.
So a lot of people spent a lot of time thinking Linus was just confused
about the license and its intentions and that if they could just show him
why he was reading it wrong he'd change his mind. The point I'm trying
to make here about what _should_ have happened a lot sooner is that the
problem should have been defined in the simplest possible terms: "We don't
want to cut off Tivo. We don't think they are in the wrong." Then it boils
down to a simple difference in philosophy and everyone can move on.
> Regards,
>
> - Ted
Thanks,
Chase Venters
On Wednesday September 27, [email protected] wrote:
>
> What I was really addressing here is that the whole F/OSS community
> exploded over the news that Linux was not adopting the GPLv3. I think it's
> fair to say that the reason why Linux is not adopting GPLv3 (aside from
> the very practical matter of gaining the consensus of copyright holders)
> is that Linus and other top copyright holders don't think what Tivo is
> doing is wrong. But when that statement first came out, it was almost lost
> in the noise of "The FSF is not going to listen to us, and what about
> encryption keys?" The former probably has no place outside of LKML; the
> latter is the sort of thing you'd bring up at gplv3.fsf.org if you wanted
> to participate in the process.
I don't think that anyone is saying that what Tivo is doing isn't
wrong. What is being said is that the license is the wrong place to
try to stop this sort of behaviour. It is too broad a brush.
There are a number of different reasons for wanting to use
technological measures for stopping people from re-purposing a device
and they aren't necessarily all bad. Do we want our code to be
prohibited from being used in all of these cases? Some people think
not.
But I wonder if GPLv3 will really stop Tivo....
I just read it again and saw - at the end of section 1.
The Corresponding Source need not include anything that users can
regenerate automatically from other parts of the Corresponding
Source.
So if Tivo included the code they used to generate the key, then they
don't need to include the key itself :-) Users can regenerate the key
form that program. Not sure how long it will take though.
NeilBrown
From: Neil Brown <[email protected]>
Date: Thu, 28 Sep 2006 10:03:57 +1000
> I don't think that anyone is saying that what Tivo is doing isn't
> wrong. What is being said is that the license is the wrong place to
> try to stop this sort of behaviour. It is too broad a brush.
I totally agree. The poll was a stated position on the gplv3, it
didn't attempt to represent the positions on the core issues of
patents and DRM.
I personally do have a problem with what Tivo does with code
that I wrote, yet I also recognize that a license might not
be the best place to deal with this.
Willy Tarreau wrote:
> On Mon, Sep 25, 2006 at 02:00:05PM +0200, Arjan van de Ven wrote:
>> On Mon, 2006-09-25 at 06:40 +0200, Willy Tarreau wrote:
>>> do a few months back. After all the fuss about binary-only modules
>>> incompatibility with GPLv2, I wanted to change the license of haproxy
>>> to explicitly permit external binary-only code to be linked with it.
>> LGPL is then a logical and commonly accepted choice for a license
>
> Not exactly, because I don't want people to include interesting parts
> of my code into their binary-only programs. I just want to allow
> people to link binary-only modules with my program. However, programs
> that are already GPLv2 are welcome to steal part of my code.
>
That sounds like the LGPL to me...
-hpa
On Wed, 27 Sep 2006, Chase Venters wrote:
> On Wed, 27 Sep 2006, Theodore Tso wrote:
> >
> > This has been made clear to Eben and the FSF, for a long time. The
> > FSF has simply chosen not to listen to Linus and other members of the
> > kernel community. In fact, I've never seen any interest in a
> > dialogue, just a pseudo-dialogue where "input is solicited", and then
> > as near as far as I can tell, at least on the anti-Tivo issue, has
> > been simply ignored. But in any case, it should not have come as a
> > surprise and should not have startled anyone.
>
> Perhaps I came off too strong, but I meant what I said, and I'm not only
> talking about things being made clear with Eben and the FSF. Frankly, I don't
> know what did or did not happen behind closed doors and it would be wrong of
> me to make assumptions about that.
I think a lot of people may be confused because what they see is
(a) Something that has been brewing for a _loong_ time. There has been
the FSF position, and there has been the open source position, and
the two have been very clearly separated.
At the same time, both camps have been trying to be somewhat polite,
as long as the fact that the split does clearly exist doesn't
actually _matter_.
So, for example, the GPLv2 has been acceptable to all parties (which
is what I argue is its great strength), and practically you've not
actually had to care. In fact, most programmers _still_ probably
don't care. A lot of people use a license not because they "chose"
it, but because they work on a project where somebody else chose the
license for them originally.
This, btw, is probably why some things matter to me more than many
other kernel developers. I'm the only one who really had an actual
choice of licenses. Relatively, very few other people ever had to
even make that choice, and as such, I suspect that a number of people
just feel that it wasn't their choice in the first place and that
they don't care that deeply.
Ted is actually likely one of the very few people who were actually
involved when the choice of GPLv2 happened, and is in the almost
unique situation of probably having an email from me asking if he was
ok with switching from my original license to the GPLv2. Ted?
So we have something that has been going on for more than a decade
(the actual name of "Open Source" happened in 1998, but it wasn't
like the _issues_ with the FSF hadn't been brewing before that too),
but that has mostly been under the surface, because there has been no
_practical_ reason to react to it.
(b) This tension and the standpoints of the two sides has definitely
_not_ been unknown to the people involved. Trust me, the FSF knew
very well that the kernel standpoint on the GPLv2 was that Tivo was
legally in the right, and that it was all ok in that sense.
Now, a number of people didn't necessarily _like_ what Tivo does or
how they did it, but the whole rabid "this must be stopped" thing was
from the FSF side.
> What I was really addressing here is that the whole F/OSS community
> exploded over the news that Linux was not adopting the GPLv3.
Not really. It wasn't even news. The kernel has had the "v2 only" thing
explicitly for more than half a decade, and I have personally tried to
make it very clear that even before that, it never had anything else (ie
it very much _had_ a specific license version, just by including the damn
thing, and the kernel has _never_ had the "v2 or any later" language).
So legally, Linux has generally been v2-only since 1992, and just to head
off any confusion, it's even been very explicit for the last five years.
So what's the "news" really?
I'll tell you what the news is: the FSF was going along, _as_if_ they had
the support of not just their own supporters, but the OSS community too,
even though they knew _full_well_ what the differences were.
In fact, a lot of people have felt that they've been riding of the
coat-tails of Linux - without ever realizing that one of the things that
made Linux and Open Source so successful was exactly the fact that we did
_not_ buy into the rhetoric and the extremism.
Claiming that the FSF didn't know, and that this took them "by surprise"
is just ludicrous. Richard Stallman has very vocally complained about the
Open Source people having "forgotten" what was important, and has talked
about me as if I'm some half-wit who doesn't understand the "real" issue.
In fact, they still do that. Trying to explain the "mis-understanding".
It was _never_ a mis-understanding. And I think the only surprise here was
not how the kernel community felt, but the fact that Richard and Eben had
probably counted on us just not standing up for it.
THAT is the surprise. The fact that we had the _gall_ to tell them that
we didn't agree with them.
The fact that we didn't agree was not a surprise at all.
> I think it's fair to say that the reason why Linux is not adopting GPLv3
> (aside from the very practical matter of gaining the consensus of
> copyright holders) is that Linus and other top copyright holders don't
> think what Tivo is doing is wrong.
Well, I personally believe that Tivo did everything right, but in the
interest of full disclosure, sure, some people even _do_ belive that what
Tivo is doing is wrong, but pretty much everybody agrees that trying to
stop them is _worse_ than the thing it tries to fix.
Because the even _deeper_ rift between the FSF and the whole "Open Source"
community is not over "Tivo" or any particular detail like that, but
between "practical and useful" and "ideology".
And no, it's not a black-and-white issue. There are all kinds of shades of
gray, and "practical" and "ideology" aren't even mutually incompatible!
It's just that sometimes they say different things.
And yes, I personally exploded, but hey, it's been brewing for over a
decade. Let me over-react sometimes. I'm still always right ;)
Linus
On Wednesday 27 September 2006 20:18, Linus Torvalds wrote:
> I think a lot of people may be confused because what they see is
>
> (a) Something that has been brewing for a _loong_ time. There has been
> the FSF position, and there has been the open source position, and
> the two have been very clearly separated.
But whats wrong with that? The FSF is a "project" (or really, a group
of projects, because some FSF projects don't agree with the FSF
position either), it isn't them official voice of the community.
The open source community (which, of course, the FSF hates the term
"open source" because it undermines their authority) is made up of
many projects, each with their own official line. RMS has his, you
have yours, GNOME has theirs, KDE has theirs, and so on.
> At the same time, both camps have been trying to be somewhat polite,
> as long as the fact that the split does clearly exist doesn't
> actually _matter_.
I agree. It doesn't matter because everyone is free to use whatever
version they want of the GPL. Of course, people do also recognize that
the GPL2 vs GPL3 argument is just a more subtle version of whats been
going on for years with BSD vs GPL.
> So, for example, the GPLv2 has been acceptable to all parties (which
> is what I argue is its great strength), and practically you've not
> actually had to care. In fact, most programmers _still_ probably
> don't care. A lot of people use a license not because they "chose"
> it, but because they work on a project where somebody else chose the
> license for them originally.
Programmers don't care because we aren't lawyers. I mean, few things
are stated so simply, but lets face it, law is boring to quite a few
geeks, and the intersection between geeks who code and geeks who law
is very small.
> (b) This tension and the standpoints of the two sides has definitely
> _not_ been unknown to the people involved. Trust me, the FSF knew
> very well that the kernel standpoint on the GPLv2 was that Tivo was
> legally in the right, and that it was all ok in that sense.
>
> Now, a number of people didn't necessarily _like_ what Tivo does or
> how they did it, but the whole rabid "this must be stopped" thing was
> from the FSF side.
Which is why I said above, the FSF is not the official voice of the
community, but instead one of many, and also no longer one of the
loudest.
> > What I was really addressing here is that the whole F/OSS community
> > exploded over the news that Linux was not adopting the GPLv3.
>
> Not really. It wasn't even news. The kernel has had the "v2 only" thing
> explicitly for more than half a decade, and I have personally tried to
> make it very clear that even before that, it never had anything else (ie
> it very much _had_ a specific license version, just by including the damn
> thing, and the kernel has _never_ had the "v2 or any later" language).
Wasn't that just to prevent the FSF from going evil and juping all your code?
> In fact, a lot of people have felt that they've been riding of the
> coat-tails of Linux - without ever realizing that one of the things that
> made Linux and Open Source so successful was exactly the fact that we did
> _not_ buy into the rhetoric and the extremism.
The only problem is that, alternatively, the FOSS movement was so
strong because of RMS's kool-aid everyone drank. The community has
teeth, and this is in partly because of the actions of the FSF. We
defend ourselves when we need to.
Its just that, at least with the Tivo case, that the defense went a tad too far.
> Claiming that the FSF didn't know, and that this took them "by surprise"
> is just ludicrous. Richard Stallman has very vocally complained about the
> Open Source people having "forgotten" what was important, and has talked
> about me as if I'm some half-wit who doesn't understand the "real" issue.
The real issue, in my opinion, is that RMS found out that he no longer
leads the community, and his power base is a lot smaller than it used
to be. The FSF itself is a lot less relevant than it was 10 years ago.
> In fact, they still do that. Trying to explain the "mis-understanding".
Ego does wonders.
> Because the even _deeper_ rift between the FSF and the whole "Open Source"
> community is not over "Tivo" or any particular detail like that, but
> between "practical and useful" and "ideology".
I agree. I totally agree. The rift exists _not_ because the OSS
community wants to do its own thing, but because the FSF are no longer
the overlords of the Bazaar that they thought they were.
> Linus
Also, I expect to get flamed for what I've written above, especially
from RMS in some form or another. Thats fine. The FSF has given the
community a lot, and us, the community, has given a lot in return.
That doesn't, however, give RMS the right to be some sort of King. The
OSS community, instead, is a form of a democracy, and you vote with
your code.
Linus, you voted with your code.
--
Patrick McFarland || http://AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
Ar Mer, 2006-09-27 am 17:18 -0700, ysgrifennodd Linus Torvalds:
> _not_ been unknown to the people involved. Trust me, the FSF knew
> very well that the kernel standpoint on the GPLv2 was that Tivo was
s/kernel/Linus and some other copyright holders/
I reserve the right some day to attempt to sue the ass of people who
tivo-ise my code. Hey I might lose but I reserve the right to.
That said the FSF DRM clause is problematic, the GPLv2 leaves things in
a slightly woolly situation with regards to keys in terms of whether
they are part of the scripts etc (for the benefit of anyone's corporate
lawyers: I think they usually are and I've said so in public). That
vagueness is actually a good thing because it lets the legal system
interpret the intent of the license and the situation at hand. Lawyers
generally don't like vaguenesses of course and the GPLv3 draft tries to
be non-vague. It's also flawed as a result precisely because it has to
cover every imaginable case in one paragraph.
There are lots of problems with the current v3 draft
1. "anything users can regenerate automatically" is horribly vague.
Automatically *how* - with a $25,000 proprietary tool for example ....
2. Section 3 is US specific and doesn't really work. In some parts of
the world breaking a technological protection seems to be a criminal
matter and you can't waive the criminal law.
3. Additional terms is a license explosion and the interactions between
them will get ugly.
4. The geographical clause still has the same bug as GPLv2. Who is the
"original author" and what happens when I write a new OS and import 90%
of Linux into it - am I the original author now ?
Some of this is quite fixable - the "regenerate automatically" for
example and the glitches in the patent clauses are just a matter of a
little more lawyering, others like the DRM clauses don't work and also
don't really address rented equipment for example.
Personally I'm still hopeful the final GPLv3 will fix at least the
majority of problems. I'm not sure it ultimately matters for the kernel
whether it does or not, but for the general case of free software it is
clearly important to get it right.
Alan
On Wed, Sep 27, 2006 at 05:18:42PM -0700, Linus Torvalds wrote:
> Because the even _deeper_ rift between the FSF and the whole "Open Source"
> community is not over "Tivo" or any particular detail like that, but
> between "practical and useful" and "ideology".
... and then there are those of us who know very well what ideology is:
the choice weapon of talentless hacks hell-bent on gaining and keeping
influence and never doing original research or any other honest work.
Al "I've grown up in USSR and USA feels just like home" Viro
On Wednesday 27 September 2006 19:16, Chase Venters wrote:
>On Wed, 27 Sep 2006, Theodore Tso wrote:
>> On Wed, Sep 27, 2006 at 01:37:37PM -0500, Chase Venters wrote:
>>> I think one thing that should have happened a _lot_ sooner is that you
>>> and others should have made clear to the startled community that you
>>> object precisely to the anti-Tivoization clause, not because of any
>>> technical reason or interpretation but because you don't see anything
>>> wrong with Tivo's use of Linux. It would have been nice but totally
>>> optional to engage in dialogue with the FSF. But slandering them about
>>> their license development process, or their intentions with regard to
>>> using Linux as leverage, is counterproductive whether true or not.
>>
>> This has been made clear to Eben and the FSF, for a long time. The
>> FSF has simply chosen not to listen to Linus and other members of the
>> kernel community. In fact, I've never seen any interest in a
>> dialogue, just a pseudo-dialogue where "input is solicited", and then
>> as near as far as I can tell, at least on the anti-Tivo issue, has
>> been simply ignored. But in any case, it should not have come as a
>> surprise and should not have startled anyone.
>
>Perhaps I came off too strong, but I meant what I said, and I'm not only
>talking about things being made clear with Eben and the FSF. Frankly, I
>don't know what did or did not happen behind closed doors and it would be
>wrong of me to make assumptions about that.
>
>What I was really addressing here is that the whole F/OSS community
>exploded over the news that Linux was not adopting the GPLv3. I think
> it's fair to say that the reason why Linux is not adopting GPLv3 (aside
> from the very practical matter of gaining the consensus of copyright
> holders) is that Linus and other top copyright holders don't think what
> Tivo is doing is wrong. But when that statement first came out, it was
> almost lost in the noise of "The FSF is not going to listen to us, and
> what about encryption keys?" The former probably has no place outside of
> LKML; the latter is the sort of thing you'd bring up at gplv3.fsf.org if
> you wanted to participate in the process.
>
And this last statement pulls my trigger, Chase. Admittedly, the kernel is
not the whole of linux, and never has been, but without it, where are we?
Based on that, I find the attitude of the FSF to be downright overbearing
when they expect each and every one of the KERNEL developers to go get an
account and go through all the lollygagging around it takes to actually
leave a message through the channels the FSF expects you to use. I don't
care what you call it, it boils down at the end of the day to a PITA.
I'm here as a lurker, and potentially a small bit of wisdom based on
nothing more than my somewhat advanced age, but it seems to me that if the
FSF wanted real input from the guys & gals submitting patches on a daily
basis, then they owed it to ALL of you to come to this list and ASK! AND
GIVE WEIGHT TO THE ANSWERS GIVEN. The fact that they didn't do this in an
open discussion forum such as this, speaks whole sets of encyclopedias
vis-a-vis their apparent consideration (or should I say disdain?) for
those that do the real work.
This, FSF & RMS, is all about 'open' source, so bring the discussion to an
'open' forum instead of treating the movers & shakers present here in such
large numbers as just so much rabble, to be blown away with the water
cannon of your so-called legal wisdom when we get unruly.
Well, seeing as how we must be rabble, now we've been roused. Bring your
arguments to the table and let a consensus, if indeed there can be one,
gradually form in a manner that all can at least agree to disagree on.
And do it in plain language that even some who do not speak english as a
first language can easily understand. We need comprehension, not
legaleze.
>So a lot of people spent a lot of time thinking Linus was just confused
>about the license and its intentions and that if they could just show him
>why he was reading it wrong he'd change his mind. The point I'm trying
>to make here about what _should_ have happened a lot sooner is that the
>problem should have been defined in the simplest possible terms: "We
> don't want to cut off Tivo. We don't think they are in the wrong." Then
> it boils down to a simple difference in philosophy and everyone can move
> on.
>
>> Regards,
>>
>> - Ted
>
>Thanks,
>Chase Venters
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Thu, 2006-09-28 at 02:35 +0100, Al Viro wrote:
> On Wed, Sep 27, 2006 at 05:18:42PM -0700, Linus Torvalds wrote:
>
> > Because the even _deeper_ rift between the FSF and the whole "Open Source"
> > community is not over "Tivo" or any particular detail like that, but
> > between "practical and useful" and "ideology".
>
> ... and then there are those of us who know very well what ideology is:
> the choice weapon of talentless hacks hell-bent on gaining and keeping
> influence and never doing original research or any other honest work.
Please, do not tell me you had RMS in mind when you wrote it!
> Al "I've grown up in USSR and USA feels just like home" Viro
Right!
On Wed, 27 Sep 2006, Patrick McFarland wrote:
> On Wednesday 27 September 2006 20:18, Linus Torvalds wrote:
> > I think a lot of people may be confused because what they see is
> >
> > (a) Something that has been brewing for a _loong_ time. There has been
> > the FSF position, and there has been the open source position, and
> > the two have been very clearly separated.
>
> But whats wrong with that? The FSF is a "project" (or really, a group
> of projects, because some FSF projects don't agree with the FSF
> position either), it isn't them official voice of the community.
Right, I'm not saying that there is anything wrong with having two
positions.
In many ways, I'm saying the opposite. I'm saying that we should _expect_
people to have different opinions. Everybody has their own opinion anyway,
and expecting people not have different opinions (especially programmers,
who are a rather opinionated lot in the first place) is just not
realistic.
There's absolutely nothing wrong with having a very wide consensus among a
very varied developer base. In fact, I think that's _great_.
And the reason I'm speaking out against the GPLv3 is that it is trying to
"sort the chaff from the wheat". The FSF is apparently not happy with a
wide community appeal - they want _their_ standpoint to be the one that
matters.
I have all through the "discussion" tried to explain that the great thing
about the GPLv2 is that it allows all these people with totally different
ideals to come together. It doesn't have to be "perfect" for any
particular group - it's very perfection comes not from it's language, but
the very fact that it's _acceptable_ to a very wide group.
When the FSF tries to "narrow it down", they kill the whole point of it.
The license suddenly is not a thing to get around and enjoy, it's become a
weapon to be used to attack the enemy.
Here in the US, the only watchable TV news program is "The Daily Show"
with Jon Stewart. One of his fairly recurring themes is about how US
politics is destroyed by all these passionate and vocal extremists, and he
asks whether there can ever be a really passionate moderate. "Can you be
passionate about the middle road?"
Dammit, I want to be a "Passionate Moderate". I'm passionate about just
people being able to work together on the same license, without this
extremism.
So here's my _real_ cry for freedom:
"It's _ok_ to be commercial and do it just for money. And yes, you can
even have a FSF badge, and carry Stallmans manifesto around everywhere
you go. And yes, we accept people who like cryptography, and we accept
people who aren't our friends. You don't have to believe exactly like we
believe!"
And for fifteen years, the GPLv2 has been a great umbrella for that.
The FSF is throwing that away, because they don't _want_ to work with
people who don't share their ideals.
> > At the same time, both camps have been trying to be somewhat polite,
> > as long as the fact that the split does clearly exist doesn't
> > actually _matter_.
>
> I agree. It doesn't matter because everyone is free to use whatever
> version they want of the GPL. Of course, people do also recognize that
> the GPL2 vs GPL3 argument is just a more subtle version of whats been
> going on for years with BSD vs GPL.
That's part of what really gets my goat. I spent too much time arguing
with crazy BSD people who tried to tell me that _their_ license was "true
freedom". The FSF shills echo those old BSD cries closely - even though
they are on the exact opposite side of the spectrum on the "freedom" part.
I hated BSD people who just couldn't shut up about their complaining about
my choice of license back then (the good old BSD/MIT vs GPL flamewars).
> > In fact, most programmers _still_ probably
> > don't care. A lot of people use a license not because they "chose"
> > it, but because they work on a project where somebody else chose the
> > license for them originally.
>
> Programmers don't care because we aren't lawyers. I mean, few things
> are stated so simply, but lets face it, law is boring to quite a few
> geeks, and the intersection between geeks who code and geeks who law
> is very small.
I think a _lot_ of programmers care very deeply indeed about the licenses.
I certainly do. I wouldn't want to be a lawyer, but I care about how my
code gets used.
That said, I don't care how everybody _elses_ code gets used, which is
apparently one of the differences between me and rms.
> > Not really. It wasn't even news. The kernel has had the "v2 only" thing
> > explicitly for more than half a decade, and I have personally tried to
> > make it very clear that even before that, it never had anything else (ie
> > it very much _had_ a specific license version, just by including the damn
> > thing, and the kernel has _never_ had the "v2 or any later" language).
>
> Wasn't that just to prevent the FSF from going evil and juping all your code?
Well, initially it wasn't even a conscious "I don't trust the FSF" thing.
But when I chose the GPL (v2, back then) I chose _that_ license. There was
absolutely no need for me to say "or later". If the GPLv2 ever really
turns out to be a bad license, we can re-license _then_.
Yes, it would be really really painful, but I think the "or later" wording
is worse. How can you _ever_ sign anything sight unseen? That's just
stupid, and that's totally regardless of any worries about the FSF.
Later, when I did start having doubts about the FSF, I just made it even
more clear, since some people wondered.
> The only problem is that, alternatively, the FOSS movement was so
> strong because of RMS's kool-aid everyone drank. The community has
> teeth, and this is in partly because of the actions of the FSF. We
> defend ourselves when we need to.
>
> Its just that, at least with the Tivo case, that the defense went a tad too
> far.
I think the FSF has always alienated as many (or more) people as they
befriended, but maybe that's just me. I was looking for old newsgroup
threads about this earlier in the week, and noticed somebody in the BSD
camp saying that I was using the GPL, but that I wasn't as radical as rms.
And iirc, that was from 1993, when Linux was virtually unknown.
So I think that not being too extreme is a _good_ thing. It's how you can
get more people involved.
So everybody - join the "Passionate Moderate" movement, even if you're not
in the US. We're not passionate about any of the issues, we are just
_really_ fed up with extreme opinions! And we're not afraid to say so!
[ The really sad part is: that was only _somewhat_ in jest. Dammit,
sometimes I think we really need that party! ]
Linus
On Wed, 27 Sep 2006, Sergey Panov wrote:
>
> Please, do not tell me you had RMS in mind when you wrote it!
You're talking to Al "even less polite than Linus" Viro, so I wouldn't
take any bets on it.
Or he might be talking about me.
There's a reason Al is widely feared in the linux-kernel mailing list
community.
The Mexicans have the Chupacabra. We have Al Viro. If you hear him roar,
just _pray_ he's about to dissect somebody elses code than yours.. There
is no point in running.
Linus
On Wed, 2006-09-27 at 20:15 -0700, Linus Torvalds wrote:
> So everybody - join the "Passionate Moderate" movement, even if you're not
> in the US. We're not passionate about any of the issues, we are just
> _really_ fed up with extreme opinions! And we're not afraid to say so!
I hope you understand that "Passionate Moderate" is an oxymoron. And I
do not believe RMS is a commie! To me he is quite a moderate figure
(very strong principals and no diplomatic skills at all, but it does not
mean he is an extremist).
On Wed, 27 Sep 2006, Sergey Panov wrote:
>
> I hope you understand that "Passionate Moderate" is an oxymoron.
No. It's a joke.
But it's a sad, serious, one. You really don't want it explained to you.
It's too painful.
> And I do not believe RMS is a commie!
Ehh. Nobody called him a commie.
I said he was an extremist (and tastes differ, but I think most people
would agree). And he _has_ written a manifesto. I'm not kidding. Really.
"How soon they forget.."
One thing that I have realized during some of these discussions is that a
_lot_ of people have literally grown up during all the "Open Source"
years, and really don't know anything about rms, GNU, or the reason Open
Source split from Free Software.
I'm feeling like an old fart, just because I still remember the BSD
license wars, and rms' manifesto, and all this crap.
For you young whippersnappers out there, let me tell you how it was when I
was young..
We had to walk uphill both ways
[ "In snow! Five feet deep!"
"No! Ten feet!"
"Calm down boys, I'm telling the story" ]
And we had all these rabid GPL haters that were laughing at us, and
telling us you could never make software under the GPL because none of the
commercial people would ever touch it and all programmers need to eat and
feed their kids..
[ "Tell them about when you killed a grizzly bear with your teeth,
gramps!"
"Shh, Tommy, that's a different story, shush now" ]
And Richard Stallman wrote a manifesto.
Thank God we still have google. "GNU manifesto" still finds it.
> To me he is quite a moderate figure
I'd hate to meet the people you call extreme.
> (very strong principals and no diplomatic skills at all, but it does not
> mean he is an extremist).
I have nothing funny to say here.
I was going to make a joke about the principals, but that's just low. It's
"principle". A "principal" is something totally different.
Anyway, I'd clearly in need of a drink, as all my "mad debating skillz"
are clearly leaving me, and I just find myself making all these silly
comments.
Linus
On Wednesday 27 September 2006 22:46, Sergey Panov wrote:
> On Wed, 2006-09-27 at 20:15 -0700, Linus Torvalds wrote:
> > So everybody - join the "Passionate Moderate" movement, even if you're
> > not in the US. We're not passionate about any of the issues, we are just
> > _really_ fed up with extreme opinions! And we're not afraid to say so!
>
> I hope you understand that "Passionate Moderate" is an oxymoron. And I
> do not believe RMS is a commie! To me he is quite a moderate figure
> (very strong principals and no diplomatic skills at all, but it does not
> mean he is an extremist).
After lots of careful consideration, I think it is fair to say that Stallman
vigorously and extremely promotes and stands by his ideals, but the ideals he
stands for aren't all that radical or extreme. That is the difference, isn't
it? Wouldn't we all love free software running on free hardware, supporting
free culture and talking over free spectrum? The biggest difference I've seen
in the movements is that one aims to strike a conservative and functional
balance while the other is always trying to push the envelope.
I sympathize with Richard on his avoidance of "open-source". I don't
necessarily take the same view, but I understand that his big concern is that
the message he feels is important will be lost. I also think some of the
things I've heard from the "open-source" side are too extreme - take, for
instance, ESR's idea that we don't need the GPL license at all. That sounds
like a nice world he's living in, but I'm not sure we're all on the same
planet yet.
The final GPLv3 may indeed go too far for many open-source supporters. But
then again, it is the FSF's license, and it should at least not surprise
anyone if they are more concerned with the ideals of the license rather than
current market realities. Market conditions change; ideals generally don't.
And I think society needs both kinds of people. We need strong leaders like
Linus to coordinate the effort of moving solar systems and strong idealists
like Richard to inspire minds. I'm not sure Linus or Richard would admit
this, but I speculate that in a world where only one of them existed, this
community would have accomplished far less than the one in which they both
act.
This is really why I got upset when I saw all the crap in the press over the
last few days. I think both sides have pissed the other off to the point that
some of us are actively forgetting that we're just, as Eben once
said, "singing slightly different lyrics to slightly different music, and
it's dissonant, and it jars us..."
Some amount of contention is naturally good, so long as it does not undermine
the great ends both movements are achieving. When our flamewars spill out
into the industry press, it's just likely to make both sides look crazy. I
wish that most people who choose to take sides could see (and acknowledge!)
the real value the other side has, even if they don't agree with the approach
or phraseology. And I wish that more of us wouldn't pick sides; that we'd be
those "Passionate Moderates" Linus just invented. But we do need loud voices!
Thanks,
Chase Venters
On Wed, 2006-09-27 at 21:13 -0700, Linus Torvalds wrote:
>
> On Wed, 27 Sep 2006, Sergey Panov wrote:
> >
> > I hope you understand that "Passionate Moderate" is an oxymoron.
>
> No. It's a joke.
>
> But it's a sad, serious, one. You really don't want it explained to you.
> It's too painful.
>
> > And I do not believe RMS is a commie!
>
> Ehh. Nobody called him a commie.
>
> I said he was an extremist (and tastes differ, but I think most people
> would agree). And he _has_ written a manifesto. I'm not kidding. Really.
>
> "How soon they forget.."
>
I appreciate it was not : "Ein Gespenst geht um in Europa ... "
> One thing that I have realized during some of these discussions is that a
> _lot_ of people have literally grown up during all the "Open Source"
> years, and really don't know anything about rms, GNU, or the reason Open
> Source split from Free Software.
>
> I'm feeling like an old fart, just because I still remember the BSD
> license wars, and rms' manifesto, and all this crap.
>
> For you young whippersnappers out there, let me tell you how it was when I
> was young..
>
FYI: I am using (in/on my home network) nothing but YOUR kernel with GNU
tools since 1993. I was A PhD student at the unnamed US university at
that time.
> We had to walk uphill both ways
>
> [ "In snow! Five feet deep!"
> "No! Ten feet!"
> "Calm down boys, I'm telling the story" ]
>
> And we had all these rabid GPL haters that were laughing at us, and
> telling us you could never make software under the GPL because none of the
> commercial people would ever touch it and all programmers need to eat and
> feed their kids..
>
> [ "Tell them about when you killed a grizzly bear with your teeth,
> gramps!"
>
> "Shh, Tommy, that's a different story, shush now" ]
It is nice to know you are not aware of the "grizzly? no, dushily"
Russian jock, people in Republic of Georgia might not appreciate.
> And Richard Stallman wrote a manifesto.
>
> Thank God we still have google. "GNU manifesto" still finds it.
http://www.gnu.org/gnu/manifesto.html. The funniest sentence is the first one:
"... the complete Unix-compatible software system which I am writing so
that I can give it away free to everyone who can use it."
> > To me he is quite a moderate figure
>
> I'd hate to meet the people you call extreme.
You are a happy individual from a happy country. Some of us were
unfortunate to be bourn in a less friendly environment.
> > (very strong principals and no diplomatic skills at all, but it does not
> > mean he is an extremist).
>
> I have nothing funny to say here.
>
> I was going to make a joke about the principals, but that's just low. It's
> "principle". A "principal" is something totally different.
>
> Anyway, I'd clearly in need of a drink, as all my "mad debating skillz"
> are clearly leaving me, and I just find myself making all these silly
> comments.
>
> Linus
On Wed, 2006-09-27 at 23:39 -0500, Chase Venters wrote:
> On Wednesday 27 September 2006 22:46, Sergey Panov wrote:
> > On Wed, 2006-09-27 at 20:15 -0700, Linus Torvalds wrote:
> > > So everybody - join the "Passionate Moderate" movement, even if you're
> > > not in the US. We're not passionate about any of the issues, we are just
> > > _really_ fed up with extreme opinions! And we're not afraid to say so!
> >
> > I hope you understand that "Passionate Moderate" is an oxymoron. And I
> > do not believe RMS is a commie! To me he is quite a moderate figure
> > (very strong principals and no diplomatic skills at all, but it does not
> > mean he is an extremist).
>
> After lots of careful consideration, I think it is fair to say that Stallman
> vigorously and extremely promotes and stands by his ideals, but the ideals he
> stands for aren't all that radical or extreme. That is the difference, isn't
> it? Wouldn't we all love free software running on free hardware, supporting
> free culture and talking over free spectrum? The biggest difference I've seen
> in the movements is that one aims to strike a conservative and functional
> balance while the other is always trying to push the envelope.
If that were true, then why is he trying to restrict people's freedom of
use? Face it: the GPLv3 is basically the GPLv2 + a load of restrictions
on how you are allowed to use the software. It is building on the same
traditions as the concepts of "Dictatorship of the proletariat" or
"PATRIOT act" whereby you are requested to give up a set of existing
freedoms in return for nebulous promises of a rosy future.
It is quite possible to fight for your ideals without compromising on
existing freedoms. That is what the FSF has failed to recognise.
Cheers,
Trond
Chase Venters wrote:
> I sympathize with Richard on his avoidance of "open-source". I don't
> necessarily take the same view, but I understand that his big concern is that
> the message he feels is important will be lost. I also think some of the
> things I've heard from the "open-source" side are too extreme - take, for
> instance, ESR's idea that we don't need the GPL license at all. That sounds
> like a nice world he's living in, but I'm not sure we're all on the same
> planet yet.
ESR is a nutcase too.
> The final GPLv3 may indeed go too far for many open-source supporters. But
> then again, it is the FSF's license, and it should at least not surprise
> anyone if they are more concerned with the ideals of the license rather than
> current market realities. Market conditions change; ideals generally don't.
As long as you can admit that FSF is divorced from reality...
Jeff
On Thu, 2006-09-28 at 01:15 -0400, Jeff Garzik wrote:
> Chase Venters wrote:
> > I sympathize with Richard on his avoidance of "open-source". I don't
> > necessarily take the same view, but I understand that his big concern is that
> > the message he feels is important will be lost. I also think some of the
> > things I've heard from the "open-source" side are too extreme - take, for
> > instance, ESR's idea that we don't need the GPL license at all. That sounds
> > like a nice world he's living in, but I'm not sure we're all on the same
> > planet yet.
>
> ESR is a nutcase too.
How did you manage to figure it out?
> > The final GPLv3 may indeed go too far for many open-source supporters. But
> > then again, it is the FSF's license, and it should at least not surprise
> > anyone if they are more concerned with the ideals of the license rather than
> > current market realities. Market conditions change; ideals generally don't.
>
> As long as you can admit that FSF is divorced from reality...
??? Ideals are always divorced from reality. But some shape it, and some
are irrelevant.
Sergey Panov wrote:
> On Thu, 2006-09-28 at 01:15 -0400, Jeff Garzik wrote:
>> Chase Venters wrote:
>>> The final GPLv3 may indeed go too far for many open-source supporters. But
>>> then again, it is the FSF's license, and it should at least not surprise
>>> anyone if they are more concerned with the ideals of the license rather than
>>> current market realities. Market conditions change; ideals generally don't.
>> As long as you can admit that FSF is divorced from reality...
>
> ??? Ideals are always divorced from reality. But some shape it, and some
> are irrelevant.
Since we have to deal with the reality of the license, I guess that
means GPLv3 is irrelevant.
Jeff
On Thu, Sep 28, 2006 at 01:27:03AM -0400, Sergey Panov wrote:
> On Thu, 2006-09-28 at 01:15 -0400, Jeff Garzik wrote:
> > Chase Venters wrote:
> > > I sympathize with Richard on his avoidance of "open-source". I don't
> > > necessarily take the same view, but I understand that his big concern is that
> > > the message he feels is important will be lost. I also think some of the
> > > things I've heard from the "open-source" side are too extreme - take, for
> > > instance, ESR's idea that we don't need the GPL license at all. That sounds
> > > like a nice world he's living in, but I'm not sure we're all on the same
> > > planet yet.
> >
> > ESR is a nutcase too.
>
> How did you manage to figure it out?
Well, you tell me... What would you say about the following kind of paper:
* it is generally assumed that conditions X, Y and Z are needed
to get the result with property P.
* in experiment [ref] P had been obtained despite the lack of all
aforementioned conditions.
* author will attempt to formulate the conditions sufficient to achieve
P, explaining the results of said experiment.
* hypothetical conditions described, their applicability to experiment
in question discussed.
* author has attempted to test his hypothetis.
* description of experiment, strongly implying that P has been
achieved as the result.
* conclusions.
The trouble being, results of experiment are available and P is profoundly
_not_ observed. Moreover, if you start looking at the description in the
paper, you find a serious misdirection; what it really shows is P', which
is considerably weaker than P. The differences are systematically glossed
over; experiment declared a success despite being a definite proof that stated
conditions are _NOT_ sufficient. Conclusions would be highly speculative
even if experiment had been successful. No discussion of alternative
explanations for the original results is to be found anywhere in the paper.
Paper is widely published on the web and is used for self-promotion worthy
of Prof. Vybegallo.
That's ESR for you. The paper in qustion is "The Cathedral and the Bazaar".
P is "coherent and stable system". ESR's experiment: fetchmail. Source
of that animal (and paper itself) are easily found. Have fun.
Alan Cox <[email protected]> writes:
>
> Fortunately the thought of a slammer equivalent that erases the firmware
> isn't something most vendors want to risk their stock price and business
> on.
AFAIK they do anyways. Stepan's /dev/flash worked on most systems
at least a couple of years ago. And I didn't think it used any SMM tricks.
-Andi
>People don't have a clue!
>
>The GPLv2 never _ever_ mentions "linking" or any other technical measure
>at all. Doing so would just be stupid (another problem with the GPLv3,
>btw). So people who think that the GPLv2 disallows "linking" with
>non-GPLv2 code had better go back and read the license again.
>
>Grep for it, if you want to. The word "link" simply DOES NOT EXIST IN THE
>LICENSE!
Hah then read LICENSE.LGPL!
"""Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License. This license, the GNU Lesser
General Public License, applies to certain designated libraries, and
is quite different from the ordinary General Public License. We use
this license for certain libraries in order to permit linking those
libraries into non-free programs."""
If the GPL does not mention linking at all, and therefore does not
really forbid it, why do we need an LGPL to allow linking then?
>What the GPLv2 actually talks about is _only_ about "derived work". And
>whether linking (dynamically, statically, or by using an army of worker
>gnomes that re-arrange the bits to their liking) means something is
>"derived or not" is a totally different issue, and is not something you
>can actually say one way or the other, because it will depend on the
>circumstances.
I would be of the opinion that dynamic linking does not make it a
derived work, because neither the ld program nor the ld-linux.so
dynamic linker knows whether -lfoo is actually GPL or not.
>> No. The definition of a derivative work is a legal one and not a
>> technical one.
And that is a major problem IMHO. If there is no definitive
[technical] answer to what constitues a derived work, and it leaves
you at risk to lose a case in court while it is a gray area.
Oh well back on the topic: A userspace app just is not a derivate
work of the kernel, for me at least.
>Now, it is also indisputable that if you _need_ to "link", it's a damn
>good sign that something is _very_likely_ to be derivative, but as Alan
>points out, you could do the same thing with RPC over a socket, and the
>fact that you did it technically differently really makes no real
>difference. So linking per se isn't the issue, and never has been.
Jan Engelhardt
--
>> >The last Q. is how good is the almost forgotten Hurd kernel?
>>
>> Wild guess: At most on par with Minix.
>
>...and here's a thing that most people forget: good code simply doesn't
>care about ideology, and ideology often does the wrong technical decisions
>because it's not about practical issues.
>
>The watch-word in Linux development has been "pragmatism". That's probably
>part of what drives the FSF wild about Linux in the first place. I care
>about _practical_ issues, not about wild goose chases.
>
>If I weren't into computers, I'd be in science. And the rules in science
>are the same: you simply can't do good science if you start with an
>agenda. If you say that you'll never touch high-energy physics because
>you find the atom bomb to be morally reprehensible, that's your right, but
>you have to also realize that then you can never actually understand the
>world, and do everything you may need to do.
>[...]
>In many ways, the GPLv3 is about "religion". They limit the technology
[...]
Oops, I think we misunderstand each other right now. I took the above question
as how functional (=good) is Hurd. I did not mean to talk about licensing here.
Jan Engelhardt
--
>>>>> "Linus" == Linus Torvalds <[email protected]> writes:
Linus> We have no trouble at all running programs with much worse
Linus> licenses than the GPLv3 (ie commercial programs). There is no
Linus> problem with user space being v3.
I guess you mean "proprietary" instead of "commercial" here.
Sam
--
Samuel Tardieu -- [email protected] -- http://www.rfc1149.net/
On Wed, 27 September 2006 17:18:42 -0700, Linus Torvalds wrote:
>
> In fact, most programmers _still_ probably
> don't care. A lot of people use a license not because they "chose"
> it, but because they work on a project where somebody else chose the
> license for them originally.
s/most programmers/some programmers/
While I can only speak for myself, I definitely had to make a decision
a couple of times without starting a kernel myself. Red Hat wanted me
to sign a piece of small-font paper assigning my copyright to JFFS2
over to them. My thoughts at the time were along the lines of "What
the fuck!!" and I had a lot of thinking to do, but didn't sign it.
My graph traversion code I did for my thesis should have been merged
into gcc, but I didn't even bother sending a patch. Copyright assign
my ***, thank you very much.
And that is in fact the primary reason, hacking gcc has been fun and I
would like to do more, from a purely technical point of view. But
having to sign a large amount of legalese is the kind of thing I may
have to do for a job, and they pay me for it. It is not the kind of
thing I do for fun. No fun, no money - hell, why should I do
something like that?!?
Thank you for not requiring copyright assignments, Linus.
J?rn
--
People will accept your ideas much more readily if you tell them
that Benjamin Franklin said it first.
-- unknown
J?rn Engel wrote:
> My graph traversion code I did for my thesis should have been merged
> into gcc, but I didn't even bother sending a patch. Copyright assign
> my ***, thank you very much.
hehe
For the miniscule patches I have contributed to gcc, I donated them to
the public domain...
> Thank you for not requiring copyright assignments, Linus.
Indeed.
Jeff
Jan Engelhardt <[email protected]> writes:
> Hah then read LICENSE.LGPL!
>
> """Most GNU software, including some libraries, is covered by the
> ordinary GNU General Public License. This license, the GNU Lesser
> General Public License, applies to certain designated libraries, and
> is quite different from the ordinary General Public License. We use
> this license for certain libraries in order to permit linking those
> libraries into non-free programs."""
>
> If the GPL does not mention linking at all, and therefore does not
> really forbid it, why do we need an LGPL to allow linking then?
Clarification, just as the system call clarification in the Linux
kernel COPYING file. By explicitly allowing dynamic linking the LGPL
makes it clear that it is ok and avoids a lot of legal uncertainty.
It may be that the that linking doesn't legally create a derived work,
and that a bunch of the claims in the GPL are invalid, but to find out
somebody has to bring it to court, get a judgement (not a settlement),
and appeal it all the way to the supreme court. And to be really sure
they'd have to do it in just about every country too.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Christer Weinigel <[email protected]> http://www.weinigel.se
On Wed, Sep 27, 2006 at 11:39:04PM -0500, Chase Venters wrote:
> This is really why I got upset when I saw all the crap in the press over the
> last few days. I think both sides have pissed the other off to the point that
> some of us are actively forgetting that we're just, as Eben once
> said, "singing slightly different lyrics to slightly different music, and
> it's dissonant, and it jars us..."
>
> Some amount of contention is naturally good, so long as it does not undermine
> the great ends both movements are achieving. When our flamewars spill out
> into the industry press, it's just likely to make both sides look crazy. I
> wish that most people who choose to take sides could see (and acknowledge!)
> the real value the other side has, even if they don't agree with the approach
> or phraseology. And I wish that more of us wouldn't pick sides; that we'd be
> those "Passionate Moderates" Linus just invented. But we do need loud voices!
I wonder if perhaps the solution should be that the GPLv3 draft should
be renamed to something else to allow RMS to create his new license that
does exactly what he wants it to do, without hijacking existing GPLv2
code using a license that in many people's opinion is NOT in the spirit
of the GPLv2 (which it could be argued overrides the "or later" part of
the license). The current GPLv3 draft may be in the spirit of what RMS
intended the GPLv2 to be, but it isn't in the spirit of what the GPLv2
says and does.
No one has a problem with people making new licenses. People have a
problem with people making new licenses and wanting to retroactively
replace existing licenses with a new and very different license.
Now what would be a good name for the GPLv3? GRLv1 (GNU Restricted
License v1) perhaps. :) That is essentially what it is doing.
Restricting what you can do with the code.
--
Len Sorensen
Hi Lennart :)
* Lennart Sorensen <[email protected]> dixit:
> I wonder if perhaps the solution should be that the GPLv3 draft
> should be renamed to something else to allow RMS to create his new
> license that does exactly what he wants it to do, without hijacking
> existing GPLv2 code using a license that in many people's opinion
> is NOT in the spirit of the GPLv2 (which it could be argued
> overrides the "or later" part of the license).
That's quite curious, because my wife (who doesn't have a great
software background and that knows FOSS and GPL through me) said
exactly the same when I told her yesterday the problem that people
like me, who has released code under GPLv2, may face if GPLv3 is
applied retroactively to every software that says "or any later
version". She said that of course anybody has the right of making new
licenses, but that, as far as she could tell, the new license
shouldn't be named "GPL" because it was very different from what we
now call "GPL". Of course her vision may be highly biased by what I
told her, but since I still don't have a clear position about all
this GPLv2 vs. GPLv3 issue, I don't think that the bias is so high.
Probably the renaming is just common sense and will avoid ALL
problems. People like me are concerned only because all GPLv2 that
doesn't state otherwise will be released automagically under GPLv3 as
soon as the latest draft is made the official version. Otherwise, I
wouldn't give a hump about any new license until I have the time to
read it and see if I like it.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Thu, 28 Sep 2006, J?rn Engel wrote:
>
> My graph traversion code I did for my thesis should have been merged
> into gcc, but I didn't even bother sending a patch. Copyright assign
> my ***, thank you very much.
Yeah, I don't see why the FSF does that. Or I kind of see why, but it has
always struck me as
(a) against the whole point of the license
and
(b) who the F*CK do they think they are?
I refuse to just sign over any copyrights I have. I gave you a license to
use them, if you can't live with that, then go fish in somebody elses
pond.
I had some code I tried to give to glibc back when I was doing Linux/axp,
since glibc was really in pretty sad shape in some areas. I think I had a
integer divide routine that was something like five times faster than the
one in glibc, and about a tenth of the size. Things like that. So I wanted
to give things back, but ended up just throwing in the towel and said "ok,
if they don't want the code, whatever..".
If somebody pays me real bucks, I'll work for them, and I'm perfectly ok
with letting them own copyright in the end result (ie I've done commercial
software too, and I think it's only reasonable that since I did it for
pay, I don't own that software myself). But copyright assignments "just
because we want to control the end result"? No thank you.
> And that is in fact the primary reason, hacking gcc has been fun and I
> would like to do more, from a purely technical point of view. But
> having to sign a large amount of legalese is the kind of thing I may
> have to do for a job, and they pay me for it. It is not the kind of
> thing I do for fun. No fun, no money - hell, why should I do
> something like that?!?
>
> Thank you for not requiring copyright assignments, Linus.
I _hate_ copyright assignments. Maybe it's a European thing.
Of course, I also hate paperwork, so maybe it's just a "lazy" thing.
Linus
On Thu, 28 September 2006 16:19:32 +0200, DervishD wrote:
>
> Probably the renaming is just common sense and will avoid ALL
> problems. People like me are concerned only because all GPLv2 that
> doesn't state otherwise will be released automagically under GPLv3 as
> soon as the latest draft is made the official version. Otherwise, I
> wouldn't give a hump about any new license until I have the time to
> read it and see if I like it.
In my very uninformed opinion, your problem is a very minor one. Your
"v2 or later" code won't get the license v2 removed, it will become
dual "v2 or v3" licensed. And assuming that v3 only adds restrictions
and doesn't allow the licensee any additional rights, you, as the
author, shouldn't have to worry much.
The problem arises later. As with BSD/GPL dual licensed code, where
anyone can take the code and relicense it as either BSD or GPL, "v2 or
v3" code can get relicensed as v3 only. At this point, nothing is
lost, as the identical "v2 or v3" code still exists. But with further
development on the "v3 only" branch, you have a fork. And one that
doesn't just require technical means to get merged back, but has legal
restrictions.
And I assume (careful, I'm _really_ uninformed here) the FSF is well
aware of that and wants a one-way compatibility between v2 and v3.
Any v2 code can be picked up by a v3 project, but not the other way
around. v3 projects have a clear evolutionary advantage over v2.
And here the kernel wording with "v2 only" in the kernel is
interesting. It turns a one-way compatibility into no compatibility
at all. So the evolutionary advantage is lost, as it only exists
through the "v2 or later" term.
J?rn
--
Homo Sapiens is a goal, not a description.
-- unknown
On Thu, 28 Sep 2006, Jeff Garzik wrote:
>
> For the miniscule patches I have contributed to gcc, I donated them to the
> public domain...
Btw, I tried that wit the code I had, it didn't work. It might depend on
the person you're working with. I was told "We need your assignment on
file". Some maintainers might be more careful.
I have been told that legally, "putting something in the public domain"
isn't actually really possible in the US, but maybe that is something that
lawyers disagree about.
You can assign or transfer your copyrights (in writing, on real paper
only!) or you can license it, but "public domain" seems to be hard. Unless
you just want to wait for several decades after your death (and that's
hoping that Disney doesn't extend it even more after you die).
Linus
DervishD wrote:
> Probably the renaming is just common sense and will avoid ALL
> problems. People like me are concerned only because all GPLv2 that
> doesn't state otherwise will be released automagically under GPLv3 as
> soon as the latest draft is made the official version. Otherwise, I
> wouldn't give a hump about any new license until I have the time to
> read it and see if I like it.
>
I've already commented on the fsf site about this in the same way, and I
wasn't the first one. The only problem with this, from the FSF p.o.v. is
when this draft will not be automatically applied to all those pieces of
code licensed under "v2 or any later", the power of their political
message will be reduced to those choosing freely to convert to the new
license. I have no idea how many that would be, but those that do would
actually support their political agenda, which would be much better from
the "free" perspective.
If they choose to "upgrade" the GPL from v2 to this draft, they will
never again get support from those who feel betrayed in their trust of
the FSF in keeping the GPL to its original meaning in v2 (but not from
its original intended meaning, so probably it would have been misplaced
trust)
So who would get "hurt" by this? People who licensed their code under
the GPLv2 or later, naively thinking that the license text was the
intended goal of the license.
Still, these are interesting times in free/open source software world ;-)
/Simon
Ar Iau, 2006-09-28 am 07:45 -0700, ysgrifennodd Linus Torvalds:
> I have been told that legally, "putting something in the public domain"
> isn't actually really possible in the US, but maybe that is something that
> lawyers disagree about.
Its also a very bad idea for another reason. In some parts of the world
placing something in the public domain doesn't imply any kind of
warranty or liability disclaimer.
Hi J?rn :)
* J?rn Engel <[email protected]> dixit:
> On Thu, 28 September 2006 16:19:32 +0200, DervishD wrote:
> > Probably the renaming is just common sense and will avoid ALL
> > problems. People like me are concerned only because all GPLv2 that
> > doesn't state otherwise will be released automagically under GPLv3 as
> > soon as the latest draft is made the official version. Otherwise, I
> > wouldn't give a hump about any new license until I have the time to
> > read it and see if I like it.
>
> In my very uninformed opinion, your problem is a very minor one.
> Your "v2 or later" code won't get the license v2 removed, it will
> become dual "v2 or v3" licensed. And assuming that v3 only adds
> restrictions and doesn't allow the licensee any additional rights,
> you, as the author, shouldn't have to worry much.
Really my problem is that I still don't fully understand neither
the new license nor the possible effects, so just in case I want to
decide if I want my code dual licensed or not. It's not a big worry,
I know, but I prefer things that way.
> The problem arises later. As with BSD/GPL dual licensed code,
> where anyone can take the code and relicense it as either BSD or
> GPL, "v2 or v3" code can get relicensed as v3 only. At this point,
> nothing is lost, as the identical "v2 or v3" code still exists.
> But with further development on the "v3 only" branch, you have a
> fork. And one that doesn't just require technical means to get
> merged back, but has legal restrictions.
See? I didn't have seen things from this point of view, and
that's the kind of problems I want to be aware of before allowing my
code to be dual licensed.
> And here the kernel wording with "v2 only" in the kernel is
> interesting. It turns a one-way compatibility into no
> compatibility at all. So the evolutionary advantage is lost, as it
> only exists through the "v2 or later" term.
Well, in my code that's exactly what I want regarding licenses.
Probably GPLv3 is better (I don't know yet) and probably GPLv4 will
be the best license out there, but I prefer to be precise about what
license do I use.
Thanks for your explanations :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Thu, 28 Sep 2006, J?rn Engel wrote:
>
> And I assume (careful, I'm _really_ uninformed here) the FSF is well
> aware of that and wants a one-way compatibility between v2 and v3.
> Any v2 code can be picked up by a v3 project, but not the other way
> around. v3 projects have a clear evolutionary advantage over v2.
A _real_ v2 project doesn't have that problem. In fact, I'm a huge
believer in evolution (not in the sense that "it happened" - anybody who
doesn't believe that is either uninformed or crazy, but in the sense "the
processes of evolution are really fundamental, and should probably be at
least _thought_ about in pretty much any context").
And I think the v2 is actually _more_ stable in an evolutionary sense
(look up Maynard Smith and "ESS" - "Evolutionarily Stable Strategy" - for
more ideas about the biological evolution case) exactly because it's more
inclusive - it handles more cases.
The GPLv3 is a dead end in some areas, exactly because it limits how the
project can be used, and as such will automatically limit itself away from
some niches. Also, because I believe that it's less "universally
acceptable", it has a harder time competing anyway.
And the GPLv2 and GPLv3 really _are_ mutually incompatible. There is
absolutely nothing in the GPLv2 that is inherently compatible with the
GPLv3, and the _only_ way you can mix code is if you explicitly
dual-license it.
Ie, GPLv2 and GPLv3 are compatible only the same way GPLv2 is compatible
with a commercial proprietary license: they are compatible only if you
release the code under a dual license.
The whole "or later" phrase is legally _no_ different at all from a dual
licensing (it's just more open-ended, and you don't know what the "or
later" will be, so you're basically saying that you trust the FSF
implicitly).
> And here the kernel wording with "v2 only" in the kernel is
> interesting.
No. I _really_ want to clarify this, because so many people get it wrong.
Really.
The "GPLv2 only" wording is really just a clarification. You don't need it
for the project to be "GPLv2 only".
If a project says: "This code is licensed under this copyright license"
and then goes on to quote the GPLv2, then IT IS NOT COMPATIBLE WITH THE
GPLv3!
Or if you just say "I license my code under the GPLv2", IT IS NOT
COMPATIBLE WITH THE GPLv3.
Really. There is zero inherent compatibility. The GPLv2 is written (on
purpose) to not be compatible with _anything_ but itself. If you want your
code to be compatible with anything else, you have to explicitly say so.
In other words, you have to dual-license it, and _keep_ it dual-licensed.
> So the evolutionary advantage is lost, as it only exists through the "v2
> or later" term.
Exactly. The GPLv3 can _only_ take over a GPLv2 project if the "or later"
exists.
It should also be pointed out that even a "GPLv2 or later" project can be
forked two different ways: you can turn it into a "GPLv3" (with perhaps a
"or later" added too) project, but you can _equally_ turn it into a "GPLv2
only" project.
In other words, even if the license says "GPLv2 or later", the GPLv3 isn't
actually "stronger". The original author dual-licensed it, and expressly
told you that he's ok with any GPL version greater than or equal to 2.
Linus
Hi Simon :)
* Simon Oosthoek <[email protected]> dixit:
> DervishD wrote:
> > Probably the renaming is just common sense and will avoid ALL
> >problems. People like me are concerned only because all GPLv2 that
> >doesn't state otherwise will be released automagically under GPLv3 as
> >soon as the latest draft is made the official version. Otherwise, I
> >wouldn't give a hump about any new license until I have the time to
> >read it and see if I like it.
>
> I've already commented on the fsf site about this in the same way,
> and I wasn't the first one. The only problem with this, from the
> FSF p.o.v. is when this draft will not be automatically applied to
> all those pieces of code licensed under "v2 or any later", the
> power of their political message will be reduced to those choosing
> freely to convert to the new license. I have no idea how many that
> would be, but those that do would actually support their political
> agenda, which would be much better from the "free" perspective.
Probably I'm wrong here, but if the renaming took place, much
more people will probably convert to the new license if given the
change of choosing. I mean, we humans tend to do exactly the opposite
of what we are forced to do...
OTOH, if the renaming takes place and almost nobody changes to
GPLv3, that's a thing to think profoundly about.
> So who would get "hurt" by this? People who licensed their code
> under the GPLv2 or later, naively thinking that the license text
> was the intended goal of the license.
That's what I think, too. Myself, I've re-released some of my
projects just in case I dislike the GPLv3 because I don't want my
license to be converted by the recipients of my code (they can pick
GPLv3 if they want). Probably I will convert to GPLv3, who knows, but
not because I lazily copied a disclaimer that says "any later
version", if I do a relicensing I'll do it on purpose. When I chose
GPLv2 I thought that future versions will correct minor legalese,
wording or things like that, but I never thought about the DRM thing.
While I don't like "tivoization", I'm not against DRM as a
technology, and the same can be applied to other chunks of the new
GPLv3 license draft.
> Still, these are interesting times in free/open source software
> world ;-)
Unfortunately ;) I think that finally people will make a good
deal about all this fuss :)) And if they don't, I'm not worried at
all for the future of FOSS, because if a fork must be produced, it
will be. Killing FOSS is very hard ;)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Thu, 28 September 2006 08:04:13 -0700, Linus Torvalds wrote:
>
> No. I _really_ want to clarify this, because so many people get it wrong.
> Really.
>
> The "GPLv2 only" wording is really just a clarification. You don't need it
> for the project to be "GPLv2 only".
>
> If a project says: "This code is licensed under this copyright license"
> and then goes on to quote the GPLv2, then IT IS NOT COMPATIBLE WITH THE
> GPLv3!
>
> Or if you just say "I license my code under the GPLv2", IT IS NOT
> COMPATIBLE WITH THE GPLv3.
And this is an area where I slightly disagree with you. While I would
hope that you were right, I can easily imagine a judge ruling that "v2
or later" in the preamble means that the project just signed a blank
license of the FSF's discretion.
I can just as easily imagine a judge ruling that "simply copying the
GPL license verbatim and not removing the 'or later'" clause is does
not sufficiently demonstrate the authors intent to dual-license the
code.
And the likelihood of either ruling will depend on many things, but
will never reach 0 or 1. It is a gray area where your legal advice is
just as bad as mine and your "GPLv2 only" clarification may in fact be
a fork I was talking about. We just don't know until this has been
tested in court, which hopefully never happens.
J?rn
--
Joern's library part 11:
http://www.unicom.com/pw/reply-to-harmful.html
On Thu, 28 Sep 2006, Linus Torvalds wrote:
>
> It should also be pointed out that even a "GPLv2 or later" project can be
> forked two different ways: you can turn it into a "GPLv3" (with perhaps a
> "or later" added too) project, but you can _equally_ turn it into a "GPLv2
> only" project.
Btw, it should be stated here: I'm not advocating either of the above. If
a license says "v2 or later", anybody who removes an explicit right
granted by the people who originally wrote and worked on the code is just
being a total a-hole.
Quite frankly, if the FSF ever relicenses any of their projects to be
"GPLv3 or later", I will hope that everybody immediately forks, and
creates a GPLv2-only copy (and yes, you have to do it immediately, or
you're screwed forever). That way the people involved can all vote with
their feet.
I think the same is true of code that is licensed "GPL or BSD dual
licensed". If I notice a patch that removes the BSD dual-license for a
file, I won't apply it to the kernel I maintain unless there is some
really pressing reason that I can't even think of off-hand (of course,
that doesn't mean it can't have happened - if it came through a
sub-maintainer I would likely never even have noticed).
Or, indeed, as in the case of the reiserfs code: it's dual-licensed "GPLv2
or any other license as per Hans Reiser".
Btw, I have always found it funny how some people have no problem at all
with "GPLv2 or later", but then complain about reiserfs: it is _exactly_
the same dual-license, it's just that a different legal entity controls
the other yet-to-be-determined license.
The only _real_ difference is that in the case of reiserfs, the "other
entity" is actually the original author of the code, so I _personally_
actually very strongly feel that the reiserfs case is _better_ than "GPLv2
or later". In the reiserfs case, the person who does the relicensing is
actually the same people who wrote the original code and maintained it.
That's how it should be (of course, I think Reiser isn't actually
actively maintaining reiserfs any more, so at some point his "moral
rights" do end up weakening, but in the absense of any big rewrites, I
don't think that has happened yet in this example - I just wanted to
point out that things aren't "black-and-white" and "original author"
only gets you so far if you then leave the project).
I know certain people don't like the reiserfs license - they've complained
to me. At the same time, I know some of those same people themselves
expressly use "GPLv2 or later". I think those people have a serious
disconnect in their logic.
Linus
On Thu, 28 Sep 2006, J?rn Engel wrote:
>
> And this is an area where I slightly disagree with you. While I would
> hope that you were right, I can easily imagine a judge ruling that "v2
> or later" in the preamble means that the project just signed a blank
> license of the FSF's discretion.
I think a judge could rule on almost anything, almost any way. Some judges
seem to have less sense than a well-trained rabbit (see the lawsuit about
"The Wind Done Gone", where at least one judge blocked it.
Judges are just people, after all.
So yes, clarifications are good. No question about that. There's a reason
I added mine. Just to tell everybody else, and to make sure there's as
little gray area in that place as humanly possible.
So I'm not saying that "v2 only" language is _bad_. I'm just saying that
it shouldn't matter. It's technically enough to just say "GPLv2", and you
don't really have to say anything else.
Linus
On Thu, 28 Sep 2006, Lennart Sorensen wrote:
>
> I wonder if perhaps the solution should be that the GPLv3 draft should
> be renamed to something else to allow RMS to create his new license that
> does exactly what he wants it to do, without hijacking existing GPLv2
> code using a license that in many people's opinion is NOT in the spirit
> of the GPLv2 (which it could be argued overrides the "or later" part of
> the license).
I've argued that in the past, and so have others.
I think the GPLv3 could well try to stand on its own, without being
propped up by a lot of code which was written by people who may or may not
agree with the changes.
The whole "in the spirit of" thing is very much debatable - the FSF will
claim that it's in _their_ spirit, but the whole point of the language is
not to re-assure _them_, but others, so the argument (which I've heard
over and over again) that _their_ spirit matters more is somewhat dubious.
I would personally think that a much less contentious thing would have
been to make a future "GPL" only happens if some court of law actually
struck down something, or some actual judge made it clear that something
could be problematic. In other words, it shouldn't extend on the meaning
of the license, it should be used to _fix_ actual problems. Not imagined
ones.
Instead, so far, every single lawsuit about the GPLv2 has instead
strengthened the thing. NONE of the worries that people have had
(language, translation, whatever) have actually been problems. The GPLv2
is stronger today than it was 15 years ago!
But there are certainly tons of non-legal reasons why the FSF doesn't want
to go that way.
Linus
On 2006.09.28 17:20:20 +0200, J?rn Engel wrote:
> On Thu, 28 September 2006 08:04:13 -0700, Linus Torvalds wrote:
> >
> > No. I _really_ want to clarify this, because so many people get it wrong.
> > Really.
> >
> > The "GPLv2 only" wording is really just a clarification. You don't need it
> > for the project to be "GPLv2 only".
> >
> > If a project says: "This code is licensed under this copyright license"
> > and then goes on to quote the GPLv2, then IT IS NOT COMPATIBLE WITH THE
> > GPLv3!
> >
> > Or if you just say "I license my code under the GPLv2", IT IS NOT
> > COMPATIBLE WITH THE GPLv3.
>
> And this is an area where I slightly disagree with you. While I would
> hope that you were right, I can easily imagine a judge ruling that "v2
> or later" in the preamble means that the project just signed a blank
> license of the FSF's discretion.
The preamble does not say "v2 or later", that's only in "How To" section
which is not part of the terms and conditions. But section 9 is even
worse than "v2 or later". Linus' second exmaple is fine, it mentions v2
and therefore it actually is v2 only. But the first one means _any_ GPL
version, even older versions, as it does not mention any version and
section 9 says "If the Program does not specify a version number of
this License, you may choose any version ever published by the Free
Software Foundation." ouch!
Bj?rn
On Wed, 27 Sep 2006, Linus Torvalds wrote:
>
> On Wed, 27 Sep 2006, Patrick McFarland wrote:
>> On Wednesday 27 September 2006 20:18, Linus Torvalds wrote:
>>> I think a lot of people may be confused because what they see is
>>>
>>> (a) Something that has been brewing for a _loong_ time. There has been
>>> the FSF position, and there has been the open source position, and
>>> the two have been very clearly separated.
>>
>> But whats wrong with that? The FSF is a "project" (or really, a group
>> of projects, because some FSF projects don't agree with the FSF
>> position either), it isn't them official voice of the community.
>
> Right, I'm not saying that there is anything wrong with having two
> positions.
>
> In many ways, I'm saying the opposite. I'm saying that we should _expect_
> people to have different opinions. Everybody has their own opinion anyway,
> and expecting people not have different opinions (especially programmers,
> who are a rather opinionated lot in the first place) is just not
> realistic.
>
> There's absolutely nothing wrong with having a very wide consensus among a
> very varied developer base. In fact, I think that's _great_.
>
> And the reason I'm speaking out against the GPLv3 is that it is trying to
> "sort the chaff from the wheat". The FSF is apparently not happy with a
> wide community appeal - they want _their_ standpoint to be the one that
> matters.
>
> I have all through the "discussion" tried to explain that the great thing
> about the GPLv2 is that it allows all these people with totally different
> ideals to come together. It doesn't have to be "perfect" for any
> particular group - it's very perfection comes not from it's language, but
> the very fact that it's _acceptable_ to a very wide group.
>
> When the FSF tries to "narrow it down", they kill the whole point of it.
> The license suddenly is not a thing to get around and enjoy, it's become a
> weapon to be used to attack the enemy.
>
> Here in the US, the only watchable TV news program is "The Daily Show"
> with Jon Stewart. One of his fairly recurring themes is about how US
> politics is destroyed by all these passionate and vocal extremists, and he
> asks whether there can ever be a really passionate moderate. "Can you be
> passionate about the middle road?"
>
> Dammit, I want to be a "Passionate Moderate". I'm passionate about just
> people being able to work together on the same license, without this
> extremism.
>
> So here's my _real_ cry for freedom:
>
> "It's _ok_ to be commercial and do it just for money. And yes, you can
> even have a FSF badge, and carry Stallmans manifesto around everywhere
> you go. And yes, we accept people who like cryptography, and we accept
> people who aren't our friends. You don't have to believe exactly like we
> believe!"
>
> And for fifteen years, the GPLv2 has been a great umbrella for that.
>
> The FSF is throwing that away, because they don't _want_ to work with
> people who don't share their ideals.
>
>>> At the same time, both camps have been trying to be somewhat polite,
>>> as long as the fact that the split does clearly exist doesn't
>>> actually _matter_.
>>
>> I agree. It doesn't matter because everyone is free to use whatever
>> version they want of the GPL. Of course, people do also recognize that
>> the GPL2 vs GPL3 argument is just a more subtle version of whats been
>> going on for years with BSD vs GPL.
>
> That's part of what really gets my goat. I spent too much time arguing
> with crazy BSD people who tried to tell me that _their_ license was "true
> freedom". The FSF shills echo those old BSD cries closely - even though
> they are on the exact opposite side of the spectrum on the "freedom" part.
>
> I hated BSD people who just couldn't shut up about their complaining about
> my choice of license back then (the good old BSD/MIT vs GPL flamewars).
>
>>> In fact, most programmers _still_ probably
>>> don't care. A lot of people use a license not because they "chose"
>>> it, but because they work on a project where somebody else chose the
>>> license for them originally.
>>
>> Programmers don't care because we aren't lawyers. I mean, few things
>> are stated so simply, but lets face it, law is boring to quite a few
>> geeks, and the intersection between geeks who code and geeks who law
>> is very small.
>
> I think a _lot_ of programmers care very deeply indeed about the licenses.
> I certainly do. I wouldn't want to be a lawyer, but I care about how my
> code gets used.
>
> That said, I don't care how everybody _elses_ code gets used, which is
> apparently one of the differences between me and rms.
>
>>> Not really. It wasn't even news. The kernel has had the "v2 only" thing
>>> explicitly for more than half a decade, and I have personally tried to
>>> make it very clear that even before that, it never had anything else (ie
>>> it very much _had_ a specific license version, just by including the damn
>>> thing, and the kernel has _never_ had the "v2 or any later" language).
>>
>> Wasn't that just to prevent the FSF from going evil and juping all your code?
>
> Well, initially it wasn't even a conscious "I don't trust the FSF" thing.
> But when I chose the GPL (v2, back then) I chose _that_ license. There was
> absolutely no need for me to say "or later". If the GPLv2 ever really
> turns out to be a bad license, we can re-license _then_.
>
> Yes, it would be really really painful, but I think the "or later" wording
> is worse. How can you _ever_ sign anything sight unseen? That's just
> stupid, and that's totally regardless of any worries about the FSF.
>
> Later, when I did start having doubts about the FSF, I just made it even
> more clear, since some people wondered.
>
>> The only problem is that, alternatively, the FOSS movement was so
>> strong because of RMS's kool-aid everyone drank. The community has
>> teeth, and this is in partly because of the actions of the FSF. We
>> defend ourselves when we need to.
>>
>> Its just that, at least with the Tivo case, that the defense went a tad too
>> far.
>
> I think the FSF has always alienated as many (or more) people as they
> befriended, but maybe that's just me. I was looking for old newsgroup
> threads about this earlier in the week, and noticed somebody in the BSD
> camp saying that I was using the GPL, but that I wasn't as radical as rms.
> And iirc, that was from 1993, when Linux was virtually unknown.
>
> So I think that not being too extreme is a _good_ thing. It's how you can
> get more people involved.
>
> So everybody - join the "Passionate Moderate" movement, even if you're not
> in the US. We're not passionate about any of the issues, we are just
> _really_ fed up with extreme opinions! And we're not afraid to say so!
>
> [ The really sad part is: that was only _somewhat_ in jest. Dammit,
> sometimes I think we really need that party! ]
>
> Linus
I didn't just jump right in yesterday when this first came up because
I wanted to take the time to properly compose a statement in view
of the fact that just about everything on the Internet is being
recorded forever.
I am certainly glad that Linus has awakened to the RMS threat that
I mentioned on this list several years ago. As soon as I saw
"GNU/Linux" and Stallman's claim that Linux was simply a small
component of a larger "Operating System" of which he claimed
ownership, I became much disturbed and reported the same on this
list. To many, my report was simply "the rantings of a lunatic."
However, now some are beginning to see the light as history
continues to be rewritten and a history lesson is unfolding.
Stallman's claim to ownership pitchforks hog shit in the face
of hundreds who took the time and effort to port BSD utilities
to that wondrous new operating system called Linux and I was one,
claiming no glory for myself, nor even bothering to add anything
to the BSD licenses that existed within these utilities. This
was done for the greater good of all (and of course me, because
I wanted to use these utilities under Linux), not for the political
aspirations of a few. These efforts go back to the days when
"distributions" consisted of 56 floppy disks and Linus was
in Helsinki, working on his degree. The FSF didn't exist, and
GNU was the name of an immature compiler. Sometimes we need
to be reminded of the history of a particular thing because,
once out-of-mind, history tends to be rewritten by those who
would advance in its new "interpretation."
Every time I accidentally execute `uname` with an -a instead of
a -r, I am reminded of the history rewrite as I am presented with:
Linux chaos.analogic.com 2.6.16.24 #1 SMP PREEMPT
Wed Jul 12 11:32:34 EDT 2006 i686 i686 i386 GNU/Linux
^^^^^^^^^
If history continues to repeat itself, the FSF has just about
run its course and, when contributors continue to realize that
their tradition of giving for the common good, is being replaced
by the politics of a small body of thrill seekers, they will
revert their licenses to become more liberal rather than
restrictive. The problem could remain that excessive damage
may already have been done.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.66 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Wed, 27 Sep 2006, Chase Venters wrote:
>
> After lots of careful consideration, I think it is fair to say that Stallman
> vigorously and extremely promotes and stands by his ideals, but the ideals he
> stands for aren't all that radical or extreme. That is the difference, isn't
> it?
I would disagree.
What you talk about is "idealism". You can be idealistic about anything. I
agree that rms is also idealistic, but that's not what makes him
extremist. There are a lot of idealistic people who aren't extreme.
Extremism has nothing to do with _what_ the ideal is, but with how you
state them. That's not just my interpretation, I can back it up with
actual meaning of the word.
S: (n) extremism (any political theory favoring immoderate
uncompromising policies)
That's from wordnet.princeton.edu.
Note the "ANY" in "any political theory".
And that "immoderate" and "uncompromizing" is rms to a T.
So please, if you want to argue semantics, at least look up the word
first. When I said extremist, I didn't use that word in the wrong way.
For example, the difference between a "deeply religious person" and an
"extremist religious person" is not in their depth or trueness of their
beliefs. It's in whether they want to allow other people to believe
otherwise and can compromize when dealing with those other people.
Linus
> However, now some are beginning to see the light as history
> continues to be rewritten and a history lesson is unfolding.
> These efforts go back to the days when
> "distributions" consisted of 56 floppy disks and Linus was
> in Helsinki, working on his degree. The FSF didn't exist, and
> GNU was the name of an immature compiler.
The FSF was founded in 1985, now who is rewriting history
here :-) "GNU" never was the name for the compiler, either.
> Sometimes we need
> to be reminded of the history of a particular thing because,
> once out-of-mind, history tends to be rewritten by those who
> would advance in its new "interpretation."
I don't really want to know what you try to gain by this
"properly composed statement", heh.
Segher
On Thu, 28 Sep 2006, Segher Boessenkool wrote:
>> However, now some are beginning to see the light as history
>> continues to be rewritten and a history lesson is unfolding.
>
>> These efforts go back to the days when
>> "distributions" consisted of 56 floppy disks and Linus was
>> in Helsinki, working on his degree. The FSF didn't exist, and
>> GNU was the name of an immature compiler.
>
> The FSF was founded in 1985, now who is rewriting history
> here :-) "GNU" never was the name for the compiler, either.
>
No. GNU was coined in 1984-85 (depending upon the source).
It was a recursive 'GNU Not Unix', and referred to some free
tools, including Eimacs. One of the most important tools
was a compiler which could be readily ported to new operating
systems. The GNU compiler was used in an attempt to make
Hurd, an early Unix clone. It was also used by BSD and Linux.
>> Sometimes we need
>> to be reminded of the history of a particular thing because,
>> once out-of-mind, history tends to be rewritten by those who
>> would advance in its new "interpretation."
>
> I don't really want to know what you try to gain by this
> "properly composed statement", heh.
>
> Segher
>
FYI, the place to research your information is not on http://www.gnu.org or
Wikipedia, both of which are too self-serving (in this area) to be used
as a reference. You need to dig deeper or ask someone who was there.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.66 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Sorry, but that pulled *my* trigger...
On 2006-09-28, linux-os (Dick Johnson) <[email protected]> wrote:
> Path: news.gmane.org!not-for-mail
> From: "linux-os \(Dick Johnson\)" <[email protected]>
> Newsgroups: gmane.linux.kernel
> Subject: Re: GPLv3 Position Statement
> Date: Thu, 28 Sep 2006 15:34:58 -0400
> Lines: 48
[...]
> Original-Received: from odyssey.analogic.com ([204.178.40.5]:5135 "EHLO odyssey.analogic.com") by vger.kernel.org with ESMTP id S1030383AbWI1TfG convert rfc822-to-8bit (ORCPT <rfc822;[email protected]>); Thu, 28 Sep 2006 15:35:06 -0400
> Original-Received: from chaos.analogic.com ([10.112.50.11]) by phoenix.analogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Sep 2006 15:35:04 -0400
> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> Original-Received: from chaos.analogic.com (localhost [127.0.0.1]) by chaos.analogic.com (8.12.11/8.12.11) with ESMTP id k8SJZ4wS031736; Thu, 28 Sep 2006 15:35:04 -0400
> Original-Received: (from linux-os@localhost) by chaos.analogic.com (8.12.11/8.12.11/Submit) id k8SJYweF031733; Thu, 28 Sep 2006 15:34:58 -0400
> X-OriginalArrivalTime: 28 Sep 2006 19:35:04.0187 (UTC) FILETIME=[3236ECB0:01C6E335]
> Content-class: urn:content-classes:message
> In-Reply-To: <[email protected]>
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic: GPLv3 Position Statement
> thread-index: AcbjNTJAPIVMpED0T6+AOQGqDk9Jbw==
> Original-To: "Segher Boessenkool" <[email protected]>
> Original-Sender: [email protected]
> Precedence: bulk
> X-Mailing-List: [email protected]
> Xref: news.gmane.org gmane.linux.kernel:450959
> Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/450959>
>
>
> On Thu, 28 Sep 2006, Segher Boessenkool wrote:
>
>>> However, now some are beginning to see the light as history
>>> continues to be rewritten and a history lesson is unfolding.
>>
>>> These efforts go back to the days when
>>> "distributions" consisted of 56 floppy disks and Linus was
>>> in Helsinki, working on his degree. The FSF didn't exist, and
>>> GNU was the name of an immature compiler.
>>
>> The FSF was founded in 1985, now who is rewriting history
>> here :-) "GNU" never was the name for the compiler, either.
>>
>
> No. GNU was coined in 1984-85 (depending upon the source).
> It was a recursive 'GNU Not Unix', and referred to some free
> tools, including Eimacs. One of the most important tools
> was a compiler which could be readily ported to new operating
> systems. The GNU compiler was used in an attempt to make
> Hurd, an early Unix clone. It was also used by BSD and Linux.
>
>>> Sometimes we need
>>> to be reminded of the history of a particular thing because,
>>> once out-of-mind, history tends to be rewritten by those who
>>> would advance in its new "interpretation."
>>
>> I don't really want to know what you try to gain by this
>> "properly composed statement", heh.
>>
>> Segher
>>
>
> FYI, the place to research your information is not on http://www.gnu.org or
> Wikipedia, both of which are too self-serving (in this area) to be used
> as a reference. You need to dig deeper or ask someone who was there.
Or just look on e-mail headers of who is talking to you.
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.16.24 on an i686 machine (5592.66 BogoMips).
Hmm...
> New book: http://www.AbominableFirebug.com/
> _
>
>
> ****************************************************************
> The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Hmmmmmm.....
> Thank you.
No, no, thank you. Very much.
--
On Thu, 28 Sep 2006, Jan Engelhardt wrote:
>
> >People don't have a clue!
> >
> >Grep for it, if you want to. The word "link" simply DOES NOT EXIST IN THE
> >LICENSE!
>
> Hah then read LICENSE.LGPL!
Thank you for proving my point.
The part you quote aren't part of the license. They're in the same file,
but they are separate from the actual text of the license. It's called the
"preamble", and you should really realize what it means.
The _license_ is the legal part. It's the thing between "terms and
conditions" and "end of terms and conditions".
I like being right, but I hate being proven right quite so quickly.
(Btw, the license you quoted wasn't even the GPL. The LGPL - which is a
totally different thing - _does_ indeed talk about "linking", but the part
you quoted wasn't even _in_ that license, so it was kind of doubly silly
to bring that part up, now wasn't it?)
> If the GPL does not mention linking at all, and therefore does not
> really forbid it, why do we need an LGPL to allow linking then?
Where did you learn logic?
The GPL doesn't mention linking, because the GPL only talks about derived
works. The LGPL talks about linking, because it wants to _narrow_ its
scope from "derived works" to something smaller, and makes it clear that
even within a derived work, the technical thing of "linking" actually
consitutes a license boundary.
However, the fact IN NO WAY logically implies the reverse is true. The
fact that you link (or not) _in_itself_ does not necessarily imply a
boundary of derived works.
Your logic is so horribly flawed that it's not even funny. It's the same
thing as if you said
- Aristotle is a man
- I am not Aristotle
- Therefore I am not a man
Please take a course in Logic 101.
Linus
PS. Just so that you don't confuse things _again_, I'd like to repeat:
pretty much everybody would agree that linking is often a damn strong
reason to believe the things are related and probably derived works. But
it's not at all a logical conclusion, and it's not at all necessarily
always right. "Derived work" is a lot more complicated than that.
Linking with a GPL'd version of a standard C library (ie a non-GPL'd
version would have worked equally well, and you just did it becasue you
didn't think) would be very possibly (even likely) not be considered to be
a "derived work", but "mere aggregation".
Think about that for a moment.
And realize that the reason people then use the LGPL is that with that
license, the question above never even comes up. So you're on much safer
ground, and you don't have to worry about crazy people suing you.
A lot of legal stuff is not just to avoid illegal things, but to
_obviously_ avoid them. You never really want to be even close to the
edge.
On Thursday 28 September 2006 16:01, Oleg Verych wrote:
>
>Or just look on e-mail headers of who is talking to you.
>
>> Cheers,
>> Dick Johnson
>> Penguin : Linux version 2.6.16.24 on an i686 machine (5592.66
>> BogoMips).
>
>Hmm...
>
>> New book: http://www.AbominableFirebug.com/
Interesting indeed, someone who succeeded, I take it by grabbing his own
bootlaces.
[...]
>Hmmmmmm.....
>
>> Thank you.
>
>No, no, thank you. Very much.
And thank you for the link.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Thursday September 28, [email protected] wrote:
>
>
> On Thu, 28 Sep 2006, Linus Torvalds wrote:
> >
> > It should also be pointed out that even a "GPLv2 or later" project can be
> > forked two different ways: you can turn it into a "GPLv3" (with perhaps a
> > "or later" added too) project, but you can _equally_ turn it into a "GPLv2
> > only" project.
>
> Btw, it should be stated here: I'm not advocating either of the above. If
> a license says "v2 or later", anybody who removes an explicit right
> granted by the people who originally wrote and worked on the code is just
> being a total a-hole.
But isn't that the whole point - to replace v2 by v3?
As v3 is almost uniformly more restrictive than v2, anyone having the
option of choosing v2 or v3 would naturally choose v2.
If there is to be no removal of the v2 license from "v2 or later"
code, then there is absolutely no point in the new license being a new
version of the GPL. Rather it is a totally new license.
Now I know that is what you would prefer, but it seems obvious that it
isn't what the new FSF wants.
I would be very surprised if new versions of any FSF-control code is
available under v2 more than a few months after v3 becomes final.
>
> Quite frankly, if the FSF ever relicenses any of their projects to be
> "GPLv3 or later", I will hope that everybody immediately forks, and
> creates a GPLv2-only copy (and yes, you have to do it immediately, or
> you're screwed forever). That way the people involved can all vote with
> their feet.
I don't see the urgency. Why are you "screwed forever"? You can
always take the last version that was available under a suitable
license and fork from there, just like OpenSSH did.
Sure: the longer you leave it the harder it will be to get critical
mass, but I don't see the need for it to be done immediately.
NeilBrown
From: "Linus Torvalds" <[email protected]>
> Exactly. The GPLv3 can _only_ take over a GPLv2 project if the "or later"
> exists.
>
> It should also be pointed out that even a "GPLv2 or later" project can be
> forked two different ways: you can turn it into a "GPLv3" (with perhaps a
> "or later" added too) project, but you can _equally_ turn it into a "GPLv2
> only" project.
>
> In other words, even if the license says "GPLv2 or later", the GPLv3 isn't
> actually "stronger". The original author dual-licensed it, and expressly
> told you that he's ok with any GPL version greater than or equal to 2.
And if it is dual licensed and the user gets to pick the license what
does it mean to have GPLv3 as part of an OR clause? Those who would use
or reuse the code can ignore the GPLv3 part and go forward as GPLv2.
The intent of "GPLv2 or later" might have been "latest GPL version".
But that is not what the words rather explicitly declare.
{^_-} Joanne
> In my very uninformed opinion, your problem is a very minor one. Your
> "v2 or later" code won't get the license v2 removed, it will become
> dual "v2 or v3" licensed. And assuming that v3 only adds restrictions
> and doesn't allow the licensee any additional rights, you, as the
> author, shouldn't have to worry much.
>
> The problem arises later. As with BSD/GPL dual licensed code, where
> anyone can take the code and relicense it as either BSD or GPL, "v2 or
> v3" code can get relicensed as v3 only. At this point, nothing is
> lost, as the identical "v2 or v3" code still exists. But with further
> development on the "v3 only" branch, you have a fork. And one that
> doesn't just require technical means to get merged back, but has legal
> restrictions.
Unless I'm missing something, you *cannot* change the license from "v2 or
later at your option" to "v3 or later". Both GPLv2 and GPLv3 explicitly
prohibit modifying license notices. (Did the FSF goof big time? It's not too
late to change the draft.)
DS
On Thursday September 28, [email protected] wrote:
>
> > In my very uninformed opinion, your problem is a very minor one. Your
> > "v2 or later" code won't get the license v2 removed, it will become
> > dual "v2 or v3" licensed. And assuming that v3 only adds restrictions
> > and doesn't allow the licensee any additional rights, you, as the
> > author, shouldn't have to worry much.
> >
> > The problem arises later. As with BSD/GPL dual licensed code, where
> > anyone can take the code and relicense it as either BSD or GPL, "v2 or
> > v3" code can get relicensed as v3 only. At this point, nothing is
> > lost, as the identical "v2 or v3" code still exists. But with further
> > development on the "v3 only" branch, you have a fork. And one that
> > doesn't just require technical means to get merged back, but has legal
> > restrictions.
>
> Unless I'm missing something, you *cannot* change the license from "v2 or
> later at your option" to "v3 or later". Both GPLv2 and GPLv3 explicitly
> prohibit modifying license notices. (Did the FSF goof big time? It's not too
> late to change the draft.)
Could you point to the test in either license that prohibits modifying
license notices?
I certainly couldn't find it in section 2 of GPLv2, which seems to be
the relevant section.
Interestingly, 2.b seem to say that if I received a program under
GPLv2, and I pass it on, then I must pass it on under GPLv2-only...
So to be able to distribute something written today under GPLv3 (when
it comes into existence), you must be the original or have received it
directly from the original author....
NeilBrown
> Thanks for posting this. It's obviously had a lot of thought go into
> it.
You're welcome ... sorry it took me a while to find this ... I'm not
subscribed to lkml, so if I'm not cc'd on the mail, I don't see the
reply (until I trawl one of the consolidator websites)
> I do think there are a few flaws in the arguments however. The biggest
> one for me can be summed up in the question "which license better
> represents the intention of the GPLv2 in the current world?"
Really, that's not a flaw. Some people like GPLv2 purely on its
practical effect; others because of its political statements. I think
Linus has summed it up much better that I can here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115915241428792
However, the true strength of GPLv2 was that we could all unite around
it, even if we had different beliefs (as in Free Software vs Open
Source).
> When the GPLv2 was drafted it wasn't a legal document in a vacuum. It
> came with a preamble that stated its intentions, and it came with
> someone who toured the world explaining the intentions and
> motivations. There were even plenty of repeat performances for anyone
> who wanted to attend :-)
> I think the GPLv3 does a better job of expressing legally those
> intentions than GPLv2 did. In particular this part of the v2 preamble:
> "For example, if you distribute copies of such a program, whether
> gratis or for a fee, you must give the recipients all the rights
> that you have."
but the preamble isn't part of the actual licence. Additionally, if you
see the rights framed in terms of access to modifications, then GPLv3 is
different.
> I think that recent developments (such as TiVo v2) have shown that
> companies have found ways to give recipients less rights then they
> have themselves.
I agree they've found ways of restricting how their hardware is used,
yes. However, I tried to give a rationale of why this isn't necessarily
bad for the open source ecosystem as a whole here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115920543731682
> So I think the parts of the position statement that talk about the
> importance of the 'development contract as expressed/represented by
> GPLv2' and the implication that this contract would be violated by the
> current GPLv3 draft are not accurate. That development contract came
> with a clear explanation (or at least it seems clear to me).
>
> Similarly, the position statement states:
>
> "This in turn is brought about by a peculiar freedom enshrined in the
> developer contract as represented by GPLv2, namely the freedom from
> binding the end use of the project."
>
> but I think this particular 'freedom' comes more from the development
> conventions of the Linux kernel community than from the GPLv2. I don't
> see anything in the GPLv2 that actually tried to enshrine that
> particular freedom. That doesn't mean it isn't a worthwhile thing to
> enshrine, I just think it is inaccurate to claim that the GPLv2
> attempts in any way to enshrine it.
Actually, no, it's enshrined in GPLv2 in clause 0:
"Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does."
It's the "act of running the program is not restricted".
This is really the crux of the argument with the FSF over the DRM
clauses. If you take the position (as the people who signed the
discussion paper do) that embedded Linux constitutes an end use, then
this freedom from restriction of running the programme is compromised in
GPLv3, and hence is against the spirit of GPLv2 (and thus violates
clause 9 of GPLv2).
To go after Tivo (and not violate GPLv2 clause 9), the FSF has to take
the position that what Tivo is doing is not use, but is distribution.
This is a dangerous shift in precedent because it applies to every
embedded use of Linux (or any other GPL licensed programme).
> > As drafted, this currently looks like it would potentially jeopardise the
> > entire patent portfolio of a company simply by the act of placing a GPLv3
> > licensed programme on their website.
>
> I can't see anything in the current GPLv3 draft which would do
> that. Could you explain how that comes about?
That's clause 11 of the current v3 Draft2:
"If you convey a covered work, you similarly covenant to all recipients,
including recipients of works based on the covered work, not to assert
any of your essential patent claims in the covered work."
This means that if you host a GPLv3 covered programme on your website
for instance (even if you didn't produce it or modify it in any way),
you licence any patent you hold covering it.
HP is already on record as objecting to this as disproportionate.
James
On 2006.09.29 12:45:40 +1000, Neil Brown wrote:
> On Thursday September 28, [email protected] wrote:
> >
> > > In my very uninformed opinion, your problem is a very minor one. Your
> > > "v2 or later" code won't get the license v2 removed, it will become
> > > dual "v2 or v3" licensed. And assuming that v3 only adds restrictions
> > > and doesn't allow the licensee any additional rights, you, as the
> > > author, shouldn't have to worry much.
> > >
> > > The problem arises later. As with BSD/GPL dual licensed code, where
> > > anyone can take the code and relicense it as either BSD or GPL, "v2 or
> > > v3" code can get relicensed as v3 only. At this point, nothing is
> > > lost, as the identical "v2 or v3" code still exists. But with further
> > > development on the "v3 only" branch, you have a fork. And one that
> > > doesn't just require technical means to get merged back, but has legal
> > > restrictions.
> >
> > Unless I'm missing something, you *cannot* change the license from "v2 or
> > later at your option" to "v3 or later". Both GPLv2 and GPLv3 explicitly
> > prohibit modifying license notices. (Did the FSF goof big time? It's not too
> > late to change the draft.)
>
> Could you point to the test in either license that prohibits modifying
> license notices?
> I certainly couldn't find it in section 2 of GPLv2, which seems to be
> the relevant section.
It's in section 1, where it says "keep intact all the notices that refer
to this License" (section 2 refers to section 1).
The current GPLv3 draft says (section 4): "keep intact all license
notices".
Notice a difference? I'm not a native speaker and of course IANAL, but
AFAICT, with "v2 or later", if you follow the terms of GPLv2, you are
only required to keep notices refering to THAT license, ie. GPLv2, so
you seem to be allowed to remove the GPLv3 notices. But if you follow
the terms of the GPLv3, you are required to keep ALL license notices,
including those that refer to v2.
So you could actually never ever make a "v2 or later" program a
"v3 only" program, but only a "v2 only".
Am I missing something?
> Interestingly, 2.b seem to say that if I received a program under
> GPLv2, and I pass it on, then I must pass it on under GPLv2-only...
> So to be able to distribute something written today under GPLv3 (when
> it comes into existence), you must be the original or have received it
> directly from the original author....
Section 9 states that the notices that refer to the license are
important. If you specify "v2-only" you can use v2 only. If you specify
"v2 or later" you are not bound to GPLv2 2.b at all if you choose to
follow the terms of any later version. And if no version is mentioned at
all, you can follow the terms of any version ever released.
Bj?rn
On Thu, 28 Sep 2006 19:29:55 -0700
"David Schwartz" <[email protected]> wrote:
> Unless I'm missing something, you *cannot* change the license from "v2 or
> later at your option" to "v3 or later". Both GPLv2 and GPLv3 explicitly
> prohibit modifying license notices. (Did the FSF goof big time? It's not too
> late to change the draft.)
The copyright holder is not constrained at all in how they license their
work. They can change the license to anything they want, including the
GPLv3 or anything else. Of course, earlier versions will still be available
under the GPLv2.
Sean
> It's in section 1, where it says "keep intact all the notices that refer
> to this License" (section 2 refers to section 1).
> The current GPLv3 draft says (section 4): "keep intact all license
> notices".
>
> Notice a difference? I'm not a native speaker and of course IANAL, but
> AFAICT, with "v2 or later", if you follow the terms of GPLv2, you are
> only required to keep notices refering to THAT license, ie. GPLv2, so
> you seem to be allowed to remove the GPLv3 notices. But if you follow
> the terms of the GPLv3, you are required to keep ALL license notices,
> including those that refer to v2.
> So you could actually never ever make a "v2 or later" program a
> "v3 only" program, but only a "v2 only".
>
> Am I missing something?
That section uses the phrase "this license" twice. I think it's only
reasonable to assume it means the same thing in both places. It says you
must "give any other recipients of the Program a copy of this License along
with the Program".
If "this license" means GPLv2, then the GPLv2 does not allow you to remove
the GPLv2 notice. I think it's somewhat absurd to say that you must include
a copy of the license but may take away their right to use the code under
that license.
If "this license" means "whatever license you happen to have to this
program", then you cannot remove or modify *any* license notices, including
the "GPLv2 or later at your option" notice.
I see no plausible way to argue that GPLv2 permits you to change "GPLv2 or
later at your option" to "GPLv3 or later at your option". If GPLv3 does not
either, then you may not do so.
DS
On Thursday September 28, [email protected] wrote:
> It's the "act of running the program is not restricted".
>
> This is really the crux of the argument with the FSF over the DRM
> clauses. If you take the position (as the people who signed the
> discussion paper do) that embedded Linux constitutes an end use, then
> this freedom from restriction of running the programme is compromised in
> GPLv3, and hence is against the spirit of GPLv2 (and thus violates
> clause 9 of GPLv2).
I hadn't seen this distinction before, and it is probably worth
repeating and exploring a bit.
You seem to be saying that including software in a product that you
then distribute is *both* a USE and a DISTRIBUTION of that software.
So if the software is obtained under the GPL, and the GPL asserts "no
restrictions on use" then it should also not restrict distribution.
It can place requirements that must be met before distribution is
allowed, but they shouldn't be so onerous as to inhibit distribution.
Does that sound right?
The requirements in GPLv2 are not sufficient to prevent distribution.
The requirements in GPLv3-draft are - they might require modification
to the device which might make it illegal to sell (?).
Presumably this doesn't just apply to embedded uses.
When Redhat or Novell/SuSE make a Enterprise Distribution, they are
"using" Linux just as much as a company produces devices with embedded
Linux are.
So if GPLv3 required not only that you give away the right to assert
your patents, and give away certain secrets (keys) but also that you
give up the right to protect your Trademarks, then Redhat would
probably be very unhappy about that, as might Mozilla. Fortunately
GPLv3-draft doesn't make that requirement.
I wonder what v4 will do :-)
I wonder how hard it is to modify the hardware of a Tivo-2 to allow
software updates (it was done for the Xbox after all), and if the
difference between that and the effort of removing trade marks from
RHEL (just producing whitebox) is a difference of degree or a
difference of kind....
NeilBrown
On 2006.09.28 20:31:07 -0700, David Schwartz wrote:
>
> > It's in section 1, where it says "keep intact all the notices that refer
> > to this License" (section 2 refers to section 1).
> > The current GPLv3 draft says (section 4): "keep intact all license
> > notices".
> >
> > Notice a difference? I'm not a native speaker and of course IANAL, but
> > AFAICT, with "v2 or later", if you follow the terms of GPLv2, you are
> > only required to keep notices refering to THAT license, ie. GPLv2, so
> > you seem to be allowed to remove the GPLv3 notices. But if you follow
> > the terms of the GPLv3, you are required to keep ALL license notices,
> > including those that refer to v2.
> > So you could actually never ever make a "v2 or later" program a
> > "v3 only" program, but only a "v2 only".
> >
> > Am I missing something?
>
> That section uses the phrase "this license" twice. I think it's only
> reasonable to assume it means the same thing in both places. It says you
> must "give any other recipients of the Program a copy of this License along
> with the Program".
>
> If "this license" means GPLv2, then the GPLv2 does not allow you to remove
> the GPLv2 notice. I think it's somewhat absurd to say that you must include
> a copy of the license but may take away their right to use the code under
> that license.
>
> If "this license" means "whatever license you happen to have to this
> program", then you cannot remove or modify *any* license notices, including
> the "GPLv2 or later at your option" notice.
>
> I see no plausible way to argue that GPLv2 permits you to change "GPLv2 or
> later at your option" to "GPLv3 or later at your option". If GPLv3 does not
> either, then you may not do so.
That's what I'm saying (ok, I didn't mention the "GPLv3 or later"
wording). Once v3 is out, you can choose between v2 and v3.
v2 seems to only forces you to keep the notice that v2 is valid.
The current v3 draft forces you to keep all license notices.
So if at all, you can only remove anything _but_ v2, but never v2.
But I've just re-read section 9 and "this License" obviously just refers to
just the GPL there, as the version number of "this License" is mentioned.
So removing the "or later" won't work either and you simply cannot change
which versions apply at all (at least not without all copyright holders
agreeing on that change).
Bj?rn
James,
> > I do think there are a few flaws in the arguments however. The biggest
> > one for me can be summed up in the question "which license better
> > represents the intention of the GPLv2 in the current world?"
>
> Really, that's not a flaw. Some people like GPLv2 purely on its
> practical effect; others because of its political statements. I think
> Linus has summed it up much better that I can here:
I probably didn't make myself clear enough. I'm not disagreeing with
the conclusion Linus has come to. I don't have enough copyright
remaining in the Linux kernel to consider trying to influence that
decision.
I am however disagreeing with the justification given in the position
statement. The position statement implies that the FSF may be in
breach of contract, at least morally, by trying to release a version
of the GPL that is not in keeping with previous versions. I think the
preamble of the GPLv2 and the explanations given of the FSF intentions
over the years are completely consistent with the GPLv3 current draft.
As Linus has said in another thread, the FSF has been arguing this
position for many years. Their position on DRM is entirely consistent
with the original motivations for starting the GNU project, especially
when you think of the original printer story that inspired it all.
At the same time, the position Linus has taken is consistent with his
past attitude towards similar issues. I don't think it is entirely
consistent with the COPYING file that has been distributed with the
kernel all these years (especially the preamble), but thats probably
debatable.
> but the preamble isn't part of the actual licence. Additionally, if you
> see the rights framed in terms of access to modifications, then GPLv3 is
> different.
The GPLv3 is certainly different, otherwise there isn't much point in
an update.
I would argue that the GPLv3 current draft is more consistent with the
aims of the GPLv2, as given in the preamble of the GPLv2 in numerous
speeches by Richard and other FSF members, than the GPLv2 license text
is.
So I think that the FSF have done nothing morally wrong. Whether Linus
or anyone else prefers the GPLv2 license text or the GPLv3 license
text is an entirely separate issue and not something that I have
commented on.
> I agree they've found ways of restricting how their hardware is used,
> yes. However, I tried to give a rationale of why this isn't necessarily
> bad for the open source ecosystem as a whole here:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=115920543731682
I am not trying to argue if its good or bad for the open source
ecosystem, at least as regards the Linux kernel. I am trying to ensure
that yourself and others understand that your criticisms of the
consistency of the FSF position are not correct.
For my own code, I think GPLv3 is a better choice. This is largely
because I have been through the pain of enforcement of GPLv2 a number
of times, and I can see that GPLv3 should make it easier, at least for
me. The language is clearer, which means less time spent on pointless
copyright law debates with various vendors.
For other projects the relative benefits of v2 versus v3 may be
different, but I at least hope that project leaders will look at GPLv3
and make an informed decision. I think the errors in the position
statement may lead to people making incorrect judgements.
> Actually, no, it's enshrined in GPLv2 in clause 0:
>
> "Activities other than copying, distribution and modification are not
> covered by this License; they are outside its scope. The act of
> running the Program is not restricted, and the output from the Program
> is covered only if its contents constitute a work based on the
> Program (independent of having been made by running the Program).
> Whether that is true depends on what the Program does."
>
> It's the "act of running the program is not restricted".
ok, lets take a really obvious example. Say that HP decided to
incorporate modified parts of the Linux kernel in HPUX on in their
printers. HP would be distributing the resulting image for people to
use. The fact that people are 'using' it in the end does not alter the
fact that HP would be in violation of the GPL during the act of
distribution.
So what clause 0 is saying is two things:
1) its a basic statement of copyright law, at least in the US
2) if someone distributes in violation of the GPL, you should go
after the distributor, not the end users.
So as a TiVo owner, I am not in violation of the GPL. But TiVo can be
in violation for selling me something based on Linux which does not
follow the GPL.
I actually think they were already in violation with TiVo version 1,
as they were using binary kernel modules. Although it is possible to
have a kernel module which is not a derivative work of the kernel (as
address space and linking concerns are only "rules of thumb", not true
tests for a derivative work), I think that their modules were in fact
pretty clearly derived works. I can say this partly because I have
disassembled a few of them and looked at them in great detail.
> This is really the crux of the argument with the FSF over the DRM
> clauses. If you take the position (as the people who signed the
> discussion paper do) that embedded Linux constitutes an end use, then
> this freedom from restriction of running the programme is compromised in
> GPLv3, and hence is against the spirit of GPLv2 (and thus violates
> clause 9 of GPLv2).
"embedded Linux constitutes end use" as a statement by itself makes no
sense. Are you really trying to argue that all embedded system vendors
get a "get out of jail free" card with regard the GPLv2?
When an embedded system vendor ships Samba as part of their system
they are very clearly distributing Samba. That has been proven time
and again in legal disputes with regards the GPL that I and others have
been involved with. The ones I have been involved with didn't end up
in court, as the lawyers and managers for these companies realised
they were wrong and quickly gave up.
> To go after Tivo (and not violate GPLv2 clause 9), the FSF has to take
> the position that what Tivo is doing is not use, but is distribution.
> This is a dangerous shift in precedent because it applies to every
> embedded use of Linux (or any other GPL licensed programme).
No, the FSF doesn't need to take a position like that.
A copyright license can put almost any burden it likes on a
distributor. I could have put a license on Samba saying it may not be
distributed with hardware that has more than 7pins on the main CPU. It
would have been an idiotic restriction, but it would also have been
enforceable, and vendors would have had to use a different software
package instead of Samba.
The FSF is using the DRM terms in GPLv3 to try to enforce their
original intentions, as they have explained those intentions for many
years. That is not a shift in what they have been doing for years
anyway, but the new language does make it clearer, and thus less time
consuming to enforce.
> That's clause 11 of the current v3 Draft2:
>
> "If you convey a covered work, you similarly covenant to all recipients,
> including recipients of works based on the covered work, not to assert
> any of your essential patent claims in the covered work."
yes, and in GPLv2, in the preamble we have:
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making
the program proprietary. To prevent this, we have made it clear that
any patent must be licensed for everyone's free use or not licensed
at all.
and in the main license text of GPLv2 we have:
For example, if a patent license would not permit royalty-free
redistribution of the Program by all those who receive copies
directly or indirectly through you, then the only way you could
satisfy both it and this License would be to refrain entirely from
distribution of the Program.
Many company lawyers have objected to those terms in GPLv2 over the
years, for much the same reason you object to the patent terms in
GPLv3. I think the GPLv3 license text is a better match for the
intentions of GPLv2 (as given in the above preamble excerpt) than the
GPLv2 text is.
I also think it is worth noting that GPLv3 is arguably better for
companies with patent portfolios than GPLv2. The reason is that the
exact match for the excerpt I gave above in GPLv3 is this:
For example, if you accept a patent license that prohibits
royalty-free conveying by those who receive copies directly or
indirectly through you, then the only way you could satisfy both it
and this License would be to refrain entirely from conveying the
Program.
Note the change from "if a patent license" to "if you accept a patent
license" ?
That should to make life easier for companies who might be
accidentally in violation of the GPLv2 patent provisions. The "accept"
part arguably implies that you have to knowingly be in violation. The
old wording could be argued to mean you are in trouble even for
accidental violation (as can easily happen via bulk cross-licensing
deals).
> This means that if you host a GPLv3 covered programme on your website
> for instance (even if you didn't produce it or modify it in any way),
> you licence any patent you hold covering it.
Many (most?) lawyers think this is already true for GPLv2, due to the
clause I quoted above.
Either way, this is very different from the statement made in the
position statement. In this position statement it said:
As drafted, this currently looks like it would potentially
jeopardise the entire patent portfolio of a company simply by the
act of placing a GPLv3 licensed programme on their website
If the "entire patent portfolio" consists of a small group of patents
which specifically deal with what the code has been posted by the
company deals with, then sure. But as written the position statement
is sensationalist and very misleading, especially when the current
GPLv2 requirements regarding patents are taken into account.
> HP is already on record as objecting to this as disproportionate.
Could you point me at their statement? I suspect it didn't use the
same words used in the position statement :-)
Cheers, Tridge
>
>And the GPLv2 and GPLv3 really _are_ mutually incompatible. There is
>absolutely nothing in the GPLv2 that is inherently compatible with the
>GPLv3, and the _only_ way you can mix code is if you explicitly
>dual-license it.
>
>Ie, GPLv2 and GPLv3 are compatible only the same way GPLv2 is compatible
>with a commercial proprietary license: they are compatible only if you
>release the code under a dual license.
>
>The whole "or later" phrase is legally _no_ different at all from a dual
>licensing (it's just more open-ended, and you don't know what the "or
>later" will be, so you're basically saying that you trust the FSF
>implicitly).
So what would happen if I add an essential GPL2-only file to a "GPL2
or later" project? Let's recall, a proprietary program that
combines/derives with GPL code makes the final binary GPL (and hence
the source, etc. and whatnot, don't stretch it). Question: The Linux
kernel does have GPL2 and GPL2+later combined, what does this make
the final binary?
(Maybe you implicitly answered it by this already, please indicate):
>Exactly. The GPLv3 can _only_ take over a GPLv2 project if the "or later"
>exists.
>From that I'd say it remains GPL2 only.
Thanks for the clarification (though I know we're all IANALs.)
Jan Engelhardt
--
On Fri, 29 Sep 2006, Neil Brown wrote:
> On Thursday September 28, [email protected] wrote:
> >
> > Btw, it should be stated here: I'm not advocating either of the above. If
> > a license says "v2 or later", anybody who removes an explicit right
> > granted by the people who originally wrote and worked on the code is just
> > being a total a-hole.
>
> But isn't that the whole point - to replace v2 by v3?
I'm sure it's the point for the FSF. Is it really the point for anybody
else? Everybody else is better off with the more permissive license..
> Now I know that is what you would prefer, but it seems obvious that it
> isn't what the new FSF wants.
> I would be very surprised if new versions of any FSF-control code is
> available under v2 more than a few months after v3 becomes final.
I suspect the FSF might well be _very_ careful here. If they move to "v3
or later", they had better be damn sure somebody won't license-fork that
project, or they'll be left with nothing at all.
So I would not be entirely surprised if projects remain "v2 or later" just
because it's to nobodys advantage to play chicken.
But who knows..
> I don't see the urgency. Why are you "screwed forever"? You can
> always take the last version that was available under a suitable
> license and fork from there, just like OpenSSH did.
>
> Sure: the longer you leave it the harder it will be to get critical
> mass, but I don't see the need for it to be done immediately.
It obviously doesn't have to be, but it gets a lot harder to do later, if
the project has any appreciable amount of real development.
Of course, a lot of projects probably don't have that much. I haven't
followed, but I don't get the feeling that bash or fileutils have a huge
amount of constant changes..
Linus
On Fri, 2006-09-29 at 14:40 +1000, Neil Brown wrote:
> You seem to be saying that including software in a product that you
> then distribute is *both* a USE and a DISTRIBUTION of that software.
Sort of ... I'm asserting that producing something (an appliance say, or
a PCI card) that runs linux to achieve its function is a "use" (an act
of running the program) within the meaning of GPLv2 clause 0. Selling
the Box (or card, or whatever) also becomes a distribution.
> So if the software is obtained under the GPL, and the GPL asserts "no
> restrictions on use" then it should also not restrict distribution.
> It can place requirements that must be met before distribution is
> allowed, but they shouldn't be so onerous as to inhibit distribution.
> Does that sound right?
Not exactly. Under v2, there are specific duties that go along with the
act of distributing (providing access to the source code and all
modifications), but explicitly none on end use. You can't get out of
the distribution requirements simply by claiming it's also a use.
However I claim that, the GPLv3 requirement that you be able to "execute
modified versions from source code in the recommended or principal
context of use" does constitute an end use restriction on the embedded
system because the appliance (or card, or whatever) must be designed in
such a way as to allow this.
If my claim is valid, it means that GPLv3 violates the spirit of GPLv2
because it specifically goes against one of its terms (clause 0). This
is the reason the FSF sees the act of running embedded Linux in
something to be a distribution; so they can apply the additional
restrictions without going against the spirit of GPLv2.
James
On Fri, 29 Sep 2006, Jan Engelhardt wrote:
>
> So what would happen if I add an essential GPL2-only file to a "GPL2
> or later" project? Let's recall, a proprietary program that
> combines/derives with GPL code makes the final binary GPL (and hence
> the source, etc. and whatnot, don't stretch it). Question: The Linux
> kernel does have GPL2 and GPL2+later combined, what does this make
> the final binary?
The final is always the most restricted license (or put another way: it's
the "biggest possible license that can be used for everything", but in
practice it means that non-restrictive licenses always lose out to their
more restrictive brethren).
This is, btw, why BSD code combined with GPL code is always GPL, and never
the other way. It's not a "vote" depending on which one has more code. And
it's not a mixture.
The GPLv2 is very much designed to always be the most restricted license
in any combination - because the license says that you cannot add any
restrictions (so if there _was_ a more restricted license, it would no
longer be compatible with the GPLv2, and you couldn't mix them at all in
the first place).
So any time you have a valid combination of licenses, if anything is
"GPLv2 only", the final end result is inevitably "GPLv2 only".
[ Btw, the same is true of the GPLv3 - very much by design in both cases.
This is why you can _never_ combine a "GPLv2" work with a "GPLv3" work.
They simply aren't compatible. One or both must accept the others
license restrictions, and since neither does, and the restrictions
aren't identical, there is no way to turn one into the other, or turn
them both into a wholly new "mixed" license.
So this is why the _only_ way you can mix GPLv2 and GPLv3 code is if the
code was dual-licensed, ie we have the "v2 or later" kind of situation. ]
Basic rule: licenses are compatible only if they are strict subsets of
each other, and you can only ever take rights _away_ when you relicense
something. You can never add rights - if you didn't get those rights in
the first place with the original license, they're simply not yours to
add.
Otherwise, we could all buy the latest CD albums, and then relicense them
with more rights than you got (or we could take GPLv3 code and remove the
restrictions, and relicense it as BSD).
So the reason you can't re-license the CD albums is that you don't even
have any license to re-distribute them at all, and as such there is
nothing for you to sublicense further. And the reason you cannot relicense
the GPLv2 is that it tells you that you can't add any new restrictions
when you re-distribute anything, and you obviously can't add any rights
that you didn't have.
And, as usual: IANAL. But none of this is really even remotely
controversial.
Linus
> So what would happen if I add an essential GPL2-only file to a "GPL2
> or later" project?
The files would have to act as a license boundary. Otherwise, it would be
GPL2 only. (However, I think people could reasonably assume that if someone
contributed to a GPL2 or later project, they intended their work to be
licensed the same as the project.)
> Let's recall, a proprietary program that
> combines/derives with GPL code makes the final binary GPL (and hence
> the source, etc. and whatnot, don't stretch it). Question: The Linux
> kernel does have GPL2 and GPL2+later combined, what does this make
> the final binary?
GPL2. If you combine dual licensed code with GPLv2 code, the result must be
GPLv2.
> (Maybe you implicitly answered it by this already, please indicate):
> >Exactly. The GPLv3 can _only_ take over a GPLv2 project if the
> "or later"
> >exists.
> From that I'd say it remains GPL2 only.
I still don't see how it can take over, unless the FSF fixes the "bug" in
GPLv3. GPLv2 does not permit such takeover, and unless GPLv3 is amended to
do so, such a takeover is prohibited.
I could be in error, I haven't looked closely enough. But if I'm right, I
presume the FSF will be tipped off by someone and fix it. If anyone from the
FSF is listening, you need to add a clause to GPLv3 permitting you to modify
any project licensed under both the GPLv3 and another license such non-GPL
and/or earlier-GPL licenses can be removed. Otherwise, no 'GPLv2 or later'
project can become 'GPLv3 or later'. (Unless that's intentional.)
DS
> On Thu, 28 Sep 2006 19:29:55 -0700
> "David Schwartz" <[email protected]> wrote:
> > Unless I'm missing something, you *cannot* change the license
> > from "v2 or
> > later at your option" to "v3 or later". Both GPLv2 and GPLv3 explicitly
> > prohibit modifying license notices. (Did the FSF goof big time?
> > It's not too
> > late to change the draft.)
> The copyright holder is not constrained at all in how they license their
> work. They can change the license to anything they want, including the
> GPLv3 or anything else. Of course, earlier versions will still
> be available
> under the GPLv2.
Right, but *you* cannot change the license. You cannot get a copy of a
"GPLv2 or later" work and add some code and release the result as "GPLv3 or
later". (Assuming you are not the copyright holder.)
I believe the FSF intended to permit this. Otherwise, even if Linux had been
"GPLv2 or later" all along, it could not adopt GPLv3 without permission from
all copyright holders (or ever include any code that was "GPLv3 or later").
That hardly seems to have been the FSF's intent. (Or was it?!)
DS
> Interestingly, 2.b seem to say that if I received a program under
> GPLv2, and I pass it on, then I must pass it on under GPLv2-only...
> So to be able to distribute something written today under GPLv3 (when
> it comes into existence), you must be the original or have received it
> directly from the original author....
The GPL *cannot* say that. The GPL can only fail to give you rights, it
cannot take rights you would otherwise have away.
DS
On Fri, 2006-09-29 at 15:51 +1000, [email protected] wrote:
> > This means that if you host a GPLv3 covered programme on your website
> > for instance (even if you didn't produce it or modify it in any way),
> > you licence any patent you hold covering it.
>
> Many (most?) lawyers think this is already true for GPLv2, due to the
> clause I quoted above.
Well, this is the principle of Estoppel, I believe. To prevail on
estoppel, the distribution must have been deliberate, not inadvertent.
The v3 language also pulls in inadvertent distribution.
> Either way, this is very different from the statement made in the
> position statement. In this position statement it said:
>
> As drafted, this currently looks like it would potentially
> jeopardise the entire patent portfolio of a company simply by the
> act of placing a GPLv3 licensed programme on their website
>
> If the "entire patent portfolio" consists of a small group of patents
> which specifically deal with what the code has been posted by the
> company deals with, then sure.
So we agree that the statement is true for a company that has only a
software patent portfolio.
> But as written the position statement
> is sensationalist and very misleading, especially when the current
> GPLv2 requirements regarding patents are taken into account.
No, the point being made is that under v2, as long as the company was
only distributing, it didn't have to go over its patent portfolio
comparing it against the functions in the code on the website. It would
still be able to sue for a patent infringement in code as long as it
didn't deliberately mislead people into using that code.
> > HP is already on record as objecting to this as disproportionate.
>
> Could you point me at their statement? I suspect it didn't use the
> same words used in the position statement :-)
Actually, HP had no input at all into the statement we made, so I would
be very surprised if the same words were used.
James
On Fri, 2006-09-29 at 15:51 +1000, [email protected] wrote:
> I am however disagreeing with the justification given in the position
> statement. The position statement implies that the FSF may be in
> breach of contract, at least morally, by trying to release a version
> of the GPL that is not in keeping with previous versions. I think the
> preamble of the GPLv2 and the explanations given of the FSF intentions
> over the years are completely consistent with the GPLv3 current draft.
Right ... see the semantic argument over the difference between use and
distribution I gave Neil a while ago.
The FSF has always maintained (and still does) that you can use the
covered work for anything (although the v2 language saying this is gone
in v3). I believe even the FSF accepts the position that reaching
beyond distribution to control end use would be a violation of the
spirit of GPLv2 .... if they didn't we wouldn't be quibbling over the
semantic meanings of the two terms. Their latest press release on this
actually says "Contrary to what some have said, the GPLv3 draft has no
use restrictions, and the final version won't either."
> ok, lets take a really obvious example. Say that HP decided to
> incorporate modified parts of the Linux kernel in HPUX on in their
> printers. HP would be distributing the resulting image for people to
> use. The fact that people are 'using' it in the end does not alter the
> fact that HP would be in violation of the GPL during the act of
> distribution.
That's correct. They have to comply with the distribution duties as
outlined in the licence (which they could do by publishing all of the
HPUX pieces they incorporated, of course). However, once they comply
with the distribution requirements, they're free to do whatever they
want with the resulting OS in their printer ... including checking for
only HP authorised ink cartridges. You can take exception to this check
and not buy the resulting printer, but you can't tell them not to do the
check without telling them how they should be using the embedded
platform.
James
On Fri, 2006-09-29 at 15:51 +1000, [email protected] wrote:
> I actually think they were already in violation with TiVo version 1,
> as they were using binary kernel modules. Although it is possible to
> have a kernel module which is not a derivative work of the kernel (as
> address space and linking concerns are only "rules of thumb", not true
> tests for a derivative work), I think that their modules were in fact
> pretty clearly derived works. I can say this partly because I have
> disassembled a few of them and looked at them in great detail.
It's simpler than that. They were in violation even if you don't
consider their module to be a derived work, because they distributed it
as part of a larger whole which was based on Linux -- and thus the GPL
extends to "each and every part regardless of who wrote it."
Binary-only modules on their own are extremely dubious, but binary-only
modules shipped as _part_ of an embedded product, in conjunction with a
Linux kernel, are a clear violation of the licence.
"If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it."
--
dwmw2
Linus,
> Quite frankly, if the FSF ever relicenses any of their projects to be
> "GPLv3 or later", I will hope that everybody immediately forks, and
> creates a GPLv2-only copy (and yes, you have to do it immediately, or
> you're screwed forever). That way the people involved can all vote with
> their feet.
I do hope your either joking about this, or that you would consult
with the major contributors to the project before doing this. In past
postings you have expressed strong support for "authors rights", which
includes the idea of not using someones code if they don't want you to
use it, even if it might be legal to do so.
I'm also a strong proponent of "authors rights", and I would consider
it very nasty if someone took one of my projects and decided to fork
it to be GPLv2 only, deliberately going against my intention. They
might have a legal right to do so but it would clearly be against my
wishes. I'm not even 100% certain it would be legal.
The "any later version" words I have put on all my projects are there
quite deliberately.
Cheers, Tridge
James,
> No, the point being made is that under v2, as long as the company was
> only distributing, it didn't have to go over its patent portfolio
> comparing it against the functions in the code on the website.
umm, you've got it entirely backwards!
In GPLv2 you _do_ have to check your entire patent portfolio. You also
have to check the patent portfolio of all of the companies you
cross-license patents from. It says this:
For example, if a patent license would not permit royalty-free
redistribution of the Program by all those who receive copies
directly or indirectly through you, then the only way you could
satisfy both it and this License would be to refrain entirely from
distribution of the Program.
If your company is currently under the impression that distribution
does not imply a patent license on the methods implemented in that
code, then your lawyers are sailing very close to the wind. As you
mention in the position statement, lawyers tend to take a broad
interpretation when assessing their own companies liability, and it
doesn't take a very broad interpretation of the GPLv2 to conclude that
distribution implies a patent license.
On the other hand, the current GPLv3 draft tries to ensure that the
innocent don't get caught. It has the following:
If you convey a covered work, knowingly relying on a
non-sublicensable patent license that is not generally available to
all, you must either (1) act to shield downstream users against the
possible patent infringement claims from which your license protects
you, or (2) ensure that anyone can copy the Corresponding Source of
the covered work, free of charge and under the terms of this
License, through a publicly available network server or other
readily accessible means.
The 'knowingly' part is very important, as is the 'or'. Compare this
paragraph to the first draft of GPLv3. It has changed a lot. You know
why it changed a lot? Because a whole lot of company lawyers saw that
the draft 1 language was problematic. They gave feedback, and the FSF
changed the draft to address their concerns.
This is the bit I find so frustrating about this debate. The GPLv3
current draft has had lots of input from precisely the people you say
will be affected the most. There is a whole committee of lawyers from
major corporations who are trying to ensure they will be happy with
the result. The draft has improved as a result of this. The GPLv2 did
not have that input, and as a result GPLv2 is more of a minefield
regarding patents than the current GPLv3 draft.
There is still more work to do, and the GPLv3 draft is not final, but
if you think "its all OK, patents are not covered by GPLv2, I'll stick
to that" then you are badly mistaken.
> > > HP is already on record as objecting to this as disproportionate.
> >
> > Could you point me at their statement? I suspect it didn't use the
> > same words used in the position statement :-)
>
> Actually, HP had no input at all into the statement we made, so I would
> be very surprised if the same words were used.
I'd also be very surprised if HP lawyers made a statement like the one
in the position statement :)
Cheers, Tridge
>
>Every time I accidentally execute `uname` with an -a instead of
>a -r, I am reminded of the history rewrite as I am presented with:
>
>Linux chaos.analogic.com 2.6.16.24 #1 SMP PREEMPT
> Wed Jul 12 11:32:34 EDT 2006 i686 i686 i386 GNU/Linux
> ^^^^^^^^^
Do you even know what that field is supposed to be?
Right, it is `uname -o`, and not `uname -s`.
Jan Engelhardt
--
James,
> > If the "entire patent portfolio" consists of a small group of patents
> > which specifically deal with what the code has been posted by the
> > company deals with, then sure.
>
> So we agree that the statement is true for a company that has only a
> software patent portfolio.
No, we don't :)
The company can consist of only a patent portfolio, but additionally
all of those patents (ie. the "entire patent portfolio") would need to
be implemented by the program being distributed them.
That caveat is important, and changes it from a misleading statement
to a true statement. It also is a statement which is true for the
GPLv2, which makes it not such a useful statement to make when
considering the relative merits of the two licenses.
I'd also like to note that I don't have much sympathy for companies
that consist of only a patent portfolio. They are pretty much scum in
my view. If they don't make any products at all and live on only
patent revenue then the world would be better off without them :-)
Cheers, Tridge
> > Quite frankly, if the FSF ever relicenses any of their projects to be
> > "GPLv3 or later", I will hope that everybody immediately forks, and
> > creates a GPLv2-only copy (and yes, you have to do it immediately, or
> > you're screwed forever). That way the people involved can all vote with
> > their feet.
> I do hope your either joking about this, or that you would consult
> with the major contributors to the project before doing this. In past
> postings you have expressed strong support for "authors rights", which
> includes the idea of not using someones code if they don't want you to
> use it, even if it might be legal to do so.
That really is totally against the spirit of the GPL and, frankly, I think
it's the opposite of the attitude the free software community should be
taking.
You have to choose between "even if you lawfully acquired a work, you should
not use it in ways the author does not want" and "once you lawfully acquire
a work, you may do with it what you want provided you respect other people's
freedom to do the same".
The GPL squarely opts for the latter.
The spirit is that you give other people a lot of freedom to do things with
your works, even things you may very much dislike. In exchange, you get the
freedom to do the same things and we all build up a large pool of
unencumbered works we can all draw on. If everyone got to impose their own
restrictions, and still take from and contribute to the same pool, it would
quickly poison the pool.
Consider just the problem "GPLv2 and later" and "GPLv3 and later"
contributions to the same project will cause. If you have to deal with "GPL
and please don't do X" also, ...
> I'm also a strong proponent of "authors rights", and I would consider
> it very nasty if someone took one of my projects and decided to fork
> it to be GPLv2 only, deliberately going against my intention. They
> might have a legal right to do so but it would clearly be against my
> wishes. I'm not even 100% certain it would be legal.
Then don't put your software under a license that permits them to do so. If
you did so accidentally or without knowledge of the consequences, I have
much sympathy. But if you accept the GPL package deal and then try to
pressure people into different terms, I have none at all.
> The "any later version" words I have put on all my projects are there
> quite deliberately.
And your work will always be available that way, nothing can make it go
away. But suppose I add my own work to your work -- why should your wishes
override mine? Or, to put it another way, how does my offering my own work
based on yours with a different license that you don't like take anything
away from you? (Especially since it's the one license you actually knowingly
chose.)
As I read the GPLv2, it only requires you to keep the ability for the work
to be licensed under the GPLv2. (Mostly per section 2b.) The preamble
appears to conflict (in the "all the rights" section), but that can't
possibly override 2b (and must mean all the rights you got from the GPLv2),
or you get some nonsensical results. For example, if I was the sole author
of a GPLv2 work and I really had to give everyone all the rights I had, I
would have to give them the right to relicense under the BSD license. (Since
I have that right.)
A lot of people get justifiably irritated at some things the GPL lets people
do with their code. The spirit of the GPL is that you have to take it, and
in exchange, you get to irritate other people if you want to.
Those are the rules we chose to play by.
DS
[email protected] wrote:
> I'd also like to note that I don't have much sympathy for companies
> that consist of only a patent portfolio. They are pretty much scum in
> my view. If they don't make any products at all and live on only
> patent revenue then the world would be better off without them :-)
So, if you outsource your manufacturing, you are scum?
Jeff
Jeff,
> [email protected] wrote:
> > I'd also like to note that I don't have much sympathy for companies
> > that consist of only a patent portfolio. They are pretty much scum in
> > my view. If they don't make any products at all and live on only
> > patent revenue then the world would be better off without them :-)
>
> So, if you outsource your manufacturing, you are scum?
I think its reasonable to include 'programming', 'developing' etc in
'make' :-)
I'm just not a fan of companies who don't do anything except collect
patent royalties on products that other people develop. I doubt there
would be anyone in that category on this mailing list :)
Cheers, Tridge
>>>>> "Tridge" == tridge <[email protected]> writes:
Tridge> I'm also a strong proponent of "authors rights", and I would
Tridge> consider it very nasty if someone took one of my projects and
Tridge> decided to fork it to be GPLv2 only, deliberately going
Tridge> against my intention. They might have a legal right to do so
Tridge> but it would clearly be against my wishes. I'm not even 100%
Tridge> certain it would be legal.
Tridge> The "any later version" words I have put on all my projects
Tridge> are there quite deliberately.
Tridge: *you* also chose deliberately to use the GPL which explicitely
allows other people to do so. You could have written "the latest
version of the GPL as released by the FSF" or used a licence similar
to the GPLv2 with the permission to restrain the licence removed.
Moreover, anyone can add a patch released under the GPLv2 only (this
is their right, morally and technically) to a copy of your software;
after that, they have no choice but to redistribute the whole as GPLv2
only (I insist on "the whole", of course they might keep the "or later"
on your individual files).
Sam
--
Samuel Tardieu -- [email protected] -- http://www.rfc1149.net/
Thomas Gleixner wrote:
> On Mon, 2006-09-25 at 12:31 +0100, Alan Cox wrote:
>
>> The GPLv3 rewords it in an attempt to be clearer but also I think rather
>> more over-reaching. It's not clear what for example happens with a
>> rented device containing GPL software but with DRM on the hardware.
>> Thats quite different to owned hardware. GPLv2 leaves it open for the
>> courts to make a sensible decision per case, GPLv3 tries to define it in
>> advance and its very very hard to define correctly.
>>
>
> Also the prevention of running modified versions is not only caused by
> economic interests and business models. There are also scenarios where
> it is simply necessary:
>
> - The liability for damages, where the manufacturer of a device might
> be responsible in case of damage when he abandoned the prevention. This
> applies to medical devices as well as to lasers, machine tools and many
> more. Device manufacturers can not necessarily escape such liabilities
> as it might be considered grossly negligent to hand out the prevention
> key, even if the user signed an exemption from liability.
>
This seems silly to me. Sure, lasers and medical equipment is
dangerous if used wrong. When such equipment is
controlled by software, then changing that software brings
huge responsibility. But it shouldn't be made impossible.
They can provide the key, with the warning that _using_ it
means you are on your own and take all responsibility.
I can take the covers off a cd player and let the laser
shine into the room. Nothing prevents me from doing
that, it isn't welded shut or anything. And it might
be useful if I ever need a laser beam. Of course I am
then responsible if I take someone's eye out. CD players
have warning labels about this. And the same can be done
for the keys to dangerous software.
> - Regulations to prevent unauthorized access to radio frequencies, which
> is what concerns e.g. cellphone manufacturers.
>
Unauthorized use is illegal and easy enough to track down.
No special protection is needed. And it cannot be enforced
by making the phones har to modify - any radio amateur knows
how to build from scratch a transmitter to jam the GSM bands
if he should be inclined to do so. Anyone can look this up in
books too.
Helge Hafting
Ar Gwe, 2006-09-29 am 12:15 +0200, ysgrifennodd Helge Hafting:
> This seems silly to me. Sure, lasers and medical equipment is
> dangerous if used wrong. When such equipment is
> controlled by software, then changing that software brings
> huge responsibility. But it shouldn't be made impossible.
You will note that large corporations like telcos routinely push for
such legislation and rules to increase the burdens on smaller companies
and prevent competition.
> > - Regulations to prevent unauthorized access to radio frequencies, which
> > is what concerns e.g. cellphone manufacturers.
> >
> Unauthorized use is illegal and easy enough to track down.
> No special protection is needed. And it cannot be enforced
> by making the phones har to modify - any radio amateur knows
Indeed - the regulations exist so that the state can control who makes
phones, ensure they contain the GSM crypto backdoors and don't support
additional voice scrambling or call relay type onion routing etc.
Alan
James Bottomley <[email protected]> writes:
> I'm asserting that producing something (an appliance say, or a PCI
> card) that runs linux to achieve its function is a "use" (an act of
> running the program) within the meaning of GPLv2 clause 0. Selling
> the Box (or card, or whatever) also becomes a distribution.
The vendor did many acts covered by copyright law (taking US copyright
law here), and it's important to distinguish the effects of the
license on each act:
1. Use: Vendor runs Linux on prototype hardware to see where it fails
to boot, in order to write new drivers. The GPL places no
restriction on this act, and probably cannot do so since US
copyright law doesn't cover running a program.
2. Prepare a derivative work: Vendor writes drivers for their
hardware, builds a new Linux kernel. The GPLv2 places no
restriction on this act. The GPLv3 restricts this act a bit in the
patent retaliation clause.
3. Use the derivative work: Vendor tests (runs) the modified Linux.
There are no restrictions placed by the GPL (v2 or v3). If you can
make the derivative work (e.g. don't fall foul of the
patent-retaliation clause in GPLv3), then you can use it how you
want.
4. Distribute the derivative work: Vendor sells the hardware with
embedded Linux. Now the GPL places restrictions. v2 says that if
you distribute, you must make source code available and (if I
understand Alan Cox's argument correctly) make the installation
keys available. v3 tightens the installation-keys requirement.
But it's not a use restriction.
> However I claim that, the GPLv3 requirement that you be able to "execute
> modified versions from source code in the recommended or principal
> context of use" does constitute an end use restriction on the embedded
> system because the appliance (or card, or whatever) must be designed in
> such a way as to allow this.
Not necessarily. If the vendor makes devices for internal use, they
are not distributing the kernel, so no GPL requirements (except
perhaps the GPLv3 patent retaliation clause) are triggered. Only when
they distribute does the GPL place requirements on what they must do:
provide source code and installation keys. So it's not the use that
is restricted (they can do what they like 'at home'), only the
distribution.
Regards,
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
> However, once they comply with the distribution requirements,
> they're free to do whatever they want with the resulting OS in their
> printer ... including checking for only HP authorised ink
> cartridges. You can take exception to this check and not buy the
> resulting printer, but you can't tell them not to do the check
> without telling them how they should be using the embedded platform.
I don't see where the GPLv3 forbids such checks. Which section are
you thinking of? In my understanding, it says only that HP must give
users the keys to install modified software. From section 1 (of the
July draft):
The Corresponding Source also includes any encryption or
authorization keys necessary to install and/or execute modified
versions from source code in the recommended or principal context of
use, such that they can implement all the same functionality in the
same range of circumstances.
So the user, having the keys, can remove the cartridge check. HP
might not like it and may choose not to distribute GPLv3 software with
the printer, but that's a separate story.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
Ar Gwe, 2006-09-29 am 17:48 +1000, ysgrifennodd [email protected]:
> I'm also a strong proponent of "authors rights", and I would consider
> it very nasty if someone took one of my projects and decided to fork
> it to be GPLv2 only, deliberately going against my intention. They
> might have a legal right to do so but it would clearly be against my
> wishes. I'm not even 100% certain it would be legal.
In the FSF case the reverse is more likely - the FSF uses its copyright
assignments to re-version a piece of software they own the rights to.
That I think is self-curing because people will contribute to the forked
tree without giving the FSF assignments - which is authors rights 8)
Hi!
> And given that Stallman has announced that the new LGPL will be (to
> use programming terms) a subclass of GPLv3, it means that the LGPLv3
> is by extension incompatible with the GPLv2. So that means that there
> will have to be two different versions of glibc (and every other
> shared library) shipped with every distributions --- one which is
> GPLv2, and one which is GPLv3. And this fork is going to be forced by
> the FSF!
Whats the problem? FSF does not do any programming itself. It will
force a fork, but world will just ignore the fork for glibc.
--
Thanks for all the (sleeping) penguins.
Hi!
> > The reason a clause such as that will work is that people have no natural
> > right to redistribute Linux.
>
> Right. Any copyright license will basically say
>
> "You can distribute this assuming you do so-and-so"
>
> and a contract can actually extend on that and also limit you in other
> ways than just distribution, ie you can sat
>
> "You can buy this, but you cannot legally benchmark it"
>
> However, none of that actually extends your "derived work" in any way.
You are right, of course, but you can affect derived work by stuff
such as:
You may not copy Linux. As a special exception, you may
copy/distribute
Linux if you never copied Tolstoy before.
That would probably work.... in cases like Tivo anyway.
Pavel
--
Thanks for all the (sleeping) penguins.
Helge Hafting wrote:
>Thomas Gleixner wrote:
>
>
>>On Mon, 2006-09-25 at 12:31 +0100, Alan Cox wrote:
>>
>>
>>
>>>The GPLv3 rewords it in an attempt to be clearer but also I think rather
>>>more over-reaching. It's not clear what for example happens with a
>>>rented device containing GPL software but with DRM on the hardware.
>>>Thats quite different to owned hardware. GPLv2 leaves it open for the
>>>courts to make a sensible decision per case, GPLv3 tries to define it in
>>>advance and its very very hard to define correctly.
>>>
>>>
>>>
>>Also the prevention of running modified versions is not only caused by
>>economic interests and business models. There are also scenarios where
>>it is simply necessary:
>>
>>- The liability for damages, where the manufacturer of a device might
>>be responsible in case of damage when he abandoned the prevention. This
>>applies to medical devices as well as to lasers, machine tools and many
>>more. Device manufacturers can not necessarily escape such liabilities
>>as it might be considered grossly negligent to hand out the prevention
>>key, even if the user signed an exemption from liability.
>>
>>
>>
>This seems silly to me. Sure, lasers and medical equipment is
>dangerous if used wrong. When such equipment is
>controlled by software, then changing that software brings
>huge responsibility. But it shouldn't be made impossible.
>
>They can provide the key, with the warning that _using_ it
>means you are on your own and take all responsibility.
>
>I can take the covers off a cd player and let the laser
>shine into the room. Nothing prevents me from doing
>that, it isn't welded shut or anything. And it might
>be useful if I ever need a laser beam. Of course I am
>then responsible if I take someone's eye out. CD players
>have warning labels about this. And the same can be done
>for the keys to dangerous software.
>
>
>>- Regulations to prevent unauthorized access to radio frequencies, which
>>is what concerns e.g. cellphone manufacturers.
>>
>>
>>
>Unauthorized use is illegal and easy enough to track down.
>No special protection is needed. And it cannot be enforced
>by making the phones har to modify - any radio amateur knows
>how to build from scratch a transmitter to jam the GSM bands
>if he should be inclined to do so. Anyone can look this up in
>books too.
>
>Helge Hafting
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Amen!
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On Fri, 29 Sep 2006, [email protected] wrote:
>
> > Quite frankly, if the FSF ever relicenses any of their projects to be
> > "GPLv3 or later", I will hope that everybody immediately forks, and
> > creates a GPLv2-only copy (and yes, you have to do it immediately, or
> > you're screwed forever). That way the people involved can all vote with
> > their feet.
>
> I do hope your either joking about this, or that you would consult
> with the major contributors to the project before doing this.
I very much mean "major contributors".
Quite frankly, the FSF isn't actually doing any of the work for any of the
tools it maintains any more. And hasn't for a long while.
Hint: look up the glibc maintainers opinions on some of these same issues
in the past. They had reason to clash with the FSF over a _much_ smaller
license change (LGPL 2 -> 2.1).
Linus
[IANAL, just an interested bystander]
James Bottomley <[email protected]> wrote:
> On Fri, 2006-09-29 at 14:40 +1000, Neil Brown wrote:
> > You seem to be saying that including software in a product that you
> > then distribute is *both* a USE and a DISTRIBUTION of that software.
Use is irrelevant; under US copyright law you can do whatever you want with
what you got legally. The "use" clauses aren't any special dispensation by
the GPL.
> Sort of ... I'm asserting that producing something (an appliance say, or
> a PCI card) that runs linux to achieve its function is a "use" (an act
> of running the program) within the meaning of GPLv2 clause 0.
Not necessarily, but it doesn't matter anyway.
> Selling
> the Box (or card, or whatever) also becomes a distribution.
Sure does.
> > So if the software is obtained under the GPL, and the GPL asserts "no
> > restrictions on use" then it should also not restrict distribution.
It doesn't, AFAICS.
> > It can place requirements that must be met before distribution is
> > allowed, but they shouldn't be so onerous as to inhibit distribution.
> > Does that sound right?
> Not exactly. Under v2, there are specific duties that go along with the
> act of distributing (providing access to the source code and all
> modifications),
No. Just to the full source code. It is very nice from distribution
builders that e.g. an SRPM includes the original code plus patches, and of
Linus that you can rumage around in Linux' git repository to trace the
history, but that isn't a requirement of GPLv2 at all.
> but explicitly none on end use. You can't get out of
> the distribution requirements simply by claiming it's also a use.
Right.
> However I claim that, the GPLv3 requirement that you be able to "execute
> modified versions from source code in the recommended or principal
> context of use" does constitute an end use restriction on the embedded
> system because the appliance (or card, or whatever) must be designed in
> such a way as to allow this.
It tries to leverage the license on the software to force certain hardware
(or use) designs. Problem is, it won't work. Can't use FunkyOS for DRMing
because it is GPLv3? Just use AnotherOS then. Or FunkyOS will do, and run
propietary software on top of it that does all the nasty stuff anyway. This
isn't rocket science, machines are so powerful today that developing such
custom software isn't a tour de force anymore, and there are several
alternatives out there, ones free for the taking and paid ones.
Folks, open source is /very, very far/ from being prevalent enough to force
anti-<whatever> provisions through via its software license (if that made
any sense, which I very much doubt); and if it was, doing so would probably
be moot anyway.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
On Fri, 29 Sep 2006, Helge Hafting wrote:
>
> This seems silly to me. Sure, lasers and medical equipment is
> dangerous if used wrong. When such equipment is
> controlled by software, then changing that software brings
> huge responsibility. But it shouldn't be made impossible.
It may be "silly", but hey, it's often a law.
Also, even if it wasn't about laws, there is a very valid argument that
you should be able to be silly. There's a reason people don't get locked
up in prisons just for being silly or crazy - sometimes something that
seems silly may turn out to be a great idea.
And people seem to totally ignore that there is no correct answer to "who
may do software updates?". People rant and rave about companies that stop
_you_ from making software updates, but then they ignore the fact that
this also stops truly bad people from doing it behind your back.
Quite frankly, in many situations, I'd sure as hell be sure that any
random person with physical access to a machine (even if it was mine, and
even if I'm _one_ of them) could not just upgrade a piece of software.
Sometimes you can make those protections yourself (ie you add passwords,
and lock down the hardware - think of any University student computer
center or a library or something), but what a lot of people seem to
totally ignore is that often it's a hell of a lot more convenient for
_everybody_ if the vendor just does it.
And no, the answer is not "just give the password to people who buy the
hardware". That requires individualized passwords, probably on a
per-machine basis. That's often simply not _practical_, or is just much
more expensive. It's quite natural for a vendor in this kind of situation
to just have one very secret private key per model or something like that.
In other words, these secret keys that people rant against JUST MAKE
SENSE. Trying to outlaw the technology is idiotic, and shortsighted.
If you don't want a machine that is locked down, just don't buy it. It's
that simple. But don't try to take the right away from others to buy that
kind of convenience.
And yes, Tivo is exactly such a situation. It's damn convenient. I've got
two Tivo's myself (and yes - I actually paid full price for them. I was
given one of the original ones, but that's long since scrapped, and even
that one I paid the subscription fee myself). But you don't have to buy
them. You can build your own at any time, and it will probably be more
powerful.
So people are trying to claim that something is "wrong", even though it
clearly is. The people arguing for "freedom" are totally ignoring my
freedom to buy stuff that is convenient, and ignore real concerns where
things like TPM etc actually can make a lot of sense.
Can it be used for bad things? Sure. Knives are dangerous too, but that
doesn't make them "wrong" or something you shouldn't allow.
Linus
Ar Gwe, 2006-09-29 am 09:51 -0700, ysgrifennodd Linus Torvalds:
> If you don't want a machine that is locked down, just don't buy it. It's
> that simple. But don't try to take the right away from others to buy that
> kind of convenience.
That cuts both ways
"If you don't want to use all this handy free code then don't lock your
system down or go use OpenBSD"
Alan
On Fri, 29 Sep 2006, Alan Cox wrote:
>
> That cuts both ways
>
> "If you don't want to use all this handy free code then don't lock your
> system down or go use OpenBSD"
That's a fallacious argument for two reasons:
- the GPLv2 allows usage in any circumstances except the geographical
limitation that can be forced on it by other laws. No serious lawyer I
have ever met is even ambiguous about this. There's just no question -
people may not be happy about it, and iirc the FSF at some point tried
to claim somethign else, but this really isn't all that controversial.
So the whole "If you don't want to use all this handy free code"
argument is simply WRONG. It's based on a premise that just isn't true.
All that handy free code is perfectly usable for things like a secure
terminal or something else that doesn't allow you to change its
behaviour because of some load-time consistency check.
You cannot make a logical argument that as it's axiom takes something
that is patently false. It may still be "logically consistent", but it
has no _relevance_, since it has nothing to do with reality.
- It tries to equate the word "free" (which means so many things that it
almost lacks meaning) with "not able to authenticate". Which is just
one of hundreds of ways to read it, and it is extremely irritating how
the FSF thinks that _its_ definition of the word free somehow trumps
everybody elses.
We already had that discussion ten years ago, and it's why people who
want to be clear in their speaking (and thinking) use the term "Open
Source". Because the OSI rules generally speak about concrete things
that mean only one thing, which means that they actually have a
well-defined _meaning_ in any discussion between two parties.
A lot of people seem to think that the problem with "free" was just the
confusion between "no cost" and "freedom". Those people seemed to never
really understand an even deeper problem in the whole FSF language use.
In other words: anybody who wants to have a logical argument about the
real world needs to start with (a) acknowledging facts and (b) avoid using
words that may mean something else to the other side.
Linus
Ar Gwe, 2006-09-29 am 10:49 -0700, ysgrifennodd Linus Torvalds:
> All that handy free code is perfectly usable for things like a secure
> terminal or something else that doesn't allow you to change its
> behaviour because of some load-time consistency check.
If you provide the neccessary information so the user can replace it and
it still works. Even with GPLv2. Thats the information I was given,
thats the interpretation that the lawyers I've talked to consider
reasonable and likely court enforcable, thats the interpretation that
has been accepted several times in out of court GPL violation
settlements.
Alan
On Fri, 29 Sep 2006, Linus Torvalds wrote:
>
> - the GPLv2 allows usage in any circumstances except the geographical
> limitation that can be forced on it by other laws. No serious lawyer I
> have ever met is even ambiguous about this. There's just no question -
> people may not be happy about it, and iirc the FSF at some point tried
> to claim somethign else, but this really isn't all that controversial.
Btw, clearly the GPLv2 requirements do say that the use may have to be
done certain ways. For example, if you actually embed keys in the binary
itself, that almost certainly means that they keys are part of the source,
and as such you need to make the keys available through other means and
rely on the "mere aggregation" clause.
The same thing goes for things like signed images. It you sign an
individual binary, it can be argued that the private key was part of the
build process. It's really a pretty weak argument, but the whole point is
made moot by the fact that you don't actually _need_ any keys: you can
just control the bootloader instead.
That one not a derived work, and is quite often even on a totally
different media: flash vs disk or similar. And once you have it do a
consistency check by just verifying the SHA1 of the aggregate media
separately, you don't actually have any keys to release, because there
simply _is_ no key that actually covers any GPLv2'd code.
You can try to take it to some (il)logical extreme, and ask yourself
whether just even holding a 128-bit hash is a "derived work"?
But I not only think you'd be laughed out of court on that one if you
claimed it was, I _really_ don't think you want to go there anyway.
Because if you think it is, then you're violating copyright law every time
you look up a CD in CDDB/fredb/whatever-it's-called-now, or any number of
other things. You don't want to try to strengthen copyrights to insane
levels (you'd also be getting rid of "fair use" if you do).
In other words, if you _really_ care about "freedom" (just about any kind)
you should be _damn_ careful not to try to extend those copyright claims
of "derived work" too far. Because quite frankly, YOU are going to lose on
that one, and the RIAA is going to laugh at your sorry ass for helping
them prove their nonexistent point, and you would end up losing a lot
more "freedoms" than the ones you thought you were fighting for.
So the point is, there's no reasonable disagreement what-so-ever that you
can use GPLv2 code for anything you damn well want, including secure
lock-down. I think the FSF has even said so in public. You have to release
_source_code_, but the GPLv2 never controlled the environment it was used
in.
Of course, a lot of people who have played games with these kinds of
issues also did other things very wrong. So a number of vendors that did
something fishy have gotten nailed for real copyright infringement due to
the _other_ things they did.
[ I'd also not be surprised if companies would decide to settle just to
avoid a lawsuit - especially one that made it clear that they were
sleazy even if they weren't perhaps actually doing anything actively
illegal. So there's a damn good reason why companies often don't want to
even toe _close_ to the line, and we should be happy about that. But we
shouldn't try to claim rules that simply never existed. ]
Linus
On Fri, 29 Sep 2006, Alan Cox wrote:
>
> thats the interpretation that has been accepted several times in out of
> court GPL violation settlements.
I think you can push that angle, and a lot of the time it will work in
practice - because the companies involved are really not "evil", and most
often they simply want to avoid any trouble.
At the same time, in many cases the settlements seem to be very much about
real issues, like not actually following the GPLv2 (giving no credit, not
mentioning the license, not making sources available). Rather than about
any imagined or real lock-down issues.
There's certainly a _correlation_ between "locking down" and "being sleazy
in general", but I don't think it's necessarily a causal relationship.
Linus
On Fri, 29 Sep 2006, Linus Torvalds wrote:
>
> I think you can push that angle, and a lot of the time it will work in
> practice - because the companies involved are really not "evil", and most
> often they simply want to avoid any trouble.
Btw, I'd also like to say that not only am I not a lawyer, I also think
that it's perfectly fine for people to disagree with me and decide to sue
somebody they really really dislike. I'm not giving legal advice, and am
just stating my own standpoint.
I think people (especially in the US) tend to be way too lawsuit-happy
anyway, but I'm in no way trying to discourage people who feel they want
to assert rights that I personally don't think _I_ have. People differ in
their opinions of the rights they hold. That's ok.
The way things _really_ get decided is not on the kernel mailing list, or
even by asking a lawyer, but by people who decided that some company or
other just simply crossed the line and did something illegal. My opinion
simply doesn't _matter_ in that sense.
For example, when I say that I think it would be totally insane to think
that a 128-bit hash of a binary is a "derived work", I say that as a
concerned citizen. I think a world where real lawyers would say that would
be a _horrible_ world. And I don't think it makes sense. But sadly, until
I'm elected(*) life-time President and King of the World, what I think
doesn't actually change anything.
Linus
(*) Hah. Who do I think I'm kidding? The revolution will be bloody and
brutal, and you're not going to get the choice to "elect" me except in the
history books written by yours truly.
From: "Helge Hafting" <[email protected]>
> Thomas Gleixner wrote:
>> On Mon, 2006-09-25 at 12:31 +0100, Alan Cox wrote:
>>
>>> The GPLv3 rewords it in an attempt to be clearer but also I think rather
>>> more over-reaching. It's not clear what for example happens with a
>>> rented device containing GPL software but with DRM on the hardware.
>>> Thats quite different to owned hardware. GPLv2 leaves it open for the
>>> courts to make a sensible decision per case, GPLv3 tries to define it in
>>> advance and its very very hard to define correctly.
>>>
>>
>> Also the prevention of running modified versions is not only caused by
>> economic interests and business models. There are also scenarios where
>> it is simply necessary:
>>
>> - The liability for damages, where the manufacturer of a device might
>> be responsible in case of damage when he abandoned the prevention. This
>> applies to medical devices as well as to lasers, machine tools and many
>> more. Device manufacturers can not necessarily escape such liabilities
>> as it might be considered grossly negligent to hand out the prevention
>> key, even if the user signed an exemption from liability.
>>
> This seems silly to me. Sure, lasers and medical equipment is
> dangerous if used wrong. When such equipment is
> controlled by software, then changing that software brings
> huge responsibility. But it shouldn't be made impossible.
>
> They can provide the key, with the warning that _using_ it
> means you are on your own and take all responsibility.
In some more rational parts of the world (presuming they exist
evidence to the contrary) this approach might work. This requires
a people and government that are rather libertarian with the people
taking full responsibility for their own actions. Now, I live in
the country that awarded a woman millions of dollars because she
was stupid enough to put a hot container of coffee in her lap as
she reached over to her purse to make change. Of course it spilled
and scorched her in a "nasty place to be scorched." This is also
the country that awarded two drunken idiots who decided to trim a
hedge with a rotary lawn mower. They tried to pick it up by the
skirts and lost their fingers to the spinning blades. They sued
the manufacturer for allowing them to be stupid - and won. So the
blunt answer is "Product Liability."
> I can take the covers off a cd player and let the laser
> shine into the room. Nothing prevents me from doing
> that, it isn't welded shut or anything. And it might
> be useful if I ever need a laser beam. Of course I am
> then responsible if I take someone's eye out. CD players
> have warning labels about this. And the same can be done
> for the keys to dangerous software.
Those warnings probably are not enough in a US court of law. But
they are enough to discourage most idiots who do get blinded by
their own stupidity from trying to sue.
>> - Regulations to prevent unauthorized access to radio frequencies, which
>> is what concerns e.g. cellphone manufacturers.
>>
> Unauthorized use is illegal and easy enough to track down.
> No special protection is needed. And it cannot be enforced
> by making the phones har to modify - any radio amateur knows
> how to build from scratch a transmitter to jam the GSM bands
> if he should be inclined to do so. Anyone can look this up in
> books too.
The bozo has to go through enough effort to build such a jammer
that it'd (mostly) insulate the parts manufactures from liability.
It's a little more work than pulling some CDROM screws and blinding
people in the room as a result. (Yeah, I darned well know how little
actual work is involved. But actual knowledge is also involved so it
would be hard for that jammer to escape personal responsibility. Of
course, there is the spark gap jammer.... Anecdotal evidence shows
that the spark gap noise can motivate the Los Angeles FCC office to
get off their lazy asses in a hurry, though.)
{^_-} Joanne
On Fri, 29 Sep 2006, Linus Torvalds wrote:
> (*) Hah. Who do I think I'm kidding? The revolution will be bloody and
> brutal, and you're not going to get the choice to "elect" me except in the
> history books written by yours truly.
Wow. You have been living in Portland too long. ]:>
--
"I will not buy this lutefisk, it is scratched."
On Fri, 29 Sep 2006, alan wrote:
>
> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>
> > (*) Hah. Who do I think I'm kidding? The revolution will be bloody and
> > brutal, and you're not going to get the choice to "elect" me except in the
> > history books written by yours truly.
>
> Wow. You have been living in Portland too long. ]:>
Is there some Portland subculture that I should be aware of?
Inquiring minds want to know.
Linus
On Fri, 29 Sep 2006, Linus Torvalds wrote:
>
>
> On Fri, 29 Sep 2006, alan wrote:
>>
>> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>>
>>> (*) Hah. Who do I think I'm kidding? The revolution will be bloody and
>>> brutal, and you're not going to get the choice to "elect" me except in the
>>> history books written by yours truly.
>>
>> Wow. You have been living in Portland too long. ]:>
>
> Is there some Portland subculture that I should be aware of?
>
> Inquiring minds want to know.
That would be telling.
Here are a few clues to the secret handshake that is Portland...
http://www.mondocroquet.com/
http://portland.cacophony.org/
http://www.orycon.org/orycon28/
http://communique.portland.or.us/02/12/santanarchy_now
And that is only the stuff I can mention in public. Portland has even
darker secrets.
--
"Oh, Joel Miller, you've just found the marble in the oatmeal. You're a
lucky, lucky, lucky little boy. 'Cause you know why? You get to drink
from... the FIRE HOOOOOSE!"
- The Stanley Spudoski guide to mailing list administration
On Fri, 29 Sep 2006, alan wrote:
> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>
>>
>>
>> On Fri, 29 Sep 2006, alan wrote:
>>>
>>> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>>>
>>>> (*) Hah. Who do I think I'm kidding? The revolution will be bloody and
>>>> brutal, and you're not going to get the choice to "elect" me except in
>>>> the
>>>> history books written by yours truly.
>>>
>>> Wow. You have been living in Portland too long. ]:>
>>
>> Is there some Portland subculture that I should be aware of?
>>
>> Inquiring minds want to know.
>
> That would be telling.
>
> Here are a few clues to the secret handshake that is Portland...
>
> http://www.mondocroquet.com/
> http://portland.cacophony.org/
> http://www.orycon.org/orycon28/
> http://communique.portland.or.us/02/12/santanarchy_now
Not to mention:
http://www.hplfilmfestival.com/
And worst of all:
http://www.stonehenge.com/merlyn/
--
"Oh, Joel Miller, you've just found the marble in the oatmeal. You're a
lucky, lucky, lucky little boy. 'Cause you know why? You get to drink
from... the FIRE HOOOOOSE!"
- The Stanley Spudoski guide to mailing list administration
On Fri, 29 Sep 2006, Linus Torvalds wrote:
>
>
> On Fri, 29 Sep 2006, alan wrote:
>>
>> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>>
>>> (*) Hah. Who do I think I'm kidding? The revolution will be bloody and
>>> brutal, and you're not going to get the choice to "elect" me except in the
>>> history books written by yours truly.
>>
>> Wow. You have been living in Portland too long. ]:>
>
> Is there some Portland subculture that I should be aware of?
>
> Inquiring minds want to know.
Some say the only subculture portland has is at:
http://www.omsi.edu/visit/submarine/wq
--
"Oh, Joel Miller, you've just found the marble in the oatmeal. You're a
lucky, lucky, lucky little boy. 'Cause you know why? You get to drink
from... the FIRE HOOOOOSE!"
- The Stanley Spudoski guide to mailing list administration
Ar Gwe, 2006-09-29 am 11:40 -0700, ysgrifennodd Linus Torvalds:
> For example, when I say that I think it would be totally insane to think
> that a 128-bit hash of a binary is a "derived work",
I would hope not, although thats the silly half of what some of the RIAA
versus bittorrent sites is alleging.
> be a _horrible_ world. And I don't think it makes sense. But sadly, until
> I'm elected(*) life-time President and King of the World, what I think
> doesn't actually change anything.
Emperor of the World is a self electing position, the post is open after
Emperor Norton passed on 8)
> And that is only the stuff I can mention in public. Portland has even darker secrets.
Thankfully, you didn't mention
http://www.portlandhumphash.org/php/index.php?title=Main_Page
so at least that dart secret is safe.
--
Christopher Smith
Pursuer of knowledge
One of the things which I'm fond of pointing out is that all of the
freedoms people would have to hack MacOS, especially MacOS 9, where
all of the various "Mac Extensions" which changed and extended the UI
of the Macintosh, would have completely disappeared if the FSF's idea
of "derived works" was in fact the law of the land. That's because
(a) Apple hated the fact that people dared to think that the UI has
handed down on the stone tablets inscribed by Steve Jobs could be
improved upon, and (b) the way those changes were made by patching
jump tables so that code to extend the UI could be patched into the OS
--- in effect, a dynamic link.
Now, because Apple hated the fact that people dared to think they
could improve on Apple's UI design, they frequently changed the jump
table interfaces, forcing the people who wrote the "Mac Hacks" to
follow a rapidly changing code stream --- much like what the Linux
kernel does with its device driver interfaces. But Apple has *never*
said that just because you dynamically link with MacOS, that instantly
makes your MacOS a derived work, and so therefore as the copyright
holder of MacOS, Apple could therefore have the right to control how,
or even whether or not the Macintosh Extensions could ever exist.
Thanks goodness, no sane court has ever ruled that the various
Macintosh Extensions were a derived work, just because they lived in
the same address space as MacOS and dynamically linked with MacOS, and
in fact were **designed** only to work with MacOS, and very often used
header files shipped by the Macintosh Programmer's Workbench.
So don't be too quick to wish that the courts will use the FSF's pet
definition of what derived works mean ---- you may find that in the
end, you end up losing far more freedoms than you expect.
- Ted
On Fri, 29 Sep 2006, Chris Smith wrote:
>> And that is only the stuff I can mention in public. Portland has even
>> darker secrets.
>
> Thankfully, you didn't mention
> http://www.portlandhumphash.org/php/index.php?title=Main_Page
> so at least that dart secret is safe.
I think that is a different GPL "position".
--
"Oh, Joel Miller, you've just found the marble in the oatmeal. You're a
lucky, lucky, lucky little boy. 'Cause you know why? You get to drink
from... the FIRE HOOOOOSE!"
- The Stanley Spudoski guide to mailing list administration
David,
> That really is totally against the spirit of the GPL and, frankly, I think
> it's the opposite of the attitude the free software community should be
> taking.
Not at all. Both tha free software communities and the open source
communities have been taking this attitude for a very long time.
When you release a patch to a LGPL program, what license do you choose
for the patch? You could legally choose the GPL. You could post your
GPL patch to the mailing list of the project and refuse to license it
under the LGPL. That would be legal, but very annoying.
Similarly for BSD licensed programs. When you patch those it is the
norm to contribute patches under a BSD license.
In both cases you are choosing the license the authors/maintainers of
the program chose, and that helps in reducing the impact of the
license proliferation we have at the moment. You are also doing the
morally right thing by playing by the rules of the community you are
participating in. You are acknowledging the "authors rights" to set
the ground rules for the community they are running.
I would defend the legal right of Linus or anyone else to do things
that the GPLv2 legally allows on my GPLv2 code. That doesn't mean I
have to like it, and it certainly doesn't mean I can't complain if I
thought what was being done was unreasonable.
So when I saw Linus advocating forking programs that are currently "v2
or later" and making them "v2 only", then I asked that he clarify to
ensure that the major contributors to the project be consulted before
doing that. Whether it is legal is beside the point - it is good
manners to follow the ground rules of the people who write the code.
Thankfully Linus has clarified that now in a later posting. I was
already pretty sure he always intended for the major contributors to
be consulted before a fork was done, but I'm glad its on the record so
people don't start forking madly while flying a "Linus said its OK"
banner :)
Cheers, Tridge
On Sat, 30 Sep 2006 07:46:25 +1000
[email protected] wrote:
> So when I saw Linus advocating forking programs that are currently "v2
> or later" and making them "v2 only", then I asked that he clarify to
> ensure that the major contributors to the project be consulted before
> doing that. Whether it is legal is beside the point - it is good
> manners to follow the ground rules of the people who write the code.
Did Linus say that? All I saw him say was if the FSF changes the
license to GPL v3 on code which they hold copyright, then people
should maintain a GPL v2 fork.
Sean
On Friday 29 September 2006 16:32, alan wrote:
>On Fri, 29 Sep 2006, alan wrote:
>> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>>> On Fri, 29 Sep 2006, alan wrote:
>>>> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>>>>> (*) Hah. Who do I think I'm kidding? The revolution will be bloody
>>>>> and brutal, and you're not going to get the choice to "elect" me
>>>>> except in the
>>>>> history books written by yours truly.
>>>>
>>>> Wow. You have been living in Portland too long. ]:>
>>>
>>> Is there some Portland subculture that I should be aware of?
>>>
>>> Inquiring minds want to know.
>>
>> That would be telling.
>>
>> Here are a few clues to the secret handshake that is Portland...
>>
>> http://www.mondocroquet.com/
>> http://portland.cacophony.org/
>> http://www.orycon.org/orycon28/
>> http://communique.portland.or.us/02/12/santanarchy_now
>
>Not to mention:
>http://www.hplfilmfestival.com/
>
>And worst of all:
>
>http://www.stonehenge.com/merlyn/
I take it that much of this indoor activity is caused by the relative lack
of sufficient umbrellas in Portland?
:-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Fri, 29 Sep 2006 19:12:15 -0400 Gene Heskett wrote:
> On Friday 29 September 2006 16:32, alan wrote:
> >On Fri, 29 Sep 2006, alan wrote:
> >> On Fri, 29 Sep 2006, Linus Torvalds wrote:
> >>> On Fri, 29 Sep 2006, alan wrote:
> >>>> On Fri, 29 Sep 2006, Linus Torvalds wrote:
> >>>>> (*) Hah. Who do I think I'm kidding? The revolution will be bloody
> >>>>> and brutal, and you're not going to get the choice to "elect" me
> >>>>> except in the
> >>>>> history books written by yours truly.
> >>>>
> >>>> Wow. You have been living in Portland too long. ]:>
> >>>
> >>> Is there some Portland subculture that I should be aware of?
> >>>
> >>> Inquiring minds want to know.
> >>
> >> That would be telling.
> >>
> >> Here are a few clues to the secret handshake that is Portland...
> >>
> >> http://www.mondocroquet.com/
> >> http://portland.cacophony.org/
> >> http://www.orycon.org/orycon28/
> >> http://communique.portland.or.us/02/12/santanarchy_now
> >
> >Not to mention:
> >http://www.hplfilmfestival.com/
> >
> >And worst of all:
> >
> >http://www.stonehenge.com/merlyn/
>
> I take it that much of this indoor activity is caused by the relative lack
> of sufficient umbrellas in Portland?
what's an umbrella?
---
~Randy
GPL v0: http://www.glacierparkinc.com/GlacierParkLodge.htm
On Friday 29 September 2006 19:25, Randy Dunlap wrote:
>On Fri, 29 Sep 2006 19:12:15 -0400 Gene Heskett wrote:
>> On Friday 29 September 2006 16:32, alan wrote:
>> >On Fri, 29 Sep 2006, alan wrote:
>> >> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>> >>> On Fri, 29 Sep 2006, alan wrote:
>> >>>> On Fri, 29 Sep 2006, Linus Torvalds wrote:
>> >>>>> (*) Hah. Who do I think I'm kidding? The revolution will be
>> >>>>> bloody and brutal, and you're not going to get the choice to
>> >>>>> "elect" me except in the
>> >>>>> history books written by yours truly.
>> >>>>
>> >>>> Wow. You have been living in Portland too long. ]:>
>> >>>
>> >>> Is there some Portland subculture that I should be aware of?
>> >>>
>> >>> Inquiring minds want to know.
>> >>
>> >> That would be telling.
>> >>
>> >> Here are a few clues to the secret handshake that is Portland...
>> >>
>> >> http://www.mondocroquet.com/
>> >> http://portland.cacophony.org/
>> >> http://www.orycon.org/orycon28/
>> >> http://communique.portland.or.us/02/12/santanarchy_now
>> >
>> >Not to mention:
>> >http://www.hplfilmfestival.com/
>> >
>> >And worst of all:
>> >
>> >http://www.stonehenge.com/merlyn/
>>
>> I take it that much of this indoor activity is caused by the relative
>> lack of sufficient umbrellas in Portland?
>
>what's an umbrella?
See what I mean folks? Underpriviledged is what Portlanders are. I mean
Shirley Seattle doesn't hog all the rain on the left coast.
However, to be fair, the one time I flew in and out of Portland, to see an
Aunt in Salem I knew I'd never see again if I didn't do it then, it didn't
outright rain either time. But Salem, an hour south, got about a foot in
that same 12 days. Last of June, the road to Crater Lake was opened the
day before we were there, and there was still around 15 feet of snow up
there in places.
>
>---
>~Randy
>GPL v0: http://www.glacierparkinc.com/GlacierParkLodge.htm
But does it have a wifi for your puter? :-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Friday 29 September 2006 16:53, Gene Heskett wrote:
> On Friday 29 September 2006 19:25, Randy Dunlap wrote:
> >On Fri, 29 Sep 2006 19:12:15 -0400 Gene Heskett wrote:
> >> On Friday 29 September 2006 16:32, alan wrote:
> >> >Not to mention:
> >> >http://www.hplfilmfestival.com/
> >> >
> >> >And worst of all:
> >> >
> >> >http://www.stonehenge.com/merlyn/
> >>
> >> I take it that much of this indoor activity is caused by the relative
> >> lack of sufficient umbrellas in Portland?
> >
> >what's an umbrella?
>
> See what I mean folks? Underpriviledged is what Portlanders are. I mean
> Shirley Seattle doesn't hog all the rain on the left coast.
No, not at all. It's simply that we Seattle-ites just whine about it the
loudest. It's nothing more than a ploy to scare away the tourists. :)
> However, to be fair, the one time I flew in and out of Portland, to see an
> Aunt in Salem I knew I'd never see again if I didn't do it then, it didn't
> outright rain either time. But Salem, an hour south, got about a foot in
> that same 12 days. Last of June, the road to Crater Lake was opened the
> day before we were there, and there was still around 15 feet of snow up
> there in places.
>
> >---
> >~Randy
> >GPL v0: http://www.glacierparkinc.com/GlacierParkLodge.htm
>
> But does it have a wifi for your puter? :-)
-- Vadim Lobanov
On Friday 29 September 2006 20:31, Vadim Lobanov wrote:
>On Friday 29 September 2006 16:53, Gene Heskett wrote:
>> On Friday 29 September 2006 19:25, Randy Dunlap wrote:
[...]
>> >what's an umbrella?
>>
>> See what I mean folks? Underpriviledged is what Portlanders are. I
>> mean Shirley Seattle doesn't hog all the rain on the left coast.
>
>No, not at all. It's simply that we Seattle-ites just whine about it the
>loudest. It's nothing more than a ploy to scare away the tourists. :)
You don't have to, the weather does that. The std joke question for anyone
from a Northern CA market tv station who goes to Seattle to interview for
a job at a larger market tv station is: Was it raining? And the answer
is always yes. I never saw it fail. :)
Reminds me of a fellow I worked with back in Iowa City, studying to be a
lawyer (about 50 years ago) who spent most of WWII in London. In two
years the sun came out for 3 days. He wears the scares from the sunburn
he got to this day if he hasn't passed, he was about 20 years older than
I, and I'm 72 next week.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Friday 29 September 2006 20:36, Gene Heskett wrote:
> On Friday 29 September 2006 20:31, Vadim Lobanov wrote:
> >On Friday 29 September 2006 16:53, Gene Heskett wrote:
> >> On Friday 29 September 2006 19:25, Randy Dunlap wrote:
>
> [...]
>
> >> >what's an umbrella?
> >>
> >> See what I mean folks? Underpriviledged is what Portlanders are. I
> >> mean Shirley Seattle doesn't hog all the rain on the left coast.
> >
> >No, not at all. It's simply that we Seattle-ites just whine about it the
> >loudest. It's nothing more than a ploy to scare away the tourists. :)
>
> You don't have to, the weather does that. The std joke question for anyone
> from a Northern CA market tv station who goes to Seattle to interview for
> a job at a larger market tv station is: Was it raining? And the answer
> is always yes. I never saw it fail. :)
Ah, our weather is honestly not all that bad. In fact, judging from the
various sources out there, Seattle actually gets less rainfall overall than
Portland. (ex. http://en.wikipedia.org/wiki/Seattle,_Washington#Climate) The
worst part is the 8-9 months of constantly-overcast and dreary weather in the
fall, winter, and spring; but, to balance that out, our summers are very,
very nice. And yes, we even get droughts every so often around here! :)
> Reminds me of a fellow I worked with back in Iowa City, studying to be a
> lawyer (about 50 years ago) who spent most of WWII in London. In two
> years the sun came out for 3 days. He wears the scares from the sunburn
> he got to this day if he hasn't passed, he was about 20 years older than
> I, and I'm 72 next week.
Yikes! No sun for that long? I couldn't do it. I'd probably go bonkers (or
even more so...).
-- Vadim Lobanov
On Fri, 29 Sep 2006 21:37:27 -0700 Vadim Lobanov wrote:
> > >No, not at all. It's simply that we Seattle-ites just whine about it the
> > >loudest. It's nothing more than a ploy to scare away the tourists. :)
> >
> > You don't have to, the weather does that. The std joke question for anyone
> > from a Northern CA market tv station who goes to Seattle to interview for
> > a job at a larger market tv station is: Was it raining? And the answer
> > is always yes. I never saw it fail. :)
>
> Ah, our weather is honestly not all that bad. In fact, judging from the
> various sources out there, Seattle actually gets less rainfall overall than
> Portland. (ex. http://en.wikipedia.org/wiki/Seattle,_Washington#Climate) The
> worst part is the 8-9 months of constantly-overcast and dreary weather in the
> fall, winter, and spring; but, to balance that out, our summers are very,
> very nice. And yes, we even get droughts every so often around here! :)
Hey, you aren't supposed to tell people about the great summer
weather out here...
---
~Randy
On Fri, 2006-09-29 at 18:53 +1000, [email protected] wrote:
> > > If the "entire patent portfolio" consists of a small group of patents
> > > which specifically deal with what the code has been posted by the
> > > company deals with, then sure.
> >
> > So we agree that the statement is true for a company that has only a
> > software patent portfolio.
>
> No, we don't :)
>
> The company can consist of only a patent portfolio, but additionally
> all of those patents (ie. the "entire patent portfolio") would need to
> be implemented by the program being distributed them.
But until you've done the due diligence, you have the potential to
compromise your entire portfolio, if it is all software patents. That's
what the phrase "...potentially jeopardise the entire patent portfolio
of a company simply by the act of placing a GPLv3 licensed programme on
their website" means. Just because their exist companies that have more
than just software patents doesn't affect the truth of the statement.
> That caveat is important, and changes it from a misleading statement
> to a true statement. It also is a statement which is true for the
> GPLv2, which makes it not such a useful statement to make when
> considering the relative merits of the two licenses.
Well, this is the whole point. Today, you can distribute GPLv2 packages
without much patent worry ... if you develop GPLv2 packages, that's
different, but if you simply act as a conduit, you're not going to have
too much trouble.. If I take the broad interpretation that I give a
licence to every patent practised by every package I distribute, then I
don't know what my liability might be until I've done an IP assessment
of everything that's distributed from the website. That means not just
what I'm working on, but also what support put up there to assist a
customer, and also what the engineers are putting up in their private
areas.
> I'd also like to note that I don't have much sympathy for companies
> that consist of only a patent portfolio. They are pretty much scum in
> my view. If they don't make any products at all and live on only
> patent revenue then the world would be better off without them :-)
Sure, we can differ in opinion, and argue over the value of software
patents, but that wasn't what was addressed in the paper.
Realistically, most companies have no choice but to play in the business
arena we have today, which includes patents. Even Red Hat has a
position statement acknowledging this.
James
On Fri, 2006-09-29 at 19:52 +1000, [email protected] wrote:
> > [email protected] wrote:
> > > I'd also like to note that I don't have much sympathy for companies
> > > that consist of only a patent portfolio. They are pretty much scum in
> > > my view. If they don't make any products at all and live on only
> > > patent revenue then the world would be better off without them :-)
> >
> > So, if you outsource your manufacturing, you are scum?
>
> I think its reasonable to include 'programming', 'developing' etc in
> 'make' :-)
>
> I'm just not a fan of companies who don't do anything except collect
> patent royalties on products that other people develop. I doubt there
> would be anyone in that category on this mailing list :)
You mean pure patent trolls (companies whose sole business model is
extracting royalties from other companies)? I think you're right, we
can all agree they're evil. However, since they don't distribute any
open source software, being purely setup to blackmail companies with
their patent portfolio, GPLv3 isn't going to help us at all in the fight
against them.
This is one of the things that really troubles me about GPLv3. I think
we can all agree that pure patent troll companies are evil and that DRM
as formulated by the media conglomerates to try to impose their will
(and legislate a business model) on the end user are evil. However,
attacking Tivo, or companies with large patent portfolios as a proxy for
getting at the real problem is also wrong.
James
On Fri, 2006-09-29 at 18:09 +1000, [email protected] wrote:
> > No, the point being made is that under v2, as long as the company was
> > only distributing, it didn't have to go over its patent portfolio
> > comparing it against the functions in the code on the website.
>
> umm, you've got it entirely backwards!
>
> In GPLv2 you _do_ have to check your entire patent portfolio. You also
> have to check the patent portfolio of all of the companies you
> cross-license patents from. It says this:
No, you don't; that's the estoppel principle. You only currently need
to scrutinise the pieces of open source your developers actually work
on.
> For example, if a patent license would not permit royalty-free
> redistribution of the Program by all those who receive copies
> directly or indirectly through you, then the only way you could
> satisfy both it and this License would be to refrain entirely from
> distribution of the Program.
>
> If your company is currently under the impression that distribution
> does not imply a patent license on the methods implemented in that
> code, then your lawyers are sailing very close to the wind. As you
> mention in the position statement, lawyers tend to take a broad
> interpretation when assessing their own companies liability, and it
> doesn't take a very broad interpretation of the GPLv2 to conclude that
> distribution implies a patent license.
This is the difference in how a lawyer thinks and how we think it might
be practically impossible to sue an open source project for infringement
(any open source project) because of the damage it would do to the
standing of the company, in theory, the option still exists from a legal
perspective.
> On the other hand, the current GPLv3 draft tries to ensure that the
> innocent don't get caught. It has the following:
>
> If you convey a covered work, knowingly relying on a
> non-sublicensable patent license that is not generally available to
> all, you must either (1) act to shield downstream users against the
> possible patent infringement claims from which your license protects
> you, or (2) ensure that anyone can copy the Corresponding Source of
> the covered work, free of charge and under the terms of this
> License, through a publicly available network server or other
> readily accessible means.
>
> The 'knowingly' part is very important, as is the 'or'. Compare this
> paragraph to the first draft of GPLv3. It has changed a lot. You know
> why it changed a lot? Because a whole lot of company lawyers saw that
> the draft 1 language was problematic. They gave feedback, and the FSF
> changed the draft to address their concerns.
Right ... it's trying to formulate the words to be the same as the
equitable estoppel principle in US law ... I just don't think it's quite
there yet.
> This is the bit I find so frustrating about this debate. The GPLv3
> current draft has had lots of input from precisely the people you say
> will be affected the most. There is a whole committee of lawyers from
> major corporations who are trying to ensure they will be happy with
> the result. The draft has improved as a result of this. The GPLv2 did
> not have that input, and as a result GPLv2 is more of a minefield
> regarding patents than the current GPLv3 draft.
And, in the discussion paper, the patents piece was phrased in terms of
the chilling effects on distributors. Remove the chilling effect (i.e.
come up with a form of words all our distributors are happy with) and
that particular complaint evaporates.
> There is still more work to do, and the GPLv3 draft is not final, but
> if you think "its all OK, patents are not covered by GPLv2, I'll stick
> to that" then you are badly mistaken.
>
> > > > HP is already on record as objecting to this as disproportionate.
> > >
> > > Could you point me at their statement? I suspect it didn't use the
> > > same words used in the position statement :-)
> >
> > Actually, HP had no input at all into the statement we made, so I would
> > be very surprised if the same words were used.
>
> I'd also be very surprised if HP lawyers made a statement like the one
> in the position statement :)
Please understand ... this discussion document was not made on behalf of
any lawyers or corporations. It's a distillation of the points made in
the debate we had coming to the vote. Each author represents themselves
only, not their company. A lawyer was consulted before it was released,
but only to ensure that the discussion document couldn't damage any
legal actions (real or potential) that might be taken over the current
GPLv2.
James
On Fri, 2006-09-29 at 13:08 +0100, Sanjoy Mahajan wrote:
> > However, once they comply with the distribution requirements,
> > they're free to do whatever they want with the resulting OS in their
> > printer ... including checking for only HP authorised ink
> > cartridges. You can take exception to this check and not buy the
> > resulting printer, but you can't tell them not to do the check
> > without telling them how they should be using the embedded platform.
>
> I don't see where the GPLv3 forbids such checks. Which section are
> you thinking of? In my understanding, it says only that HP must give
> users the keys to install modified software. From section 1 (of the
> July draft):
This was an illustration of the difference between use and distribution.
I don't claim GPLv3 limits these activities; I was just using the
example I was given.
> The Corresponding Source also includes any encryption or
> authorization keys necessary to install and/or execute modified
> versions from source code in the recommended or principal context of
> use, such that they can implement all the same functionality in the
> same range of circumstances.
>
> So the user, having the keys, can remove the cartridge check. HP
> might not like it and may choose not to distribute GPLv3 software with
> the printer, but that's a separate story.
Under GPLv3, yes. That's one of the fulcrums of the argument. As one
of the copyright holders, I don't want to get into the business of
dictating terms for uses to which linux (or other open source software)
is put. I fundamentally don't want to require in the copyright licence
that device manufacturers using embedded linux have to give me the key.
I'd love to persuade them why modifiable hardware is a good thing
(linksys WRT54GL) and give them market reasons for allowing it. But I
don't want to compel them. The pragmatic reason is that to impose
compulsion I have to forsee all the end uses (this is why we get
drafting issues with the GPLv3). However, the moral reason is that I
believe this type of compulsion to be wrong in principle: it acts as a
damper on innovation if everyone has to keep looking over their shoulder
and considering what my wishes might be in software they use.
Fundamentally, I want people to do things I never even dreamed of with
my software.
James
On Friday 29 September 2006 21:54, Randy Dunlap wrote:
> On Fri, 29 Sep 2006 21:37:27 -0700 Vadim Lobanov wrote:
> > > >No, not at all. It's simply that we Seattle-ites just whine about it
> > > > the loudest. It's nothing more than a ploy to scare away the
> > > > tourists. :)
> > >
> > > You don't have to, the weather does that. The std joke question for
> > > anyone from a Northern CA market tv station who goes to Seattle to
> > > interview for a job at a larger market tv station is: Was it raining?
> > > And the answer is always yes. I never saw it fail. :)
> >
> > Ah, our weather is honestly not all that bad. In fact, judging from the
> > various sources out there, Seattle actually gets less rainfall overall
> > than Portland. (ex.
> > http://en.wikipedia.org/wiki/Seattle,_Washington#Climate) The worst part
> > is the 8-9 months of constantly-overcast and dreary weather in the fall,
> > winter, and spring; but, to balance that out, our summers are very, very
> > nice. And yes, we even get droughts every so often around here! :)
>
> Hey, you aren't supposed to tell people about the great summer
> weather out here...
True, we shouldn't announce this particular little secret to the whole wide
world, but I think it's alright to tell the people on this list about it. ;)
After all, the only thing that could happen is that more kernel hackers
decide to move here... and getting more smart neighbors like them, as a
result, is never a bad thing!
So does this mean that you live in the Pacific Northwest in general, or
Seattle in particular? If so, I never knew. And speaking of, who else haunts
this little corner of the world? David Miller is moving here, unless my mind
is playing tricks on me; anybody else?
> ---
> ~Randy
-- Vadim Lobanov
James,
> Well, this is the whole point. Today, you can distribute GPLv2 packages
> without much patent worry ... if you develop GPLv2 packages, that's
> different, but if you simply act as a conduit, you're not going to have
> too much trouble.
I just can't see where you get this interpretation of the GPLv2
from. The wording in GPLv2 is:
If you cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations,
then as a consequence you may not distribute the Program at all.
For example, if a patent license would not permit royalty-free
redistribution of the Program by all those who receive copies
directly or indirectly through you, then the only way you could
satisfy both it and this License would be to refrain entirely from
distribution of the Program.
It specifically says "distribute" (4 times in fact). It specifically
says that all people, direct or indirect must be able to redistribute
royalty free, or you have to refrain from distributing.
It never mentions the word develop in the license text (only in the
"how to apply these terms to your program" section).
I just can't see how any lawyer, especially one trying to be cautious
about their companies potential liability, could try to claim that the
above paragraph doesn't apply to distribution.
Do you really have a solid legal opinion that the above paragraph from
GPLv2 doesn't apply when distributing? If so, could you ask the lawyer
to explain the argument? I know legal interpretations can sometimes be
tortuous, but to read the above without it applying to distribution
seems far too much of a stretch.
Cheers, Tridge
[email protected] wrote:
> So when I saw Linus advocating forking programs that are currently "v2
> or later" and making them "v2 only", then I asked that he clarify to
> ensure that the major contributors to the project be consulted before
> doing that. Whether it is legal is beside the point - it is good
> manners to follow the ground rules of the people who write the code.
>
> Thankfully Linus has clarified that now in a later posting. I was
> already pretty sure he always intended for the major contributors to
> be consulted before a fork was done, but I'm glad its on the record so
> people don't start forking madly while flying a "Linus said its OK"
> banner :)
It's good manners, but ultimately users vote with their feet.
If codebase A requires that modifications be given back (GPL v2), and
codebase A' additionally requires embedded device makers to permit users
to use modified code in all cases, which do you think device makers --
and ultimately users -- will choose?
For a lot of kernel devs who voted, I got the sense that the DRM clause
was the big stopping point. I actually think the patent clauses might
help things a bit, providing the "convey" language is cleared up. But
the DRM clause is far from technology-neutral, and doesn't take into
account useful DRM.
DRM is just a technology. It's not good or evil. It's a bit like
bittorrent: arguably, the majority of BT usage is for copyright
violations, but there are good uses for it too.
Further, the GPL v3 gets _too specific_ when it comes to talking about
technological remedies. It gets into the same trouble that politicians
get into, when they write technological remedies into law. Technology
changes too rapidly to get specific. Pretty soon you'll find that a
useful scenario was outlawed.
Jeff
On Sat, 2006-09-30 at 17:05 +1000, [email protected] wrote:
> I just can't see where you get this interpretation of the GPLv2
> from. The wording in GPLv2 is:
>
> If you cannot distribute so as to satisfy simultaneously your
> obligations under this License and any other pertinent obligations,
> then as a consequence you may not distribute the Program at all.
> For example, if a patent license would not permit royalty-free
> redistribution of the Program by all those who receive copies
> directly or indirectly through you, then the only way you could
> satisfy both it and this License would be to refrain entirely from
> distribution of the Program.
This means if you try to enforce royalties on a patent in a piece of
GPLv2 software, you and everyone else lose the right to distribute it.
However, to enforce or license royalty free is an existing choice. The
damage caused by making the programme undistributable is assessable
against the value of the patent.
v3 removes this choice by making the patent automatically licensed as
soon as you distribute, hence the choice is taken away.
James
Hello,
On Fri, Sep 29, 2006 at 05:48:17PM +1000, [email protected] wrote:
> wishes. I'm not even 100% certain it would be legal.
How can you not be sure that it would be legal? If you didn't want to
allow forking, you shouldn't have released the code as GPL. See qmail
and pine for example of slightly different licenses in terms of forking.
The basic logic of the GPL and open source as well, is that anyone is
legally allowed to fork away your code as much as they want as long as
the result is still using the same license. Oh well, if even this
_basic_ legal point is not clear, then I'm not surprised there's lots
of confusion about the rest...
IMHO GPL is _all_ about _freedom_ of usage in any shape and form, and
most important about _sharing_ of the resulting/modified code. GPL has
_never_ been about restricting usage. Infact it apparently even allows
you to do whatever you want with it as long as you do it behind the
corporate firewall and you don't redistribute the code itself, but
only the result of the computations of the code.
If there's something to work on for GPLv3 it is _not_ about
restricting usage. It's about forcing _more_ sharing even behind the
corporate firewall! In the ideal world that should be the only
priority in FSF minds and I think they're still in time to change
their focus on what really matters.
My ideal GPLv3 would be that if you modify a GPLv3 project and you
have a _third_party_ using in any way (think a web application running
behind the corporate firewall), you would be required to release your
GPLv3 source code to the third party that is using the GPLv3 code on
your servers, even if you never redistributed the code itself (nor in
source nor in binary form). Now I clearly don't know for sure if this
is enforceable, but I think this is the only point where the GPLv2
could be improved.
Nothing would change if the user of the code isn't a third party, so
for example you can still pick your preferred webmail for your
intranet, improve it, and release nothing back as long as it's never
used by third parties living outside the corporate firewall. But if
you start shipping the service to third parties as a webapplication
through the internet, my ideal GPLv3 would give the third parties the
right to see the modifications you did.
Creating a GPLv3 that restricts usage is not going to work. They think
the worst usage possible is DRM, I disagree, the DRM certainly
wouldn't be at the top of my priority of the worst possible usage of
my GPL code. Restricting usage is something where there cannot be a
real agreement on what should be forbidden, and as such it should be
avoided. If RMS has to choose which usage to forbid in GPLv3 he
apparently goes after DRM which sounds fair from his point of
view. Now if a greenpeace activist would have to choose he would
probably instead go after usage inside nuclear reactors which sounds
fair enough again from his point of view. I would go after different
things that sounds fair enough to me. If we keep focusing on
"forbidding what is unethical" eventually GPLv4 will forbid making too
much money off the software too ;). This is why there should be not be
any restriction on usage at all, so everyone can agree to giveup his
small wish for the common good. And if somebody really wants to add up
any exceptional restriction on usage on top of the GPL, that should be
up to the copyright holder to decide, not a job for the GPLv3 authors.
The worry that open source will eventually die with the advent of DRM
and trusted computing because no kernel will boot anymore, is
baseless. Who says something on those lines, probably doesn't
understand how the economy works (and most certainly they don't
understand how trusted computing works). To make an example if some
hardware vendor is not allowing to replace kernels, and I want to be
allowed to do that, I simply decided to buy my new htpc from
linuxtechtoys instead. It's truly as simple as that. And regardless,
even if they would be right about trusted computing going to kill open
source (again a baseless claim IMHO), it certainly wouldn't be the
GPLv3 DRM clause that could save us.
To make an example: I truly hope Microsoft will use trusted computing
to make the windows genuine update program totally unbreakable and to
force 100% of their users to pay. They can easily do that. There are
many more positive things around trusted computing that are never
being mentioned.
About the patent claims I also didn't see anything that would
invalidate the entire patent portfolio of any company (well, unless
the linux kernel already infringe on the whole patent portfolio of
said company, but I doubt that's what they meant ;). To me it looked
like v3 made explicit what was already implicit with v2 (i.e. when you
release patented software under GPLv2, you already implicitly allow
anybody to run your patented idea as long as the code is still under
the GPLv2). I didn't think there was any need to make it explicit, but
anyway I can't see a big difference.
On Sat, 30 Sep 2006, Andrea Arcangeli wrote:
>
> If there's something to work on for GPLv3 it is _not_ about
> restricting usage. It's about forcing _more_ sharing even behind the
> corporate firewall!
In many ways, I agree. The FSF seems to be barking up the wrong tree, the
real problem is not things like Tivo (who already _do_ give source back),
but the whole "we don't give source back because we're just exporting the
results", aka the "ASP problem".
> In the ideal world that should be the only
> priority in FSF minds and I think they're still in time to change
> their focus on what really matters.
While I agree with you, I think one of the reasons that the FSF hasn't
gone that way is that while in many cases it would make sense, it's
actually even more controversial. The "Tivo" issue is a populist issue,
and trying to solve the "ASP problem" is actually seriously more
problematic.
First off, the ASP issue, while not in any way limiting "use" (you could
still _use_ things as you see fit, you just have to give sources out: I
think that's much more "in the spirit" than the current GPLv3 ever is),
would actually require that in order to enforce it, such a license would
clearly have to be a _contract_. If it's not distributed, it's not a
matter of copyright any more, it's very obviously a matter of mutual
agreement: "we give you source, you give us source back".
Secondly, a lot of people use GPL code privately, with private
modifications, and you would see a lot more screaming than about the
current GPLv3 draft. So I think the FSF (correctly) decided that they
simply cannot do it.
In fact, it's one of the very traditional ways of making money for some
Free Software projects: the whole way Cygnus supported itself was largely
to make "private" branches of GCC for various commercial vendors, and
while the vendors had the _right_ to distribute the sources, they also had
the right not to (and since they didn't want to, they wouldn't be
distributed).
Does that sound against the spirit of "give back source"? Sure does. But
it's one of those things that the FSF has always supported, so they don't
see it as a huge problem, and since they don't want to limit _that_ kind
of usage, they automatically also cannot limit the ASP kind of usage which
really is exactly the same thing.
So I actually think that an ASP clause would be totally unacceptable to a
lot of people, even more so than the stupid anti-Tivo clauses. And I think
the FSF realized that, and didn't even push it, even though they have been
talking about the "ASP hole" when they don't like it.
So it really does boil down to a very simple end result (which is the
exact same deal that I think the whole anti-DRM problem has been about):
- Not everybody agrees about the current GPLv2
- But trying to extend the reach of it just causes more (fundamental)
problems than the problems such extensions would try to fix.
So I'd like to repeat: the reason the GPLv2 is wonderful is exactly the
fact that it's so widely applicable, and useful for such a wide audience.
That _does_ mean that it will inevitably have to accept a certain level of
bad behaviour by selfish people, but since you can't distribute the
derived work without distributing the source code, you're guaranteed that
the bad behaviour cannot "procreate".
In other words: if you think of open source development as a kind of
"sexual reproduction" (it really does have a lot of analogies - it's a
"memetic recombination and survival of the fittest"), any "bad use" by
definition is a dead end. You can be bad, but a bad use is always a
eunuch, and as such doesn't matter in the long run. The only way you can
actually make a _difference_ is by participating constructively.
In other words: I do agree that the "ASP hole" is a hole, but exactly as
with all the Tivo issues, it's a hole that needs to be there simply
because trying to plug it would cause disaster.
Linus
On Fri, 2006-09-29 at 12:15 +0200, Helge Hafting wrote:
> > - The liability for damages, where the manufacturer of a device might
> > be responsible in case of damage when he abandoned the prevention. This
> > applies to medical devices as well as to lasers, machine tools and many
> > more. Device manufacturers can not necessarily escape such liabilities
> > as it might be considered grossly negligent to hand out the prevention
> > key, even if the user signed an exemption from liability.
> >
> This seems silly to me. Sure, lasers and medical equipment is
> dangerous if used wrong. When such equipment is
> controlled by software, then changing that software brings
> huge responsibility. But it shouldn't be made impossible.
>
> They can provide the key, with the warning that _using_ it
> means you are on your own and take all responsibility.
This might be silly in your opinion, but it is simply the reality,
especially in the US, but also in Europe we have an increasing madness
in liability jurisdiction. Do you believe that any responsible corporate
lawyer will buy your "with a warning" argument when he is aware of
rulings stating the opposite ?
I talked to very reasonable corporate lawyers about this and they
provided enough prove, that I take this serious.
Your argument is logical and should reflect common sense, but reality is
different. If we could rely on common sense, we would not have this
discussion at all.
tglx
Ar Sad, 2006-09-30 am 20:38 +0200, ysgrifennodd Thomas Gleixner:
> This might be silly in your opinion, but it is simply the reality,
> especially in the US, but also in Europe we have an increasing madness
> in liability jurisdiction. Do you believe that any responsible corporate
> lawyer will buy your "with a warning" argument when he is aware of
> rulings stating the opposite ?
Well the corporate laywer can also havea warning that he may get sued if
he doesn't release the needed keys. There now he can and use openbsd and
everyone is happy.
On Sat, 2006-09-30 at 21:49 +0100, Alan Cox wrote:
> Ar Sad, 2006-09-30 am 20:38 +0200, ysgrifennodd Thomas Gleixner:
> > This might be silly in your opinion, but it is simply the reality,
> > especially in the US, but also in Europe we have an increasing madness
> > in liability jurisdiction. Do you believe that any responsible corporate
> > lawyer will buy your "with a warning" argument when he is aware of
> > rulings stating the opposite ?
>
> Well the corporate laywer can also havea warning that he may get sued if
> he doesn't release the needed keys. There now he can and use openbsd and
> everyone is happy.
Really?
tglx
On Fri, 29 Sep 2006, James Bottomley wrote:
>> That caveat is important, and changes it from a misleading statement
>> to a true statement. It also is a statement which is true for the
>> GPLv2, which makes it not such a useful statement to make when
>> considering the relative merits of the two licenses.
>
> Well, this is the whole point. Today, you can distribute GPLv2 packages
> without much patent worry ... if you develop GPLv2 packages, that's
> different, but if you simply act as a conduit, you're not going to have
> too much trouble.. If I take the broad interpretation that I give a
> licence to every patent practised by every package I distribute, then I
> don't know what my liability might be until I've done an IP assessment
> of everything that's distributed from the website. That means not just
> what I'm working on, but also what support put up there to assist a
> customer, and also what the engineers are putting up in their private
> areas.
this is especially relavent for companies that have formerly been willing to act
as mirrors for free software projects. now the act of mirroring debian means
that any patent they own could be comprimised by a random debian developer
adding a patch to any of 19000 packages that implements that patent
David Lang
Andrea,
> On Fri, Sep 29, 2006 at 05:48:17PM +1000, [email protected] wrote:
> > wishes. I'm not even 100% certain it would be legal.
>
> How can you not be sure that it would be legal?
I am nearly sure it would be legal, but in some private discussions
I've had I have heard some arguments about why it may not be legal. It
may even depend on jurisdiction.
So I'll be surprised if it turns out not to be legal, but it is
something that is definately worth checking on.
Cheers, Tridge
David Lang wrote:
> On Fri, 29 Sep 2006, James Bottomley wrote:
>
>>> That caveat is important, and changes it from a misleading statement
>>> to a true statement. It also is a statement which is true for the
>>> GPLv2, which makes it not such a useful statement to make when
>>> considering the relative merits of the two licenses.
>>
>> Well, this is the whole point. Today, you can distribute GPLv2 packages
>> without much patent worry ... if you develop GPLv2 packages, that's
>> different, but if you simply act as a conduit, you're not going to have
>> too much trouble.. If I take the broad interpretation that I give a
>> licence to every patent practised by every package I distribute, then I
>> don't know what my liability might be until I've done an IP assessment
>> of everything that's distributed from the website. That means not just
>> what I'm working on, but also what support put up there to assist a
>> customer, and also what the engineers are putting up in their private
>> areas.
>
> this is especially relavent for companies that have formerly been
> willing to act as mirrors for free software projects. now the act of
> mirroring debian means that any patent they own could be comprimised
> by a random debian developer adding a patch to any of 19000 packages
> that implements that patent
Conversely, is it possible that the 'random debian developer' could be
sued for patent infringement if he isn't protected by the GPL?
Besides, software patents are evil, period.
Regards, Michiel de Boer
James,
> > from. The wording in GPLv2 is:
> >
> > If you cannot distribute so as to satisfy simultaneously your
> > obligations under this License and any other pertinent obligations,
> > then as a consequence you may not distribute the Program at all.
> > For example, if a patent license would not permit royalty-free
> > redistribution of the Program by all those who receive copies
> > directly or indirectly through you, then the only way you could
> > satisfy both it and this License would be to refrain entirely from
> > distribution of the Program.
>
> This means if you try to enforce royalties on a patent in a piece of
> GPLv2 software, you and everyone else lose the right to distribute it.
> However, to enforce or license royalty free is an existing choice. The
> damage caused by making the programme undistributable is assessable
> against the value of the patent.
I think you would have a hard time convincing a judge that "permit
royalty-free redistribution by all those who receive copies directly
or indirectly through you" applies only to "right now", and you can
reserve the right to start charging royalties or other enforcements at
a later date.
It doesn't say "right now" or "temporarily". It also talks about
people who receive it indirectly through you, and doesn't qualify that
with "as long as they check back with you that you still think its
OK".
If a company decided down the track to 'monetise' one of their
patents, and begun by stopping distribution of the GPLv2 program, then
I suspect that the copyright holders of that program could take action
against them for having been in breach of the license for the period
of distribution. What the penalty for that might be is hard to tell
(it might depend on the jurisdiction and whether the copyright is
registered with the LOC in places like the US). I could certainly
imagine circumstances where the penalty is quite substantial.
Cheers, Tridge
David,
> this is especially relavent for companies that have formerly been willing to act
> as mirrors for free software projects. now the act of mirroring debian means
> that any patent they own could be comprimised by a random debian developer
> adding a patch to any of 19000 packages that implements that patent
I'd be interested to hear what the debian legal people think of this,
but my reading of the GPLv2 is that mirror sites are already
effectively granting a patent license by distributing GPLv2 programs.
Maybe this has already been discussed to death somewhere else and some
solid legal conclusion has been come to? If so, can someone please
send me a link :)
Cheers, Tridge
On Sun, 2006-10-01 at 16:28 +1000, [email protected] wrote:
> > > from. The wording in GPLv2 is:
> > >
> > > If you cannot distribute so as to satisfy simultaneously your
> > > obligations under this License and any other pertinent obligations,
> > > then as a consequence you may not distribute the Program at all.
> > > For example, if a patent license would not permit royalty-free
> > > redistribution of the Program by all those who receive copies
> > > directly or indirectly through you, then the only way you could
> > > satisfy both it and this License would be to refrain entirely from
> > > distribution of the Program.
> >
> > This means if you try to enforce royalties on a patent in a piece of
> > GPLv2 software, you and everyone else lose the right to distribute it.
> > However, to enforce or license royalty free is an existing choice. The
> > damage caused by making the programme undistributable is assessable
> > against the value of the patent.
>
> I think you would have a hard time convincing a judge that "permit
> royalty-free redistribution by all those who receive copies directly
> or indirectly through you" applies only to "right now", and you can
> reserve the right to start charging royalties or other enforcements at
> a later date.
Erm ... I think you'll find there's already case law precedent on that:
the SCO case. The question there was could SCO sue IBM for copyright
infringement after having distributed the kernel from their website.
The answer, from the judge in the case, was yes.
James
On Sun, 01 Oct 2006 10:45:50 CDT, James Bottomley said:
> Erm ... I think you'll find there's already case law precedent on that:
> the SCO case. The question there was could SCO sue IBM for copyright
> infringement after having distributed the kernel from their website.
> The answer, from the judge in the case, was yes.
(IANAL, just an interested amature bystander - if my explanation actually
matters to anybody, they should hire competent legal representation instead)
Note that the precedent set there was "Yes, you can *file suit* about it",
handed down by a judge that is being *very* careful to not leave *any*
possible reason for SCO to have grounds for an appeal (and "judge improperly
denied our cause of action" would likely qualify for an appeal).
(For those readers outside the US - due to quirks in the US legal system,
it *is* permissible to bankrupt yourself by filing pointless lawsuits that
have no chance of winning. The truly dangerous part is that the people you
sue often countersue, and include "and attourney's fees" in the list of
damages they claim. So if you sue somebody and it costs them $150K to
defend themselves against a pointless lawsuit, you can end up owing them
$150K....)
IBM recently filed a motion for summary judgement on one of their
counterclaims, which basically said "SCO isn't permitted to ask for it after
distributing it themselves". Once that counterclaim is resolved, *then* we
will have a better precedent to cite (most likely changing "You can file suit
about it" into "You can file suit, but SCO v. IBM already said you can go stick
it in a pig, unless your lawyer can show how this case is *different* from SCO
v. IBM"). And that's the way the legal system works in the US - both sides
cite all the precedents they think support *their* view of the case, the
judge listens to all of them, and decides one of the following:
1) The case is basically the same as a precedent cited by one side or the other,
and therefor the ruling should be decided the same way.
2) The judge buys one side's claim that this is a *new* situation, and writes
a precedent-setting ruling for the situation.
3) Rarely, except in appelate courts, the judge will decide a prededent's
situation applies, but that the previous judge got the ruling wrong, and
will overrule the prededent. Most often, this happens when a lawyer cites
a precedent from a different "District" (the US is divided into a dozen or
so Districts, each of which has a semi-autonomous set of courts). Occasionally,
the Supreme Court will take a case of the form "The Third District precedent
is this, and the Ninth Distric is that, and we need to know which one is
the Law of the Land".
And yes, every once in a while, a lawyer will even base a case on claiming
that a Supreme Court ruling is an incorrect precedent, usually by arguing
that the precedent was written in 1873, and that society has changed so much
that the ruling doesn't apply correctly anymore, or similar.
Linus Torvalds wrote:
> On Fri, 29 Sep 2006, Helge Hafting wrote:
>
>>
>> This seems silly to me. Sure, lasers and medical equipment is
>> dangerous if used wrong. When such equipment is
>> controlled by software, then changing that software brings
>> huge responsibility. But it shouldn't be made impossible.
>>
>
> It may be "silly", but hey, it's often a law.
>
The manufacturer is liable for damages if the product is
dangerous as-is. If you modify the product in ways the documentation
says you shouldn't, then it isn't their product anymore. It
is _your_ product then, and now you are the one responsible
for damages.
A law against software modification just move the discussion
to "for or against" that law.
> Also, even if it wasn't about laws, there is a very valid argument that
> you should be able to be silly. There's a reason people don't get locked
> up in prisons just for being silly or crazy - sometimes something that
> seems silly may turn out to be a great idea.
>
> And people seem to totally ignore that there is no correct answer to "who
> may do software updates?". People rant and rave about companies that stop
> _you_ from making software updates, but then they ignore the fact that
> this also stops truly bad people from doing it behind your back.
>
And how would truly bad people modify any of my software?
My car engine may explode if programmed with sufficiently
stupid ignition timing and/or turbo mismanagement.
Nothing prevent upgrades though, there are companies
selling "chip upgrades" and so on. Now, this isn't open source, but
the information isn't that hard to get either. Still, we don't see
abuses. Just chip upgrades, that often voids the warranty.
The car is secured by a lock - to which I have a key. That's all
the security I need. My home devices mostly require precence
to be reprogrammed, so no bad guys without my house keys.
The PC is an exception of course.
> Quite frankly, in many situations, I'd sure as hell be sure that any
> random person with physical access to a machine (even if it was mine, and
> even if I'm _one_ of them) could not just upgrade a piece of software.
>
I want to be silly and reprogram something. I should be able
to be silly, but not be able to do this reprogramming?
> Sometimes you can make those protections yourself (ie you add passwords,
> and lock down the hardware - think of any University student computer
> center or a library or something), but what a lot of people seem to
> totally ignore is that often it's a hell of a lot more convenient for
> _everybody_ if the vendor just does it.
>
Vendor upgrades are convenient, sure. That is not a reason for
limiting us to vendor upgrades _only._
> And no, the answer is not "just give the password to people who buy the
> hardware". That requires individualized passwords, probably on a
> per-machine basis. That's often simply not _practical_, or is just much
>
A jumper needed for reprogramming limits reprogramming to
someone who is physically present - i.e. the owner. Problem
solved without passwords.
> more expensive. It's quite natural for a vendor in this kind of situation
> to just have one very secret private key per model or something like that.
>
History have showed, again and again, that such a "very secret"
key will be broken, and that only have to be done once. Therefore,
people run linux on gaming boxes that was supposed to be locked
down. And we can watch DVDs on linux too.
> In other words, these secret keys that people rant against JUST MAKE
> SENSE. Trying to outlaw the technology is idiotic, and shortsighted.
>
Yes "very secret" keys makes sense. They are so useful, because
someone nice will disassemble an upgrade and then publish the
key. Then the hobbyists can do what they want, while the
companies flasely believes they get what they want too. :-)
Still, it'd be better if they didn't bother. Just add a sticker with
"reprogramming voids the warranty and might kill you." and
be done with it.
> If you don't want a machine that is locked down, just don't buy it. It's
> that simple. But don't try to take the right away from others to buy that
> kind of convenience.
>
Seems to me that this "convenience" is only for monopolists trying
to limit the usefulness of the device? Sure, I can refrain from buying
some device, except that they don't usually document this kind
of limitation until you suddenly runs into it.
And of course this works the other way too.
People may write software that explicitly forbids locking down. If
device manufacturers don't like that, they are free to not use the code. And
it is sometimes fun when they don't discover this until they have
shipped the devices and gets forced to supply a key. ;-)
> And yes, Tivo is exactly such a situation. It's damn convenient. I've got
> two Tivo's myself (and yes - I actually paid full price for them. I was
> given one of the original ones, but that's long since scrapped, and even
> that one I paid the subscription fee myself). But you don't have to buy
> them. You can build your own at any time, and it will probably be more
> powerful.
>
> So people are trying to claim that something is "wrong", even though it
> clearly is. The people arguing for "freedom" are totally ignoring my
> freedom to buy stuff that is convenient, and ignore real concerns where
> things like TPM etc actually can make a lot of sense.
>
> Can it be used for bad things? Sure. Knives are dangerous too, but that
> doesn't make them "wrong" or something you shouldn't allow.
>
What is the convenience of a locked-down device? I agree it is nice
if the manufacturer can upgrade it - a convenience for any device
I won't bother with myself. But why should that prevent _me_ from
reprogramming my device in a different way? I see no need for
that at all. You can have one _and_ the other.
Helge Hafting
Just a thought. Suppose we forked the GPL2 license and created the Linux
license? (Or some better name) It's kind of clear the Stallman has his
own ajenda and that it's not compatible with the Linux model. So - lets
fork it an start a new one.
The idea of the new license is as follows. It would be backwards
compatible with GPL2. It's would eliminate the "or later" clause because
we have already seen the potential for abuse there. How can one agree to
future licenses without knowing what they are going to be? The other
feature is that the license is only modified to provide legal
clarification or to deal with future issues that occur as a result of
new technology or circumstances that we don't know about yet. If the
licenses is modified then copyright holders would then have to
explicitly declare that they accept the modifications by switching to
the new terms.
Anyhow - I'm thinking that Richard Stallman might be more of a liability
to the GPL movement and that if something can't be worked out with GPLx
then maybe it's time to just fork the license and come up with a new
system that is crazy leader proof.
Just suggesting this as an alternative if the FSF folks insist on a
political ajenda.
On 02/10/06, Marc Perkel <[email protected]> wrote:
> Just a thought. Suppose we forked the GPL2 license and created the Linux
> license? (Or some better name) It's kind of clear the Stallman has his
> own ajenda and that it's not compatible with the Linux model. So - lets
> fork it an start a new one.
>
Why? We can just stay with the GPLv2 forever.
> The idea of the new license is as follows. It would be backwards
> compatible with GPL2. It's would eliminate the "or later" clause because
> we have already seen the potential for abuse there.
The "or later" clause is not part of the actual license. It's part of
the preamble.
> How can one agree to
> future licenses without knowing what they are going to be? The other
> feature is that the license is only modified to provide legal
> clarification or to deal with future issues that occur as a result of
> new technology or circumstances that we don't know about yet. If the
> licenses is modified then copyright holders would then have to
> explicitly declare that they accept the modifications by switching to
> the new terms.
>
As things are now we'd already need acceptance from all major
copyright holders to switch license away from GPLv2...
> Anyhow - I'm thinking that Richard Stallman might be more of a liability
> to the GPL movement and that if something can't be worked out with GPLx
> then maybe it's time to just fork the license and come up with a new
> system that is crazy leader proof.
>
> Just suggesting this as an alternative if the FSF folks insist on a
> political ajenda.
>
I don't see the point. RMS can create GPLv3 any way he wants, the
Linux kernel will still be under GPLv2 terms... GPLv3 really doesn't
change anything for the kernel. It would only change something if we
switched the kernel to GPLv3, but doing that would probably be next to
impossible anyway since all copyright holders would need to agree on
the switch and; a) some copyright holders have already publicly stated
that they will not agree to GPLv3 terms, and b) some of the copyright
holders are dead.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
My thoughts on this was to make the new license backwards compatible
with GPL2 so that there wouldn't be a change. The main feature of a new
name is to lose RMS control. From what I can see the FSF is an cult that
worships RMS who has become a little full of himself and has abandoned
logic and scientific process. He has no concept of IP at all and wants
to put GNU in front of everything as if he had personally invented all
software. He's more like a cat spraying everything to mark it with his
scent than someone who is contributing in a meaningful way.
It's late - and I'm on a rant. I suppose it's a metaphor for a divorce
from RMS. Just getting tired of his bullshit.
On Monday 02 October 2006 04:55, Marc Perkel wrote:
> Just a thought. Suppose we forked the GPL2 license and created the Linux
> license? (Or some better name) It's kind of clear the Stallman has his
> own ajenda and that it's not compatible with the Linux model. So - lets
> fork it an start a new one.
>
> The idea of the new license is as follows. It would be backwards
> compatible with GPL2. It's would eliminate the "or later" clause because
> we have already seen the potential for abuse there. How can one agree to
> future licenses without knowing what they are going to be? The other
> feature is that the license is only modified to provide legal
> clarification or to deal with future issues that occur as a result of
> new technology or circumstances that we don't know about yet. If the
> licenses is modified then copyright holders would then have to
> explicitly declare that they accept the modifications by switching to
> the new terms.
I'd be behind such a license if it was 100% functionally equivalent to the GPL
(ie, a reword just to get around the FSF Copyright of the GPL). I'd even
license my own code under it.
Linus, you want to chime in here?
--
Patrick McFarland || http://AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
On Mon, 2006-10-02 at 01:55 -0700, Marc Perkel wrote:
> Just a thought. Suppose we forked the GPL2 license and created the Linux
> license? (Or some better name) It's kind of clear the Stallman has his
> own ajenda and that it's not compatible with the Linux model. So - lets
> fork it an start a new one.
>
> The idea of the new license is as follows. It would be backwards
> compatible with GPL2. It's would eliminate the "or later" clause because
> we have already seen the potential for abuse there.
Common misconception. As countless times before stated, there is no "or
later" clause in the licence itself.
--
Cioby
On 10/2/06, Patrick McFarland <[email protected]> wrote:
> On Monday 02 October 2006 04:55, Marc Perkel wrote:
> > Just a thought. Suppose we forked the GPL2 license and created the Linux
> > license? (Or some better name) It's kind of clear the Stallman has his
> > own ajenda and that it's not compatible with the Linux model. So - lets
> > fork it an start a new one.
> >
> > The idea of the new license is as follows. It would be backwards
> > compatible with GPL2. It's would eliminate the "or later" clause because
> > we have already seen the potential for abuse there. How can one agree to
> > future licenses without knowing what they are going to be? The other
> > feature is that the license is only modified to provide legal
> > clarification or to deal with future issues that occur as a result of
> > new technology or circumstances that we don't know about yet. If the
> > licenses is modified then copyright holders would then have to
> > explicitly declare that they accept the modifications by switching to
> > the new terms.
>
> I'd be behind such a license if it was 100% functionally equivalent to the GPL
> (ie, a reword just to get around the FSF Copyright of the GPL). I'd even
> license my own code under it.
>
it doesn't matter, how compatible it is, there is still the problem
that all past code submitters would have to agree to it. Since they
submitted their code to be gpl v2.
James Dickens
uadmin.blogspot.com
> Linus, you want to chime in here?
>
> --
> Patrick McFarland || http://AdTerrasPerAspera.com
> "Computer games don't affect kids; I mean if Pac-Man affected us as kids,
> we'd all be running around in darkened rooms, munching magic pills and
> listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
> Inc, 1989
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>> The idea of the new license is as follows. It would be backwards
>> compatible with GPL2. It's would eliminate the "or later" clause because
>> we have already seen the potential for abuse there.
>
> The "or later" clause is not part of the actual license. It's part of
> the preamble.
It's mentioned in the preamble, but it is actually a part of the license
tag you put in your code. </nitpick>
Jan Engelhardt
--
Jan Engelhardt wrote:
>
> It's mentioned in the preamble, but it is actually a part of the license
> tag you put in your code. </nitpick>
>
>
> Jan Engelhardt
>
Yep - and if it's in there it creates confusion. Anyhow - I just threw
the idea out there because even though the GPL2 has served the community
well there comes a point where if RMS has evolved into more f a
hinderence than a help to the cause and if he is going to dig in and be
unreasonable then the idea of forking the license becomes more
thinkable. I would feel more comfortable if say Larry Lessig of Creative
Commons in combination with perhaps with EFF we in charge of license
development. These are more trusted organization with serious legal
minds who can write a license that actually protects our interests in a
way that will hold up in courts.
So far the GPL2 is doing fine but it occasionally needs a little tweak
to make it more accurate. One of those tweaks is that the preamble lose
the "or later" clause.
Maybe RMS will get the message and realize that the Linux voice must be
heard and he will return to some kind of sanity on this. I don't think
it's time yet to fork the GPL but I think it's time to talk about the
possibility if GPL3 doesn't change. I think that GPL3 is so
substantially different than GPL2 that it should not have the same name.
So if GPL3 doesn't change then I vote fork.
If you want to kill linux then fork it.And remember that many people use
GNU/Linux because of the ideology and the idea of freedom, not because
of the "Security" that DRM will provide them... This guy Linus is just
an ambitious and selfish bastard...
On Tue, 3 Oct 2006, Ivan Dimitrov wrote:
> If you want to kill linux then fork it.And remember that many people use
> GNU/Linux because of the ideology and the idea of freedom [snip]
Ivan makes a good point here. I understand that pragmatism is king in this
community but it would be a mistake to forget that there are lots of happy
users out there that care about the idealism too. And it would be a
mistake to offend those users just to make good on your personal vendetta
against Richard Stallman.
Thanks,
Chase
Ivan Dimitrov wrote:
> If you want to kill linux then fork it.And remember that many people use
> GNU/Linux because of the ideology and the idea of freedom, not because
> of the "Security" that DRM will provide them... This guy Linus is just
> an ambitious and selfish bastard...
>
Ivan - It's not GNU/Linux - it's just LINUX. Time to get the name right.
RMS doesn't get to rename Linux. Linux isn't going to go away just
because they fork the license.
On Tuesday October 3, [email protected] wrote:
> Ivan Dimitrov wrote:
> > If you want to kill linux then fork it.And remember that many people use
> > GNU/Linux because of the ideology and the idea of freedom, not because
> > of the "Security" that DRM will provide them... This guy Linus is just
> > an ambitious and selfish bastard...
> >
>
> Ivan - It's not GNU/Linux - it's just LINUX. Time to get the name right.
> RMS doesn't get to rename Linux. Linux isn't going to go away just
> because they fork the license.
"Linux" is an operating system kernel. By itself it is pretty
useless.
A thing which is Linux plus lots of libraries and utilities and maybe
a windowing system and a "desktop" is a lot more than "Linux".
It might be Redhat Linux, it might be SuSE Linux. It might be
GNU/Linux. It might be Debian GNU/Linux. It might be KLX (referring
to KDE, Linux and The X11 Windowing System I think). It might be
Ubuntu. But isn't just "Linux".
It was never my understanding that RMS tried to rename the Linux
Kernel as GNU/Linux. Rather he wanted to name the complete system
comprising Linux and some GNU software and X and anything else that
was free as "GNU/Linux". I suspect he has more right than many to
suggest a name for the system seeing how much philosophy and
technology he has contributed.
NeilBrown
On 03/10/06, Marc Perkel <[email protected]> wrote:
< ... >
> Ivan - It's not GNU/Linux - it's just LINUX. Time to get the name right.
> RMS doesn't get to rename Linux. Linux isn't going to go away just
> because they fork the license.
>
o_O
Well this *is* the Linux kernel mailing list...so yes, the kernel is
called Linux.
RMS wants to take credit for the parts of your complete operating
system breakfast (including GCC et al.) that were developed by the GNU
project. Whether this is wholly unreasonable or not is an exercise for
the reader.
Adam Henley wrote:
> On 03/10/06, Marc Perkel <[email protected]> wrote:
> < ... >
>> Ivan - It's not GNU/Linux - it's just LINUX. Time to get the name right.
>> RMS doesn't get to rename Linux. Linux isn't going to go away just
>> because they fork the license.
>>
>
> o_O
>
> Well this *is* the Linux kernel mailing list...so yes, the kernel is
> called Linux.
>
> RMS wants to take credit for the parts of your complete operating
> system breakfast (including GCC et al.) that were developed by the GNU
> project. Whether this is wholly unreasonable or not is an exercise for
> the reader.
Most of the GNU utilities were just clones of the work the AT&T did when
the C language and the Unix operating system was invented. To clone an
existing product is trivial as compared to coming up with the original
ideas in the first place. RMS didn't invent C, he cloned it. If anything
it should be called AT&T/Linux if you want to give credit to the
innovators. RMS is just a middleman in the process.
El Martes, 3 de Octubre de 2006 4:47 PM, Marc Perkel
escribi?:
> Adam Henley wrote:
> > On 03/10/06, Marc Perkel <[email protected]> wrote:
> > < ... >
> >
> >> Ivan - It's not GNU/Linux - it's just LINUX. Time to
> >> get the name right. RMS doesn't get to rename Linux.
> >> Linux isn't going to go away just because they fork
> >> the license.
> >
> > o_O
> >
> > Well this *is* the Linux kernel mailing list...so yes,
> > the kernel is called Linux.
> >
> > RMS wants to take credit for the parts of your complete
> > operating system breakfast (including GCC et al.) that
> > were developed by the GNU project. Whether this is
> > wholly unreasonable or not is an exercise for the
> > reader.
>
> Most of the GNU utilities were just clones of the work
> the AT&T did when the C language and the Unix operating
> system was invented. To clone an existing product is
> trivial as compared to coming up with the original ideas
> in the first place. RMS didn't invent C, he cloned it. If
> anything it should be called AT&T/Linux if you want to
> give credit to the innovators. RMS is just a middleman in
> the process.
AT&T/Minix
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to
> [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html Please read
> the FAQ at http://www.tux.org/lkml/
--
M4y3c0
On Tue, 3 Oct 2006, Marc Perkel wrote:
>
>
> Adam Henley wrote:
>> On 03/10/06, Marc Perkel <[email protected]> wrote:
>> < ... >
>> > Ivan - It's not GNU/Linux - it's just LINUX. Time to get the name right.
>> > RMS doesn't get to rename Linux. Linux isn't going to go away just
>> > because they fork the license.
>> >
>>
>> o_O
>>
>> Well this *is* the Linux kernel mailing list...so yes, the kernel is
>> called Linux.
>>
>> RMS wants to take credit for the parts of your complete operating
>> system breakfast (including GCC et al.) that were developed by the GNU
>> project. Whether this is wholly unreasonable or not is an exercise for
>> the reader.
>
> Most of the GNU utilities were just clones of the work the AT&T did when the
> C language and the Unix operating system was invented. To clone an existing
> product is trivial as compared to coming up with the original ideas in the
> first place. RMS didn't invent C, he cloned it. If anything it should be
> called AT&T/Linux if you want to give credit to the innovators. RMS is just a
> middleman in the process.
>
Linus didn't invent the UNIX syscall interface either, but I think he
deserves a hell of a lot of credit for doing a good job making an
implementation of it.
I fail to see how this conversation thread could possibly be considered
even remotely productive. Can I kindly ask you to stop attacking RMS and
the FSF on LKML?
Thanks,
Chase
> Most of the GNU utilities were just clones of the work the
> AT&T did when the C language and the Unix operating system
> was invented. To clone an existing product is trivial as
> compared to coming up with the original ideas in the first
> place. RMS didn't invent C, he cloned it. If anything it
> should be called AT&T/Linux if you want to give credit to the
> innovators. RMS is just a middleman in the process.
Since we've got to this point, let's call it AT&T/Unix.
Hua
On Mon, 2 Oct 2006, Marc Perkel wrote:
> Just a thought. Suppose we forked the GPL2 license and created the Linux
> license? (Or some better name) It's kind of clear the Stallman has his own
> ajenda and that it's not compatible with the Linux model. So - lets fork it an
> start a new one.
The GPLv2 isn't open source, so it can't (legally) be forked:
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
(The "mere aggregation" clause is, in fact, very important, since
otherwise it would be impossible to distribute GPLed code along with the
license for it.)
Now, it would be plausible to get Creative Commons to do a "provide
source" clause, such that there would be an alternative text with the same
effect as the GPLv2, if there was enough negative opinion about the FSF to
justify having an alternative text to use for this effect.
-Daniel
*This .sig left intentionally blank*
On 10/3/06, Hua Zhong <[email protected]> wrote:
> Since we've got to this point, let's call it AT&T/Unix.
Neither would exist without Alexander Graham Bell, and even had a mother.
Let's call it Alexander Graham Bell's Mom.
--
Patrick Draper --- [email protected]
Austin, Texas --- http://www.pdrap.org
On Tuesday 03 October 2006 21:17, Patrick Draper wrote:
> On 10/3/06, Hua Zhong <[email protected]> wrote:
> > Since we've got to this point, let's call it AT&T/Unix.
>
> Neither would exist without Alexander Graham Bell, and even had a mother.
>
> Let's call it Alexander Graham Bell's Mom.
Wow, this may be the first "yo momma" insult ever told on the LKML.
--
Patrick McFarland || http://AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
On 10/3/06, Patrick McFarland <[email protected]> wrote:
> > Let's call it Alexander Graham Bell's Mom.
>
> Wow, this may be the first "yo momma" insult ever told on the LKML.
Not intended as an insult, just my lame attempt at humor...
--
Patrick Draper --- [email protected]
Austin, Texas --- http://www.pdrap.org
>"Linux" is an operating system kernel. By itself it is pretty
>useless.
I have to object.
Linux (kernel) plus a static standalone userspace binary -- 'enough' for
embedded applications. It does not need GNU in it (with the exception
of the kernel's license, GPL, of course).
>A thing which is Linux plus lots of libraries and utilities and maybe
>a windowing system and a "desktop" is a lot more than "Linux".
-`J'
--
On Wed, 4 Oct 2006, Jan Engelhardt wrote:
>
>> "Linux" is an operating system kernel. By itself it is pretty
>> useless.
>
> I have to object.
>
> Linux (kernel) plus a static standalone userspace binary -- 'enough' for
> embedded applications. It does not need GNU in it (with the exception
> of the kernel's license, GPL, of course).
>
Actually, it needs no libraries at all. See attached. It doesn't
even need the 'C' language to perform useful work although I'm sure
you would not want to write a database application in assembly
language. Also, although I used the GNU assembler and Linker, there
are other tools that would work just as well.
>> A thing which is Linux plus lots of libraries and utilities and maybe
>> a windowing system and a "desktop" is a lot more than "Linux".
>
> -`J'
> --
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.72 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.