Not logged in
Log in now
Create an account
Subscribe to LWN
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
(Nearly) full tickless operation in 3.10
Project Harmony opens website (The H)
Posted Apr 8, 2011 1:13 UTC (Fri) by JoeBuck (subscriber, #2330)
The second case is assignment to a profit-making company, in exchange for basically nothing, with all rights going to that company. There are certainly situations where I might consider accepting that (e.g. to get a small patch in to code I rely on), but it's not a good deal at all.
Maybe there's a third alternative, like authorizing some trusted group to make one's software available under some additional FLOSS license under certain narrow circumstances, to keep projects out of corners where they have to choose which code they can no longer use.
Posted Apr 8, 2011 16:37 UTC (Fri) by error27 (subscriber, #8346)
So not needed and harmful is probably an accurate description.
Posted Apr 8, 2011 18:27 UTC (Fri) by dlang (✭ supporter ✭, #313)
the people who died can't sue you, but their heirs can.
Posted Apr 8, 2011 22:49 UTC (Fri) by JoeBuck (subscriber, #2330)
Posted Apr 8, 2011 1:22 UTC (Fri) by droundy (subscriber, #4559)
Anyhow, I'd be happy to sign such a thing (modulo which options were chosen and my level of trust in the company). I'm not sure that I'd bother, if I didn't have strong desire to contribute to a given project, but that's another issue. As you say, I don't think it's necessary, but I can certainly see that companies large enough to be tasty targets of lawsuits might prefer to have some documentation that contributors claim to have the rights to the code they contribute, and to be willing to contribute said code under a given license. And keeping the flexibility to relicense can be a *very* good thing.
Posted Apr 8, 2011 16:00 UTC (Fri) by aliguori (subscriber, #30636)
The Harmony CA with Option Three and Option Four are pretty reasonable.
However, Option One and Option Two are basically proprietary software in sheep's clothing. The fact that a reasonable CA is going to share it's name with an entirely unreasonable one is pretty unfortunate.
Posted Apr 8, 2011 16:16 UTC (Fri) by droundy (subscriber, #4559)
Compare, for instance:
which is the CA needed to contribute to golang. Go is under a very liberal BSD-like license ("proprietary software in sheep's clothing", to use your language), so the options 1 and 2 would be harmless... and in fact all the options would be harmless, in that they wouldn't give Google any additional rights that the primary license doesn't also give them.
I prefer copyleft licenses, but have no strong objection to licenses that are more liberal, particularly if they're GPL compatible so that (in case of nuclear war) the community could retaliate to a proprietary fork with a GPL fork.
Posted Apr 8, 2011 18:29 UTC (Fri) by jspaleta (subscriber, #50639)
But when code is (L)GPL licensed the terms of the associated CA can change the playing field drastically and can be a significant barrier for projects that should be co-developed by people and entities which have their own business interests to look after. A CA which allows one party to proprietary relicense gives that one party a significant business advantage over other parties. In the calculus of business dynamics that is easily viewable as a situation to avoid. It also allows one party to financially profit from the contributions of others without any equitable trickle back. This can be viewed as taking unfair advantage of cheap labor for financial gain by a for-profit entity. Those who argue this is okay are deliberately devaluing the contributed labor and utterly misunderstand how the FOSS ecosystem works as a marketplace which builds _value_ into the commons.
That being said CAs _can_ be done in a way that nullifies these concerns. The devil is in the details, and the Harmony language I don't think goes far enough to express that level of detail necessary to make the proprietary options reasonable.
If a CA has strong promise back clauses or liberal re-licensing clauses which engage if the central authority oversteps prescribed limits of its proprietary re-licensing authority then a CA can be a reasonable compromise between the interests of the central authority and contributor interests.
The FSF's evolving promise-back language in its CA tries very hard to mitigate the unfairness inherent when a CA is used with (L)GPL code while still giving the FSF the authority to re-license in good faith to meet its foundational objectives without giving any single entity a marketplace advantage or taking unfair advantage of contributor labor. I believe Harmony's draft language has an option that attempts FSF like use of a CA which explicitly does not include proprietary licensing.
And I think Trolltech's CA that was used with (L)GPL'd Qt in the past also made a reasonable attempt at a compromise concerning proprietary licensing. I don't see the Harmony draft language covering this case at all. I don't see any language in the Harmony draft that puts reasonable compromise limits on proprietary licensing of contributed code.
The old Trolltech CA used a non-profit entity structure as a sort of code escrow authority. If Trolltech stopped shipping the open licensed code, and made it available only as a proprietary option, a clause latched which permitted the non-profit entity to re-license the code as BSD which anyone could then turn into a proprietary offering. This did give Trolltech a marketplace advantage as it gave them sole ability to make proprietary licensing deals. But that advantage only existed under the condition that they continued to provide (L)GPL code. If they got greedy, the BSD relicensing doomsday clause kicked-in allowing new vendors to compete in proprietary offerings without TrollTech's blessing. Not perfect, but definitely a reasonable compromise to restrain future corporate bad faith activity. But it doesn't solve the problem of project co-development by multiple business entities in the same way the FSF's use of a CA does.
License agreement (I assert it's legal) vs. Assignment
Posted Apr 8, 2011 21:43 UTC (Fri) by david.a.wheeler (guest, #72896)
I agree that assigning copyright to a non-profit is different than assigning copyright to a for-profit, but there's another issue as well.
There are fundamentally two different kinds of agreements that Project Harmony is working out: a "contributor license agreement" and a "contributor assignment agreement". The "license agreement" looks quite innocuous; it lets you assert that you have the legal right to release this back. Several projects do this sort of thing, because it gives them a somewhat better protection against those who claim something was illegally contributed. The "assignment" is the big issue; that actually hands over rights, so that the recipient will have more rights than the contributor (e.g., to relicense).
I can see the point of these, but I know that I (and many others) will continue to be leary of assignments. I will sign assignments occasionally, especially for non-profits; for example, I've signed an assignment with the Free Software Foundation. But requiring any of these agreements creates red tape that slows down development; assignments cause even more problems, and assignments to for-profit organizations is a BIG flag.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds