This means that when the code went GPLv1-->GPLv2, the transition was permissible. Linux v1.0 shipped with the GPLv2. 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 GPLv2. 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 licensable 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 GPLv3 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.

Linux has been v2-only for a long time, long before there was even any choice of licenses. That explicit “v2 only” thing was there at least for 2.4.0, which is more than five years ago. So this is not some sudden reaction to the current release of GPLv3. This has been there quite independently of the current GPLv3 discussion.

If you disagree with code you write, you can (and always have been able to) say so, and dual-license in many different ways, including using the “or later version” language. But that doesn't change the fact that others (a lot of others) have been very much aware of the “v2 only” rule for the kernel, and that most of the Linux kernel sources are under that rule.

People argue that Linux hasn't specified a version, and that by virtue of paragraph 9, you'd be able to choose any version you like. I disagree. Linux has always specified the version: I don't put the license in the source code, the source code just says: “Copyright (C) 1991-2002 Linus Torvalds”, and the license is in the COPYING file, which has ALWAYS been v2. Even before (for clarification reasons) it explicitly said so.

In other words, that “if no version is mentioned” simply isn't even an argument. That's like arguing that “if no license is mentioned, it's under any license you want”, which is crap. If no license is mentioned, you don't have any license at all to use it. The license AND VERSION has always been very much explicit: linux/COPYING has been there since 1992, and it's been the version_2 of the license since day 1.

People can argue against that any way they like. In the end, the only way you can really argue against it is in court. Last I saw, intentions mattered more than any legalistic sophistry. The fact that Linux has been distributed with a specific version of the GPL is a big damn clue, and the fact that I have made my intentions very clear over several years is another HUGE clue.

I don't see any real upsides to GPLv3, and I do see potential downsides. Things that have been valid under v2 are no longer valid under v3, so changing the license has real downsides.

Quite frankly, if we ever change to GPLv3, it's going to be because somebody convinces me and other copyright holders to add the “or any later license” to all files, just because v3 really is so much better. It doesn't seem likely, but hey, if somebody shows that the GPLv2 is unconstitutional (hah!), maybe something like that happens.

So I'm not entirely dismissing an upgrade, but quite frankly, to upgrade would be a huge issue. Not just I, but others that have worked on Linux during the last five to ten years would have to agree on it. In contrast, staying with GPLv2 is a no-brainer: we've used it for almost 15 years, and it's worked fine, and nobody needs any convincing.

And that really is a big issue: GPLv2 is a perfectly fine license. It has worked well for us for 14 years; nothing really changed with the introduction of GPLv3. The fact that there is a newer license to choose from doesn't detract from the older ones.

DRM is something worth fighting, but we need something that attacks the root problem, not its symptoms. In comparison, GPLv2 was indeed successful in that it attacked the root problem of software distribution freedom. How it may leverage that by introducing restrictions on symptoms of another problem still evades me.

Side note: the reason GPLv2 is so successful at fighting the root problem of using copyright to fight restrictive copyrights is that it makes “interesting material” available under a license that forbids further restricting it.

I would suggest that anybody who wants to fight DRM practices seriously look at the equivalent angle. If you create interesting content, you can forbid that content ever be encrypted or limited.

In other words, I personally think that the anti-DRM clause is much more sensible in the context of the Creative Commons licenses, than it is in software licenses. If you create valuable and useful content that other people want to be able to use (catchy tunes, funny animation, good icons), I would suggest you protect that content by saying that it cannot be used in any content-protection schemes.

Afaik, all the Creative Commons licenses already require that you can't use technological measures to restrict the rights you give with the CC licenses. The “Share Alike” license in particular requires all work based on it also to be shared alike—that is, it has the “GPL feel” to it.

If enough interesting content is licensed that way, DRM eventually becomes marginalized. Yes, it takes decades, but that's really no different at all from how the GPL works. The GPL has taken decades, and it hasn't “marginalized” commercial proprietary software yet, but it's gotten to the point where fewer people at least worry about it.

As long as you expect Disney to feed your brain and just sit there on your couch, Disney & Co. will always be able to control the content you see. DRM is the smallest part of it—the crap we see and hear every day (regardless of any protection) is a much bigger issue.

The GPL already requires source code (that is, non-protected content). So the GPL already does have an anti-DRM clause as far as the software is concerned. If you want to fight DRM on non-software fronts, you need to create non-software content, and fight it there.

I realize that programmers are bad at content creation. So many programmers feel that they can't fight DRM that way. Tough. Spread the word instead. Don't try to fight DRM the wrong way.

The point is not only getting access to the source code, but also being able to change it. Being able to freely study the code is only half of the beauty of the GPL. The other half, being able to change it, can be very effectively stopped using DRM.

No it cannot.

Sure, DRM may mean that you cannot install or run your changes on other people's hardware. But, it in no way changes the fact that you got all the source code, and you can make changes (and use their changes) to it. That requirement has always been there, even with plain GPLv2. You have the source.

The difference? The hardware may run only signed kernels. The fact that the hardware is closed is a hardware license issue. Not a software license issue. I'd suggest you take it up with your hardware vendor, and quite possibly just decide not to buy the hardware. Vote with your feet. Join the OpenCores groups. Make your own FPGAs.

And it's important to realize that signed kernels that you can't run in modified form under certain circumstances is not at all a bad idea in many cases.

For example, distributions signing the kernel modules (that are distributed under the GPL) that they have compiled, and having their kernels either refuse to load them entirely (under a “secure policy”) or marking the resulting kernel as “tainted” (under a “less secure” policy) is a GOOD THING.

