| |||||||||||||
Not all contributor agreements are created equalNot all contributor agreements are created equalPosted May 12, 2011 5:27 UTC (Thu) by rickmoen (subscriber, #6943)Parent article: Ubuntu developer summit
I respect and appreciate Jono Bacon's polite but pointed reference to Canonical's problematic 'contributor agreement'. Canonical impose it for, I believe, all software projects they sponsor, including Upstart, Bazaar, etc.: It's important to realise that this is simply not the sort of licence grant normally implied by that term, as with, e.g., Apache Software Foundation's implementation of that idea.
It's not a contributor agreement at all, really. Rather, it's an outright transfer of copyright ownership, directly and categorically, from the coder to commercial firm Canonical, Ltd. Your work becomes literally their property, to do with exactly as they please, from that point forward, free of charge.
ASF, by contrast, don't insist on owning your work. Additionally, although ASF's Contributor License Agreement does give ASF broad rights, it conditions those rights on ASF never using your property 'in a way that is contrary to the public benefit or inconsistent with [ASF's] nonprofit status and bylaws in effect at the time of the Contribution'. And, as with FSF, ASF's commitment to that effect has credibility earned over a long period, which cannot be said of Canonical, Ltd., even if they made a similar commitment, which they do not.
Rick Moen
(Log in to post comments)
Not all contributor agreements are created equal Posted May 12, 2011 9:37 UTC (Thu) by dgm (subscriber, #49227) [Link]
Yet I still think that copyright transfer makes sense in some cases. Namely, when your contribution is "trivial" (think a bug fix). What's the point of keeping the copyright of a handful of lines of code? It only serves to complicate matters for everybody (maybe that's what Marc was referring to, otherwise I cannot make sense of the plant analogy).
Substantial contributions are a complete different thing, though. I don't think that copyright assignment is a good idea in such cases, unless you truly trust the receiver.
Not all contributor agreements are created equal Posted May 12, 2011 9:47 UTC (Thu) by AlexHudson (subscriber, #41828) [Link]
I roughly agree with that, but I'm not sure "lines of code" is a good metric for substantiveness. Sure, something which is around 10 lines is probably not substantial whatever it's doing (it's arguable you even have a copyright interest in something really trivial).
But on an ongoing basis, does it matter if the thing you've contributed is only 100 lines if it's doing something rather clever and really improves the software? Likewise, if you contribute twenty 10-line patches, are they insubstantial?
Trying to draw this line is why I think all contributors should be treated equally; otherwise it just becomes a divisive issue about trying to weigh the contribution people are making, and that's about as ungracious as you can get.
Not all contributor agreements are created equal Posted May 12, 2011 10:56 UTC (Thu) by dgm (subscriber, #49227) [Link]
indeed, I forgot to mention that the trouble is in agreeing with the meaning of "trivial".
But there's no need for project maintainers to value contributor's code. Let'em do it themselves. Offer two sets of terms under which you will accept contributions: copyright assignment (for "trivial" stuff) and copyright retention for "substantial" stuff), and let their common sense do the work. And if you feel like it, you can always retain the right to reject patches offered under the "wrong" terms.
Not all contributor agreements are created equal Posted May 21, 2011 16:51 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]
Even then, saying "oh, your contribution is not substantial, so give the code to me or I won't take it" simply doesn't seem friendly...
Trivial bug fixes Posted May 12, 2011 12:50 UTC (Thu) by corbet (editor, #1) [Link] A "trivial bug fix" probably does not contain anything which is subject to copyright in the first place, so the ownership issue is moot.
Not all contributor agreements are created equal Posted May 13, 2011 2:23 UTC (Fri) by rickmoen (subscriber, #6943) [Link] dgm wrote:What's the point of keeping the copyright of a handful of lines of code? You ask that as if doing so created a problem. In my experience (in the general case), it doesn't. Bugfix patches traditionally don't even include an author-credit comment line, so the codebase maintainer cannot be even said to be burdened by an overflowing credits list. So, no, it doesn't 'complicate matters for everybody'. In fact, it doesn't require anybody to do anything they're not already doing by default. The codebase maintainer's only burden, actually, is to avoid injuring the property interests of the various copyright holders, who might otherwise sue if they can prove 'actual damages' from copyright infringement, which for all practical purposes can happen only by purporting to adopt a new licence grossly out of step with the existing one. And that raises the more important question: Why is the codebase maintainer seeking copyright assignments? There's really only the one, obvious reason: The maintainer wants the option to use other people's property in ways they might not consent to, e.g., in proprietary forks, and wishes to avert that problem through complete ownership. Strictly speaking, by the way, the author of a bugfix patch might not even gain copyright title at all. Copyright arises only from works with 'some minimal degree of creativity' (see Feist Publications decision). Code that is purely functional or for compatibility with existing interfaces thus might not be copyright-eligible (something only a judge could decide). More important, alleged owners of unregistered copyright over a very small contribution would seldom have much in the way of available remedies. Rick Moen
Not all contributor agreements are created equal Posted May 16, 2011 20:39 UTC (Mon) by job (guest, #670) [Link]
Requiring copyright transfer is a good way of making sure you only receive trivial patches.
|
|||||||||||||