Slashdot Mirror
Linus Says No GPLv3 for the Linux Kernel
HenchmenResources writes "Late Wednesday a posting from Linus Torvalds appered on the the Linux Kernel Mailing List. In it Linus states that the Linux Kernel will remain under the GPLv2. Types Linus,"The "version 2 of the License, or (at your option) any later version" language in the GPL copying file is not - and has never been - part of the
actual License itself.""
Linux is licensed under GPL v2. In order to move to GPL v3, v4, v99 etc, EVERY SINGLE CONTRIBUTOR must accept this. Practically impossible.
His concern appears to be with a clause that would require publically releasing the keys that were used to sign-off sections of the code.
I'd have to look into it in more detail to figure out what keys he is referring to. Does anybody know? I could see the logic of GPLv3 requiring this, and I can also see Linus' objection.
In other words, this isn't a knee-jerk reaction.... there is logic to it. Now maybe what Linus should be doing is commenting on GPLv3 so that it gets changed, and for all we know he has.
Here is the full text as it took me several times to get past the MySQL errors with too many connections:
Date Wed, 25 Jan 2006 17:39:16 -0500 (EST)
From Linus Torvalds
Subject Re: GPL V3 and Linux - Dead Copyright Holders
On Wed, 25 Jan 2006, Chase Venters wrote:
>
> This means that when the code went GPL v1 -> GPL v2, the transition was
> permissible. Linux v1.0 shipped with the GPL v2. It did not ship with a
> separate clause specifying that "You may only use *this* version of the GPL"
> as it now does. (I haven't done any research to find out when this clause was
> added, but it was after the transition to v2).
Bzzt. Look closer.
The Linux kernel has _always_ been under the GPL v2. Nothing else has ever
been valid.
The "version 2 of the License, or (at your option) any later version"
language in the GPL copying file is not - and has never been - part of the
actual License itself. It's part of the _explanatory_ text that talks
about how to apply the license to your program, and it says that _if_ you
want to accept any later versions of the GPL, you can state so in your
source code.
The Linux kernel has never stated that in general. Some authors have
chosen to use the suggested FSF boilerplate (including the "any later
version" language), but the kernel in general never has.
In other words: the _default_ license strategy is always just the
particular version of the GPL that accompanies a project. If you want to
license a program under _any_ later version of the GPL, you have to state
so explicitly. Linux never did.
So: the extra blurb at the top of the COPYING file in the kernel source
tree was added not to _change_ the license, but to _clarify_ these points
so that there wouldn't be any confusion.
The Linux kernel is under the GPL version 2. Not anything else. Some
individual files are licenceable under v3, but not the kernel in general.
And quite frankly, I don't see that changing. I think it's insane to
require people to make their private signing keys available, for example.
I wouldn't do it. So I don't think the GPL v3 conversion is going to
happen for the kernel, since I personally don't want to convert any of my
code.
> If a migration to v3 were to occur, the only potential hairball I see is if
> someone objected on the grounds that they contributed code to a version of the
> kernel Linus had marked as "GPLv2 Only". IANAL.
No. You think "v2 or later" is the default. It's not. The _default_ is to
not allow conversion.
Conversion isn't going to happen.
Linus
Quality Hosting e3 Servers
Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications. It also includes any decryption codes necessary to access or unseal the work's output. Notwithstanding this, a code need not be included in cases where use of the work normally implies the user already has it.
I think that's what he's talking about, seeing as that's the only section I see having to do with encryption/private keys. I don't see how that requires developers to give out their private keys, but then again, I'm not privy to exactly how the Linux development process works.
Tluin natha Linux xxizzuss uriu olt bwael mon'tun.
http://software.newsforge.com/article.pl?sid=06/01 /17/1454213&from=rss
DRM clause I guess?
"Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications. It also includes any decryption codes necessary to access or unseal the work's output."
http://gplv3.fsf.org/draft
Nope! That's why copyright problems are so much more of a concern for the Linux kernel than they are for, say, HURD (because for HURD the copyright has to be assigned to the Free Software Foundation).
It's also why the Linux kernel is much more popular among developers than HURD (because people and companies can contribute to it and still keep their copyright).
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
Don't contributors assign copyright to some type of Linux foundation?
No. Linux kernel contributors retain their own copyright. This is frequently considered to be a good thing, as it means that no single group has copyright over everything, which means that no single group can change the license to e.g. BSD and start selling a proprietary version of Linux.
No, the copyright holders can give permission to re-release it as GPLv3 or Carl and Jabbas Artistic Hut Licence. The 'problem' with the Linux kernel, is that there are an extreme amount of copyright holders, so even if RedHat gave permission to re-release their code as GPLv3, that would not be anywhere near the complete kernel source code.
Dvorak on Doomtech
As the grandparent tried to put it, only the copyright holder can change the license on a piece of software.
If I create a program that counts to 100 and then exits, I can release it under any license(s) I want. If I release it GPL v2 and someone says, "Hey, Stine, management wants us to avoid GPL. Can we get it under BSD?", I can decide to release it under BSD if I so choose. You cannot decide to release my code under any other license than I have explicitly said that you can. If you want it under a different license, you have to ask my permission.
How can code released under the GPL be relicensed at all, even GPLv3?
1) Because the GPL license can optionally include the statement that it's covered by the GPL and/or any later version.
2) Because a copyright holder can relicense, dual-license and in general put any conditions he or she wants on their copyrighted work, including multiple different sets of conditions (licenses).
What you are asking is akin to saying "If someone lends a book to me on a set of conditions, how can they be allowed to lend it to someone else on different ones?".
If it can be, why can't I take it and license it with a BSD-style or completely closed source license?
Because you don't own the copyright.
He misinterpreted part of the GPLv3. The private key section says that if private keys are required for the code to function (in other words, your program will only load signed code) than you must make available a means to generate the signed code. The theory here is that certain hardware devices (*cough*TiVo*cough*) use GPLed software, but make it impossible to actually modify and run that software on their hardware device. In order to allow people to make changes and actually use those changes, you have to make available any private keys required to make the code actually run.
So if Mr. Torvalds has a private key that he uses to sign code, he is under no obligation to release that key to the public assuming that an end user can build and run the code without requiring the private key. You only have to release your private key if a third-party build of the software will not run without being signed by that key.
Now, another common misinterpretation that came up at the GPLv3 launch was that this meant that if you had set up your system to require signed code that you would have to make your private key available. This isn't the case. The only requirement is that a third party must be able to build and run the system without your private key. If this requires them to generate their own private key, that's perfectly acceptable.
If a GPLv3ed program cannot run without a specific private key, that private key must be made available. That's all the license says. Developers are not required to disclose private keys that they use to sign code.
You are in a maze of twisty little relative jumps, all alike.
If you are the copyright holder, you can re-release your code any time under any license you want. Now if every kernel contributor re-releases his code under GPLv3, then the whole kernel is re-released under GPLv3. Of course, the code you received under v2 would remain under v2; and if you have an old kernel containing code which isn't in the current one, and isn't relicensed, then you couldn't redistribute it under v3 either. Also I think GPLv2 and GPLv3 are not compatible, because e.g. the GPLv3 DRM stuff is an extra restriction, and GPLv2 explicitly disallows any additional restrictions, therefore you couldn't add that v2 code to the hypothetical v3-licensed kernel and distribute it.
IANAL however, and the above is just my understanding.
The Tao of math: The numbers you can count are not the real numbers.
People still using Internet Exlorer are really annoying.
Yes, that code is freely available at http://www.explorerdestroyer.com/
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
Of course, it's actually GPLv2 or later, because several source files have the "v2 or later" clause.
http://outcampaign.org/
There's no grey area. It's recommended but optional, and linux doesn't use it.
I am trolling
http://lkml.org/lkml/2003/4/24/19
The issue of private keys, DRM, code signing and the effect of GPL V3 has been in discussion for a long time. Linus has said he might in some circumstances sign binaries, in which case you would need the private key to regenerate the signed binary.
"And since I can imaging [sic] signing binaries myself, I don't feel that I can
disallow anybody else doing so."
Linus Torvalds, LKML April 2003
[Fuck Beta]
o0t!
They'll need to get it working first. They've had 15 years so far, with nothing to show for it...
Grab.
The Hurd would have to work first.
Game... blouses.
I think that he is confusing the private keys used to prove authenticity of code (usually binary) or media for restrictive purposes (DRM) and keys that prove authenticity of code (source) to protect against modifications.
Hopefully Torvalds will clarify this soon enough, but I got the impression that he was referring to companies which use private keys to implement DRM as "developers" (which makes sense -- engineers at these companies develop Linux code, and if the company's suits couldn't deploy DRM with this code then the engineers might be told to stop developing Linux code and develop for some other platform (VxWorks, *BSD, OpenServer, WinCE, whatever)). I could be totally misreading him, but perhaps he thinks this source of development is good for Linux.
Or perhaps he's objecting on principle .. hopefully he will clarify soon.
-- TTK
[RMS says] anyone using closed-source software (even in niches where no free equivalent exists) is guilty of immorality
That's simply not true, and amounts to a gross misrepresentation of RMS' position.
What he says is: "If you value freedom, you will resist the temptation to use a program that takes away your freedom, whatever technical advantages it may have."
Which is a different thing altogether.
If the kernel project guys really do not want GPLv.3-released code in their product because they consider it to be virally too restrictive, then fine. That is their prerogative and they don't need to include it. However, if the author of some highly-desired code really wants v.3 and doesn't care if it lands in the official kernel source tree, then the contrapositive applies: they can't force him to change it, either.
Remember, the GPL in its various forms is not restrictive; it is permissive. It starts with the default copyright restrictions allowing no copying of the code. It then generously gives permission to copy and use it while only asking for a few small acts of good behaviour in return.
Good to see I wasn't hallusinating about the "definition of a user" bit not being in there.
What most people *are* listing under the disadvantages is the DRM stuff. It is believed by many that it would be impossible to make a DRM decoding device using Linux without giving out enough information to break the DRM, thus preventing a huge potential market for Linux.
There's basically thre parts to the DRM section.
The first part says you can't use the GPLed code for illegal purposes. The GPL already sais that it's void if you'd be breaking the law by using it, so that bit's redundant,
The third bit says that you have to provide any necessary keys to the user if the user isn't already getting those keys some other way. But in a DRM application, you have to provide the keys to the user for them to decrypt the DRM: that's how DRM works, so that bit is actually irrelevant. Plus, it's covered in the definition of the source code, so it's redundant.
That leaves the bit in the middle. Which is interesting. What it mostly seems to be for is to ensure that if someone uses their access to the GPLed code to learn how to bypass the DRM, or to actually bypass the DRM, you can't sue them under the DMCA or similar laws for breaking or bypassing a security device.
also the method of reinstalling the software could change the keys so that the machine will no longer decode the "real" data but instead now be able to decode some other data that does not have any entertainment encoded in it
I believe that would violate the earlier section where it defines what it means by source code.
The purpose of Free Software is to provide _ALL_USERS_ 4 basic freedoms. Not just some... as such certain restrictions would have to apply.
Enter the GNU GPL
The GNU GPL is a Free Software license that fills the ring making it an unbreakable circuit of Freedom by stopping people from removing Freedom to anyone. This is a basic point of the GPL: Freedom for all, and that means that uses that mean removing Freedom are against the spirit of the GPL even if they are legally valid under GPLv2.
Enter the GNU GPL version 3
The new installment of the GNU GPL aims to close some loopholes against user Freedom, like better anti-patent and anti-DRM oppression regimes. The purpose is not about source code and it's uses but about user's Freedoms.
Finally
Your assessment that this breaks Freedom 0 is false on all accounts.
Freedom 0 is about running for any purpose. The abstract term use that you used is not about running the program but about publication of modified versions (Freedom 3).
Although at first sight V3 _seems_ to break Freedom 3, it breaks it in the very same way V2 already _seems_ to break. It imposes restrictions on the act of redistribution that forbid removing Freedoms to others.
Actually, the project and distribution you're referring to calls itself Debian GNU/Linux.
You misunderstand the argument for calling the system GNU/Linux. Allow me to summarize it.
Premises
Conclusion: The best name for the operating system in question is GNU/Linux.
I understand why someone who rejects any of these premises would disagree with the conclusion. If GNU were not the most significant component, it would be unfair to insist on including it in the system's name, even if one wanted to promote the philosphy. (We don't call Solaris or FreeBSD, GNU systems) If one does not feel it is important to spread the project's philosophy, there is little gained by including it in the name, even when one recognizes that GNU is the most significant component. Thus, it must be understood that the combination of these reasons and circumstances leads to the conclusion.
These are all GNU/Linux systems, Debian doesn't have more GNU software than the others. All of them use Linux as a kernel and the following vital GNU components:
In the case of Gentoo, GNU make, gcc, GNU binutils. and GNU patch should be viewed as vital too. :)
If you think carefully about what makes a system 'Unix like', you will appreciate why GNU is the most significant contribution. Another pos