GPLv3 Position Statement

195 views
Skip to first unread message

James Bottomley

unread,
Sep 22, 2006, 1:30:13 PM9/22/06
to
Although this white paper was discussed amongst the full group of kernel
developers who participated in the informal poll, as you can expect from
Linux Kernel Developers, there was a wide crossection of opinion. This
document is really only for discussion, and represents only the views of
the people listed as authors (not the full voting pool).

James

----------

The Dangers and Problems with GPLv3


James E.J. Bottomley Mauro Carvalho Chehab
Thomas Gleixner Christoph Hellwig Dave Jones
Greg Kroah-Hartman Tony Luck Andrew Morton
Trond Myklebust David Woodhouse

15 September 2006
Abstract

This document is a position statement on the GNU General Public
License version 3 (in its current Draft 2 form) and its surrounding
process issued by some of the Maintainers of the Linux Kernel
speaking purely in their role as kernel maintainers. In no regard
should any opinion expressed herein be construed to represent the
views of any entities employing or being associated with any of the
authors.

1 Linux and GPLv2

Over the past decade, the Linux Operating System has shown itself to be far
and away the most successful Open Source operating system in history.
However, it certainly wasn't the first such open source operating system
and neither is it currently the only such operating system. We believe that
the pre-eminent success of Linux owes a great part to the dynamism and
diversity of its community of contributors, and that one of the catalysts
for creating and maintaining this community is the development contract as
expressed by GPLv2.

Since GPLv2 has served us so well for so long, and since it is the
foundation of our developer contract which has helped propel Linux to the
successes it enjoys today, we are extremely reluctant to contemplate
tampering with that licence except as bug fixes to correct exposed problems
or updates counter imminent dangers. So far, in the whole history of GPLv2,
including notable successes both injunctively and at trial, we have not
found any bugs significant enough to warrant such corrections.


2 Linux, the Kernel and the Open Source Universe

Linux Distributions, as the Free Software Foundation (FSF) has often
observed, don't only contain the kernel; they are composed of a
distribution of disparate open source components of which the kernel is
only a part (albeit a significant and indispensable part) which
collectively make up a useful and usable system. Thus, Linux as installed
by the end user, is critically dependent on entities, known as
distributions, who collect all of the necessary components together and
deliver them in a tested, stable form. The vast proliferation of Open
Source Licences complicates the job of these distributions and forces them
to spend time checking and assessing the ramifications of combining
software packages distributed under different (and often mutually
incompatible) licences--indeed, sometimes licensing consideration will be
sufficient to exclude a potential package from a distribution altogether.

In deference to the critical role of distributions, we regard reducing
the Open Source licensing profusion as a primary objective. GPLv2 has
played an important role in moving towards this objective by becoming the
dominant Licence in the space today, making it possible to put together a
Linux Distribution from entirely GPLv2 components and thus simplify the
life of a distributor. Therefore, we believe that any update to GPLv2 must
be so compelling as to cause all projects currently licensed under it to
switch as expediently as possible and thus not fragment the currently
unified GPLv2 licensed ecosystem.


3 Linux and Freedom

Another of the planks of Linux's success rests squarely on the breadth and
diversity of its community of contributors and users, without whom we
wouldn't have the steady stream of innovation which drives our movement
forward. However, an essential element of this is the fact that individuals
with disparate (and sometimes even competing) objectives can still march
together a considerable distance to their mutual benefit. This synergy of
effort, while not compromising dissimilar aims, is one of the reasons Linux
manages to harness the efforts of not only motivated developers but also
corporate and commercial interests. This in turn is brought about by a
peculiar freedom enshrined in the developer contract as represented by
GPLv2, namely the freedom from binding the end use of the project. Without
this freedom, it would be much more difficult to satisfy the objectives of
the contributors, since those objectives often have expression in terms of
the end use to which they wish to put the particular project. Therefore, in
order to maintain the essential development synergy and consequent
innovation stream it provides to Linux, we could not countenance any change
to the GPL which would jeopardise this fundamental freedom.


4 Pivotal Role of the Free Software Foundation

We have acknowledged before, projects controlled by the FSF (especially
gcc, binutils and glibc) are essential components of every shipping Linux
distribution. However, we also take note of the fact that the FSF operates
very differently from Linux in that it requires assignment of copyright
from each and every one of the thousands of contributors to its code
base. These contributions have been given to the FSF not as a tribute to do
with as it will but under a solemn trust, as stated in article 9 of GPLv2,
only to licence the code under versions of the GPL that "... will be
similar in spirit to the present version". We, like all the individual
contributors to GNU projects, have taken that trust at face value and
accorded the FSF a special role in the Open Source Universe because of
it. It goes without saying that any updates to GPLv2 must be completely in
accord with the execution of that trust.


5 GPLv3 and the Process to Date

The current version (Discussion Draft 2) of GPLv3 on first reading fails
the necessity test of section 1 on the grounds that there's no substantial
and identified problem with GPLv2 that it is trying to solve.

However, a deeper reading reveals several other problems with the
current FSF draft:

5.1 DRM Clauses

Also referred to as the "Tivoisation" clauses.

While we find the use of DRM by media companies in their attempts to
reach into user owned devices to control content deeply disturbing, our
belief in the essential freedoms of section 3 forbids us from ever
accepting any licence which contains end use restrictions. The existence of
DRM abuse is no excuse for curtailing freedoms.

Further, the FSF's attempts at drafting and re-drafting these
provisions have shown them to be a nasty minefield which keeps ensnaring
innocent and beneficial uses of encryption and DRM technologies so, on such
demonstrated pragmatic ground, these clauses are likewise dangerous and
difficult to get right and should have no place in a well drafted update to
GPLv2.

Finally, we recognise that defining what constitutes DRM abuse is
essentially political in nature and as such, while we may argue forcefully
for our political opinions, we may not suborn or coerce others to go along
with them. Therefore, attempting to write these type of restrictions into
GPLv3 and then relicense all FSF code under it is tantamount to co-opting
the work of all prior contributions into the service of the FSF's political
ends, and thus represents a fundamental violation of the trust outlined in
section 4.

5.2 Additional Restrictions Clause

As we stated in section 2 one of the serious issues in Open Source is too
many licences. The additional restrictions section in the current draft
makes GPLv3 a pick and choose soup of possible restrictions which is going
to be a nightmare for our distributions to sort out legally and get
right. Thus, it represents a significant and unacceptable retrograde step
over GPLv2 and its no additional restrictions clause.

Further, the additional restrictions create the possibility of
fragmentation of the licensing universes among particular chosen
restrictions, which then become difficult to combine and distribute
(because of the need for keeping track of the separate restrictions). Thus,
we think this potential for fragmentation will completely eliminate the
needed compulsion to move quickly to a new licence as outlined in section 2

5.3 Patents Provisions

As drafted, this currently looks like it would potentially jeopardise the
entire patent portfolio of a company simply by the act of placing a GPLv3
licensed programme on their website. Since the Linux software ecosystem
relies on these type of contributions from companies who have lawyers who
will take the broadest possible interpretation when assessing liability, we
find this clause unacceptable because of the chilling effect it will have
on the necessary corporate input to our innovation stream.

Further, some companies who also act as current distributors of Linux
have significant patent portfolios; thus this clause represents another
barrier to their distributing Linux and as such is unacceptable under
section 2 because of the critical reliance our ecosystem has on these
distributions.


6 Conclusions

The three key objections noted in section 5 are individually and
collectively sufficient reason for us to reject the current licence
proposal. However, we also note that the current draft with each of the
unacceptable provisions stripped out completely represents at best marginal
value over the tested and proven GPLv2. Therefore, as far as we are
concerned (and insofar as we control subsystems of the kernel) we cannot
foresee any drafts of GPLv3 coming out of the current drafting process that
would prove acceptable to us as a licence to move the current Linux Kernel
to.

Further, since the FSF is proposing to shift all of its projects to
GPLv3 and apply pressure to every other GPL licensed project to move, we
foresee the release of GPLv3 portends the Balkanisation of the entire Open
Source Universe upon which we rely. This Balkanisation, which will be
manifested by distributions being forced to fork various packages in order
to get consistent licences, has the potential to inflict massive collateral
damage upon our entire ecosystem and jeopardise the very utility and
survival of Open Source. Since we can see nothing of sufficient value in
the current drafts of the GPLv3 to justify this terrible cost, we can only
assume the FSF is unaware of the current potential for disaster of the
course on which is has embarked. Therefore, we implore the FSF to
re-examine the consequences of its actions and to abandon the current GPLv3
process before it becomes too late.

-
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

unread,
Sep 22, 2006, 2:00:09 PM9/22/06
to
On Fri, Sep 22, 2006 at 11:15:50AM -0500, James Bottomley wrote:

> Although this white paper was discussed amongst the full group of kernel
> developers who participated in the informal poll, as you can expect from
> Linux Kernel Developers, there was a wide crossection of opinion. This
> document is really only for discussion, and represents only the views of
> the people listed as authors (not the full voting pool).
>
> James
>
> ----------
>
> The Dangers and Problems with GPLv3
>
>
> James E.J. Bottomley Mauro Carvalho Chehab
> Thomas Gleixner Christoph Hellwig Dave Jones
> Greg Kroah-Hartman Tony Luck Andrew Morton
> Trond Myklebust David Woodhouse

>...
> 6 Conclusions
>
>... Therefore, as far as we are


> concerned (and insofar as we control subsystems of the kernel) we cannot
> foresee any drafts of GPLv3 coming out of the current drafting process that
> would prove acceptable to us as a licence to move the current Linux Kernel
> to.

>...


Some people might wonder why kernel developers have any business
discussing the GPLv3 in their positions as kernel developers and why
10 core kernel developers put their names on a document containing this
statement.


Isn't all this complete nonsense considering that the COPYING file in
the kernel contains the following?

<-- snip -->

Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.

<-- snip -->


Considering that the number of people that contributed to the Linux
kernel during the last 15 years might be in the range 5.000-20.000, so
asking all contributors to agree with a licence change from GPLv2 to
GPLv3 (or any other license) and handling all the cases where
contributors do not answer, are not reachable or disagree, and doing
this in a way not creating legal issues in any jurisdiction is not a
realistic option.


So aren't all discussions about "acceptable to us as a licence to move
the current Linux Kernel to" silly since this is anyway not an option?


In the internal discussions there was one point that changes this
pictures, and I would consider it highly immoral to keep it secret since
it affects every single contributor to Linux.


Thinking about probably changing the license of the kernel makes sense
if you believe the following "nuclear option" is a real option:

1. It is a legally tenable and arguable position that the Linux
kernel is a work of joint authorship whose legal citus is that
of the USA.
2. On this basis, a single co-author can cause the kernel to be
relicensed.
3. To be legally sound, such a co-author would have to be either a
current major subsystem maintainer or a demonstrated contributor
of a significant proportion of code of the kernel.


cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

James Bottomley

unread,
Sep 22, 2006, 2:10:09 PM9/22/06
to
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

Greg KH

unread,
Sep 22, 2006, 2:10:10 PM9/22/06
to
On Fri, Sep 22, 2006 at 07:49:53PM +0200, Adrian Bunk wrote:
> Isn't all this complete nonsense considering that the COPYING file in
> the kernel contains the following?
>
> <-- snip -->

In a way, it is, but no one else is standing up in the free software
community becides Linus stating that they think the GPLv3 is bad. So we
wanted to make our statement also known.

> In the internal discussions there was one point that changes this
> pictures, and I would consider it highly immoral to keep it secret since
> it affects every single contributor to Linux.
>
> Thinking about probably changing the license of the kernel makes sense
> if you believe the following "nuclear option" is a real option:
>
> 1. It is a legally tenable and arguable position that the Linux
> kernel is a work of joint authorship whose legal citus is that
> of the USA.
> 2. On this basis, a single co-author can cause the kernel to be
> relicensed.
> 3. To be legally sound, such a co-author would have to be either a
> current major subsystem maintainer or a demonstrated contributor
> of a significant proportion of code of the kernel.

Note that almost no lawyer that I have spoken to about this believes
this is an option. However, one lawyer I have talked to does believe
this, luckily, that lawyer does not have a client who is a co-author in
the current Linux kernel :)

Anyway, this is arguing a legal point on lkml that even the lawyers
don't all agree apon. I don't think it will get very far here either.

And don't let it detract from the main issue here, the GPLv3 as drafted
has some major issues that a number of us publicly object to, and feel
it will cause great harm if it becomes ratified as drafted.

thanks,

greg k-h

Manu Abraham

unread,
Sep 22, 2006, 2:10:11 PM9/22/06
to

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

unread,
Sep 22, 2006, 2:40:10 PM9/22/06
to
On Friday 22 September 2006 14:08, James Bottomley wrote:
>On Fri, 2006-09-22 at 13:59 -0400, Gene Heskett wrote:
>> James, I'm most definitely NOT a kernel developer, just a lurker who
>> occasionally exhibits his lack of knowledge with (usually) dumb
>> questions.
>>
>> But, while I can't say the above any better than you have, I do have
>> one question:
>>
>> Why is the FSF and RMS not included in the Cc: line of all messages on
>> this subject, so they can have first hand, the benefit of the remarks
>> this group makes by reading about them from the first person? You
>> folks are, as a group, the movers and shakers in the advancement of
>> linux, and would continue to do so without the gnu trying to claim they
>> invented linux, which we all know is a prevarication.
>
>Basically because this is a discussion document, not an open letter.
>
>We had some discussion amongst a small group of kernel developers. Now
>we're opening it up to the linux community---which we can't do without
>effectively going public as well.
>
>James

Well, since this document states the general consensus quite well, and is
not likely to be edited other than crossing all the t's, I think including
them (FSF & RMS) would show them just how concerned the major developers
are with the deviciveness that the proposed V3, as worded say a month ago
the last time I read it and was appalled, will cause. You, nor the rest
of the fans of a great os, will ever be properly served.

You need to remind RMS that he is not a majority when the vote shows
otherwise by a quite resounding margin, and that he and the FSF may well
become irrevalent if the V2 is not going to be supported after V3 is
final. Let me put it this way, I would be willing to become a paying
member of a new organization dedicated to preserving the V2 status if the
due weren't too onnerous. If V3 becomes the defacto, then my membership
in the FSF will get dropped like a hot potato. I'm just one person, but
how many other paying members will do likewise? Enough to cause a serious
hurt to the FSF's finances I'd think.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Jeff Garzik

