simple answer: a DRM-allowing exception [LWN.net]

simple but wrong answer: a DRM-allowing exception

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

Section 7a gives every project the infrastructure to remove that provision (by granting an exception).

Then we can all benefit from the other improvements in GPLv3, the compatibility issue will be solved, no need for any rift or split.

What you are missing is the "detail" in 7c that anyone remove any such extra permission!

See section 7c of the GPLv3 draft:

  c. Terms Added or Removed by You.

  When you convey a copy of a covered work, you may at your option
  remove any additional permissions from that copy, or from any part of
  it.

'Conveying' is defined in Section 0 as:

  To "convey" a work means any kind of propagation that enables
  other parties to make or receive copies, excluding sublicensing.

I.e. remove the extra permission from the source and redistribute the result - the extra permission is gone!

I.e. the 'extra permissions' language of the GPLv3 makes extra permissions second-class citizens compared to the "pure" values expressed in the GPLv3. Extra permissions in the GPLv3 are like old paint: they can be removed by anyone, anytime, for any reason.

So by moving the kernel to GPLv3+DRM-exception the kernel developers would give blanket permission to anyone in essence to relicense the kernel to a license we dont agree with on many grounds. How is that fair in your opinion?

Your suggestion that this is a "simple" solution acceptable to those who oppose the fallout of the GPLv3's DRM language on moral, practical and legal grounds is misguided at best.

(And even if extra permissions survived modification and derivation, there would be other fundamental assymetries making GPLv3+DRM-permission works a second-class citizen. I dont want my GPL-ed work to be a second-class citizen, to be slowly assimilated into the "pure" GPLv3 codebase. I'd prefer a GPLv3 that is unconditionally acceptable to the overwhelming majority of contributors.)

in practice, you get what you want

Posted Oct 6, 2006 9:44 UTC (Fri) by coriordan (guest, #7544) [Link]

Lets look at how it works. There's me, the Linux devs, and Tivo.

The Linux devs accept GPLv3+DrmException code into their trees. I download a copy, make my improvements, and publish my version with the exception removed.

Enter Tivo. Tivo has the option of Linux under GPLv3+DrmException, or CiaranSuperLinux under GPLv3. They go for the former.

The only effect is that Tivo lose the benefit of the work of a guy who doesn't want his code to be incorporated into the software of hardware manufacturers who are trying to block users from running modified software.

The wishes of the Linux devs are respected, and my wishes are respected for my non-integrated patch.

Important point: the lack of an exception will only effect my modifications (because the vanilla version will be available elsewhere with the exception), and it will only affect my modifications if I don't want that exception on my modifications.

you are missing the whole point of the GPL!

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

What you suggest is absurd.

So by your logic it would be acceptable to remove a "permission" from the GPLv2, and modify a GPLv2-ed work with that permission removed?

I consider that permission an integral portion of the contribution that i do and did. I dont accept narrower nor broader terms. Your suggestion that our objection to the incorrectness of the DRM language can be rectified by making that language optional - but on the other hand can be removed by anyone, allows the co-opting of our code under conditions that we dont agree with!

That's what the whole GPLv2 is about. You dont get to remove the permission of "allow all others you distribute this binary to to receive the source code too" either...

you are missing the whole point of the GPL!

Posted Oct 6, 2006 14:31 UTC (Fri) by sepreece (subscriber, #19270) [Link]

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.

you are missing the whole point of the GPL!

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.