Recent Features
| |||||||||||||
A turning point for GNU libcA turning point for GNU libcPosted Mar 28, 2012 17:40 UTC (Wed) by slashdot (guest, #22014)Parent article: A turning point for GNU libc
It seems that there is work to get rid of the absurd and detrimental copyright assignment requirement.
Linus Torvalds on Google+:
David Miller replies:
(Log in to post comments)
Planning for decades Posted Mar 28, 2012 18:43 UTC (Wed) by mcoleman (guest, #70990) [Link]
It's worth noting that the copyright assignment stuff is not there just to be obsessive. The FSF is trying to build something that will stand for decades, if not forever, and so some of their preparations are with that in mind.
Planning for decades Posted Mar 28, 2012 20:14 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]
While that may be true, I don't think the kernel hackers consider the Linux kernel to be a short term hack any longer, Linus' original release announcement nonwithstanding. The kernel thus far has survived without copyright assignment, and indeed many consider that a feature.
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.
Planning for decades Posted Mar 28, 2012 20:23 UTC (Wed) by mcoleman (guest, #70990) [Link] The FSF designed the GPL explicitly to disallow anyone from unilaterally determining the destiny of the code it is applied to. This seems clear from their words and actions.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.
Planning for decades Posted Mar 29, 2012 1:53 UTC (Thu) by smurf (subscriber, #17840) [Link]
You need to distinguish past and future releases.
True, the copyright holder can do nothing whatsoever about the code that's already out there.
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).
Planning for decades Posted Mar 31, 2012 19:28 UTC (Sat) by giraffedata (subscriber, #1954) [Link] 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.
Planning for decades Posted Apr 5, 2012 20:02 UTC (Thu) by Wol (guest, #4433) [Link]
Actually, I believe there IS something that would stop them releasing proprietarylibc.
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.
Cheers,
Planning for decades Posted Mar 29, 2012 1:55 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] 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.
Planning for decades Posted Mar 29, 2012 2:04 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
And, there's smurf's observations upthread. Point is, the only point of assigning your copyright to the FSF is to allow them to act with respect to your code without consulting you or anyone else, period.
Planning for decades Posted Mar 29, 2012 2:09 UTC (Thu) by mcoleman (guest, #70990) [Link]
You're talking about the power of the FSF to unilaterally give away my code under a license that is less restrictive than the original. That's not a contingency that keeps me up nights.
The real problem would be if the FSF could unilaterally restrict access to my code when I did not intend it. They cannot.
Planning for decades Posted Mar 29, 2012 3:12 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
some people would get really upset if their code was released under a license that allowed it to be put in proprietary code.
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.
Planning for decades Posted Mar 29, 2012 3:39 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
That's pretty much my point. Thank you for providing additional examples.
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...
Planning for decades Posted Mar 29, 2012 4:08 UTC (Thu) by xtifr (subscriber, #143) [Link]
If you're really paranoid about the "or later" thing, you can always say something like "or any later version which has similar requirements to always provide full source code when distributing derivatives", etc. Heck, now that I think about it, I might actually change some of my code to say that.
Planning for decades Posted Mar 29, 2012 4:17 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
I'm not really all that paranoid myself. But to deny that the FSF is in a unique position and seeks to retain that unique position belies the facts. That's the only point I'm trying to make.
Planning for decades Posted Mar 29, 2012 11:06 UTC (Thu) by smurf (subscriber, #17840) [Link] 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.
Planning for decades Posted Mar 29, 2012 11:16 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
remember that in some people's eyes, GPLv3 breaks the "… which intends to convey essentially the same rights" criteria compared to v2
in the opinion of the FSF it doesn't, in the opinion of many others, it does.
Planning for decades Posted Mar 29, 2012 12:25 UTC (Thu) by wookey (subscriber, #5501) [Link]
"in the opinion of the FSF and many others it doesn't, in the opinion of many others, it does."
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.)
Planning for decades Posted Mar 29, 2012 12:50 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] 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.
Planning for decades Posted Mar 29, 2012 13:03 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
Here's a thought experiment for you: Suppose someone releases a software package under "GPL v3 or later", with all its new requirements to prevent tivoization. They do this because they like the additional guarantees their software will remain free, and they really don't want their software tivoized.
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.
Planning for decades Posted Mar 29, 2012 16:45 UTC (Thu) by khim (subscriber, #9252) [Link] 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. 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.
Planning for decades Posted Mar 29, 2012 4:45 UTC (Thu) by slashdot (guest, #22014) [Link]
I guess that as long as Stallman is in charge, it's a reasonably safe bet that he won't release a non-copyleft GPL.
The more worrisome thing is what happens after him.
Planning for decades Posted Mar 29, 2012 12:45 UTC (Thu) by mcoleman (guest, #70990) [Link] Right now, it looks like the FSF is more stable over time than the legal and social systems that it is embedded in, so it seems kind of pointless to worry about them. Could they go Komen? Sure, it could happen. Nothing is forever.If you're really worried about them making your code less restricted under a "or later" clause, just leave it out.
Planning for decades Posted Mar 29, 2012 23:50 UTC (Thu) by xtifr (subscriber, #143) [Link]
The problem with simply removing the "or later" clause is that each version of the GPL is pretty-much inherently incompatible with other versions. The GPL basically allows no exceptions to any of its terms (ignoring some of the explicitly-allowed-variations in the GPLv3), so GPLv4 will be incompatible with GPLv3 and GPLv2. If you use the "or later" clause, this doesn't matter, because GPLv2-or-later code can be used in a GPLv4 (with or without "or later") project, so all the "or later" versions are compatible. But without the "or later", you get a combinatorial explosion of license incompatibilities as the number of versions of the GPL increases. Which I think is probably a very bad thing.
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.
Planning for decades Posted Mar 30, 2012 0:14 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> 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.
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.
Planning for decades Posted Mar 30, 2012 6:12 UTC (Fri) by xtifr (subscriber, #143) [Link] 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.
Planning for decades Posted Mar 30, 2012 6:27 UTC (Fri) by sfeam (subscriber, #2841) [Link] "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." Only if you are talking about a standalone bit of code. If someone takes my GPLv2orlater code and incorporates it in a larger GPL3 program, then the result cannot be used under GPL2, only under GPL3. If I don't want that to happen then GPL2orlater is not an option.
Planning for decades Posted Mar 30, 2012 6:59 UTC (Fri) by xtifr (subscriber, #143) [Link] 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.)
Planning for decades Posted Mar 30, 2012 9:03 UTC (Fri) by paulj (subscriber, #341) [Link]
A likely problem with "GPLv2 or any later version which has [feature list]" is that then the "[feature list]" itself turns into a licence, with attendant complexity of text etc..
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. ??
Planning for decades Posted Mar 31, 2012 3:05 UTC (Sat) by xtifr (subscriber, #143) [Link]
yes, that could definitely work too.
Planning for decades Posted Mar 30, 2012 15:21 UTC (Fri) by mcoleman (guest, #70990) [Link] ...then the result cannot be used under GPL2, only under GPL3Of 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...
Planning for decades Posted Mar 31, 2012 10:13 UTC (Sat) by mpr22 (subscriber, #60784) [Link] Part of the point of the GPL is "share and share alike" (or so it seems to me). GPLv3+'ing a derivative of a GPLv2+ project is, at best, shockingly rude, since it amounts to saying "I don't want to share with you" to the upstream maintainer.
Planning for decades Posted Mar 31, 2012 11:41 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246) [Link] 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+?
Planning for decades Posted Mar 31, 2012 15:47 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
Looking through a repoquery on Rawhide, some of note (ignoring GNU projects):
- audacious
Planning for decades Posted Mar 31, 2012 15:57 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246) [Link]
Cool. Looks like it has picked up at least a little steam outside GNU. I guess we'll see in 20 years whether it becomes as popular as GPL v2 did in its ~20 year run as the leading GNU license.
Planning for decades Posted Apr 5, 2012 11:03 UTC (Thu) by njs (guest, #40338) [Link]
The Samba project enthusiastically supports GPLv3; IIUC their experiences with messy court cases, license enforcement, etc., were strong influences on GPLv3's design.
Planning for decades Posted Apr 5, 2012 20:10 UTC (Thu) by Wol (guest, #4433) [Link]
What you should do then (if you can) is to treat the GPL2 code like a LGPL2 library - keep it in its own section of the source tree, and leave it at GPL2+.
If you make major changes you can then decide whether to move it into the main GPL3 tree or not.
Cheers,
Planning for decades Posted May 29, 2012 12:31 UTC (Tue) by mirabilos (subscriber, #84359) [Link]
This is actually wrong.
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.
Planning for decades Posted Mar 30, 2012 1:11 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] 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.
Planning for decades Posted Mar 29, 2012 13:13 UTC (Thu) by mina86 (subscriber, #68442) [Link]
> 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.
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.
Planning for decades Posted Mar 29, 2012 18:02 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the litigation need may have been a valid argument at one time, but given that there has been so much successful GPL enforcement by people who don't have exclusive copyright assignment (gpl-violations.org, busybox to name two high profile projects), that argument doesn't really fly anymore
Planning for decades Posted Mar 29, 2012 19:19 UTC (Thu) by mina86 (subscriber, #68442) [Link]
Maybe it's not a valid argument, I'm not arguing that. What I'm saying is that the reason why FSF requires assignments for some projects is because of the litigation need, and not because they wish to have full control over the licensing of the code (which, as have been pointed out, they have quite of lot of anyway).
Planning for decades Posted Mar 29, 2012 18:06 UTC (Thu) by smurf (subscriber, #17840) [Link]
> The theory behind copyright assignment is that it's easier with litigations
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.
Planning for decades Posted Mar 29, 2012 18:14 UTC (Thu) by mcoleman (guest, #70990) [Link]
IANAL, but this sounds like something that would open you up to all sorts of liability. Merely giving away copyright is much more benign.
(Compare: "I authorize the FSF to use my bat as they see fit." versus "I give the FSF my bat.")
|
|||||||||||||