unread,
Sep 22, 2006, 2:40:10 PM9/22/06
to
Gene Heskett wrote:
> You need to remind RMS that he is not a majority when the vote shows
> otherwise by a quite resounding margin, and that he and the FSF may well
> become irrevalent if the V2 is not going to be supported after V3 is
> final.

Pretty much.

Also consider the "v3 probably won't be compatible with v2" license
compatibility headaches that will abound, given the number of people
that oppose GPL v3 so far.

Jeff

Alan Cox

unread,
Sep 22, 2006, 2:50:10 PM9/22/06
to
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.

Gene Heskett

unread,
Sep 22, 2006, 3:00:17 PM9/22/06
to
On Friday 22 September 2006 14:34, Jeff Garzik wrote:
>Gene Heskett wrote:
>> You need to remind RMS that he is not a majority when the vote shows
>> otherwise by a quite resounding margin, and that he and the FSF may
>> well become irrevalent if the V2 is not going to be supported after V3
>> is final.
>
>Pretty much.
>
>Also consider the "v3 probably won't be compatible with v2" license
>compatibility headaches that will abound, given the number of people
>that oppose GPL v3 so far.
>
> Jeff
>
The question then Jeff, is: Since when is this os a democracy, where there
are voting rights? The ultimate big red veto for the kernel at least, is
for Linus to stamp on it, and thats the one that many, if not all, will
follow. If the top 50 contributors were to lean on Linus to change his
mind, giving lucid arguments, he, haveing an open mind might consider it.
OTOH, given this vote tally, he'd not be foolish enough to buck that, its
a confirmation of his own feelings.

Unforch, here we all stand (0r sit), preaching to the choir, when its the
FSF and RMS we need to be subjecting to the sermon by giving them the
chapter and verse of the book we generally follow. YMMV of course.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Gene Heskett

unread,
Sep 22, 2006, 3:00:18 PM9/22/06
to
On Friday 22 September 2006 15:05, Alan Cox wrote:
>Ar Gwe, 2006-09-22 am 14:30 -0400, ysgrifennodd Gene Heskett:
>> final. Let me put it this way, I would be willing to become a paying
>> member of a new organization dedicated to preserving the V2 status if
>> the due weren't too onnerous.
>
>What probably matters more in that situation, and I hope its one that
>doesn't arise - v3 is in draft and there is fixing time left for many
>issues - is people to maintain the other projects which will get forked
>from the FSF if it were to happen: glibc, gcc, etc. My guess is many of
>these projects would effectively leave the FSF if this happened.

I'd almost place bets on that list, Alan.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

David Schwartz

unread,
Sep 22, 2006, 4:10:10 PM9/22/06
to

> 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

unread,
Sep 22, 2006, 4:50:10 PM9/22/06
to
James Bottomley wrote:
> Although this white paper was discussed amongst the full group of kernel
> developers who participated in the informal poll, as you can expect from
> Linux Kernel Developers, there was a wide crossection of opinion. This
> document is really only for discussion, and represents only the views of
> the people listed as authors (not the full voting pool).

> ----------


>
> The Dangers and Problems with GPLv3
>
>
> James E.J. Bottomley Mauro Carvalho Chehab
> Thomas Gleixner Christoph Hellwig Dave Jones
> Greg Kroah-Hartman Tony Luck Andrew Morton
> Trond Myklebust David Woodhouse


To the slashdot, LWN, etc. crowd: please re-read the first paragraph,
quoted above.

The whitepaper only represents the views of the people listed as authors.

That is distinct from the people who voted against GPL v3 in its current
form (for some or even none of the whitepaper-listed reasons).

Jeff

Linus Torvalds

unread,
Sep 22, 2006, 5:50:08 PM9/22/06
to

