Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

you are missing the whole point of the GPL!

Posted Oct 6, 2006 14:31 UTC (Fri) by sepreece (subscriber, #19270)
In reply to: you are missing the whole point of the GPL! by mingo
Parent article: Similar in spirit?

I agree with mingo. The current language is asymmetrical - it says, in effect, "restrictions are statements of deep philosophical import and must be retained; permissions are minor preferences that you can remove".

I don't see any reason why granting an extra permission should be considered less important to the author than making an extra restriction.

(Log in to post comments)

Posted Oct 6, 2006 15:05 UTC (Fri) by mingo (subscriber, #31122) [Link]

Yes. But the assymetry gets worse than that: there are permissions that are "more equal" than other permissions: the core permissions of the GPLv3 - which (of course) no-one is allowed to remove!

All this plug-in language makes sense for small details that no-one cares deeply about but which have to be adhered to for legal reasons. It very much does not work for "details" that people feel strongly about and which details people want to survive in works that are based on theirs.

2 days later, the answer

Posted Oct 8, 2006 14:42 UTC (Sun) by coriordan (guest, #7544) [Link]

It was a good question, and it took me two days to think of the answer, but here it is.

Tivoisation _could_ be a global catastrophy for free software. If, in the future, the majority of personal computers adopt tivoisation, free software will be failing FSF's goal of giving people freedom, and it will be failing the collabration-of-many-tinkerers goal of the anti-GPLv3 Linux hackers.

(The Tivo doesn't allow tinkering, so Linux gains the Tivo employees as collaborators but loses the Tivo owners. Tivo on its own is no catastrophy, but the widespread implementation of tivoisation could be.)

The Linux kernel developers who wrote the anti-GPLv3 doc have disregarded FSF's position that users of Tivos should be free to modify the software and run the modified version on their Tivo. Similarly, they can disregard the catastrophy scenario I mention. They can say it's unlikely and they can point to economic or engineering reasons for why they believe it is unlikely. But, it is possible, and if the situation changes and that scenario seems more likely, the Linux kernel developers (whoever they are at the future point in time when the situation changes, if it changes) and the free software community must have an escape route. They must have a way to raise a protection against the problem.

Being able to remove that extra permission at a later date is an essential escape route.

(Also, the nice thing about having an escape route is that it makes it less likely that an escape will have to be made. When a threat sees that escape is easy, they are less likely to mount an attack. This thinking was the basis of the "liberty or death" clause of GPLv2)

Asymmetry

Posted Oct 11, 2006 2:33 UTC (Wed) by sanjoy (subscriber, #5026) [Link]

I don't see any reason why granting an extra permission should be considered less important to the author than making an extra restriction.

The asymmetry is because the GPL is a copyleft license. The "you can remove them" aspect of permissions is not new to the GPLv3. Under the GPLv2, the result would be the same except handled less conveniently. And extra restrictions are forbidden by the GPLv2; the GPLv3 slightly weakens that requirement (and hence weakens the asymmetry). I'll discuss each aspect in turn.

Permissions

Let's assume that the new contribution is itself not a derivative work or a 'covered work' (in the sense of the GPLv3). If it is, then the author probably cannot add permissions under the GPLv2 or GPLv3, so this discussion would be irrelevant. But even when the new contribution is not a covered work, the combination of new contribution and distributed work is a covered work and subject to the license.

Under the GPLv2, an author would write his or her contribution, and could distribute it under the GPLv2 (by itself or combined with the original work) and also distribute it by itself under a GPLv2+permission license: a multiple-licensing privilege available to the copyright holder. Special cases of GPLv2+permission include distributing under a new-style BSD license or under a public-domain license. Recipients could use it under either license. If they incorporate it into the original work, they would use the vanilla GPLv2 (with no extra permissions). So, the permissions have just been removed. The contribution is still available from the author with the extra permissions, just not available with those permissions when combined with the original work. (Probably the notice of extra permissions, a "notice of licensing", would have to be retained in the combined source code, but the combined work would be distributed under the vanilla GPLv2, so the extra notice would have no effect.)

The GPLv3 makes this process more convenient for the author and downstream recipients. The recipients can, if they want to, maintain the author's extra permission in the source file they distribute, and recipients farther downstream can extract it with those permissions. Whereas with the GPLv2 they would have to find the source distributed by the author.

Restrictions

Restrictions are already (in the GPLv2) treated differently from the above permission scenario, in that the GPLv2 already forbids any restrictions. For example, it forbids a requirement that secondary downstream recipients pay the author $10/copy.

The GPLv3 relaxes this asymmetry slightly by allowing a few specified restrictions. Thereby common, non-show-stopping restrictions, such as from the Apache License, do not make a work GPL incompatible.