GPLv3 Position Statement
James Bottomley
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Adrian Bunk
> 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
Greg KH
> 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
Manu Abraham
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
Gene Heskett
>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.
Alan Cox
> 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.
Gene Heskett
>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.
>
>
>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.
Gene Heskett
>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.
David Schwartz
> 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
Jeff Garzik
> 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
Linus Torvalds
[ 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
David Schwartz
> 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
Linus Torvalds
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
Paul Jackson
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 <p...@sgi.com> 1.925.600.0401
Manu Abraham
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
Florian Weimer
> 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.
Linus Torvalds
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
Linus
Oleg Verych
>
> 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
David Schwartz
> 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
Linus Torvalds
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
Petr Baudis
Dear diary, on Sat, Sep 23, 2006 at 08:00:23PM CEST, I got a letter
where Linus Torvalds <torv...@osdl.org> said that...
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*',/((..)*)$/)
Jan Engelhardt
>> 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.
>>
>
>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
--
Linus Torvalds
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
Linus Torvalds
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
Willy Tarreau
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
Jan Engelhardt
>> 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
--
Marc Perkel
stating a very well reasons position on GPL3 and laid out in good detail
the problems and consequences in a logical manner.
Michiel de Boer
> 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
>
> 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.
>
> 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
Russell King
> 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
tri...@samba.org
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
Neil Brown
>
> 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
Alan Cox
> 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
Jan Engelhardt
> 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
--
Arjan van de Ven
> 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
Willy Tarreau
> 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
James Bottomley
> 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
Lee Revell
> 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
Linus Torvalds
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
Xavier Bestel
> [...] 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
This language looks terribly like US politician bullshit. Maybe you
should reformulate that "paper".
Xav
Thomas Gleixner
> 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
Linus Torvalds
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
James Bottomley
> 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
Jan Engelhardt
>> 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
--
Jeff Garzik
> 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
Gene Heskett
>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.
Gene Heskett
>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 majo...@vger.kernel.org
>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.
linux-os (Dick Johnson)
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!
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 Deliver...@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Oleg Verych
On 2006-09-25, Lee Revell <rlre...@joe-job.com> 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.
Sergey Panov
> 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?
Jan Engelhardt
>Fuzzy (but realistic) logic:
>
> kernel != operating_system
>
> operating_system > kernel
>
> operating_system - kernel = 0
>
> kernel - (operating_system - kernel) < 0
>
> 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
--
Sergey Panov
> >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.
Jan Engelhardt
>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
--
Nicolas Mailhot
> 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
Alan Cox
> 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
Theodore Tso
> 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.
Linus Torvalds
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
Linus Torvalds
[ 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
Linus Torvalds
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
Theodore Tso
> >... ???. 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
Chase Venters
>
> 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
Linus Torvalds
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
Krzysztof Halasa
Linus Torvalds <torv...@osdl.org> 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
Linus Torvalds
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
Krzysztof Halasa
> 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
David Schwartz
> 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
Alan Cox
> 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
Theodore Tso
> 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
Linus Torvalds
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
Thomas Gleixner
> 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
Chase Venters
> 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
Neil Brown
>
> 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
David Miller
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.
H. Peter Anvin
> 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
Linus Torvalds
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
Patrick McFarland
> 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
Alan Cox
> _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
Al Viro
> 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
Gene Heskett
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.
Sergey Panov
> 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".
>
> 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!
Linus Torvalds
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
Linus Torvalds
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
Sergey Panov
> 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).
Linus Torvalds
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
Chase Venters
> 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
Sergey Panov
>
> 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.
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.
Trond Myklebust
> 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
Jeff Garzik
> 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
Sergey Panov
> 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.
Jeff Garzik
> 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
Al Viro
> 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.
Jan Engelhardt
>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
--
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.
Samuel Tardieu
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 -- s...@rfc1149.net -- http://www.rfc1149.net/
Jörn Engel
>
> 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
Jeff Garzik
> 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
Christer Weinigel
> 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 <chri...@weinigel.se> http://www.weinigel.se
Lennart Sorensen
> 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
DervishD
* Lennart Sorensen <lsor...@csclub.uwaterloo.ca> 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!
Linus Torvalds
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
Jörn Engel
>
> 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