GPLv3 and the kernel

One of those is that there will be no GPLv3 at all for another year. What is being circulated is a draft, and, if the Free Software Foundation is responsive to comments at all, there are likely to be changes. There is little point in debating the adoption of a license which does not exist, which is why most kernel developers have stayed out of the current discussion. While a certain ZDNet columnist engaged in a humorous exercise in wishful thinking:

The simple fact is that most developers are taking a quiet "wait and see" approach for now. And, now or later, there seems to be little appetite for a big licensing fight.

Another thing to keep in mind is that Linus can change his mind, even after seemingly painting himself into a corner with an absolute statement. One of your editor's favorite Linus pronouncements was issued almost exactly seven years ago. In response to a query on how to set up an i386 box with 4GB of memory, Linus stated:

Less than one year later, Ingo Molnar's high memory patch was merged for 2.3.23. The lesson is clear: even when Linus says "never," the right argument can change his mind. And, in fact, Linus has left the door open to just that possibility:

The door may not be open very far, but neither is it barred shut.

Then, there's the fact that, as Linus points out, it is not just his decision. Much code in the kernel is explicitly licensed with the FSF's recommended "or any later version" language; that code will be distributable (separately from the kernel) under the GPLv3 in any case. Relicensing the GPLv2-only code, however, would require the assent of every developer who holds copyrights on that code. Given that copyrights in the kernel are widely distributed and tracked by nobody, obtaining that permission would be a significant challenge.

Or would it? Linus added the explicit GPLv2 language for the 2.4.0-test8 release. Another significant kernel contributor (Alan Cox) is unconvinced that this language will get in the way:

If this view prevails, the number of copyright holders who would have to agree to a relicensing would be much reduced, and the problem might just become tractable.

The relicensing discussion is premature now, and it can be expected to fade away. But it will certainly come back. The anti-DRM provisions found in GPLv3 resonate strongly with many developers, and, to many of those, said provisions only clarify a requirement which, they believe, is already present in GPLv2. To these developers, locking Linux into a DRM-equipped machine takes away the freedom that the GPL promised in the first place and is an abuse of the software they have contributed to the world. The opportunity to end that abuse with a license change will be appealing; expect to see developers pushing for that change after the license becomes official.

Linus, however, has made it clear in the past that locking down systems with signed kernels is just fine with him. He reiterated that point recently:

So blue-eyed Linus is unlikely to agree to a license change on the basis of the anti-DRM provisions. But it is possible that other factors could eventually bring about a change of heart (and license). For example, many of the changes in GPLv3 are motivated by the requirements of legal systems in various parts of the world; if GPLv2 turns out to be hard (or impossible) to enforce somewhere, a shift to GPLv3 could become more appealing. Such a change, however, cannot occur before the license moves out of the comment period and is adopted officially by the FSF. Until then, any predictions on whether the kernel will ever shift to the GPLv3 should be taken with a grain of salt.

:0
* ^X-Mailing-List:.*linux-kernel@vger\.kernel\.org|\
  ^X-Mailing-List:.*git@vger\.kernel\.org

  {
   :0
   * ^From:.*torvalds@osdl\.org
   ! forwarding-address@example.com

   :0
   /dev/null
  }