| |||||||||||||
in practice, you get what you wantin practice, you get what you wantPosted Oct 6, 2006 9:44 UTC (Fri) by coriordan (guest, #7544)In reply to: simple but wrong answer: a DRM-allowing exception by mingo Parent article: Similar in spirit?
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.
(Log in to post comments)
you are missing the whole point of the GPL! Posted Oct 6, 2006 13:06 UTC (Fri) by mingo (subscriber, #31122) [Link] 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. 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] 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". 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. PermissionsLet'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. RestrictionsRestrictions 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.
|
|||||||||||||