a dissenting opinion: this is useful [LWN.net]

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 12, 2011 4:17 UTC (Tue) by zooko (subscriber, #2589) [Link]

Thanks, Jon. I've read these articles when they came out and I just now read them again for good measure.

I recognize that there are legitimate concerns, especially several of the sagas around SunOracle (which you, Jon, correctly predicted and which I at the time dismissed as FUD).

But on the other hand, I think the community consensus on lkml and lwn.net is too one-sided.

My own experience with Tahoe-LAFS is that whenever contributors would offer patches that were substantial, I would politely ask them if the for-profit company that I then worked for (allmydata.com) could please have the rights to do whatever we wanted with the patches. With two exceptions they all said "sure". The two exceptions said they didn't want to give those rights to a for-profit company, and so we said "fine". (Their two contributions were in auxiliary modules rather than in the core and they turned out to be modest.)

It didn't seem to me that anybody was deterred from contributing because of my practice of asking for this permission, and it didn't seem to me that we suffered from communication problems because of it.

My experience in this parallels the recollections of L. Peter Deutsch about Ghostscript in his interview with Stig Hackvan: http://devlinux.org/deutsch-interview.html . (Note: Raph Levien told me in personal communication that later there were problems with Ghostscript's dual-licence model which is why they changed it to be GPL-only. However, I don't remember him telling me specifically what the problems were and his recollections aren't in the public record where I can look them up and cite them.)

Re-reading Michael Meeks's article today gives me more reservations about his position. For example, he says it took a few weeks to get his first copyright assignment to FSF and then his patch languished without review or merge for years, which deterred him from contributing further. Then he says that he wondered if the delay due to copyright assignment partially caused the larger delay. Well maybe, maybe not! The real deterrent was the years of not-accepting his patch, not the weeks of waiting for paperwork, and failure to review a patch happens far too often, with or without copyright assignment.

For another example, he cites the existence of XEmacs as a demonstration that some people prefer not to assign copyright (in this case to FSF for GNU Emacs). Okay, that's fair, but at the same time the greater rate of contributions to GNU Emacs and the more vibrant community of contributors must be taken as a demonstration that some people are fine assigning copyright and this doesn't necessarily derail a project.

I just think we don't need to be doctrinaire about this. Maybe one size doesn't fit all. Maybe it's okay if some projects try different copyright assignment policies.

Almost all open source projects fail to attract any contributors at all, and that's true regardless of whether they require copyright assignment or not. A few open source projects attract lots of contribution, and both approaches are present in that set too.

People have asked me how I succeeded at attracting contributions to Tahoe-LAFS. My answers are: (a) we just got lucky, (b) we had (and have) an exciting and potentially important system with working code (which was more due to Brian Warner than to me), and (c) our community is friendly and polite.

Regards,

Zooko

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 12, 2011 7:09 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

I don't think you can ignore the ample examples of major projects including Openoffice.org, Upstart and Java where copyright assignment agreements have caused significant strain on the project and forks or alternatives that explicitly promote the fact that there is no copyright assignment required in their projects. Libreoffice and systemd being the most recent examples of this.

Yes, you might able to get away with it and yes, it might not have affected your project much but it is not easy to assert that and I do wonder how many didn't even bother to send patches because they were aware of this requirement. If you want to lower the barrier to entry and create a neutral ground for all contributors that doesn't favor one company or individual over other, then I would certainly recommend that you consider dropping it.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 3:11 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

In the upstart -- systemd case there was not really a fork (there are several "dependency-based" init systems floating around in any case), but a fundamental technical difference in handling of dependencies. The other cases are as you state, AFAIU.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 3:54 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I did say forks or alternatives. You seem to have overlooked that.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 16:31 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

I still think its a stretch to lump in systemd and upstart into this argument. I think the difference of opinion there is primarily one of technical design not the politics of copyright. The assignment issues around upstart may have complicated things and kept people from communicating, but I'm not sure removing the assignment policy would have changed the course of events. At least that is my reading of things.

I think it weakens the argument you are making to include them as examples, unless you can point to some sort of previous discussion in the context of upstart development where good-faith contributions from contributors were turned aside by the assignment policy requirement. I'm not aware of that ever happening.

I think what is happening right now with LibreOffice stands up by itself as an unfolding relevant case study to make the point.

Though I would like to see if the clutter development experience has something interesting to add. When clutter dropped its assignment policy did contributor activity rise in a noticable way?

A certain individual has argued in private with me that business entities,such as the one that previously required assignment to clutter, only drop the assignment requirements after they are no longer incentivised to lead the development. Essentially the argument made to me was that dropping assignment is a "we wash our hands of it..throw it over the wall..and let the community have the scraps" action on the part of most business entities. Pardon me from interpretatively paraphrasing from a private conversation. I did have the foresight to obtained permission to archive and republish the short conversation. You can read the argument in the context of the conversation from Sept, 2010 here:
http://jspaleta.fedorapeople.org/A_conversation_with_Mark...

I don't think opinions on the matter have changed. The people who walked into the Harmony discussion in favor of for-profit assignment still feel that way. The people who came in against it, still feel that way.

Nor do I think Harmony as drafted are going to change the character of the dispute. Harmony is a codification of the battlelines. I know some people are _hopeful_ that some for-profit entities who switch from in-house contributor agreements to Harmony drafted agreements will be choosing more contributor friendly options. But I don't see any evidence of that. And I don't plan to give any for-profit entity the benefit of the doubt on that score. Whether you choose a Harmony statement or not is not important. It is the specific choice and the details that matter. I don't plan to pat any entity on the back for choosing a Harmony option that requires assignment to a for-profit with sufficient promisebacks to protect the long term interests of the uncompensated contributor.

The Harmony drafts allow for pretty much all the bad for-profit behaviour that is currently allowed now. At best Harmony will make it easier to identify. At worst Harmony will give for-profits political cover that they can hide behind when their choose unfair/unbalanced assignment policies instead of the more reasonable Harmony options.

-jef

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 17:26 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

"I think it weakens the argument you are making to include them as examples, unless you can point to some sort of previous discussion in the context of upstart development where good-faith contributions from contributors were turned aside by the assignment policy requirement. I'm not aware of that ever happening."

Technical design might be the more important reason for systemd but it is clear that copyright assignment requirements played a role and while what you have suggested is one way to look for the impact, I think it is far from the only way. For instance, the questions one can ask include, how many developers were turned away from ever submitting patches because of the requirement? Among the active systemd developers, which ones felt more motivated to systemd because it explicitly advertised the fact that no copyright assigned is required? Did it influence adoption by distributions? and so on. I don't purport to know the answers to these questions but I disagree that it is not a valid example although it might not be as big a instance as Openoffice.org vs Libreoffice.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 17:34 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

"What ifs" when it comes to trying to estimate the number of people who refused to engage because of assignment is difficult to use effectively as a rhetorical tool. We don't have a reliable measure or even estimate on that. From a strategic messaging standpoint I shun making that particular argument unless I can find at least one example of a specific contribution submitted in good faith which was turned away because an assignment wasn't agreed to. I have such historic examples for other codebases that require assignment. I don't have one handy for upstart.

-jef

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 18:07 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

My goal is not rhetoric or strategic messaging or whatever. I can reliably point out that when systemd was launched, the first blog post describing the project pointed out the lack of copyright assignment as a advantage when comparing itself to upstart and it is clear that developers involved view it as such. No doubt about that and that by itself establishes the negative impact.

Whether patches submitted to a project were rejected on the basis of such a requirement is not a very interesting way to measure the impact as far as I am concerned because anyone who looks at contributing to a project and realizes there is a requirement to assign copyright would just not bother submitting any patches in the first place. If you are interested enough, you can talk to the developers involved and find out more. I have but there is no public reference for you so you will have to do the leg work yourself to find out more.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 18:06 UTC (Wed) by zooko (subscriber, #2589) [Link]

> I do wonder how many didn't even bother to send patches because they were aware of this requirement.

I'm pretty sure this wasn't the case, as we didn't publicly mention this requirement anywhere.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 18:40 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I remember discussing the strategies for copyright assignment for this project with you right here in LWN which is a public forum and if you haven't mentioned such a requirement in the developer oriented documentation, you should and do so prominently. I would consider it cheating and would be deeply disappointed if I spend time and effort writing a patch for a project only for the maintainers to let me know after the fact, that need me to sign over a legal agreement that grants them rights to use the code however they please before accepting my patch.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 20:08 UTC (Wed) by zooko (subscriber, #2589) [Link]

It's not so much a "requirement" as a polite request. Two people politely declined, around a dozen or so (including all of the most prolific and valuable contributors) readily agreed. I don't want to complicate the developer documentation and distract people from writing code by adding that fact to the developer documentation.

Which, I suppose, definitely proves one of the points against such contributor agreements. Perhaps I should reconsider and add a mention about that to the developer docs.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 21:01 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Requests are entirely different than a codified requirement.

I think its entirely ethical for a central authority, even a for-profit one, to make that sort of request as long as they contributor really does have the ability to say no. As long as the incorporation of contribution in question is not held up because of a lack of requested assignment, then I don't see a problem with.

I have no problem with contributors choosing to gift their copyrights as long as its a gift freely given with no explicit or implicit strings attached with regard to their standing as a contributor or the incorporation of their submitted work.

-jef

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 14, 2011 5:02 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

"It's not so much a "requirement" as a polite request."

Unless you would accept a patch without the contributor signing the legal agreement, I would say it is still a requirement albeit a politely worded one. There is nothing inherently wrong with requirements as long as they are explicit.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 14, 2011 14:54 UTC (Thu) by zooko (subscriber, #2589) [Link]

Actually we *did* accept patches to add-on modules without this grant of rights. I don't actually *know* if we would similarly accept patches to the core without that grant of rights. Maybe somebody reading this should test my resolve by writing some really awesome patches and then offering to support them in Tahoe-LAFS but not to grant us all the rights. :-)

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 12, 2011 7:55 UTC (Tue) by spaetz (subscriber, #32870) [Link]

> I would politely ask them if the for-profit company that I then worked for (allmydata.com) could please have the rights to do whatever we wanted with the patches. With two exceptions they all said "sure".

Why don't you just license your project under an MIT license then? The issue that I see, is that of complexity. Licensing is already hard to understand. Even for lawyers, not to speak of code contributors. So when there are licenses out there that can solve the goals that you have in your project, why not simply use these?

By introducing *another* complex legal document that interacts with the first one, the legal subleties become so complex that they are very hard to grok.

Reading the harmony options is hard, then thinking about how those options interact and interfere with the rights and limitations set out for various licenses is HARD:
- If I sign over copyright, and get a liberal license can I still sue, or only you?
- If I license contributions under the MIT license, what are the additional rights you get?
- If I contribute as part of my job, is it legal for me to sign away my copyright (ie in might be my employers copyright in the first place and they might have opinions about giving away their copyright)
- Licenses are already hard enough to apply in all jurisdictions, what about CAs. Now, you'll have different status for people contributing from countries where you can sign off copyright, compared to those where you can't (I *believe* e.g. in Germany you can't). More complexity.

I know all these questions are probably answered somewhere, but they are questions that come on top of licensing issues, and that puts me off.

Using 2 complex legal agreements when most of the goals can be reached with a single one does not sound appealing to me, I mean there are plenty of people who haven't even fully gotten the GPL, and now you expect contributors to become lawyers just to submit a bugfix? :-)

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 12, 2011 13:52 UTC (Tue) by wahern (subscriber, #37304) [Link]

"If I contribute as part of my job, is it legal for me to sign away my copyright (ie in might be my employers copyright in the first place and they might have opinions about giving away their copyright)."

I scanned over the text of one of the documents and what struck me was that the contributor represents that he has authority to transfer the copyright. That means that if you're wrong, they're protecting their ability to sue you. Such things are boilerplate in rights transfers, but what, exactly, are you getting out of the exchange for potentially opening yourself up to more or easier liability?

With that clause in there, unless there's no doubt about your rights in the work (i.e. you're unemployed and a hermit), a prudent person should think twice about making such an open ended representation without any compensation.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 12, 2011 21:22 UTC (Tue) by wahern (subscriber, #37304) [Link]

Looks like the FSF assignment has similar representation language:

I hereby represent and warrant that I am the sole copyright holder for the Work and that I have the right and power to enter into this contract. I hereby indemnify and hold harmless the Foundation, its officers, employees, and agents against any and all claims, actions or damages (including attorney's reasonable fees) asserted by or paid to any party on account of a breach or alleged breach of the foregoing warranty.

(http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/assign.changes.manual)

Fraud is illegal. Erroneously authorizing rights is also illegal, and has the same strict liability as use infringement.

Subject to sections 107 through 122, the owner of copyright under this title has the exclusive rights to do and to authorize any of the following.... 17 U.S.C. 106.

It just seems a little gratuitous for individual contributors (as opposed to corporate contributors) to indemnify the FSF when the contributor already has every motivation to be honest. A lone programmer is not much of a target for litigation, but the FSF is a larger target, and by indemnifying the FSF a contributor has significantly increased their own exposure. But I guess if the chance of the FSF actually being sued is miniscule, it hardly matters.

Interestingly, the Ubuntu agreement seems much more favorable to the contributor:

9. I have not created or assigned to Canonical the Assigned Contributions in breach of My employment or any other contract.

10. To the best of My knowledge I have the legal right to enter into this assignment and have not infringed any third party's intellectual property rights in creating and assigning the Assigned Contributions to Canonical.

(http://www.canonical.com/system/files/Canonical%20Contributor%20Agreement%2C%20ver%202.5.pdf)

Two noteworthy differences here. There's no express indemnification. But also the catch-all clause 10 requires knowing breach or infringement, which is infinitely more fair to the contributor. So unless he gets wrong the work for hire status or other contractual interest in the contribution (strict representation in clause 9), his exposure is much less. Although, the applicable law is nominally English law according to clause 12. But unless English law implies those things just discussed then on first blush, kudos to Ubuntu.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 14, 2011 2:26 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

You're not reading the indemnification language correctly. The only thing you're indemnifying the FSF for is if it turns out that your claim that you are the sole copyright holder turns out to be incorrect (e.g. you passed off others' work as your own).

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 14, 2011 4:04 UTC (Thu) by wahern (subscriber, #37304) [Link]

Right. But that can happen accidentally. But per the terms it doesn't matter whether it was an accident or not.

By way of example, let's say that hypothetically some court says that interfaces are copyrightable, like Oracle claimed for Java. All of a sudden that contribution of code implementing the Java API is infringing. Or rather, it was always infringing, but only now do you know that.

Or you're an employee of a software company. The free software code you wrote happens to be so related to your company's business interests that it falls within the scope of your employment, so the code is theirs. The FSF probably tries to screen these people in their questionnaire, but they can't always be right about it.

There are tremendous grey areas in copyright law, and the FSF clause shifts most of the repercussions of this onto you. That's its very purpose. If they didn't want to do this, they would have qualified it with a variant of something like "known or should have known". The Ubuntu language, "to the best of my knowledge", is even more pro-contributor.

Also consider that you're indemnifying for any "alleged breach." So maybe you were in the right, but the FSF chose to settle out of prudence. You're still on the hook. But now let's say you can find a way around the language, or that my interpretation is totally bogus. My interpretation isn't so bogus that you won't be forced to spend thousands of dollars on an attorney to make your case.

But now let's say that we all agree none of the FSF officers would ever willing do any of this. (Which probably goes without saying.) I don't know much about non-profit governance, but if it were a for-profit corporation the benevolence of the officers doesn't matter much. If they don't sue they could possibly be on the hook for shirking their duty to protect the corporation.

None of this is worth discussing anymore, though. Frankly, I was just surprised that these organizations would use this language, and even more surprised that Ubuntu didn't. In reality we all take much greater legal risks every day.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 14, 2011 9:53 UTC (Thu) by mjw (subscriber, #16740) [Link]

Not disputing that there are always legal risks in whatever activity you do, but I think at least some of your worries in this case are somewhat covered.

> it was always infringing, but only now do you know that.

In my contract with the FSF it explicitly says "(to the extent known to Developer)".

> The free software code you wrote happens to be so related to your company's business interests that it falls within the scope of your employment, so the code is theirs.

They also send you a separate company disclaimer of rights which you can then let your company sign. You can keep that on file (or also send to the FSF) to show they were aware and approved of your actions.

> Also consider that you're indemnifying for any "alleged breach."

In the FSF contract I got it says "Developer is not obliged to defend FSF against any spurious claim of adverse ownership, but will cooperate with FSF in defending against any such claim"

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 13, 2011 21:43 UTC (Wed) by zooko (subscriber, #2589) [Link]

> Why don't you just license your project under an MIT license then?

Because we didn't want (other) companies to be able to make proprietary derivatives and redistribute them. At least not without paying us.

in defense of "contributor agreements" or whatever they are called nowadays

Posted Apr 21, 2011 16:04 UTC (Thu) by farnz (guest, #17727) [Link]

At a really, really trivial level: I work for a company that uses Linux. When I work on an open source project, I am permitted by my contract of employment to contribute my work upstream under the licences the upstream project offers me, provided my employer retains ownership of the copyright. If you ask for a copyright assignment, I have to get the Board of Directors to approve the resulting paperwork. So, I can contribute to the kernel under GPLv2, to X.org under their permissive licence, without going up to the top; I can't contribute to GCC easily, due to the need to get copyright assignment in place, although I can offer a patch under GPLv3 or any later version as long as my employer retains the copyright.

Practically, this means I'm keen on throwing patches at upstream if they don't need copyright assignment, and doing major rewrites as needed to get them to take the feature, where I don't have to maintain it (I'm in the middle of a rewrite for upstream now - and doing the work requested has explained and indicated a fix for at least one bug). If you need copyright assignment, I'm going to be put off contributing due to the hassle.