Yesterday I got email from a project asking me to wear my tribal-elder hat, looking for advice on how to re-invent its governance structure. I’m not going to name the project because they haven’t given me permission to air their problems in public, but I need to write about something that came up during the discussion, when my querent said they were thinking about requiring a contributor release form from people submitting code, “the way Apache does”.
“Don’t do it!” I said. Please don’t go the release-form route. It’s bad for the open-source community’s future every time someone does that. In the rest of this post I’ll explain why.
Every time a project says “we need you to sign a release before we’ll take your code”, it helps create a presumption that such releases are necessary – as opposed to the opposite theory, which is that the act of donating code to an open-source project constitutes in itself a voluntary cession of the project’s right to use it under terms implied by the open-source license of the project.
Obviously one of those theories is better for open source – no prize for guessing which.
Here is the language NTPsec uses in its hacking guide:
By submitting patches to this project, you agree to allow them to be redistributed under the project’s license according to the normal forms and usages of the open-source community.
There is as much legal ground for the cession theory of contribution as there is for any idea that contributor releases are required for some nebulous kind of legal safety. There’s no governing statute and no case law on this; no dispute over an attempt to revoke a contribution has yet been adjudicated.
And here’s the ironic part: if it ever comes to a court case, one of the first things the judge is going to look at is community expectations and practice around our licenses. A jurist is supposed to do this in contract and license cases; there’s some famous case law about the interpretation of handshake contracts among Hasidic Jewish diamond merchants in New York City that makes this very clear and explicit. Where there is doubt about interpretation and no overriding problem of of equity, the norms of the community within which the license/contract was arrived at should govern.
So, if the judge thinks that we expect contribution permissions to fail closed unless explicitly granted, he/she is more likely to make that happen. On the other hand, if he/she thinks that community norms treat contribution as an implied cession of certain rights in exchange for the benefits of participating in the project, that is almost certainly how the ruling will come out.
I say, therefore, that Apache and the FSF and the Golang project and everybody else requiring contributor releases are wrong. Because there is no governing law on the effect of these release forms, they are not actually protection against any risk, just a sort of ritual fundament-covering that a case of first impression could toss out in a heartbeat. Furthermore, the way they’ve gone wrong is dangerous; this ritual fundament-covering could someday bring about the very harm it was intended to prevent.
If your project has a contributor release, do our whole community a favor and scrap it. Any lawyer who tells you such a thing is necessary is talking out his ass – he doesn’t know that, and at the present state of the law he can’t know it.
(My wife Cathy, the attorney, concurs. So this advice isn’t just a layperson vaporing in ignorance.)
Instead, post a contract of adhesion on your website or in your guide for contributors. Use my language, or edit to taste. The one thing you should be sure stays in is some language equivalent to this part: “according to the normal forms and usages of the open-source community”.
That is important because, if it ever comes to a court case, we want to be able to point the judge at that as a clue that there are normal forms and usages and he/she can do what he’s supposed to and almost certainly wants to do by understanding them and applying them.
If there is ever need to provide chain of provenance, “Signed-off-by” trailers in commit message and file with Developer’s Certificate of Origin – description what does it mean – in the documentation should be enough… and provides much, much less friction to contribution than requiring formal _contributor license agreement_.
ICLAs have the problem that a project cannot actually know if the person who signed it is authorized to contribute the code. This happens when the contributor is an employee. There is an additional problem that all CLAs are written such that even if the contributor is authorized by their employer to contribute the patch, the language of the CLA is such that it would require someone with the necessary signing authority and executive control, e.g. an EVP or higher. Who is not going to be spending time with CLAs. So corporations and orgs instead just do the kabuki theater of ICLAs and hope this doesn’t blow up in everyone’s face someday.
CCLAs have all the same problems as ICLAs, plus if any player tries to take them seriously, they cause a N-squared-times-M combintoric explosion where N is the number of companies in the world and M is the number of open source projects in the world. Nobody actually keeps track of that, and thus again, it is just kabuki theater that everyone hopes won’t explode in everyone’s face someday.
(mandatory disclaimer: I do not speak for my employer. This is just personal opinion born out of decades of mucking around in kind of work.)
Mark, for the benefit of my readres without in-the-tranches experience, would you please unpack the acronyms ICLA and CCA and explain how they differ?
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201106.mbox/%3C4E0B6848.5070700@gmail.com%3E
Individual Contributor License Agreement vs Contributor License Agreement vs Corporate Contributor License Agreement
My comment seems to have been truncated to nothing. In case the form is looking for minimum length, I pad.
“in-the-tranches experience”
groan
Instead, just make contributors agree NOT to ever participate in an SJW “code of conduct”.
That’s also treacherous to the spirit of open source, though, isn’t it?
“You can’t contribute here if you agree under badthink conditions elsewhere” is … the same sort of corrosive tactics, and who decides which codes of conduct count?
No, just no, even for a “good cause”, no.
ICLA is Individual Contributor License Agreement. CCLA is Corporate Contributor License Agreement. I see the links are already posted, thank you. A common variant of the latter are ones written for government contributors and for edu contributors. They are still all bullshit, for the reasons I already stated.
“But what about the FSF?”, people ask. Their agreement is not a contributor license agreement, but is instead a license ASSIGNMENT. A license agreement, you still own the copyright of the patch you write, you just assert a specific open source license over your contribution. A license assignment, you give the legal title and ownership.
The FSF is just about the only org that a corp is willing to do an open source assignment to. Maybe.
When corps modify the Apache CLAs or even worse write one from scratch, they love to sneak in a copyright assignment, which is the reason why corps insist on a full legal review of every CLA that is not a simple clone of the Apache CLA text.
As a professional open source policy wonk, I will now assert that a project that has a required contributor license ASSIGNMENT to a for-profit corporation is NOT an “open source project”, even if it has an open source license. When you see a corp complaining that other corps are not contributing to “their” “open source project”, look for that pattern, and all will be made more clear.
About the Apache CLAs. The Apache Foundation does not require a CLA for contributions to their projects, and the Apache license does not require a CLA for contributions to any random Apache licensed project. There are people who have cargo-culted that the ASF or the Apache license does, but they are wrong.
The ASF does require a CLA from the people who have commit rights to an official ASF project. In Git terms, you dont need to sign a CLA to create a pullrequest or mergerequest, but you do need to sign their CLA if they give you “git push to master” permissions. This was a bigger deal in the SVN era.
So, what SHOULD a project do? If you can, do what NTPsec does, and put a statement in the CONTRIBUTIONS file. And possibly also put a statement in your pullrequest tempate or merge request template.
If your lawyers really really insist on something, do the DCO.
If they still push back, have them call me. Or maybe grit your teeth and use the Apache CLA *UNMODIFIED*.
As an example, see:
https://github.com/awslabs/s2n/blob/master/.github/PULL_REQUEST_TEMPLATE.md
Snd the “Contributing to” section of https://github.com/awslabs/s2n/blob/master/docs/DEVELOPMENT-GUIDE.md
If it’s good enough for my lawyers who approved that, I should like to hope that it should be good enough for your lawyers.
>If your lawyers really really insist on something, do the DCO.
What’s a DCO?
DCO = Developer Certificate of Origin
https://developercertificate.org/
Basically, stating what “Signed-off-by:” trailer line in commit message means.
I am a bit confused about terminology. I don’t think “Contributor Agreement” means what you think it means – you are talking about “Contributor License Agreement”.
From what I understand, it goes like this:
* Contributor Agreement is a simple statement that you submit the changes, and that you give license to the project to use those changes
* Contributor License Agreement is formal contract to give changes under specific license or set of licenses (possibly also agreeing to changing the license), saying that you have rights to submit the code
* Copyright Transfer Agreement (or Copyright Assignment) is transferring the rights to code to the organization; as far as possible it is changing the authorship of the changes; FSF used to recommend this for GNU projects, IIRC.
I think there was an LWN.net article about the difference, but I cannot find it now. The closest is the article that agrees with what you wrote: https://lwn.net/Articles/592503/
>I am a bit confused about terminology. I don’t think “Contributor Agreement” means what you think it means – you are talking about “Contributor License Agreement”.
I was being deliberately vague, because I believe all these things are worthless – at best pointless process friction, at worst iatrogenically dangerous for the reasons I described.
If a Copyright Transfer/Assignment is worthless, why does FSF use them?
Ostensibly, GPL enforcement. The FSF can’t go to court over code it doesn’t explicitly own, so it asks GNU project contributors to assign copyright so that if someone violates the license of software developed under their auspices, they will have standing in court. That’s what they say anyway.
As Winter mentioned, profit-oriented vendors usually seek copyright reassignment so that they have the option of later closing the source and selling it as a proprietary product.
The actual reason is because without the copyright assignment, the author could revoke the license at any time from others. Non-exclusive licenses are revocable absent valid bargained-for consideration ($).
>If a Copyright Transfer/Assignment is worthless, why does FSF use them?
Because they listened to the wrong lawyers early on and now have an institutional habit it would cost them too much psychological investment to back away from.
I mean something specific by “wrong lawyers”. There is a common variety of lawyer who, under the banner of risk mitigation, advises his clients to perform legalistic gestures that are essentially voodoo invocations – not responses to reality but to weird, hypertrophied theories of future legal risk that all have one common factor. They make lawyers important. Gee, what a surprise!
Actually Mark Atwood has already explained in some detail why the FSF’s cabinet full of assignments is voodoo. You may have missed it because his exposition was compressed and used a lot of acronyms, but you should pay attention. Because part of his day job is managing these risks for Amazon. They have literally billions of dollars of skin in this game and can’t afford illusions about voodoo hexes.
I suspect that this also comes out of ideology where the FSF is more interested in ideological purity than in useful development process. Thus they wanted maximum leverage in the world where everybody would steal their code.
Given that roughly 30 years of actual experience has shown that publicity and reputation is enough to ensure compliance from most large companies, it seems to have mattered less than originally projected.
Nonsense. One must have something for the Eloi to do.
The corporations I have worked for all had (probably still have) policies against employees and contractors signing such agreements, though they were/are ok with a certificate of origin. Of course, they really preferred employees not contribute to open source projects, but they didn’t forbid it as long as the projects didn’t compete with the corporation’s products and services.
I have contributed to a few open source projects through either pull requests or patch submissions and never had to sign any agreement to do so. Also, I have accepted patch submissions to my own projects without asking anyone to sign anything. So far, I’ve never had any problems.
Someone I met and chatted with once said that’s fine for projects under the GPL and similar licenses, but not a good for projects under BSD or similar licenses. She claimed that a copyright assignment is necessary for those.
There are a few project I would like to contribute code to, but I feel safer limiting my contributions to bug reports and high level, vague-ish suggestions, due to the requirement to sign a contributors and/or assignment agreement.
(forgot to check “notify” buttons)
What about the case of graduate students doing code for an assignments? That might be a case of willing consent – “Look, you want your grade don’t you? Then sign!” I can see somebody being very unhappy in this scenario and deciding after they have their degree that they want the code removed. I never heard of this happening in the computer world but it’s common enough in other academic areas. Usually the ex-grad student retroactively wants a credit line added to a paper or book, but plagiarism complaints are so common that some academic trade associations (the American Psychology Association and I think the National Association of Social Workers) have arbitration procedures in place. So do some universities.
>I can see somebody being very unhappy in this scenario and deciding after they have their degree that they want the code removed
Not my problem. Academia has to fix its own messes; I’m not willing to try to bend the legal system in a direction that would hurt my community to address that one case..
I get confused by the terminology. When I try to think it through, this is what I understand:
1. There are projects that want to make sure you have the rights to license any code you submit. They could want that in writing.
2. There are projects that want to make sure about the license a contributer gives them for using the code. They probably want that in writing.
3. There are projects that want the copyrights of any code submitted to be able to relicense the code under a different, proprietary, license. They must have that in writing.
1 and 2 are OK with me. 3 is poison.
You made the wrong call on the copyrightability of APIs, and I think you may be making the wrong call here. Simply because if you want to expose yourself to liability, not having a paper trail that shows all the parties in question explicitly released their work for use, copying, or distribution is a better way than most to do it.
In the porn industry, photographers and videographers make their models sign model-release forms, simply because when having the photos or videos out there is no longer convenient to the model, they can put you at risk of civil and criminal (“revenge porn” is a felony in some states) liability unless you have that paper trail showing all parties agreed to the shoot when it happened. If you think the software industry is any more legitimate or upstanding than the porn industry, you haven’t been paying attention.
That is exactly the FUD that drives fearful lawyers to think there is a problem and that CLAs are the solution to that problem. Please stop.
There is no hard systemic problem here, and even if there was, CLA are not a solution to it.
An “in-out” statement such as is used by the NTPsec project, coupled with the git history, is all that is sufficient to deal with any hypothetical problem that may exist.
In the cases where any problem do rarely occasionally happen, when someone contributes code they don’t own and then later the actual owner shows up and is unhappy, CLAs are irrelevant to the process of sorting out and fixing the problem.
@Jeff
You lost me here.
In what way is software coding comparable to the production of porn?
And why do you invoke revenge porn in a discussion on open source software licensing?
Both an open source contributor’s code and a porn actor’s likeness are valuable intellectual property, the owners of which may be incentivized to revoke distribution rights to later down the line. To deal with this, the porn industry (actually the photography and videography industries in general) uses a model release contract, which explicitly gives the producer rights to publish the material they make featuring the model’s image, in perpetuity, so that if, say, the model later becomes a born again Christian and no longer wants to be associated with such material, they have no legal recourse to shut down distribution of the material they were involved with.
The Contributor License Agreement serves much the same purpose for software that model releases do for the image of a person.
I admit that there is no real equivalent to that bit in the software world; it’s difficult to impossible to prosecute someone for criminal copyright infringement when it comes to code copied into an open source project.
Porn actresses have been known to claim that they were photographed or videoed without their consent (e.g., they were given drugs, had a gun pointed at them during filming, etc.). U.S. revenge porn laws make the distribution of any nude or erotic material of a person without their consent a crime — often a felony — irrespective of whether it falls under the rubric of what we think of as “revenge porn”. This is part of why the model release form is so important and standard practice in that industry; it provides a record of consent and shields the producer from legal trouble should an actress attempt to rehabilitate her tarnished image by falsely claiming that she didn’t really agree to appear naked or involved in sexual activity on camera.
I don’t blame you for not understanding. It is, in part, an American thing. The notion of a person’s (particularly a woman’s) image being irreparably tarnished by their appearing in porn must seem strange indeed to a man from a city famous for its brothels. And Americans are, on average, more likely than Dutch to attempt to get away with filing false or frivolous lawsuits.
You are in error as to the source of the model release or why it’s standard practice.
A release is required for all photographic & video work to make commercial distribution legal. Most of the case law here is from photographers selling their work to be used for ads and being sued by the subjects, not porn. And it has nothing to do with relatively new ‘Revenge Porn’ laws.
Without a model release it is not legal to use recognizable imagery of a person for anything other than artistic or editorial purposes. The moment you charge money, you need a release.
Releases have been standard practice in the photography & movie businesses for decades. The porn side is subject to the same set of laws and uses releases for the same set of reasons.
“Porn actresses have been known to claim that they were photographed or videoed without their consent “
Eh, not the professional ones so much, and honestly it’s 2019, not 1979 – basically nobody gives a damn that someone was/is in porn. I can’t recall the last time I heard of such a thing (though admittedly I don’t follow porn industry news, so …).
(Forms are frankly less useful for “prove it was consensual”, since form signing can happen at gunpoint or while drunk, eh?
Porn producers simply roll cameras through the whole process, from intake to makeup to performance to cleanup after, and document that the person in question was adequately sober and acting freely – and cashed the check.
Because again, it’s 2019, and digital video makes your cost-per-minute of “film” basically zero, so you just record it all.
And as a bonus you can release a “Behind the Scenes” video and make MORE money.)
Pray tell what “revenge coding” would be?
Samba? Wine?
>Pray tell what “revenge coding” would be?
It lives on the shelf next to “peak oil”. *snrk*
Hubbert’s theory is sound. I think he made some flawed assumptions in his initial forecasts of when the peak would occur. For example, it turns out that oil executives don’t mind causing a few earthquakes if it gets them access to deep crude reserves.
The theory, as I understand it, is that the fracking fluid acts as a lubricant which makes it easier for the tension between plates to be released, causing earthquakes.
If so, this is a GOOD thing. Would you rather have the tension released as a multitude of small earthquakes, or have one really big one when the tension gets too large for it to be contained?
IIRC, Hubbert’s production model is accurate for a given oilfield and technology, and has a nice sharply-dropping curve.
The problem with “peak oil” hysterics was thinking that curve was the shape of the aggregate production curve in the real world.
It does not.
>The problem with “peak oil” hysterics was thinking that curve was the shape of the aggregate production curve in the real world.
There was a deeper problem than that. Peak-oil boosters didn’t understand demand substitution. And didn’t want to understand it – it would have interfered with their end-times cultism.
Hey, peak oil *is* a danger!
But not for the reasons that peak oil fearmongers think it is. It’s because bureaucrats can throw in enough sand into the gears that it becomes difficult, if not impossible, to get the oil we need to function properly as a society.
(I made this realization as I was reading the blurb of a book about peak oil.)
Don’t think this can’t happen: we’re already at “peak thorium” even though thorium is more plentiful than uranium, in no small part because however mildly radioactive thorium is, it’s enough to regulate it into oblivion. This, in turn, has led to “peak rare earths”, because the valuable rare earths also happen to be mixed thoroughly with thorium, and thus, no one dares to mine it for fear of being held responsible for thorium “pollution”.
Come to think of it, this should serve as a warning for us, as well: it’s possible to reach “peak open source” — but only if we aren’t careful with the legal issues surrounding IP.
Yeah, lemme stop you right there.
The “simply because” is that:
1) 18 U.S.C. §2257 already mandates, on pain of imprisonment for up to five years, collecting and keeping a pile of information (name, any other names ever used by the performer for anything, and date of birth), verified by looking at identity documents, on anyone depicted in the work.
2) There are whole a pile of of laws specifically criminalizing taking unauthorized photos or videos of people in various states of undress if they had a reasonable expectation of privacy. Large amounts of porn is not self-proving that it was taken with consent, and so a standard procedure of getting documented consent is adopted as part of the existing legally-mandated documentation process.
3) Right of publicity laws generally have a cause of action on any of intrusion upon physical solitude, public disclosure of private facts, depiction in a false light, and appropriation of name and likeness. All of which are potentially implicated for porn if you don’t have it established that the person depicted consented to publication (as opposed to, say, consenting to making a private photo/film). Which is then a second reason to add a simple form to the existing documentation process.
So, the porn makers go ahead and add a form to establish that a person, whose identity and DOB they legally had to unambiguously establish anyway, consented to the taking and publication of the image/video, zeroing out all their legal concerns.
On the other hand, a form from somebody you can’t positively establish is the person named on the form, covering code you can’t positively establish was written by either the person filling out the form or the person named on it, does absolutely nothing to cover you from copyright violations. If you can establish that the person submitting the code to you has the copyright to it, you’ve already got perfectly fine evidence that they consented to your use by the fact they submitted it; an additional form does nothing. If they don’t have the copyright, no stack of forms can change the fact that you didn’t get consent from the actual copyright holder.
a form from somebody you can’t positively establish is the person named on the form, covering code you can’t positively establish was written by either the person filling out the form or the person named on it, does absolutely nothing to cover you from copyright violations. If you can establish that the person submitting the code to you has the copyright to it, you’ve already got perfectly fine evidence that they consented to your use by the fact they submitted it; an additional form does nothing. If they don’t have the copyright, no stack of forms can change the fact that you didn’t get consent from the actual copyright holder.
Thank you Steven, that is a perfect summary of the situation.
If I may ask for a favor: Erc, when this thread has run its course, could you update your Software Release Practice HOWTO to include your and Mark’s points under “good IP practice” or whatever? Independently, uploading the current version of this HOWTO to Gitlab would help because the Linux Documentation Project’s HOWTO pages seem abandoned these days.
>If I may ask for a favor: Erc, when this thread has run its course, could you update your Software Release Practice HOWTO to include your and Mark’s points under “good IP practice” or whatever?
That’s a really good idea. Poke me again in a week or two if you don’t see any action on it.
Any legal argument that hinges on the “norms of the hacker community” is likely to run in to problems. The hacker community is not the Basque Region, any norms you wish to point to can be shown to not be norms at all, but rather local tics. You will find no shortage of people to testify that it’s not like that at all, for all values of “that.”
Eric, you have, for some decades now (props on your single-minded focus, by the way) been trying to define and enforce “hacker culture” to fit your personal idea of what it ought to me. This essay is another attempt at it — and the fact that it exists at all demonstrates that you’ve not succeeded, and that hacker culture, insofar as it exists at all, continues to be much broader than you wish it was.
Indeed, were I called upon to gather up an argument to the effect that hacker culture norms are in fact not what Eric Raymond says they are, this essay would appear in the packet of materials!
>You will find no shortage of people to testify that it’s not like that at all, for all values of “that.”
Silly person, that’s largely true of all cultural and subcultural subgroups of non-trivial size. Even the Basque Region isn’t the Basque Region. There are almost always dissenters on most issue, each partly engaged in their own attempted reinvention of the intersubjectivity around them.
I’ve never enforced a damn thing – don’t have the power to, and wouldn’t want it if I could have it. Mostly I’ve just pointed people in a direction they already wanted to go and given them language to articulate who they wanted to be.
Bob uses some open source tool at work, and as part of his job duties he liases with the maintainer. One day Bob finds a bug, and sends the maintainer a diff correcting it. The maintainer applies the diff and distributes an updated version. Seeing this, Bob’s employers have their lawyer contact the maintainer to point out that Bob wrote that code on company time. They claim that while Bob was authorised to send the diff, it was only to illustrate the form a solution could take and did not come with any licence beyond “fair use” for that purpose. As a work for hire, the code is the IP of Bob’s employers, the maintainer has infringed their copyright by distributing it, and the lawyers threaten to sue him for royalties.
The maintainer can defend himself by showing that Bob had signed a contributor agreement declaring that he was the copyright owner or duly authorised representative thereof, that he granted the maintainer an irrevocable license to distribute the work, that he agreed to indemnify, save, and hold harmless the maintainer – you know the drill. Now even if the company lawyers convince a jury that community norms don’t include an implicit licence, the maintainer can show that he was given an explicit one.
On the other hand, if the maintainer had no such agreement with Bob, the company could get away with calling enough contradictory witnesses to make a jury unsure as to the actual community norms, and then paint the maintainer as not having done his due diligence to ensure that he had distribution rights over the code.
All of this *could* potentially happen, and it’s exactly the kind of disasterbating that you can pay your lawyer to imagine for you.
In practice, it doesn’t happen, because the pathway of events do not default to what you describe, and when something like this starts to happen, it gets dealt with a lot more sanely than you describe. I won’t describe more here, because I am not a lawyer, I am not your lawyer, and this is part of my dayjob that stays in in-person conference rooms, not in public blog posts.
Yes, it could happen. No, CLAs won’t help anyone if it does happen.
>They claim that while Bob was authorised to send the diff, it was only to illustrate the form a solution could take and did not come with any licence beyond “fair use” for that purpose.
Which is why this language is phrased this way:
That is a contributor agreement, expressed as a contract of adhesion. You may not like the fact that contracts of adhesion are legally enforceable and I’m none too happy about it myself, but as long as they are the good guys might as well get some benefit from the mechanism.
And that second clause is explanatory, not restrictive. Even if it weren’t, good luck convincing any judge or jury that those forms and usages include ransomwaring your patches.
Right, what you have is a contract to which you don’t get affirmative consent. That is, you serve Bob with this notice (and it may take some doing to get the court to accept putting a sencence in “/devel/hacking.adoc” as serving him) that taking action X constitutes acceptance of terms Y. Even a contract of adhesion can’t be unilaterally imposed by one party – the other party still has the option to reject it, just not to negotiate its terms. Your problem is that Bob doesn’t need your permission to take action X anyway, so he can reject your contract without being barred from sending you diffs. In this way it’s fundamentally different from the GPL, where a user must accept the terms if he wants to redistribute the software – otherwise he’s violating the developer’s copyright.
It’s not that the terms of your contract are too weak – but that your ability to show that Bob actually entered into the contract isn’t very strong.
That Bob signed an agreement saying that he was the rights-holder or duly-authorized representative thereof is meaningless; all that matters for an infringement case is if he is actually the rights-holder or duly-authorized representative thereof. There’s no magic “But someone who didn’t have the rights said I have a license” exception to copyright law. So regardless of whether or not Bob signed an agreement, you’d need to come up with actual evidence that Bob had the right to contribute the code (internal company memos, Bob’s contract provisions on copyright, or the like) to ward off Bob’s company’s effort.
If Bob didn’t have the right to license the code on behalf of the company, he also didn’t have the right to sign away any remedies against infringement on behalf of the company. So all those “indemnify” and “hold harmless” clauses are worthless. The “indemnify” lets you try to sue Bob himself for recompense of the costs imposed on you by Bob’s company, but as a practical matter, Bob’s net assets are going to be small enough that it isn’t worth it after you figure the legal fees you’ll expend trying to extract them.
So, what does that leave? The contrived scenario where Bob did have a clear right to contribute the code, and sent in the code, but now says he didn’t mean to contribute it to the project when he sent it in, and the method of sending in the code was such that it’s not laughable that he didn’t mean to contribute it, and the code is valuable enough Bob wants to claw it back. Then the friction costs you imposed on each and every contributor to your project might finally pay off.
Better idea — spend a dollar every time you get a contribution on a lottery ticket. There are documented cases of those paying off.
>There’s no magic “But someone who didn’t have the rights said I have a license” exception to copyright law. So regardless of whether or not Bob signed an agreement, you’d need to come up with actual evidence that Bob had the right to contribute the code (internal company memos, Bob’s contract provisions on copyright, or the like) to ward off Bob’s company’s effort.
What the law ought to say about the situation where Bob wrote the code on company time is that Bob can give his employer the rights to the code, but cannot fully divest himself of them in doing so, the most he can do is sign a contract not to exercise those rights, but he retains the right to breach the contract and face the applicable penalties. That way, if:
1) He wrote the code.
2) On company time.
3) He gave the code to a third party.
4) Without his employer’s approval.
Then the consequences fall completely on him.
Ah well. If wishes were fishes…
>Ah well. If wishes were fishes…
As long as we’re fantasizing, here’s the Constitutional language authorizing the enforcement of copyrights and patents.
Enforcing any copyright or patent against an open-source project hinders the progress of science and the useful arts. The government should therefore be barred from such enforcement.
Of course, if we took the Constitution that seriously I’d be able to buy fully automatic weapons at the corner store.
Ehhhh, I think that that would be seen to be inequitable enough, and to create a big enough loophole in copyright law, that it would be easier to make the same argument with out the clause “against an open source project”, in other words, to argue that the powers provided by the copyright clause are inconsistent with its stated goals. Which is fine with me, because I’m a copyright abolitionist anyway.
But either argument strikes me as too close for my comfort to the liberal habit of word wrangling with the constitution until one gets a reading contrary to the clear intent of the founders. It would be better just to either have Congress disestablish the copyright and patent offices and all copyright and patent statutes (they are granted, but not required to use, the powers set forth in the copyright clause), or else to amend the constitution to the effect of the following “As it has been found that granting copyrights and patents is injurious to the purpose of promoting the progress of science and the useful arts, Article 1, section 8, clause 8 of this Constitution is hereby repealed. Neither Congress, nor any state, nor any level or branch of government within the United States shall exercise the powers granted therein”.
That last clause is because judicial and executive overreach have proved “Congress shall make no law” too weak.
Obligatory:
If we took the Constitution that seriously, “Alcohol, Tobacco, Firearms, and Explosives” would be a convenience store chain, not a government agency.
>If Bob didn’t have the right to license the code on behalf of the company, he also didn’t have the right to sign away any remedies against infringement on behalf of the company.
Correct. This is also why even the FSF’s copyright assignments are basically worthless. You’re not going to get sued by Bob – he contributed the code with intent in the first place. Your risk (such as it is) is that Bob’s employers, with actual money and lawyers, will decide your project is a target.
If that happens, their legal posture is going to be that the code was work for hire and Bob had no more right to assign the copyright than he would have had to license under a CLA. And they’d probably win that argument.
Yes, and Bob then contributing that code without company approval (if it’s actually anything significant re: intellectual property or time) would generally be a breach of the work-for-hire agreement (usually at least confidentiality / trade secrets), unless such an agreement was unusually permissive.
So if Bob wasn’t terminated for cause, it’s probably a fishing expedition, or a non-issue. If he was terminated, then it would be a problem, but I’m not aware of anything that would be a positive protection against that sort of situation.
Paraphrasing Mark Atwood, who summed it up very nicely for CLAs: Yes, it could happen. Almost nothing will help you if it does happen.
A legal contract with the company (rather than the individual), signed off by someone at the company with sufficient authority to bind the company to a contract. You’re looking for a CTO or similar. Also, the contract will need to include mutual consideration, and should explicitly state what the consideration is, or it may be unilaterally rescindable.
It’s not meaningless; it can at a minimum show that any infringement wasn’t willful and thus protect the maintainer from enhanced damages. And in fact, you may be interested to know that there is a doctrine called “agency by estoppel” – if Bob’s employers appoint him as liaison to your project, then they can be estopped from recovering any damages from you if a “reasonable person” would have believed Bob’s authority extended to authorising reuse as he claimed by signing the contract.
>It’s not meaningless; it can at a minimum show that any infringement wasn’t willful and thus protect the maintainer from enhanced damages,
So, if I were the bad guys, I’d counter that by saying: “Maintainer did not check that Bob was in a work-for-hire situation. didn’t even ask Bob at the time the ICLA was proposed to him, because maintainer wanted to evade his responsibility by ignorance. Treble-quintuple-eleventy damages!”
“that he granted the maintainer an irrevocable license to distribute the work,”
Illusory promise, since not supported by bargained-for consideration, owner can revoke.
My own understanding of legal requirements for electronic signatures (at least in the US) strongly agrees with Eric and Mark Atwood here (and Stephen’s summation as: If you can establish that the person submitting the code to you has the copyright to it, you’ve already got perfectly fine evidence that they consented to your use by the fact they submitted it; an additional form does nothing.)
Git repository history captures something effectively equivalent to (and in many cases better than) most electronic signature systems that e.g. various websites implement, for each commit in the history. Any equivalent version control system should provide similar certification of authorship.
Therefore, combined with e.g. the NTPSec language Eric quoted above, a patch (with sufficient metadata to identify the parent commit, date, and author) would effectively *be* an electronically signed agreement with regards to the contribution policy.
The DCO just calls this out more explicitly. Extending this to pull/merge request templates draws more attention to it, but is not strictly necessary.
If you really want to be sure, also require every commit to be GPG-signed, probably also limiting to public key algorithms that meet current government standards in the US and/or EU.
Note that none of the above ensures that the submitter holds the copyright or that the provenance is otherwise acceptable (at best, the submitter claimed that this is true). The same is also true for any of the higher-friction options.
There is a strong argument to be made that most contributor agreements fail the “consideration” test of enforceability which applies under among others US and English law.
>There is a strong argument to be made that most contributor agreements fail the “consideration” test of enforceability which applies under among others US and English law.
However, it would be better for us if they did not fail for that reason.
It would be better if the law recognized that contributors do in fact receive consideration for their grant of rights. What consideration? Ask them: why are they putting in the effort? You’ll get a lot of different answers; what matters is that there are answers.
None of those “answers” were bargained for, they’re only incidental after-the-fact (“oh yay, the project got popular, people know your name now, oh you didn’t ask us for that and we didn’t gaurentee it?”) and not something the “other side” (project) can actually provide on its own. Also many courts do not actually countenance “sham” consideration.
Do you agree about this sum up or generalization?
Contributor agreements are a stronger protection for a software project. Unfortunately, it’s a local optimization: stronger for a specific project but it creates a weaker free software ecosystem (because it weaks the habit which is a patch is considered under the same licence by default). It’s not good to have contributor agreements in every project because it increases the contribution cost for each part.
Lawyers are paid for optimal protection by the software project, not for the FOSS ecosystem, explaining why they prefer contributor agreements.
>Do you agree about this sum up or generalization? Contributor agreements are a stronger protection for a software project.
No, because I don’t think they’re actually protection at all. There’s no shield from liability there.
Non-exclusive licenses are revocable absent consideration.
A non-exclusive license is NOT a transfer, it is simple permission.
https://scholarship.law.duke.edu/faculty_scholarship/1857/
https://www.amazon.com/Open-Source-Licensing-Software-Intellectual/dp/0131487876
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=243237
For those who don’t like legal papers: https://lkml.org/lkml/2019/5/3/698
https://lkml.org/lkml/2019/5/4/334
This is not a “bad thing”. The opensource world has worked for decades in the USA under this regime. The programmers need some leverage, otherwise they get CoC’d and MeeToo’d in the USA. The USA is not the only realm in existence either.
“I say, therefore, that Apache and the FSF and the Golang project and everybody else requiring contributor releases are wrong. ”
The FSF has been doing this from the beginning: this suggests they understand it is necessary, legally.
Ownership rights are well discussed in the above comments. I have enjoyed reading them.
I would like to add that a gotcha of contribution agreements is that you may be agreeing that its governed under a jurisdiction that you are not familiar with and have never even been to. The above comments seem to be a robust discussion around US law, however I am not a US citizen nor do I reside there.
I recently attempted to send some Dockerfile changes to the Scylla project. I was asked to agree to their agreement, it seemed reasonable enough until I am asked to agree that it is governed under law in the State of Israel. I have no qualms with Israel, in fact I hope to visit there in the future. But I am unfamiliar with their legal system and laws, so do not want to sign a contract under that system. See https://www.scylladb.com/open-source/contributor-agreement/