Thursday, February 09, 2006

Linux could still adopt GPL v3

In an interesting twist to the GPLv3 story, Richard Stallman has mentioned that Linus has no say in what happens to the Linux kernel, and that the kernel developers are the ones who will decide over the licence. According to Linux-watch, the developers are split over the point. Another interesting point made in the article is that the problem is not really about DRMs, as previously reported, but that the problem is about the provision of making private keys available, present in paragraph 1 of the draft.

I must say that I am a bit surprised by the statement. As far as I know, Linus owns the trade mark to Linux, and he also owns the copyright of the Linux kernel, even if there are plenty of developers who work on it. After all, the GPL can only work if someone owns the copyright. This would pose an interesting question, what if the majority of kernel developers decide to move to GPLv3, and Linus does not? He can impose his view as he owns the copyright. Would developers release their own GPLv3 kernel? Would some of them sue Linus because they have contributed to the kernel?

I do not like what is happening. In my opinion GPLv3 has made things worse by splitting the non-proprietary community.


Andrea Glorioso said...


you might be interested to know that Linus Torvalds does not own the copyright over the totality of the Linux kernel - only on the parts written by him, or whose copyright has been transferred to him (but as far as I know, this is not requested nor enforced in the same way that the Free Software Foundation does with the GNU project). You can easily verify that by looking at Linux source code, where each file is usually introduced by a notice of the various copyrights applying thereof, i.e.:

{linux-source}/net/ax25/ax25_dev.c : (boldface added)

* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
* Copyright (C) Jonathan Naylor G4KLX (


More generally, the licensing notice in the source tree (the file COPYING) reads:

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.

(boldface added)

Therefore, it is possible, in principle, that some contributors to the Linux kernel will want to switch to the GNU GPL v3. What will this entail in practical terms is beyond my understanding at the moment (and probably in the future).

Keep up with your most interesting blog and best regards,

Andrea Glorioso

Andres Guadamuz said...

Thanks Andrea,

I was looking at the kernel source in my SuSE 10.0 distro and I could not find the copyright notices, only the files naming distributors.

This is still worrying. If the copyright is owned by a bunch of people, then a change in the licensing scheme will require the approval of all of the contributors (I have to see the provisions about upgrading the license). This would be a big mess. Hopefully they can all agree in one course of action, either GPLv2 or v3.

A split will only make Linux weaker.

Andrea Glorioso said...

I agree the situation is not ideal. The alternative is what the FSF does - requiring an assignment of copyright (if I remember correctly). The FSFE has tried to do a similar thing with the FLA (Fiduciary Licensing Agreement) but as far as I know, it didn't get a lot of success: it is hard to mix centralized control with the touted principles of distributiveness, horizontality, crowds-know-better etc etc (I'm not arguing one option is better than another, only that it's difficult to make them live together).

As regards upgrading the license, the file COPYING in standard linux source trees reads (end of introductory paragraph):

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.

Therefore I assume that each and every holder of copyright in the Linux kernel would have to be contacted in order to make the transition (assuming it would be desiderable).

Personally and as a person that is rather uninformed on the substance of GPL v3, I think the best option for Linux is to remain with GPL v2. I really doubt the advantages would outweight the costs of switching.

David M said...

This was exactly the kind of problem I was forecasting in the paper that I gave at the AHRB copyright conference where the purported benefits of commons-based peer production are destroyed if that commons is but a simulacra of a commons (see also Libre Commons for a similar critique).

The privatisation of a distributed collective project will eventually run into problems when the project requires unpicking to move on for whatever reason. I think that Stallman is making some important and critical moves in the protection of the Free Software 'commons' by GPLv3 which Torvalds completely fails to understand or care about. Somehow the FSF need to address the fragmentation possible by license upgrades to prevent a balkanisation when threats to the integrity of the FSF commons are made (i.e. through DRM). This may well be an unforeseen and unintended consequence of the all-conquering power of the GPL copyleft clause that Moglen was so delighted about. I suggest that they think carefully about the future move to GPLv4 whilst drafting, as well as considering legacy code. Otherwise we'll all be going through this again in a few years.

In any case, Torvalds has for a long time tried to portray a 'sensible' or common-sense approach whilst harbouring a great dislike for Stallman (which I think sometimes verges on the pathological) but here the question really needs to be asked as to whether he is acting for the good of the community of Linux developers or to win some petty battle. One reason for suspicion is that he speaks as if he is king of the castle, and doesn't so far, seem to interested in the democratic voice of all the developers.



Andrea Glorioso said...

Perhaps Torvalds' attitude (which I am neither endorsing nor criticising) could be best framed by considering that Linux development process, notwithstanding the claims popping up here and there, can hardly be defined as democratic - you all know the term "benign dictatorship" used to describe the internal dynamics thereof. No matter how benign, a dictatorship is still a dictatorship; and sometimes, for specific kinds of objectives, dictatorships are more efficient and effective than democracies.

P.S.: David, is it possible to have a copy of the paper you mention?

David M said...

for specific kinds of objectives, dictatorships are more efficient and effective than democracies

This is a very very scary thing to say Andrea. Efficiency is surely not the key consideration here, and even if it were I would be suspicious of claims that 'just because the trains run on time' it is inherently better. Sometimes inefficiencies in governance, politics and yes, even business, can be a pause to consider where we are going and that should be done...


ps. As soon as I get a PDF I'll forward the paper onto you.

Andrea Glorioso said...


my comment should not be taken as endorsing dictatorship as a form of government/governance; and I agree that inefficiences are in a way an efficient response to the risks that centralized decision-making processes imply. Mine is a mere re-statement of an empirically observed fact, that in very specific situations and for specific goals (for example, developing a computer program with certain features in an allotted amount of time, spending a fixed amount of money) democracy is not always the most efficient decisional system. This is, I think, confirmed by the fact that decisional and management processes in most firms - to make a single example - are hardly "democratic".

The reason why I mentioned the dichotomy between dictatorship and democracy is because I keep on hearing people making the association between Open Source "methods" and "democracy", arguably without realizing that in a lot of Open Source Software projects there is little democratic structure in place. This is not necessarily a bad thing, since the goal of an Open Source Software project is rather different from the goals that a state - again, taking a single example - ought to have.

The tension between these two poles of the political spectrum is all the more interesting, considering the claims made against the Free Software Foundation that the drafting process of the GNU GPL v3 is not sufficiently democratic. There is a very subtle balance to be struck between producing a license in a reasonable time, and making sure that all the stakeholders have a possibility to influence the process.



P.S.: thanks for the paper, I will be looking forward to reading it.

David M said...

I, of course, agree with many of your comments about the links between open source and democracy. But remember that democracy is also linked to ideals of transparency (something o/s has a lot of) and participatory governance (which in some instances is also true). Voting for source code changes is not quite what I mean in terms of democracy (this more accurately would be called aggregative democracy) rather I am talking in terms of deliberative democracy. I think this is the aspect that people think is interesting esp. considering the widely held view that making 'things' and democracy cannot go hand in hand (indeed that is why many political theorists bracket out the economy when they are talking about political change).

Andrea Glorioso said...

While I agree that Open Source Software is, generally speaking, more transparent than other ICT fields (although we should understand what is the object of transparency - practices on access to the development process? information as embodied in the source code? knowledge about what the source code actually means?) I am not sure I understand what you mean by "deliberative democracy" - could be a language limit (I'm not an English mothertongue, as you might have suspected). Could you elaborate on that, maybe private mail if this conversations starts to drift too much off-topic with regards to the Technollama blog?

Andrea Glorioso said...

David, I forgot that comments here do not automatically include email addresses - mine is andrea [at] digitalpolicy [dot] it (usually substitution rules apply).

David M said...

Hi Andrea,

Deliberative notions of democracy are linked to the idea that citizenship should be reflected in the processes we undertake in order to come to some form of decision-making. Principally they highlight the importance of discussion and debate (hence deliberative), a term drawn particularly from Habermas' concept of discourse ethics and communicative action. Whilst I am somewhat critical of the 'consensual claims' made by Habermas (I prefer Laclau & Mouffe) I think that Habermas does highlight an important educative moment in a deliberative form of democracy.

Some good references might be:

Barber, B. R. (1984). Strong Democracy: Participatory Politics for a New Age. California: University of California.

Habermas, J. (1985). Theory of Communicative Action Vol 1: Reason and the Rationalisation of Society. London: Beacon Press.

Sclove, R. E. (1995). Democracy and Technology. London: Guildford Press.

Wilhelm, A. G. (2000). Democracy in the Digital Age: Challenges to Political Life in Cyberspace. London: Routledge.