16

I have published the first version of my software on my company's git repo and some other developers outside of our company have shown interest in contributing to our work. We are releasing our software under the LGPL license. How can we prevent these external developers from claiming copyright on their contribution in future?

How can we make sure that the external developers/companies do not claim copyright on the source they contributed to our project? What we want to avoid is a situation where a company comes and asks us to re-license our product (for example for the purpose of commercial application) and the external developer/company has to agree to the terms of the re-licensing.

migrated from programmers.stackexchange.com Oct 10 '16 at 13:52

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • 1
    Facebook's approach (I have a decent amount of confidence in their legal team) is to run a bot making users sign their code.facebook.com/cla before the merge can occur. – ceejayoz Oct 11 '16 at 16:59
15

This is a legitimate issue that's come up various times in the past on various open source projects. The way it's typically handled is by not accepting external contributions into your repository unless they sign an agreement either transferring their copyright interest to you or, at the very least, explicitly waiving their right to disagree with your future non-LGPL licensing choices.

Of course, the nature of an open source license means that they're still free to fork the code and merge in their own changes, and there's nothing you can do about that. But a having a contributor's license agreement means that the code under your control doesn't end up entangled with external copyright interests.

  • 17
    @hsalimi The mechanism of merging contributions is entirely up to you. But keeping external copyright interests from interfering with your licensing decisions is a legal issue, not a technical one. It's all about when and under what conditions you merge in contributions, not about how you merge them. – Mason Wheeler Oct 10 '16 at 14:08
  • 1
    Yes. For example, here is the agreement used by the .NET Foundation for contributing code to its projects. The project managers will not merge PRs from a person who has not signed this agreement. – Mason Wheeler Oct 10 '16 at 14:20
  • 7
    Note that there is no way to do this that's not free of risk. Someone could sign that agreement and then include code that someone else later claims that they wrote. – David Schwartz Oct 10 '16 at 17:18
  • 4
    @DavidSchwartz Many of those agreements state to varying degrees of legally sound perjury that contributors have the proper rights to what they contribute. So it would be a problem for you, but it would give you recourse to sue them. – William Kappler Oct 10 '16 at 19:07
  • 2
    @WilliamKappler in theory thats all fine, but when you really try to sue John Doe from Shittytown, Sealand for compensation, you might just find out that he doesn't exist as much as he made you to believe. And even if you thoroughly checked his documents, it might just happen that he lost all his money in the casino and now lives in his moms trailer. So this won't guarantee you that you'll ever see any money if someone hands you "stolen" code. – Josef Oct 10 '16 at 19:14
11

We have run into this problem in libpng. We addressed it by putting any contributions that insist on keeping their own copyright, or are under a different open source license, into a "contrib" directory, which has its own README.txt:

This "contrib" directory contains contributions which are not necessarily under the libpng license, although all are open source. They are not part of libpng proper and are not used for building the library, although some are used for testing the library via "make check".

The subdirectories in the contrib directory have their own LICENSE, README, etc., or the files have copyright/license statements embedded in them.

Libpng isn't under LGPL (it's under the libpng license) but that's irrelevant; we were still concerned about contributors possibly taking control of our license, as you are.

We have on occasion moved a contribution out of the "contrib" directory into libpng proper, once the contributor had agreed to relinquish copyright on the contribution to us.

  • Thanks ! Have you ever tried to merge one of your contributions into your main line of source code. – Hoodi Oct 10 '16 at 16:36
4

I've thought about this before, and considered the following:

Contributions to the project must themselves be licensed under the MIT license (or a similarly permissive license). MIT-licensed software can be safely included in (L)GPL projects and proprietary projects alike. The only requirements is that the copyright notice and the license terms be included.

The idea here is that the contributors retain their copyright (thus not requiring signing a contract to transfer copyright, a significant barrier to entry), while giving you the freedom to do with their contributions what you want.

I am, however, not a lawyer, and I'm not sure where the pitfalls - if any - lie with this approach. I don't think I've seen it used in the wild, but I can only speculate why.

  • This seems simple, minimal hassle, and makes sense to me. IANAL either, I'm taking note of this. As I see, it avoids any re-licensing issues while ensuring that contributors still must be credited in the main work and any derivatives. – Mark K Cowan Oct 11 '16 at 13:35
3

How can we make sure that the external developers/companies do not claim copyright on the source they contributed to our project?

This is commonly handled with what is called a Contributor License Agreement or CLA. These come in several shapes or forms and their purpose boils down to terms such as:

  • ensuring that contributions are original or have a well defined provenance and licensing
  • in many cases assigning or licensing the contribution rights to the project or organization

CLA may be very simple and automatic such as the Linux Kernel Developer Certificate of Origin.

Or they can be full featured "contracts" that require signature.

Most handle the cases (or have a variant) when contributions are made on behalf of your employer or as part of your employment. There is even an open source project to provide standardized CLA templates.

Some licenses such as the Apache 2.0 have CLA-like terms built-in to ensure that contributions to an Apache-licensed project are automatically received under the Apache license.

Some practical examples:

  • major open source foundations such as the Apache Foundation, the OpenStack Foundation or the Eclipse Foundation typically require that a CLA is in place before accepting significant contributions.
  • several software companies distributing product under a dual copyleft/commercial or releasing open source projects need or prefer a CLA: to ensure that they can carry on this dual licensing scheme they need to hold the rights to the code such that they can relicense it commercially.
1

Contract

How can we prevent these external developers from claiming copyright on their contribution in future?

Well, the only way to achieve the quoted is to not just take in any pull requests, but only do so when you get a written, signed contract from that external developer which clearly transfers the copyright to you for those changes (have them include the commit hash in the contract). If you do that, I do not see how there could be any problems whatsoever (that your lawyer couldn't handle). Of course, you will want to make sure that there is a spotless track record of your version of the repository, so you can prove in court that you only added commits that were from either your company or properly contracted external developers.

To be on the save side, you would also formulate your contract so that it is the external developers obligation to prove that he actually holds the copyright (that he transfers to you) in the first place, i.e., they cannot include 3rd party code in their code or will be held liable if they do.

Compartmentalization

What we want to avoid is a situation where a company comes and asks us to re-license our product (for example for the purpose of commercial application) and the external developer/company has to agree to the terms of the re-licensing.

Well, let's focus on what you mean by "a company comes and asks us to re-license our product". Do you have any concrete idea why a company would do that (this is not a rhetorical question).

Maybe you have some part of your library that is excessively clever that you want to keep secret? Trade secret? As soon as you LGPL and distribute the library, you can forget about secrecy anyway, people can fork it and there is nothing whatsoever you can do against it, neither technical nor by law.

Is there some cryptography involved? Forget about keeping that secret by closing the source at a later date - or by closing at all; security by obscurity does not work.

So, if you do come up with a good reason (for yourself - you don't need to tell us), then the easier solution, (easier than the contract variant), would be to put the "special" code in its own library and do not put it in the same repository. Release it separately under some license that is open source but firmly keeps your interests in mind - especially, never accept merge requests by external contributors. Then you can have your "free" parts really free (as in freedom), and just trust the (L)GPL; and you can keep the sensitive parts to yourself.

  • Thanks for your complete answer @AnoE. By saying "a company cones and asks .... ", I meant we just want to avoid situations in which other real/legal persons can claim and ask to re-licensing. We want to be the only owners of the work and make the work commercial in future. BTW, we have no secret library or code in our project, no crypto-stuff as well. – Hoodi Oct 11 '16 at 15:22
  • Then I am a bit confused - why do you plan to LGPL it in the first place? – AnoE Oct 11 '16 at 21:14
  • You mean we could select a license that we had the license of external contributions out of the box? such as Apache? – Hoodi Oct 14 '16 at 13:04
  • @hsalimi, I have never specifically looked for licenses to make it harder to open-source the stuff. ;) the xGPL licenses have been specifically invented to avoid things that you want to happen (i.e., re-licensing, closing stuff up again, grabbing copyrights and all that stuff). My question was: if you know that you want to re-license (which means go back to closed source, right?) in the future, why open-source in the first place? – AnoE Oct 14 '16 at 13:15
  • Let's make it clear. The project is open source and WILL REMAIN open source forever. We need to make it open because it is a research-based project and we want to have contributions from the experts of our community. The point is that, after some time, we MAY decide to release a commercial version of our project, under license X. In that case, we do not want any external developers to claim about the ownership of the code. – Hoodi Oct 14 '16 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.