| |||||||||||||
Project Harmony opens website (The H)Project Harmony opens website (The H)Posted Apr 8, 2011 0:38 UTC (Fri) by pabs (subscriber, #43278)Parent article: Project Harmony opens website (The H)
Isn't the general consensus that contributor agreements are at least unnecessary and at worst actively harmful? Skimming over the draft agreements, personally I wouldn't consider signing these.
(Log in to post comments)
Project Harmony opens website (The H) Posted Apr 8, 2011 1:13 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] I would distinguish between two cases. The first case is assignment to a nonprofit that's committed to keeping the software free, with a contributor agreement that provides some protections. This has some problems but also some advantages; it certainly makes relicensing easier when it needs to be done. GCC recently made the license on some support files more permissive, since they should have had the "runtime exception" language but this was overlooked. We only had to convince one stubborn person, instead of needing to contact any number of people, some of whom might not even be alive (GCC's been around since the 1980s after all).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.
Project Harmony opens website (The H) Posted Apr 8, 2011 16:37 UTC (Fri) by error27 (subscriber, #8346) [Link]
The GNU copyright contributions are still harmful. They've caused forks and driven away potential contributors. The kernel has no copyright agreements but it's been more useful in enforcing the GPL. GCC could still be relicensed by using the GPLv2+ license. If you need to change the license entirely, that's maybe trickier, but lots of projects have relicensed by asking individual contributors. Btw, the people who died can't sue you.
So not needed and harmful is probably an accurate description.
Project Harmony opens website (The H) Posted Apr 8, 2011 18:27 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
slight clarification
the people who died can't sue you, but their heirs can.
Project Harmony opens website (The H) Posted Apr 8, 2011 22:49 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] Yes, for anything with commercial value, if anything heirs are more likely to sue, and it's not safe to assume that they won't. Anyone out there who owns copyright in important FLOSS software, please include what you want to happen to that software on your death in your will. We've had a number of important contributor die recently, you aren't immortal.
Project Harmony opens website (The H) Posted Apr 8, 2011 1:22 UTC (Fri) by droundy (subscriber, #4559) [Link]
I'm not a huge fan of contributor agreements, but at least the "Harmony Individual Contributor License Agreement" looks pretty reasonable and potentially innocuous. It's got reasonable options that limit the company in terms of which license they can choose to redistribute the code under. You promise that you've got rights to the code and that you can't sue them (or any of their sublicensees) for any patents to the code you contribute.
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.
Project Harmony opens website (The H) Posted Apr 8, 2011 16:00 UTC (Fri) by aliguori (subscriber, #30636) [Link]
Actually, I think the options make it pretty evil.
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.
Project Harmony opens website (The H) Posted Apr 8, 2011 16:16 UTC (Fri) by droundy (subscriber, #4559) [Link]
But it's a CA, not a license. Surely people won't be signing a legal form based on its name? But having a guideline for CA's so that they are kept reasonably short and simple and reasonable readable seems like quite a bonus.
Compare, for instance:
http://code.google.com/legal/individual-cla-v1.0.html
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.
Project Harmony opens website (The H) Posted Apr 8, 2011 18:29 UTC (Fri) by jspaleta (subscriber, #50639) [Link]
Yes the issue is and is always been how CA's interact with the copyright license. When code is BSD or MIT licensed, it is difficult for CA's to give any party an advantage over another. Not impossible but certainly difficult.
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.
-jef
License agreement (I assert it's legal) vs. Assignment Posted Apr 8, 2011 21:43 UTC (Fri) by david.a.wheeler (guest, #72896) [Link] 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.
|
|||||||||||||