| |||||||||||||
|
| |||||||||||||
GPLv3 & additional permissions/restrictionsGPLv3 & additional permissions/restrictionsPosted Sep 26, 2006 11:06 UTC (Tue) by michich (subscriber, #17902)In reply to: GPLv3 & additional permissions/restrictions by mingo Parent article: Some GPLv3 clarifications from the FSF
What would be fair was if the process of "extensions" was fundamentally symmetric (fair): if i could take any GPLv3 code and incorporate it back into my GPLv3+permissions project. That would be unreasonable, because then you could effectively do whatever you wanted with any GPLv3 code. Example: 1. You start a dummy GPLv3 project with an additional permission which says something like "Anyone can distribute derivative works of this program as proprietary software". 2. Then you grab any GPLv3 sources you like and copy them into your project. 3. You distribute your project to a friendly proprietary software-making company of yours. 4. The company can now do what it wants with the code that was supposed to stay free.
(Log in to post comments)
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:23 UTC (Tue) by mingo (subscriber, #31122) [Link] That would be unreasonable, because then you could effectively do whatever you wanted with any GPLv3 code.Yes - i would not suggest that as a license text. And that's why i think the GPLv2 method of having a single body of code is better. Trying to add "extensions" inevitably leads to either balkanisation, inequality of treatment or to a loss of meaning of those extensions. What we should recognize is the fundamentally free-spreading nature of source code within a GPL ecosystem. We take and add code freely. Xen for example includes big chunks of the Linux kernel and thus it also carries my copyrights for example - despite me never having directly contributed to the Xen supervisor itself. So any attempt to recognize some "extensions" inside a GPL body of code is fundamentally futile, because there's just no fair way to keep things from "infecting each other". That's the /goal/ in fact of the GPL: let free software be used and reused within itself. We should only take a look at LGPLed projects: they have constant trouble linking to GPL-ed libraries (for example readline), and they obviously cannot freely take GPL-ed code. So LGPLed projects are constrained to a few well-selected areas where the LGPL is an absolute technological necessity - and even those projects are often isolated from the rest. And even then it's still quite a hassle. Also, flames whether something should be GPL or LGPL are not uncommon. And that's just a _single_ license split, not dozens (or more)! We should also realize that maintaining a list of "extensions" (of various granularity which might be as highly granular as per-function) is fundamentally cumbersome for developers to do. And because the GPLv3 allows the /free dropping/ of additional permissions, what do you think most lazy developers like me will do: i'll just drop them, accidentally most of the time. So to maintain a clean body of GPLv3+permissions code will be a constant hassle against the 1) fundamental inequality hardcoded into the GPLv3 2) human laziness. I'd not voluntarily pick a battle against any of these factors, let alone both of them ;)
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:33 UTC (Tue) by alexbk (subscriber, #37839) [Link] Perhaps these two factors could be defeated by the the fact that GPLv3+permissions code has muchbigger license compatibility. Might be worth it for all that extra non-GPL code you can combine it with :)
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:39 UTC (Tue) by robilad (guest, #27163) [Link] GPLv3 just codifies existing practice in this area, where large projects with many stake holders like gcc, or the Linux kernel have used their specific exceptions to the GPL to make sure recepients of the code receive additional permissions that are not in the GPLv2, per se, or clarify the recepients obligations.
That has been going on since 1992, or so.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:49 UTC (Tue) by mingo (subscriber, #31122) [Link] GPLv3 just codifies existing practice in this area, where large projects with many stake holders like gcc, or the Linux kernel have used their specific exceptions to the GPL to make sure recepients of the code receive additional permissions that are not in the GPLv2, per se, or clarify the recepients obligations.Would you mind to elaborate on what kind of additional permission there is in the Linux kernel's license? I'm not aware of any, and i'm a copyright holder of the Linux kernel.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 12:05 UTC (Tue) by robilad (guest, #27163) [Link] Thanks for the correction, Ingo.
I may be completely off base here, but I was under the impression that the kernel had a clarification/permission for exported interfaces facing glibc that their use does not consititute a derivative work of the GPLd kernel?
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 12:21 UTC (Tue) by robilad (guest, #27163) [Link] I meant the text
NOTE! This copyright does *not* cover user programs that use kernel
on top of GPLv2 in the file COPYING in the Linus kernel. I think it serves to clarify the licensing status of the kernel regarding works using it by normal means through an addition to the GPL.
I would argue that such a permission in the kernel has not led to dire consequences that balkanisation predicts. I am unaware of any Linux forks without such an addition to the GPL.
I would argue that's for a simple reason: removing freedoms that have been granted before by yourself and other generous contributors to the kernel would only leads to a less useful code base, and serve to shut out existing stake holders. As such, the forked code base would be less useful than the existing project, so no such forks would be as successful.
I'd furthermore argue that a similar argument would hold for any tightening of licensing conditions by removing additional permissions from GPLv2/v3 licensed code.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 12:27 UTC (Tue) by mingo (subscriber, #31122) [Link] that was never meant to be an additional permission. See: this collection of emails from Linus.What constitutes derived work isnt Linus' job to determine: it's a matter of law. (the GPLv2 is pretty silent on the issue so what controls is copyright law)
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 13:21 UTC (Tue) by robilad (guest, #27163) [Link] Oh, I fully agree with that, I'm just pointing out that the kernel itself has an additional note on top of the GPLv2 regarding the desired interpretation of the permissions in the license. There is nothing wrong in that, and I don't mean to nitpick whether it's a mere clarification, or an additional permission, or something else.
My point above was that some large projects find it useful to clarify or extend the permissions contained in their GPLv2-based licensing terms through such additions to the GPLv2. That practice has so far not had the negative consequences alluded to in gregkh's piece, despite going on for a long time.
Open Source seems quite alive, actually. :)
You can't have it both ways. Posted Sep 26, 2006 11:47 UTC (Tue) by hummassa (subscriber, #307) [Link] Either the additional terms clause 7 will cause "balkanization" or it will cause "trending-to-purification", and your argument is just swinging between those instances.
You are right that clause 7 is biased towards "purification". And that is intentional IMHO, so "balkanization" is less likely to occur. If you can compatibilize "things with additional permisisons" with "things with no additional permissions" under the "things with no additional permissions" umbrella, then balkanization is not occurring (at least from the point of view of "things with no additional permissions".) OTOH, if you can compatibilize "things with (some, restricted) additional requirements" with "things with no additional requirements" under the umbrella of "things with additional requirements, that don't apply to the whole body equally". Which, although not as simple, is not very different from the situation today, applied to multi-holders, multi-license systems like the the linux kernel (that has BSD/2clauses code, BSD/3clauses code, v2-only code, v2+ code...)
So, yes, there is a bias in clause 7 towards the distribution of works under the "pure" v3 conditions. But this is really intentional.
You can't have it both ways. Posted Sep 26, 2006 12:00 UTC (Tue) by mingo (subscriber, #31122) [Link] So, yes, there is a bias in clause 7 towards the distribution of works under the "pure" v3 conditions. But this is really intentional.And dont you see a fundamental problem with that approach, if what to you is an "additional permission" is another person's "core value"? Dont you think the FSF's answer: "oh, just use extensions by the way" is insufficient to such people, because a fundamental bias towards a "pure" set of morals is codified? Dont you think that such an answer could be outright offensive as well, not just plain insufficient, if that "core value" is also a "belief" of that person, and if that person sees the real question of "whether we should be dictating morals to begin with" being (it appears to me, intentionally) dodged and a non-answer "use extensions" answer being provided?
You can't have it both ways. Posted Sep 26, 2006 14:09 UTC (Tue) by Zack (guest, #37335) [Link] >And dont you see a fundamental problem with that approach, if what to you is an "additional permission" is another person's "core value"?
If this person wants to use a license to propagate these core values and make them non-removable she should not use the GPL.
The core values the GPL set out to protect are the four software freedoms.
I'm sure there are lots of people who would rather not have their software used by the for example the military or in baby mulching machines, but it is not the job of the FSF to steer the GPL in that direction.
>Dont you think the FSF's answer: "oh, just use extensions by the way" is insufficient to such people, because a fundamental bias towards a "pure" set of morals is codified?
To my understanding the additional permissions are not there to address new ethical questions, but simply to make it easier to distribute software using code that is licensed under a free but GPL-incompatible license. (such as the CDDL, which would allow for GNU/Solaris)
The GPL3 is the vision of the FSF as to how to defend the four freedoms they set out to defend. If the four freedoms are a '"pure" set of morals', then yes, there is a fundamental bias towards that. In fact, it is the very foundation of the GPL.
>Dont you think that such an answer could be outright offensive as well, not just plain insufficient, if that "core value" is also a "belief" of that person, and if that person sees the real question of "whether we should be dictating morals to begin with" being (it appears to me, intentionally) dodged and a non-answer "use extensions" answer being provided?
Only if that person is offended that the FSF will not alter their original goal at her behalf.
I would be very disappointed if the FSF would codify new ethics into the GPL even if I would completely agree with the goal these new restrictions would aim for.
<AOL>I agree</AOL> Posted Sep 26, 2006 14:49 UTC (Tue) by hummassa (subscriber, #307) [Link] Zack responded to mingo exactly the way I would. Thank you.That's the point: If you want to GPL your work (and make it automagically compatible with lots of things "in the wild" to mix and match) those are the rules. And the rules exist to protect the Four Freedoms.
You can't have it both ways. Posted Sep 26, 2006 16:08 UTC (Tue) by sepreece (subscriber, #19270) [Link] "To my understanding the additional permissions are not there to address new ethical questions, but simply to make it easier to distribute software using code that is licensed under a free but GPL-incompatible license. (such as the CDDL, which would allow for GNU/Solaris)"
I basically agree with everything you said, but it's worth noting one thing here: If the point of allowing additional permissions is to make it possible to combine code with code written under other, more permissive licenses, it's important to note that removing those permissions removes the ability to make that combination, so a downstream redistributor would have to strip out any code that was no longer compatible with the more restrictive license.
I think the whole question of compatibility and of distributing mixed-license code is under-addressed in the license and in licensing discussions in the community.
The FSF site says a license is GPL-compatible if it allows distribution under the GPL. That's somewhat misleading. The code [in most cases] remains licensed under its original terms. The compatibility is that the terms of the other license are not violated by distribution under the terms of the GPL - you're still distributing the included software under the terms of its own license, because those are the only terms that allow you to distribute it.
You can't have it both ways. Posted Sep 27, 2006 1:08 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] how is any downstream distributer (especially years later) supposed to know what the source for all the bits of code were so that they can strip out the bits of code that 'needed' that extra permissions to be there?
David Lang
Simple... Posted Sep 27, 2006 9:01 UTC (Wed) by hummassa (subscriber, #307) [Link] The GPL demands all changes to be logged.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 15:16 UTC (Tue) by nim-nim (subscriber, #34454) [Link] This is the only point where I agree with the current criticism.
The great value of the GPL v2 is the simple way it's expressed, the fact there is only one of it, and a project does not need a dedicated lawyer to handle it. So either the so-called optional conditions are reasonable, simple and useful enough to be folded in the main license, or they should just be dumped. Being compatibe with every OSI license under the Sun via plugins is not simplifying the current mess, it's keeping it under a GPL label.
For the same reasons I support the language clarifications of the GPL v3. The US asumptions of the current license may be transparent to US developpers but they're a real cost to projects in other countries.
Likewise I support adopting common patent and DRM clauses. If the GPL continues to ignore other areas of IP law, the GPL will lose any practical value, as it's simplicity and unicity will be consumed by the specific patent and DRM agreements used in parallel.
Now finding a good simple and clear patent/DRM wording may be hard. But if the FSF with all the FLOSS community input can not find it, do you really expect your average corp lawyer to do better ?
No generic patent/DRM clause means the return of specific obfuscated arbitrary lawyerspeak. If you think the optional GPLv3 clauses are painful, you havent seen anything about what patent agreements of DRMs will require
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 16:34 UTC (Tue) by mingo (subscriber, #31122) [Link] Likewise I support adopting common patent and DRM clauses.The software patent changes i do support - but DRM is not really a "new area of IP", it is something that has existed for a long time and which roots in plain copyright. (and i have mentioned many reasons against trying to over-regulate in this area in the other threads so i wont repeat them here.) Software patents are embodied in source code and are mostly orthogonal to classic copyright, so an extension of the Quid Pro Quo (from which the four freedoms derive) covering source code to software patents is only fair.
criminalization of un-DRM-ing.... Posted Sep 27, 2006 9:25 UTC (Wed) by hummassa (subscriber, #307) [Link] is a DMCA (2000? 1999?) thing. You must remember that PSP/tivo hacking isactually a criminal offense in some countries. And no, that was NOT the case before the DMCA.
criminalization of un-DRM-ing.... Posted Sep 27, 2006 10:00 UTC (Wed) by nim-nim (subscriber, #34454) [Link] Making GPLed software use incompatible with maximalist interpretations of the OMI treaty (father of DMCA and EUCD) is actually a feature, as media companies worldwide are trying very hard to convince legislators their clauses will be a boon for the media sector without harming everyone else.
It's much easier to convince a judge/MP the wordings pushed by the Universals of the word are harmful/dangerous/unreasonable if you can confront them to actual existing binding legal documents such as a license.
If you're only backed by general philosophy/economic considerations OTOH you'll lose to their general feeling, which is "hackers" are bad "protecting IP" is nice, and hobbyists will adapt
DRM is not new, but the GPLv3 is over-regulating. WTF? Posted Sep 27, 2006 9:33 UTC (Wed) by xoddam (subscriber, #2322) [Link] > DRM is not really a "new area of IP", it is something that> has existed for a long time and which roots in plain copyright.
Copy-protection mechanisms themselves have indeed existed for a long
And far more significantly than that, the DMCA is new. Copy-protection
> (i have mentioned many reasons against trying to over-regulate...)
The GPLv3 is not "trying to over-regulate". It is a mild attempt at a
Dear Ingo and fellow kernel-developers,
A GPLv3 operating system kernel would be a great boon to freedom. Please
Regards,
Jonathan Maddox (xoddam)
|
|
||||||||||||