Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
Planning for decades
Posted Mar 28, 2012 20:14 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)
My understanding is that the FSF wants copyright assignment so that it can unilaterally determine its destiny. It can, for example, decide to begin releasing it under an entirely new license at some point. While it won't eradicate older versions under older licenses, it does make it easy to relicense the whole thing even if the original author didn't submit code with a "version X or later" clause.
I seem to recall that the FSF also argues that it makes it easier to litigate on behalf of the code, although I would counterargue that the critical mass of code that's already there is likely sufficient for litigation purposes. I guess the only sticky points would come down to litigation around a specific contribution that hasn't been assigned to the FSF. I suppose with all the lawsuits out there, that's not outside the realm of possibility. And, to further poke holes in my reasoning, more recent code is more likely to trigger lawsuits than code that's been there for many years, especially if it's based on newer techniques. Older code is more likely to have been vetted against legal issues.
Posted Mar 28, 2012 20:23 UTC (Wed) by mcoleman (guest, #70990)
Once you apply the GPL to code you write, you give up almost all possibility of unilateral control of the code. In return, you get that same grant from all future contributors.
Posted Mar 29, 2012 1:53 UTC (Thu) by smurf (subscriber, #17840)
But as the FSF has the copyright on the whole code, the only thing that'd prevent it from releasing proprietarylibc tomorrow is their promise not to do that, which they gave by way of their past policies and activities.
Other organizations which required copyright assignment either never did so (Canonical) or even explicitly state that there's a commercial version (mysql).
Posted Mar 31, 2012 19:28 UTC (Sat) by giraffedata (subscriber, #1954)
You need to distinguish past and future releases.
The distinction is not between past and future releases, but between the code and the project. GPL's provision for forking means the distributor can't control future releases, because anyone can make one. And that's central to GPL's purpose.
But GPL isn't meant to give the public control of a project such as the GNU libc project, and that control is what the copyright assignment is designed to prevent.
Posted Apr 5, 2012 20:02 UTC (Thu) by Wol (guest, #4433)
It's called a contract.
aiui, the standard contract assigning copyright to the FSF places some restrictions on what they can do, and that's one of them.
Posted Mar 29, 2012 1:55 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
Disallow anyone except the FSF, you mean. The FSF has very carefully set things up such that they trust themselves with unilateral action, but no one else.
Anyone who has released code under a "GPL version X or later" has left themselves open to whatever the FSF decides the next version of the GPL would say. If the FSF decided tomorrow that GPL v4 will read exactly as the 3-clause BSD license (minus references to UCB, of course), suddenly vast mountains of GPL software would be available under a BSD license (effectively) with no feedback or input from the software's authors.
If that's not unilateral, what is it? We only trust that the FSF wouldn't do that. They've earned it, but let's face it: They wield a fair bit of unilateral power here. The power above derives from their special status as the only source of future versions of the GPL.
But that isn't the issue at hand. Copyright assignment was. I'm getting there... So, assume the GPL is a fixed thing, and let's move on to copyright assignment.
When the FSF talks of "unilateral action" in a negative light, they mean by anyone but themselves. That doesn't mean that the FSF doesn't want to engage in unilateral actions. Their own reasons for copyright assignment page makes it plain that they want to be able to litigate unilaterally with respect to the software, and they can do that only if they own all the copyrights.
If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors. In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect . . . .
I read the highlighted "we" as meaning "the FSF and its legal team," not "the community at large." That sounds pretty unilateral to me.
So there you have it, two axes of unilaterality:
What the GPL effectively prevents is proprietary forks and unilateral action against a project by anyone else. Nobody else can release a new GPL license. And if folks assign their copyrights to FSF for FSF-maintained code, that grants no rights to anyone who isn't FSF.
How is it not clear that the FSF is in the cat bird seat here?
FWIW, I release all my software either under a GPL v2 (or GPL v2 and later) license, or I release it to the public domain if it's small enough to be inconsequential. I'm not against the GPL or the FSF. But, please understand that the FSF does have some special unilateral powers with respect to certain GPL uses, and for code submitted to an FSF-maintained project they ask for a few more unilateral powers.
Posted Mar 29, 2012 2:04 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
Posted Mar 29, 2012 2:09 UTC (Thu) by mcoleman (guest, #70990)
The real problem would be if the FSF could unilaterally restrict access to my code when I did not intend it. They cannot.
Posted Mar 29, 2012 3:12 UTC (Thu) by dlang (✭ supporter ✭, #313)
the FSF has the ability to allow that (make GPLv4 equivalent to BSD, proprietary company takes code and moves it to it's own license)
and before you protest and say that they have promised to never do anything like that, remember that they made a special clause in the license to allow GPL documents that were in wikipedia before a specific date to be moved to a GPL incompatible license.
They have the ability, the only question is will they.
I am not saying that they will, only that they have the ability to do so.
Posted Mar 29, 2012 3:39 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
The FSF is in a unique position of power with respect to the GPL (at least the "ver X or later" variant). And because they ask you assign copyrights for anything you contribute to the FSF, they're in a unique position of power over that. Both give the FSF various (and differing) unilateral powers over your code, should you elect to extend those powers to the FSF. Those powers can be used in ways you do or do not agree with.
We trust that FSF won't disappoint us. They've earned a lot of trust from the community over the years, but that vague yet pervasive sense of trust is not a legal construct. As you say, "They have the ability; the only question is 'Will they?'"
The most likely answer is "They will not." But, it _is_ a potential single point of failure if I ever saw one...
Posted Mar 29, 2012 4:08 UTC (Thu) by xtifr (subscriber, #143)
Posted Mar 29, 2012 4:17 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
Posted Mar 29, 2012 11:06 UTC (Thu) by smurf (subscriber, #17840)
Legally, "any later version" might well be interpreted as "… which intends to convey essentially the same rights".
If I had intended to publish my code under a 3-BSD license, ten years ago, I would have done so; therefore the FSF has no right to publish a 3-BSD-equivalent and label it "GPLv4".
Again, this is about the stated intent of both the FSF (what does it stand for? what are their goals?) and me (did I agree with these, when I chose that license?). It's not about the text "or any later version" with an implied "… whatever that says, decided unilaterally by the FSF".
Whatever your opinion about legal beagles in general, give them some credit.
Posted Mar 29, 2012 11:16 UTC (Thu) by dlang (✭ supporter ✭, #313)
in the opinion of the FSF it doesn't, in the opinion of many others, it does.
Posted Mar 29, 2012 12:25 UTC (Thu) by wookey (subscriber, #5501)
Would be a more even statement of the situation. (Your original suggests that it is FSF's opinion versus 'many people'. Opinion is more evenly divided than that.)
Posted Mar 29, 2012 12:50 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
3-BSD conveys fewer restrictions on the recipient of the code than GPL v2. So are you saying future GPL licenses can only be more restrictive?
Let's consider the spectrum of freedom from the perspective of the recipient of the code, not the author. Public domain code is the most free of all. 3-BSD is a step back from public domain, but not by much. GPL v2 is more restrictive than 3-BSD, with all its wording about derivative works and the like, source redistribution requirements, and so on. GPL v3 is more restrictive yet. And then there's the default state of "copyrighted work," where the recipient has very few default rights.
Are you suggesting that the only arc future GPL licenses can take is toward less freedom for the recipient?
Ok, so perhaps I was leading you down a rhetorical garden path with those questions. And, since you're well steeped in Free Software, you're not persuaded to follow. But, imagine arguments constructed along those lines in court. Such arguments could be much more persuasive to a less deeply invested judge and/or jury. If someone used your code with an imagined GPL v5 that let them make a proprietary package that you didn't approve of, good luck winning over the court if you try to sue.
I realize that the FSF is trying to maximize the freedom of the ecosystem as a whole. But realize that it does so by limiting the freedom of individuals to appropriate the code and take it private. It lays that all out in the preamble, saying that to protect your rights, it puts limits on what you (or anyone using the software) can do, and places on you certain responsibilities in order for you to use the licensed software. That subtle, tricky and almost counter-intuitive balance of "protecting your rights by limiting your actions" can be a lot for folks to wrap their heads around.
What if the FSF decides that it's in the greater interest of the ecosystem to place fewer restrictions on the recipients of the software, thinking that yes, there will be some that abuse the additional privilege, but it's entirely likely be more new contributors that will not. There are those who find the GPL legally risky and don't contribute, and maybe someday the FSF will try to meet them in the middle to bring them into the fold. (Probably not as long as St. Ignucious is still kicking, but hey, there's an awful lot of future ahead of us. And don't think that I'm advocating that the FSF should do this. I'm only arguing about the potential range of outcomes here.)
The GPL v2 states:
The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
"Similar in spirit" is rather wide open to interpretation. The overriding theme is "freedom", and as we've all seen, there are many, many differing interpretations of what constitutes freedom. A license that shifts the balance of freedoms toward the recipient (ie. a move toward something more like 3-BSD, if not moving entirely to 3-BSD) would not necessarily be incompatible in spirit with the GPL in many peoples' eyes.
In any case, the only truly legally binding phrase in that clause is this one:
If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
Sure, the preceding paragraph said "similar in spirit," but the FSF alone gets to define what their spirit is. After all, they wrote the license.
Posted Mar 29, 2012 13:03 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
Now the FSF releases the GPL v4 that reverts the changes in GPL v3, and reads identical to GPL v2.
Theoretically, the GPL v3 was similar in spirit to the GPL v2. So, this imagined GPL v4 should also be similar in spirit to GPL v3. Now what?
Really, the "or later" clause cedes an awful lot of control to the FSF. That's been my point all along. The punch line is that if you care that much about the specific semantics of the license that covers your code, you really shouldn't put a wildcard in the license that you don't control.
Posted Mar 29, 2012 16:45 UTC (Thu) by khim (subscriber, #9252)
The punch line is that if you care that much about the specific semantics of the license that covers your code, you really shouldn't put a wildcard in the license that you don't control.
Yup. The irony here is that it looks like FSF is the only organization which understands that.
MPL: You may distribute the Covered Software under the terms of the version of the License under which You originally received the Covered Software, or under the terms of any subsequent version published by the license steward.
CC-BY-SA: You may Distribute or Publicly Perform an Adaptation only under the terms of… (ii) a later version of this License with the same License Elements as this License.
GPL is the only popular copyleft license which gives program author the right to refuse delegation of “autoupgrade” rights to license “stewards”. Note that such liberty was given to authors by all versions of GPL, including the first one. All these other licenses were created after GPL was created - yet they cede “an awful lot of control” unconditionally.
It's funny that the very people who are bashing FSF for the “or later” clause are often advocating MPL or CC-BY-SA as an alternative despite the fact that they are obviously more problematic in this regard.
Posted Mar 29, 2012 4:45 UTC (Thu) by slashdot (guest, #22014)
The more worrisome thing is what happens after him.
Posted Mar 29, 2012 12:45 UTC (Thu) by mcoleman (guest, #70990)
If you're really worried about them making your code less restricted under a "or later" clause, just leave it out.
Posted Mar 29, 2012 23:50 UTC (Thu) by xtifr (subscriber, #143)
That's why I suggested above: if you don't trust the FSF to do the right thing, then, instead of simply removing the "or later" clause, replace it with something that says "or any later version that meets [list of criteria I consider indispensable]". For example, if you're a big fan of Tivoization, you could say, "GPLv2 or any later version that allows [tivoization]". Then, if the FSF had a change of heart and decided to allow tivozation (perhaps as an option) in the GPLv4, your code would automatically be compatible with v4 (or at least with v4 projects that exercised the tivoization option).
Bottom line: "the FSF might do things I don't like in the future" is a mostly-hypothetical bad thing, while removing the "or later" clause is license proliferation, which is a right-now bad thing.
Posted Mar 30, 2012 0:14 UTC (Fri) by dlang (✭ supporter ✭, #313)
you've obviously missed all the people (including a large number of linux kernel developers) who consider GPLv3 a perfect example of the FSF doing something that they didn't like with a future license change.
for them this is not a hypothetical thing, it's the reality, and they especially don't like being bullied into changing the license on their code because not doing so leads to license proliferation, especially as they made their concerns (including the problem of license proliferation) very clear before the GPLv3 was published.
I'm not saying that you are doing the bullying, but there are others who are doing so.
Posted Mar 30, 2012 6:12 UTC (Fri) by xtifr (subscriber, #143)
No, I had them in mind when I said mostly. And, while I've heard a lot of people bitch about the GPLv3, in my experience, the majority of the bitching boils down to "wah, it's so long and complicated--v2 was so much simpler and more elegant!" The people I've heard complain about actual terms of the GPLv3 are...well, greater than zero, but not a whole lot greater. The main thing among the actual terms I've heard people complain about is the anti-tivoization stuff, which is why I explicitly covered that in my earlier post. (In fact, if enough people followed my earlier advice, it might actually make my improbable hypothetical come true, and persuade the FSF to conditionally allow tivoization in a future version.)
(Also, a lot of people don't seem to grasp the difference between "GPLv2 or later" can always be used under the GPLv2, no matter how many later versions may have been published. The GPLv3 wouldn't prevent the Linux kernel from being Tivoized even if the kernel were "v2 or later", because anyone can still continue to use the code under the terms of v2. But I'm trying to ignore idiotic arguments, even though it's hard when this topic has generated so much heat and so little light.)
In any case, you seem to be ignoring the fact that my solution works for both sides! It minimizes the license proliferation problem, while preventing the FSF from adding conditions you don't like to your code. It's not necessarily perfect (you have to have guess which terms might turn out to be important), but I think it's good enough that I'll probably try using it myself.
Posted Mar 30, 2012 6:27 UTC (Fri) by sfeam (subscriber, #2841)
Posted Mar 30, 2012 6:59 UTC (Fri) by xtifr (subscriber, #143)
Once again, you're completely ignoring what I actually said in order to argue with some straw man. If there's some change in the GPLv3 you don't like, then say "GPLv2 or any later version which has [the GPLv2 version of that feature]". That doesn't make you more any more compatible with v3, but allows you compatibility if the FSF rethink their position and add the feature as an option in v4. (And even puts some pressure on them to do so, if your program is widespread and popular enough.)
Posted Mar 30, 2012 9:03 UTC (Fri) by paulj (subscriber, #341)
A simpler solution perhaps, if you don't fully trust the FSF, would be to add additional authorities as to which later versions are blessed? E.g.: "GPLv2 or any later version approved by [authority]", where authority could be, say, Linus Torvalds, or some cabal. ??
Posted Mar 31, 2012 3:05 UTC (Sat) by xtifr (subscriber, #143)
Posted Mar 30, 2012 15:21 UTC (Fri) by mcoleman (guest, #70990)
Of course. Why would you expect to be able to use someone else's code in a manner that they forbid? Microsoft won't let you do that either...
Posted Mar 31, 2012 10:13 UTC (Sat) by mpr22 (subscriber, #60784)
Posted Mar 31, 2012 11:41 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246)
Ah, but what if a GPL v3+ project decides to integrate a non-trivial part of your GPL v2+ code base into the larger GPL v3+ project, as sfeam suggested a few comments up?
For example, I'm making a GPL v3/v3+ paint program, and you wrote a nice chunk of GPL v2+ code for handling the whizzy new Frobnitz N-dimensional drawing tablet. Now I integrate your Frobnitz handling code into my paint program. The resulting application is GPL v3+. What's the point of GPL v2+ if not to allow such forward compatibility?
Sure, if I were to release a GPL v3/v3+ only application that was created by taking someone else's GPL v2+ app and adding only a little bit of GPL v3 code, that would be somewhat rude (unless I had the author's blessing), but entirely legit by the license. But sfeam's example had the sizes the other way around -- smaller GPL v2+ code subsumed into a larger GPL v3 / v3+ project. I don't think anyone should find that rude. (I almost said "I don't think anyone would find that rude," but I thought better of it. The Internet is a big place.) I imagine it happens with large GPL v3 projects somewhat regularly.
Speaking of which, aside from GCC, what are some somewhat large GPL v3 projects out there? Or did most everyone hang back with GPL v2/2+?
Posted Mar 31, 2012 15:47 UTC (Sat) by mathstuf (subscriber, #69389)
Posted Mar 31, 2012 15:57 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246)
Posted Apr 5, 2012 11:03 UTC (Thu) by njs (guest, #40338)
Posted Apr 5, 2012 20:10 UTC (Thu) by Wol (guest, #4433)
If you make major changes you can then decide whether to move it into the main GPL3 tree or not.
Posted May 29, 2012 12:31 UTC (Tue) by mirabilos (subscriber, #84359)
The combined work can be shared under GPLv3 only. (The act of running the program, coll. using, is not restricted by the GNU GPL.)
But if your original source code is still intact (and copyright law apparently – IANAL, TINLA – forbids removing copyright notices) within the combined work and a visibly separate entity, you can still take that (possibly patched) file under GPLv2+ as it originally was, because the GNU GPL in no version has the power of actually changing *other* peoples’ copyright licences.
Posted Mar 30, 2012 1:11 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246)
Perhaps a safer course would just to replace "or any later version" with "or later versions approved by <name of authority here>." That approval could even extend to another version of the license with a different named authority, should you care to pass the torch.
Note that the named authority need not be an individual. It could be a committee, such as the Frobnitz Steering Team or what-have-you.
Posted Mar 29, 2012 13:13 UTC (Thu) by mina86 (subscriber, #68442)
Sorry, but this is BS.
The theory behind copyright assignment is that it's easier with litigations as you pointed later.
FSF could change GPL if they really wanted to, and the easy solution for authors that do not submit with a “or later” clause is to not accept such patches.
Posted Mar 29, 2012 18:02 UTC (Thu) by dlang (✭ supporter ✭, #313)
Posted Mar 29, 2012 19:19 UTC (Thu) by mina86 (subscriber, #68442)
Posted Mar 29, 2012 18:06 UTC (Thu) by smurf (subscriber, #17840)
This does not make sense. You can do the same thing with an agreement authorizing the FSF (or, more specifically, their lawyer) to act on your behalf, should a license violation involving your code come to their attention.
Posted Mar 29, 2012 18:14 UTC (Thu) by mcoleman (guest, #70990)
(Compare: "I authorize the FSF to use my bat as they see fit." versus "I give the FSF my bat.")
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds