Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
GPLv3 & additional permissions/restrictionsGPLv3 & additional permissions/restrictionsPosted Sep 26, 2006 10:37 UTC (Tue) by mingo (subscriber, #31122)In reply to: Just a question about the GPLv3 by stevenj Parent article: Some GPLv3 clarifications from the FSF However, the GPLv3 allows the copyright holders to optionally impose a few additional terms under section 7. The problem is that the GPLv3 treats such "additional permissions and restrictions" in an unequal way, and creates an unjust and unfair "pressure" towards a pure, permission-less GPLv3. Let me explain. Under Section 7/c: " 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. " This means that anyone who conveys (i.e. who copies or distributes the code) can remove an additional permission. Anyone. Code that was written with specific additional permissions can be taken and incorporated into a "pure" GPLv3 project with those permissions removed. But can I do what that person did to my code, can I include his fixed/improved version of my code into my "GPLv3 + permissions" project? I might not be able to do it, because under Section 7/b: "You may place additional permissions, or additional requirements as allowed by subsection 7b, on material, added by you to a covered work, for which you have or can give appropriate copyright permission." And I might not be able to get that "permission" from a "pure GPLv3" project ... even if the code i want to merge back was largely my code to begin with.This unequal pressure towards a "purification" of the GPLv3 codebase i understand as a sign that the writers of the license dont look at extra permissions with symphaty, and want to eliminate them, slowly but surely. 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 fully democratic: the success of the projects would be the metric of what permissions are the best. Not the unequal playing rules hardcoded into the license.
(Log in to post comments)
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:06 UTC (Tue) by michich (subscriber, #17902) [Link] 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.
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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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)
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:12 UTC (Tue) by alexbk (subscriber, #37839) [Link] LGPL has allowed this kind of relicensing into pure-GPL for years and no evil purification hasoccured. If you don't want removal of extra permissions/requirements, use a different license where those are not allowed to be removed; the good thing is that it can still be combined with GPLv3 code.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:21 UTC (Tue) by drag (subscriber, #31333) [Link] "" 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 fully democratic: the success of the projects would be the metric of what permissions are the best. Not the unequal playing rules hardcoded into the license."" So following your logic wouldn't that make ALL GPLv3 code essentially "GPLv3 + permissions" pretty much automaticly? And how would it be democratic to force authors who may want their code to be "GPLv3 pure" and have other people make it "GPLv3 + permissions"? Maybe I am just tired, but none of that realy makes sense to me. What they are stating in the the license seems to me just clarification on how copyright licensing law works rather then a additional restriction, subtle manipulation, or "pressure". Even if they left the sentence out of the license which you qouted it would still absolutely work that way. In other words it is simple "clarification". You can take any code and make it GPL or incorporate it into GPL programs as long as the original license does not impose any additional restrictions. You can take 'BSD licensed' code and incorporate it into a GPL'd program, but those BSD authors can't turn around and make GPL'd code from that program and license it BSD code without consent from all the relevent copyright holders, correct? Same thing with MIT and a dozen other licenses.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:35 UTC (Tue) by mingo (subscriber, #31122) [Link] So following your logic wouldn't that make ALL GPLv3 code essentially "GPLv3 + permissions" pretty much automaticly? And how would it be democratic to force authors who may want their code to be "GPLv3 pure" and have other people make it "GPLv3 + permissions"? Maybe I am just tired, but none of that realy makes sense to me.yes, that's my point - it makes no sense either way. There's just no solution i can see at all but to get all developers in the GPL ecosystem agree - anything else will result in inequality on either the "restrictive" (pure) side or on the "permissive" side. The reason for that inequality is that in an assymetric licensing model there's just no technical way to determine who put how much effort into some code, hence there is simply no mechanism to be fair - the only solution is equal treatment. I see the GPLv2 as a pretty well working "agreement" that isnt perfect but seems to unify alot of people who ended up writing a body of code that currently consists of 300+ million lines of code and who are currently producing tens of millions of new lines of code per year. Trend: "accelerating exponentially". I'd be very, very careful to mess with that powerful machinery.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 19:38 UTC (Tue) by drag (subscriber, #31333) [Link] I think that how it is stated in GPLv3 is how GPLv2 works right now.
Say I modify a GPLv2 and add some permissions. Now that's not GPL proper anymore, but basicly it's the the same thing as saying GPLv2 + permissions.
Now that code is still GPL compatable and a person can strip away those permissions and use it in a "GPLv2" proper. The original author now can't turn around and use code from that GPLv2 proper program and add permissions without special agreement with the copyright holders.
So that is the way the GPLv2 works right now, is it not?
Isn't this part of the 'viral' nature of the GPL and the sort of thing people having to work with 'GPL compatable' licenses have to deal with on a regular basis?
To me it's no difference between GPLv2 and GPLv3 in this regard. I think that this GPL+permissions language was added to make the GPL to be more 'universal' and work the same way in more countries as it works in the U.S. or most places in Europe. Different countries may not interprete the GPL in the same way as their copyright laws maybe different or they use different conventions. But you'd have to ask the FSF people about that.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 16:44 UTC (Tue) by smoogen (subscriber, #97) [Link]
If 7c allows anyone to remove an extra permission/rule.. why have them in the first place? It would also seem to be an even bigger impediment for dual licensed code than before.
My reading of it is that if I get code under MPL/GPLv3 then I can release the code again as GPLv3 only with only small changes to the code (if any?). I can see the reason that the FSF does not want to have multiple licenses.. but this seems a bit draconians
One License to rule them all, One License to find them,
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 23:44 UTC (Tue) by drag (subscriber, #31333) [Link] "One License to rule them all, One License to find them,One License to bring them all and in the FSF bind them."
Isn't that what Microsoft says is going to happen?
You guys are nuts. It seems that your are on a anti-GPLv3 rampage and are refusing to look at it objectively or completely fail to understand how the GPLv2 works right now!
The GPL is the 'lowest common demominator' in a Linux based system.
When all software is GPL-compatable then that means something to the end users. This is very attractive and it means that everything is 'Free' software. Sure there are licenses that are not GPL compatable and are free, but for each one of those it causes huge headaches.
Could you imagine if everything was based on the MPL, for instance?
I've seen projects that are using Mozilla stuff that have closed portions of the program, they have other portions of the source code which you can't use if your doing something the original author politically incorrect, then they have other portions you are only allowed to use for non-commercial purposes unless your a paticular company. All these incompatable and conflicting licenses in a single work of software. It's hugely distructive.
A program like that has no future.
People have perfectly good Free software licenses in their code right now that are GPL-incompatable but are acceptable by most people. It's a pain in the neck for distributers like Debian or Redhat to sometimes deal with the fact that although they are using Free software it is incompatable with the 70% of the rest of the operating system that is using the LGPL (sure they can link, but they can't be used in those libs) or GPL.
Now with GPLv3 many more of them will be compatable and cause much less headaches for end users and distributers.. And now people are accusing the drafters of GPLv3 in attempting to 'steal' code from these other projects and turn them all into FSF controlled software?
I have news for you.. This is exactly how the GPLv2 operates and it has been very very successfull. Insanely successfull... and the vast majority of those projects which currently use GPL-compatable licenses are still completely outside the control of FSF, GNU, RMS, and friends.
What your saying is FUD.
|
|||||||||||