Notice how the current GPLv3 draft pretty clearly says that Red Hat would have to distribute its private keys so that people sign their own versions of the modules they recompile, in order to re-create their own versions of the signed binaries that Red Hat creates. That's INSANE.

Btw, what about signed RPM archives? How well do you think a secure auto-updater would work if it cannot trust digital signatures?

I think a lot of people may find that the GPLv3 “anti-DRM” measures aren't all that wonderful after all.

Because digital signatures and cryptography aren't just “bad DRM”. They very much are “good security” too.

Babies and bathwater....

So taking open software and closed hardware and combining it into something that I cannot modify is okay by you?

But you CAN modify the software part of it. You can run it on other hardware. It boils down to this: we wrote the software. That's the only part I care about, and perhaps (at least to me) more importantly, because it's the only part we created, it's the only part I feel we have a moral right to control.

I literally feel that we do not—as software developers—have the moral right to enforce our rules on hardware manufacturers. We are not crusaders, trying to force people to bow to our superior God. We are trying to show others that cooperation and openness works better.

That's my standpoint, at least. Always has been. It's the reason I chose the GPL in the first place (and it's the exact same reason that I wrote the original Linux copyright license). I do software, and I license software.

And I realize that others don't always agree with me. That's fine. You don't have to. But I licensed my project under a license I agreed with, which is the GPLv2. Others who feel differently can license under their own licenses. Including, very much, the GPLv3.

I'm not arguing against the GPLv3.

I'm arguing that the GPLv3 is wrong for me, and it's not the license I ever chose.

Then I have to ask, why GPL and not a BSD license? GPL is after all, forcing our beliefs onto anyone who wishes to benefit from our work.

Yes, a lot of people see the GPL as a “crusading” license, and I think that's partly because the FSF really has been acting like a crusader.

But I think that one of the main reasons Linux has been successful is that I don't think the Linux community really is into crusading (some small parts of it are, but it's not the main reason). I think Linux has made the GPL more “socially acceptable”, by being a hell of a lot less religious about it than the FSF was.

So to me, the point of the GPL is not the “convert the infidels” logic, but something totally different—“quid pro quo”.

This is where I started out. My initial reason for my original license (which was also “you must make changes available under the same license”) was not crusading, but simple reciprocity. I give out source code—you can use it if you reciprocate.

In other words, to me, the GPL “give back source” is an issue of fairness. I don't ask for anything more than I give. I ask for source code and the ability to incorporate your changes back into my use, but I don't want to limit your use in any way.

So in my world view—not as a crusader—the GPLv2 is fair. It asks others to give back exactly what I myself offer: the source code to play with. I don't ask for control over their other projects (be they hardware or software), and I don't ask for control over copyrights (in the kernel, people are encouraged to keep their copyrights, rather than sign them over to me).

I only ask for exact reciprocity of what I give: the license for me to use freely the changes to source code that I initiated.

The GPLv3 fundamentally changes that balance, in my opinion. It asks for more than it gives. It no longer asks for just source back, it asks for control over whatever system you used the source in.

See? I think the GPLv3 makes perfect sense as a conversion tool. But as a “please reciprocate in kind” tool, the GPLv2 is better.

Now, my very earliest original license (and the GPLv2) fit my notion of reciprocity, and as mentioned, that was the reason I “originally” selected that over the BSD license. However, over time, having seen how things evolve, I've come to appreciate another aspect of the GPLv2, which is why I would never put a project I personally really cared about under the BSD license—encouraging merging.

I've come to believe that the BSD license is not a “sustainable” license, because while it encourages (and allows) forking even more than the GPL does, it does not encourage merging the forks back.

And I've come to the private conclusion that the real value of a fork is lost if you don't have the ability to merge back the end result. Not that all forks should be merged back—most forks are dead ends—but the firm ability to merge back if it turns out to be something other than a dead end.

The GPL guarantees you the right to both fork and merge the result back—equally, and on both sides. That makes it sustainable. In contrast, the BSD license encourages forking, but also allows for not merging back, and that means that if the project ever gets to the point where there are economic or political reasons to diverge, it will eventually diverge, and there is no counteracting force at all.

Now, not all projects have any economic incentives to diverge. There are good reasons to stay on one base, and the costs of forking are bigger than the advantages. So projects like Apache and Sendmail have worked fine—the pain of being different (when you're “just” a network service) is generally much higher than the gain of differentiation.

But just about anywhere else, the “cohesion” of a BSD-licensed project is just lower. You'll have people make a commercial release of it, and they'll spend a bit more effort on it, and eventually the original freely licensed project will become immaterial.

So long-term, I believe that a GPL'd project is stabler. I believe, for example, the fact that Wine switched over to the LGPL (which shares a lot of the cohesion argument) was a very important decision for the project, and that it would eventually have otherwise become irrelevant, and the commercial users of the BSD-licensed code would have taken over. But note that my second reason is not why I began using the GPLv2, and that it's also equally true of the GPLv3 and LGPL. Anyway, there are other reasons I like the GPLv2. It's a “known entity” and it's been around for a long time.

In fact, even in -92, when I switched to the GPL, that “known factor” part was a major secondary reason for switching. I could have tried to just change my own license—but I felt it was an advantage to be something that people knew about, and not have to explain it and check it with lawyers. The fact that the GPLv2 was still “young” back then was nothing compared to how wet behind the ears my own license was.