[ 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

unread,
Sep 22, 2006, 8:20:10 PM9/22/06
to

> 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

unread,
Sep 22, 2006, 9:40:07 PM9/22/06
to

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

unread,
Sep 23, 2006, 3:30:13 AM9/23/06
to
> However, what happens if three years from now, ...

Yes - the asteroid may destroy us all. But the greater, almost
inevitable, risk comes from the centralization of too much power.

Once an authority exists to unilaterally impose a license change on
Linux, it becomes like the ring in The Lord of the Rings, a thing of
evil potential.

Best not to create the ring in the first place.

Besides, I suspect my company's lawyer might discourage me from
submitting patches to the kernel if its license could be unilaterally
changed by some third party, whether Linus or even the esteemed David S.

To the top 30 maintainers who performed this GPLv3 analysis - nice job.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <p...@sgi.com> 1.925.600.0401

Manu Abraham

unread,
Sep 23, 2006, 4:10:05 AM9/23/06
to


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

Jan Engelhardt

unread,
Sep 23, 2006, 4:20:07 AM9/23/06
to
>
>Second, I should point out again that it is unfortunate that Linus did not
>retain for himself the exclusive right to modify the Linux kernel license.
>If some real problem ever does emerge in the GPLv2 as applies to Linux, it
>will be extremely difficult to resolve.
>
Easy to resolve, but difficult to implement:
remove the offending code (and rewrite).

>This is probably going to be controversial, but Linus should seriously
>consider adding a clause that those who contribute to the kernel from
>now on consent to allow him to modify the license on their current
>contributions and all past contributions, amending the Linux kernel
>license as appropriate.

Now that you raise it: I think developers can already have done that
if they wish - properly name author and conditions who may possibly
change the license to what. Not that I have seen such code yet, but you
never know.


Jan Engelhardt
--

Florian Weimer

unread,
Sep 23, 2006, 7:40:06 AM9/23/06
to
* James Bottomley:

> Further, the FSF's attempts at drafting and re-drafting these
> provisions have shown them to be a nasty minefield which keeps ensnaring
> innocent and beneficial uses of encryption and DRM technologies so, on such
> demonstrated pragmatic ground, these clauses are likewise dangerous and
> difficult to get right and should have no place in a well drafted update to
> GPLv2.

There is a very simple litmus test for DRM code: code that cannot be
altered or removed, according to applicable law or other agreements.
The GPLv3 could forbid the addition of such code to a covered code
base, I suppose. However, this runs contrary to the DRM-like optional
clauses in the GPLv3 (mandatory access through sources over a
communication channel, certain forms of copyright notices).

I think several of these optional clauses are bad. Even the copyright
notices can be annoying (although it's already in GPLv2). For
instance, if I run

emacs somefile.c

from the command line, somefile.c doesn't show up on in the editor,
but the copyright notice. Of course, you can put

(defun display-splash-screen () (interactive))

in a startup file, but if you do this as a distributor, it might be a
GPLv2 violation.

Linus Torvalds

unread,
Sep 23, 2006, 8:50:07 AM9/23/06
to

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

unread,
Sep 23, 2006, 11:40:10 AM9/23/06
to
On 2006-09-22, Linus Torvalds <torv...@osdl.org> wrote:
>
> On Fri, 22 Sep 2006, David Schwartz wrote:
>>
>> This is probably going to be controversial, but Linus should seriously
[...]

>
> I don't actually want people to need to trust anybody - and that very much
> includes me - implicitly.
>
> I think people can generally trust me, but they can trust me exactly
> because they know they don't _have_ to.

And somebody chooses anoter license, f.e see:
linux/drivers/video/aty/radeon_base.c

>
> Now, I could have done it all directly on the Linux-kernel mailing list,
> but let's face it, that would just have caused a long discussion and we'd
> not have really been any better off anyway. So instead, I did
>
> git log | grep -i signed-off-by: |
> cut -d: -f2- | sort | uniq -c | sort -nr | less -S
>
> which anybody else can do on their copy of their git repository, and I
> just picked the first screenful of people (and Alan. And later we added
> three more people after somebody pointed out that some top people use

Alan *is on top* of (old fashioned, gitless):

$ for i in `find linux/drivers/`
do dd count=1 <$i | grep @ | sed 's_[^<]*<\(.*@.*\)>[^>]*_\1_g'
done | sort | uniq -c | sort -rn | most

And what about linux/CREDITS ? Creating (even in the past) is also worth.

As Adrian Bunk noted, there are may who contibuted, still CREDITS has
reasonable size. Search above && grep in CREDITS 50 / 50 from the git
logs would be better ;D.

I would, say

H. Peter Anvin, Vojtech Pavlik, Patrick Mochel, Pavel Machek

are also major contributors. Cheers, guys !
[i usually do credit search on stuff i read in the kernel, so that is IMHO]

-o--=O`C 5 years ago TT and WTC7 were assassinated.
#oo'L O Learn more how (tm) <http://911research.com>
<___=E M

David Schwartz

unread,
Sep 23, 2006, 1:40:12 PM9/23/06
to

> 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

unread,
Sep 23, 2006, 2:10:07 PM9/23/06
to

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

unread,
Sep 23, 2006, 2:20:06 PM9/23/06
to
(Quoting in full for the git@ people.)

Dear diary, on Sat, Sep 23, 2006 at 08:00:23PM CEST, I got a letter
where Linus Torvalds <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

unread,
Sep 24, 2006, 4:00:15 AM9/24/06
to
>> Side note: in "git", we kind of discussed this. And because the project
>> was started when the whole GPL version discussion was already in bloom,
>> the git project has a note at top of the COPYING file that says:
>>
>> Note that the only valid version of the GPL as far as this project
>> is concerned is _this_ particular version of the license (ie v2, not
>> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>>
>> HOWEVER, in order to allow a migration to GPLv3 if that seems like
>> a good idea, I also ask that people involved with the project make
>> their preferences known. In particular, if you trust me to make that
>> decision, you might note so in your copyright message, ie something
>> like
>>
>> This file is licensed under the GPL v2, or a later version
>> at the discretion of Linus.
>>
>
> Actually, this didn't catch on very well anyway, I guess because most
>people just know it's GPLv2 and don't even bother to peek at COPYING, we
>are a bit sloppy about copyright notices and most of them don't mention
>licence at all (if there are any in the file at all), and adding
>explicit copyright notices to mails isn't too popular either.

Would every file that does not contain an explicit license (this
excludes MODULE_LICENSE) falls under COPYING?

> $ git grep 'discretion'
> COPYING: at the discretion of Linus.
> git-annotate.perl:# at the discretion of Linus Torvalds.
> git-relink.perl:# Later versions of the GPL at the discretion of Linus Torvalds
> git-request-pull.sh:# at the discretion of Linus Torvalds.
>
>and I've found no patches with such special assignment.


Jan Engelhardt
--

Linus Torvalds

unread,
Sep 24, 2006, 12:40:10 PM9/24/06
to

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

unread,
Sep 24, 2006, 10:50:05 PM9/24/06
to

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.

Willy Tarreau

unread,
Sep 25, 2006, 1:10:06 AM9/25/06
to
Hi Linus,

On Sun, Sep 24, 2006 at 07:44:59PM -0700, Linus Torvalds wrote:
[...]


> And thus spake PJ in response:
> "GPLv2 is not compatible with the Apache license. It doesn't cover
> Bitstream. It is ambiguous about web downloads. It allows Tivo to
> forbid modification. It has no patent protection clause. It isn't
> internationally useful everywhere, due to not matching the terms of
> art used elsewhere. It has no DMCA workaround or solution. It is
> silent about DRM."
>
> Exactly!
>
> That's why the GPLv2 is so great. Exactly because it doesn't bother or
> talk about anything else than the very generic issue of "tit-for-tat".
>
> You see it as a failure. I see it as a huge advantage. The GPLv2 covers
> the only thing that really matters, and the only thing that everybody can
> agree on ("tit-for-tat" is really something everybody understands, and
> sees the same way - it's totally independent of any moral judgement and
> any philosophical, cultural or economic background).
>
> The thing is, exactly because the GPLv2 is not talking about the details,
> but instead talks entirely about just a very simple issue, people can get
> together around it. You don't have to believe in the FSF or the tooth
> fairy to see the point of the GPLv2. It doesn't matter if you're black or
> white, commercial or non-commercial, man or woman, an individual or a
> corporation - you understand tit-or-tat.

[...]


> That's also why I ended up changing the kernel license to the GPLv2. The
> original Linux source license said basically: "Give all source back, and
> never charge any money". It took me a few months, but I realized that the
> "never charge any money" part was just asinine. It wasn't the point.
> The point was always "give back in kind".

[...]


> And that's what the GPLv2 is. It's "fair". It asks everybody -
> regardless of circumstance - for the same thing. It asks for the effort
> that was put into improving the software to be given back to the common
> good. You can use the end result any way you want (and if you want to use
> it for "bad" things, be my guest), but we ask the same exact thing of
> everybody - give your modifications back.
>
> That's true grace. Realizing that the petty concerns don't matter,
> whether they are money or DRM, or patents, or anything else.
>
> And that's why I chose the GPLv2. I did it back when the $169 I paid for
> Minix still stung me, because I just decided that that wasn't what it was
> all about.
>
> And I look at the additions to the GPLv3, and I still say: "That's not
> what it's all about".
>
> My original license was petty and into details. I don't need to go back
> to those days. I found a better license. And it's the GPLv2.

That's an interesting analysis, and it somehow reflects one I had to
do a few months back. After all the fuss about binary-only modules
incompatibility with GPLv2, I wanted to change the license of haproxy
to explicitly permit external binary-only code to be linked with it. It's
a TCP/HTTP load balancer and people might sometimes have to implement
algorithms under NDA for specific protocols, and I don't want to have
to decide for them if it is the right tool for them or not. I don't
either want to force them to release their code if I don't use it and
if nobody has contributed to it. I just wanted them to give back any
change they bring to the core.

I spend a full week-end reading other licenses, and many others looked
appealing but added specific clauses for patents, DRM, etc... which were
too restrictive for the end user. Others in turn did not make provisions
for feedback. I finally gave up, and decided that the GPLv2 was definitely
the best one for the job. I only changed all the interfacing headers to
LGPL and added a note to explicitly state that my intent was to allow
people to write binary-only modules as long as they gave back their
fixes or work on the core system they use.

As a result, developers are free to choose how they work, and the type
of contribution they expect from others, but they must respect the
work of others. *That* is what I consider fair use.

Just my 2 cents,
Willy

Jan Engelhardt

unread,
Sep 25, 2006, 2:10:09 AM9/25/06
to
>> Would every file that does not contain an explicit license (this
>> excludes MODULE_LICENSE) falls under COPYING?
>
>[...]

>If a file doesn't have a license mentioned, it doesn't mean that it's
>"free for all" or not copyrighted, it just means that you need to find out
>what the license is some other way (and if you can't find out, you
>shouldn't be copying that file ;)
>
>Of course, for clarity, a lot of projects end up adding at least a minimal
>copyright header license everywhere, just to cover their *sses. It's not
>required, but maybe it avoids some confusion, especially if that file is
>later copied into some other project with other basic rules (but if you
>do that, you really _should_ have added the information at that point!).
>[...]

Though I strongly agree with you, some GNU folks (such as
savannah.nongnu.org) seem to explicitly require it, even for files
that do not make up a single program (i.e. like coreutils/ls.c).

Jan Engelhardt
--

Marc Perkel

unread,
Sep 25, 2006, 2:40:08 AM9/25/06
to
I have to say for wht it's worth that you did an excellent job of
stating a very well reasons position on GPL3 and laid out in good detail
the problems and consequences in a logical manner.

Michiel de Boer

unread,
Sep 25, 2006, 5:00:15 AM9/25/06
to
James Bottomley wrote:
> Although this white paper was discussed amongst the full group of kernel
> developers who participated in the informal poll, as you can expect from
> Linux Kernel Developers, there was a wide crossection of opinion. This
> document is really only for discussion, and represents only the views of
> the people listed as authors (not the full voting pool).
>
> James

>
> ----------
>
> The Dangers and Problems with GPLv3
>
>
> James E.J. Bottomley Mauro Carvalho Chehab
> Thomas Gleixner Christoph Hellwig Dave Jones
> Greg Kroah-Hartman Tony Luck Andrew Morton
> Trond Myklebust David Woodhouse
>
> 15 September 2006
> Abstract
>
> This document is a position statement on the GNU General Public
> License version 3 (in its current Draft 2 form) and its surrounding
> process issued by some of the Maintainers of the Linux Kernel
> speaking purely in their role as kernel maintainers. In no regard
> should any opinion expressed herein be construed to represent the
> views of any entities employing or being associated with any of the
> authors.
>
> 1 Linux and GPLv2
>
> Over the past decade, the Linux Operating System has shown itself to be far
> and away the most successful Open Source operating system in history.
> However, it certainly wasn't the first such open source operating system
> and neither is it currently the only such operating system. We believe that
> the pre-eminent success of Linux owes a great part to the dynamism and
> diversity of its community of contributors, and that one of the catalysts
> for creating and maintaining this community is the development contract as
> expressed by GPLv2.
>
> ...<SNIP>....
>
> 6 Conclusions
>
> The three key objections noted in section 5 are individually and
> collectively sufficient reason for us to reject the current licence
> proposal. However, we also note that the current draft with each of the
> unacceptable provisions stripped out completely represents at best marginal
> value over the tested and proven GPLv2. Therefore, as far as we are
> concerned (and insofar as we control subsystems of the kernel) we cannot
> foresee any drafts of GPLv3 coming out of the current drafting process that
> would prove acceptable to us as a licence to move the current Linux Kernel
> to.
>
> Further, since the FSF is proposing to shift all of its projects to
> GPLv3 and apply pressure to every other GPL licensed project to move, we
> foresee the release of GPLv3 portends the Balkanisation of the entire Open
> Source Universe upon which we rely. This Balkanisation, which will be
> manifested by distributions being forced to fork various packages in order
> to get consistent licences, has the potential to inflict massive collateral
> damage upon our entire ecosystem and jeopardise the very utility and
> survival of Open Source. Since we can see nothing of sufficient value in
> the current drafts of the GPLv3 to justify this terrible cost, we can only
> assume the FSF is unaware of the current potential for disaster of the
> course on which is has embarked. Therefore, we implore the FSF to
> re-examine the consequences of its actions and to abandon the current GPLv3
>

For what it's worth, i support RMS and his fight for free software fully.
I support the current draft of the GPL version 3 and am very dissapointed
it will not be adopted as is. IMHO, Linux has the power and influence
to move mountains in the software industry, and shouldn't shy away from
the opportunity to take moral responsibility when it arises.

What is the stance of the developer team / kernel maintainers on DRM,
Trusted Computing and software patents? Does the refusal to adopt GPLv3 as
is mean that these two are more likely to emerge as supported functionality
in the Linux kernel? Are there any moral boundaries Linux kernel developers
will not cross concerning present and new U.S. laws on technology? Are they
willing to put that in writing? Will Linux support HD-DVD and BluRay by
being slightly more tolerant to closed source binary blobs? What about
the already existant problems with the Content Scrambling System for
DVD's?

Finally, i hope that the wishes of the community of people that have only
contributed to the kernel a few times but whose combined work may equal that
of the core developers, are taken into account; as well as the wishes of
the massive amount of users of the Linux kernel.

How about a public poll?

Regards, Michiel de Boer

Russell King

unread,
Sep 25, 2006, 5:10:13 AM9/25/06
to
On Mon, Sep 25, 2006 at 10:53:14AM +0200, Michiel de Boer wrote:
> For what it's worth, i support RMS and his fight for free software fully.
> I support the current draft of the GPL version 3 and am very dissapointed
> it will not be adopted as is.

Let me stop you there. The kernel has had far too many contributors
submit code under "GPLv2 only" to allow it to be universally relicensed
as GPLv3, even if we _wanted_ to do that.

So the question about adoption of GPLv3 is largely irrelevant for the
kernel.

If you think otherwise, please seek expert legal advice.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

tri...@samba.org

unread,
Sep 25, 2006, 6:10:09 AM9/25/06
to
James,

Thanks for posting this. It's obviously had a lot of thought go into
it.

I do think there are a few flaws in the arguments however. The biggest
one for me can be summed up in the question "which license better
represents the intention of the GPLv2 in the current world?"

When the GPLv2 was drafted it wasn't a legal document in a vacuum. It
came with a preamble that stated its intentions, and it came with
someone who toured the world explaining the intentions and
motivations. There were even plenty of repeat performances for anyone
who wanted to attend :-)

I think the GPLv3 does a better job of expressing legally those
intentions than GPLv2 did. In particular this part of the v2 preamble:

"For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights
that you have."

I think that recent developments (such as TiVo v2) have shown that
companies have found ways to give recipients less rights then they
have themselves.

So I think the parts of the position statement that talk about the
importance of the 'development contract as expressed/represented by
GPLv2' and the implication that this contract would be violated by the
current GPLv3 draft are not accurate. That development contract came
with a clear explanation (or at least it seems clear to me).

Similarly, the position statement states:

"This in turn is brought about by a peculiar freedom enshrined in the
developer contract as represented by GPLv2, namely the freedom from
binding the end use of the project."

but I think this particular 'freedom' comes more from the development
conventions of the Linux kernel community than from the GPLv2. I don't
see anything in the GPLv2 that actually tried to enshrine that
particular freedom. That doesn't mean it isn't a worthwhile thing to
enshrine, I just think it is inaccurate to claim that the GPLv2
attempts in any way to enshrine it.

Linus clearly values this freedom very highly, as I'm sure many kernel
developers do. So for those people the GPLv2 license may better
represent their own intentions.

For myself, I value other things more highly. One of the most
important aspects of the GPL for me is the equality between vendors
and recipients of software. I really like the symmetry between giver
and receiver, and the fact that this symmetry is passed on down the
chain, so that someone ten steps away from me as an author ends up
with the same rights that I had.

(There is an exception to this. The copyright holder is the only one
who can sue over a violation of the license, so that is an asymmetry,
but I think it is an essential asymmetry and prevents chaos. When
faced with a GPL violation of my code I have almost always chosen to
work with the violator to bring them into compliance, whereas if
anyone could sue then we'd see lawsuits far too often)

One result of this symmetry is that most GPLd software is 'free as in
beer' as well as 'free as in freedom'. If someone were to start
charging outrageous prices for GPLd software then someone else will
come along and sell it cheaper. That drives down the price to a
reasonable level.

I like the fact that I was able to distribute useful patches for the
kernel in TiVo v1. I didn't like the fact that I had to work around
the binary kernel modules used by TiVo, but I didn't complain too
loudly partly because it was a nice challenge to work around the
problem. I was delighted when TiVo incorporated some of my changes (in
particular a new driver) into their future releases. That was the GPL
working.

With v2 TiVo introduces something which had the potential to make that
impossible, at least for me. Thankfully they didn't get it quite
right, but it certainly made me aware that the symmetry I had been
taking for granted in the GPL was under threat.

So for me this symmetry is more important than the loss of the 'end
users can do what they want' freedom. From my point of view, that
freedom was never part of the 'contract' I had with the FSF, but the
symmetry freedom was, and thus I think the FSF has done well in fixing
a hole in the GPLv2 license.

Finally, I'm curious as to the legal basis of this statement:

> As drafted, this currently looks like it would potentially jeopardise the
> entire patent portfolio of a company simply by the act of placing a GPLv3
> licensed programme on their website.

I can't see anything in the current GPLv3 draft which would do
that. Could you explain how that comes about?

Cheers, Tridge

Neil Brown

unread,
Sep 25, 2006, 7:00:10 AM9/25/06
to
On Monday September 25, x...@rebelhomicide.demon.nl wrote:
>
> For what it's worth, i support RMS and his fight for free software fully.
> I support the current draft of the GPL version 3 and am very dissapointed
> it will not be adopted as is. IMHO, Linux has the power and influence
> to move mountains in the software industry, and shouldn't shy away from
> the opportunity to take moral responsibility when it arises.

I think that would be against the character of Linux. Linux has
always been primarily about technology and community rather than
freedom. Doing something to improve the technology or enable the
community would be very in-character. Doing something in the name of
freedom would not.

Is that a reasonable position to take? Well, maybe.

There are (at least) two ways to change unpleasant behaviour in
others. One is through legislation. The other is through making the
pleasant behaviour more attractive.
Legislation is short term, but makes things black-and-white (or, in
the case of grey areas, very expensive).
Rewarding good behaviour is a much slower process, but deals with gray
areas much more effectively.

I think it is clear that we need a balance.
The 'legislation' of GPLv2 plus the economic benefit of hundreds of
developers have been an effective 2-prong attack to encourage people
to share their software. This has been self re-enforcing. The more
people see the benefit, the more people seem to get involved.
So Linux has done a lot for freedom by focussing on technology.

So the question is: has the balance swung far enough the wrong way to
make a change in legislation necessary?

The 'DRM' provision of the proposed GPLv3 seem to be being driven by 1
company - Tivo. Yes, what they are doing is against our spirit of
freedom. But is it enough to justify changing the legislation? Or
would that be 'the tail wagging the dog'??

The 'patent' provisions are - to me - more defensible than the DRM
provisions (fewer grey areas). But are they an actual problem, or
just a potential problem?

The GPLv2 was written based on experience of people taking code and
giving nothing back. Based on quite a lot of (unpleasant) experience,
a very effective measure was developed to combat it.
Do we have the same amount of experience with the problems that the
GPLv3 is supposed to fix? If not, fixing now might be a bit premature
and may lead to unwanted side effects.

But maybe I am just misinformed. Maybe there are dozens of different
manufacturers making devices that use DRM to prohibit freedom despite
using GPL code, and maybe there are hundreds of submarine patents
owned by distributors of GPL code and embodied in that code that the
owners are going to start suing us overs.... Is there a list of these
somewhere?

>
> What is the stance of the developer team / kernel maintainers on DRM,

While I cannot speak for other developers (and sometimes have trouble
speaking for myself), one stance I have often heard is that DRM is
simply a tool - one that is largely based on cryptography which is
just another tool. They can have good uses and bad uses just like the
TCP/IP stack (think 'spam'). So code to implement then would (if of
suitable quality) be allowed into the kernel. If you want to make DRM
illegal, speak to your member-of-parliament, not your code developers.

> Trusted Computing and software patents? Does the refusal to adopt GPLv3 as
> is mean that these two are more likely to emerge as supported functionality
> in the Linux kernel? Are there any moral boundaries Linux kernel developers
> will not cross concerning present and new U.S. laws on technology? Are they
> willing to put that in writing? Will Linux support HD-DVD and BluRay by
> being slightly more tolerant to closed source binary blobs? What about
> the already existant problems with the Content Scrambling System for
> DVD's?

Tolerance of binary blogs seems to be steadily dropping.

As far as I can tell, the DVD-CSS is purely a legal issue today - the
technical issues are solved (I can watch any-region on my Linux
computer, and in Australia, the law requires that all DVD players must
ignore region encoding as it is an anti-competitive practice).

How HD-DVD and BluRay will work on Linux is yet to be seen, but I
seriously doubt that anything in the GPLvX would have much effect on
the outcome. The greater effect would come from people writing to
their congress-person and voting with their wallet.... or just
reverse-engineering the technology:-)

>
> Finally, i hope that the wishes of the community of people that have only
> contributed to the kernel a few times but whose combined work may equal that
> of the core developers, are taken into account; as well as the wishes of
> the massive amount of users of the Linux kernel.

This isn't about anyone's wishes. The kernel is GPLv2 only and that is not
going to change - arguably is cannot change.

This is about a group of developers giving an opinion. If others
agree, it might become an argument that the FSF will choose to allow
to affect their policy making (rather than thinking it is just Linus
raving as usual). If no-one agrees, it will remain the opinion of a
few, with all the lack of force that implies.

>
> How about a public poll?

We've all see the sort of politician that get into government on the
back of a public poll... Do you really think a public poll would
provide a useful result :-)

NeilBrown

Alan Cox

unread,
Sep 25, 2006, 7:10:07 AM9/25/06
to
Ar Llu, 2006-09-25 am 20:51 +1000, ysgrifennodd Neil Brown:
> The 'DRM' provision of the proposed GPLv3 seem to be being driven by 1
> company - Tivo. Yes, what they are doing is against our spirit of

Actually quite a few companies have done this, and in some cases have
been involved in out of court settlements over that kind of abuse.

Let's be clear about this. The GPLv2 covers the scripts etc for
installation. The DRM keys are probably covered, and out of court
settlements lend weight to that. It has always been my publically stated
position that I reserve the right to sue anyone who uses my code and
locks it away with keys.

The GPLv3 rewords it in an attempt to be clearer but also I think rather
more over-reaching. It's not clear what for example happens with a
rented device containing GPL software but with DRM on the hardware.
Thats quite different to owned hardware. GPLv2 leaves it open for the
courts to make a sensible decision per case, GPLv3 tries to define it in
advance and its very very hard to define correctly.

Alan

Jan Engelhardt

unread,
Sep 25, 2006, 7:20:15 AM9/25/06
to
>
> 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

unread,
Sep 25, 2006, 8:10:14 AM9/25/06
to
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

Willy Tarreau

unread,
Sep 25, 2006, 9:40:10 AM9/25/06
to
On Mon, Sep 25, 2006 at 02:00:05PM +0200, Arjan van de Ven wrote:
> On Mon, 2006-09-25 at 06:40 +0200, Willy Tarreau wrote:
> > do a few months back. After all the fuss about binary-only modules
> > incompatibility with GPLv2, I wanted to change the license of haproxy
> > to explicitly permit external binary-only code to be linked with it.
>
> LGPL is then a logical and commonly accepted choice for a license

Not exactly, because I don't want people to include interesting parts
of my code into their binary-only programs. I just want to allow
people to link binary-only modules with my program. However, programs
that are already GPLv2 are welcome to steal part of my code.

Regards,
Willy

James Bottomley

unread,
Sep 25, 2006, 10:20:09 AM9/25/06
to
On Mon, 2006-09-25 at 10:53 +0200, Michiel de Boer wrote:
> For what it's worth, i support RMS and his fight for free software fully.
> I support the current draft of the GPL version 3 and am very dissapointed
> it will not be adopted as is. IMHO, Linux has the power and influence
> to move mountains in the software industry, and shouldn't shy away from
> the opportunity to take moral responsibility when it arises.

Well ... as Russell already pointed out; adopting GPLv3 was made
incredibly difficult for us by the FSF. We could easily adopt a GPLv2
compatible licence simply by going through some sort of process to
secure agreement and then altering the COPYING file of the kernel (the
point being that past contributions would still be v2, future
contributions would be the new licence and there's no distribution
problem because they're compatible).

There are definite bug fixes to v2 in the v3 draft: Bittorrent and
termination. However, we could adopt those in a v2 compatible fashion
(as additional permissions). Additionally, it does strike me that a
patent grant could be formulated in a v2 compatible manner if people
agreed on it. Obviously, the additional restrictions of v3 is
completely impossible to accommodate in a v2 compatible manner. The DRM
provisions could be disputed: if you believe they're already in v2, then
they could be adopted in a v2 compatible fashion as a clarification ...
however, they'd have to be quite a bit less broad than the current v3
language.

All in all, we could probably only switch to v3 by some type of
universal acclamation process, which, with 28 votes against already
isn't really likely.

James

Lee Revell

unread,
Sep 25, 2006, 10:30:10 AM9/25/06
to
On Mon, 2006-09-25 at 20:51 +1000, Neil Brown wrote:
> Tolerance of binary blogs seems to be steadily dropping.
>
> As far as I can tell, the DVD-CSS is purely a legal issue today - the
> technical issues are solved (I can watch any-region on my Linux
> computer, and in Australia, the law requires that all DVD players must
> ignore region encoding as it is an anti-competitive practice).

Tolerance by who? As far as I can tell tolerance for binary blobs by
the typical Linux desktop user is higher than ever. They consider it a
bug if their distro does not automagically install the nvidia/ATI
drivers, and immediately write you off as a GPL zealot if you even
mention that a tainted kernel cannot be debugged.

Lee

Linus Torvalds

unread,
Sep 25, 2006, 11:20:13 AM9/25/06
to

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

unread,
Sep 25, 2006, 11:40:18 AM9/25/06
to
On Fri, 2006-09-22 at 18:15, James Bottomley wrote:
> [...] we

> foresee the release of GPLv3 portends the Balkanisation of the entire Open
> Source Universe upon which we rely. This Balkanisation, which will be
> manifested by distributions being forced to fork various packages in order
> to get consistent licences, has the potential to inflict massive collateral
> damage upon our entire ecosystem and jeopardise the very utility and
> survival of Open Source. [...]

This language looks terribly like US politician bullshit. Maybe you
should reformulate that "paper".

Xav

Thomas Gleixner

unread,
Sep 25, 2006, 12:10:21 PM9/25/06
to
On Mon, 2006-09-25 at 12:31 +0100, Alan Cox wrote:
> The GPLv3 rewords it in an attempt to be clearer but also I think rather
> more over-reaching. It's not clear what for example happens with a
> rented device containing GPL software but with DRM on the hardware.
> Thats quite different to owned hardware. GPLv2 leaves it open for the
> courts to make a sensible decision per case, GPLv3 tries to define it in
> advance and its very very hard to define correctly.

Also the prevention of running modified versions is not only caused by
economic interests and business models. There are also scenarios where
it is simply necessary:

- The liability for damages, where the manufacturer of a device might
be responsible in case of damage when he abandoned the prevention. This
applies to medical devices as well as to lasers, machine tools and many
more. Device manufacturers can not necessarily escape such liabilities
as it might be considered grossly negligent to hand out the prevention
key, even if the user signed an exemption from liability.

- Regulations to prevent unauthorized access to radio frequencies, which
is what concerns e.g. cellphone manufacturers.

- ...

An ultimate definition of acceptable and unacceptable usage scenarios is
simply not possible due to the complexity of the problem. Any attempt to
create a definition will lead to loopholes and grey areas. Further it
will compulsory exclude acceptable usage scenarios.

A simple loophole example was brought up in the discussion already:
Technical limitations which do not allow modification at all, e.g. ROMs,
ASICs are apparently considered as a valid usage scenario, but it also
allows in consequence the circumvention of the intended lock down
protection by simple technical means, e.g. ROM based software
cartridges.

If you knit narrower meshes, you create more holes. This is not only
true for knitgoods, it's also a well known problem of legal systems.

tglx

Linus Torvalds

unread,
Sep 25, 2006, 1:00:16 PM9/25/06
to

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

unread,
Sep 25, 2006, 1:30:14 PM9/25/06
to
On Mon, 2006-09-25 at 10:53 +0200, Michiel de Boer wrote:
> What is the stance of the developer team / kernel maintainers on DRM,
> Trusted Computing and software patents? Does the refusal to adopt GPLv3 as
> is mean that these two are more likely to emerge as supported functionality
> in the Linux kernel? Are there any moral boundaries Linux kernel developers
> will not cross concerning present and new U.S. laws on technology? Are they
> willing to put that in writing? Will Linux support HD-DVD and BluRay by
> being slightly more tolerant to closed source binary blobs? What about
> the already existant problems with the Content Scrambling System for
> DVD's?

Well, I think the email you quoted above gave the stance on DRM as used
by the content industry (in the bit you snipped):

> ... we find the use of DRM by media companies in their attempts to
> reach into user owned devices to control content deeply disturbing

I'll venture my personal opinion of replacing "deeply disturbing" with
"abhorrent". The trusted computing platform insofar as it is an agent
of that same DRM use by the media companies would thus share that
opinion. However, if it were sold as an agent at the disposal of the
user of the machine (rather than the content providers) then it
wouldn't. These technologies are not intrinsically "evil" it's the use
to which they're put that can be.

As far as the you must be able to run modifications language goes: too
many embedded devices nowadays embed linux. To demand a channel for
modification is dictating to manufacturers how they build things. Take
the case of an intelligent SCSI PCI card which happens to run embedded
linux in flash. The v3 draft requirements dictate a channel to modify
the flash image ... if that's a PCI card, the manufacturer has no
earthly way to control what happens on the platform into which its
plugged. So, if it's soldered onto a sparc motherboard and the card
manufacturer though their responsibility was discharged by producing a
dos flash floppy, who just broke the v3 requirements? should the sparc
motherboard maker care what embedded OS all the components run? should
the price for using linux to make embedded components be that you have
to provide modification toolkits for every conceivable platform they
could be used in?

Also, I just don't accept that Tivo is bad for Linux (even if I could be
persuaded that attacking Tivo would somehow help the battle against the
content providers' DRM efforts). I admit that not much useful has come
out of that one company, but the no tampering with the image requirement
came from cable companies who saw modifying a Tivo to store and
redistribute content to be a threat to them. There's a much more
clearcut example than Tivo: the Moxi (its rival), which has identical
bootloader requirements forced on it by cable companies for identical
reasons. It's produced by Digeo who, according to my personal count,
provided us with several device driver updates, a slew of filesystem
improvements and a kernel maintainer (which, I think everyone will
agree, went beyond their strict GPLv2 requirements)... how does some
perceived inequity with Tivo justify killing Digeo? or even making life
difficult for embedded hardware manufacturers? Look at it this way:
every Tivo is a potential Digeo ... we just have to persuade them.

James

Jan Engelhardt

unread,
Sep 25, 2006, 3:10:10 PM9/25/06
to

>> 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

unread,
Sep 25, 2006, 3:50:14 PM9/25/06
to
Neil Brown wrote:
> But maybe I am just misinformed. Maybe there are dozens of different
> manufacturers making devices that use DRM to prohibit freedom despite
> using GPL code, and maybe there are hundreds of submarine patents
> owned by distributors of GPL code and embodied in that code that the
> owners are going to start suing us overs.... Is there a list of these
> somewhere?

At least for patents, lawyers scream bloody murder if a list of patents
is posted. Once that is done, people can no longer claim ignorance of a
patent.


>> What is the stance of the developer team / kernel maintainers on DRM,
>
> While I cannot speak for other developers (and sometimes have trouble
> speaking for myself), one stance I have often heard is that DRM is
> simply a tool - one that is largely based on cryptography which is
> just another tool. They can have good uses and bad uses just like the
> TCP/IP stack (think 'spam'). So code to implement then would (if of
> suitable quality) be allowed into the kernel. If you want to make DRM
> illegal, speak to your member-of-parliament, not your code developers.

This is a KEY POINT: There can be good DRM as well as bad DRM.

Jeff

Gene Heskett

unread,
Sep 25, 2006, 5:10:09 PM9/25/06
to
On Monday 25 September 2006 10:27, Lee Revell wrote:
>On Mon, 2006-09-25 at 20:51 +1000, Neil Brown wrote:
>> Tolerance of binary blogs seems to be steadily dropping.
>>
>> As far as I can tell, the DVD-CSS is purely a legal issue today - the
>> technical issues are solved (I can watch any-region on my Linux
>> computer, and in Australia, the law requires that all DVD players must
>> ignore region encoding as it is an anti-competitive practice).

I suspect thats history now, with the DMCA proposals now being voted on
there.

>Tolerance by who? As far as I can tell tolerance for binary blobs by
>the typical Linux desktop user is higher than ever.

Generaly speaking, from someone way up in the top level of the bleacher
seats here, thats true, as for instance the ndiswrapper scenario, required
by the rules of the various radio spectrum regulating agencies around the
planet. They would never, ever, give approval to a driver that was 100%
open source because of the ease with which the open source coder could
make them illegal, either for frequencies used, or for the Transmitter
Power Output one of these software radios COULD be made to do.

>They consider it a
>bug if their distro does not automagically install the nvidia/ATI
>drivers, and immediately write you off as a GPL zealot if you even
>mention that a tainted kernel cannot be debugged.

No, I do not, and never have said too much about it (as if anyone would
listen to me anyway) unless I was pissed because the kernels available
driver was obviously broken and caused crashes etc. We DO understand,
very well, that troubleshooting a problem just isn't possible when the
srcs are not available, meaning there is no way in hell you can certify
that the tainting driver didn't scribble all over memory it has no
business scribbling into.

Begin rant:

Yeah, we'ed be fools to say we don't have a political agenda when we're
forced to use substandard or questionably legal means for reasons related
to the above. But give us credit for understanding the reasons. What we,
the users, need in many cases, is a contact address to address our vents
to, for instance for someone at broadcom, high enough to have meaningfull
input to the discussions in the board room, that we could mail-bomb with
requests for better support. If 3000+ people who bought their stuff with
some well known makers label on it, like HP, and found they couldn't use
that builtin radio and do it 100% legal and compatibly, would email (and
Cc: your countries regulatory agency too) that chip maker and gently but
firmly bitch, that bit of 'politics' might well bring about some
constructive change in broadcoms (and the regulatory agencies involved)
attitude vis-a-vis specs release so better drivers could be written.

End rant.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Gene Heskett

unread,
Sep 25, 2006, 5:20:10 PM9/25/06
to
On Monday 25 September 2006 15:46, Jeff Garzik wrote:
>Neil Brown wrote:
>> But maybe I am just misinformed. Maybe there are dozens of different
>> manufacturers making devices that use DRM to prohibit freedom despite
>> using GPL code, and maybe there are hundreds of submarine patents
>> owned by distributors of GPL code and embodied in that code that the
>> owners are going to start suing us overs.... Is there a list of these
>> somewhere?
>
>At least for patents, lawyers scream bloody murder if a list of patents
>is posted. Once that is done, people can no longer claim ignorance of a
>patent.

Thats their problem, they created this mess in the first place. I can
recall buying, years ago, things whose makers label devoted more text area
to listing the applicable patents either pending or granted on the device
the label was attached to than was devoted to the makers logo itself. Now
it probably takes whole pages of 4 pt pica text with the patent
proliferation ad adsurdium thats taken place in the last 40 years... Bah.
All created to make sure the legal profession never starves.

>>> What is the stance of the developer team / kernel maintainers on DRM,
>>
>> While I cannot speak for other developers (and sometimes have trouble
>> speaking for myself), one stance I have often heard is that DRM is
>> simply a tool - one that is largely based on cryptography which is
>> just another tool. They can have good uses and bad uses just like the
>> TCP/IP stack (think 'spam'). So code to implement then would (if of
>> suitable quality) be allowed into the kernel. If you want to make DRM
>> illegal, speak to your member-of-parliament, not your code developers.
>
>This is a KEY POINT: There can be good DRM as well as bad DRM.
>
> Jeff
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to 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)

unread,
Sep 25, 2006, 6:20:09 PM9/25/06
to

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

unread,
Sep 26, 2006, 5:40:10 PM9/26/06
to
Hallo,

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

unread,
Sep 26, 2006, 9:20:07 PM9/26/06