[PieterH]

This is a really good article. There's one part in particular that struck me:

"Despite the assumption of some newer open-source developers that sending a pull request on GitHub “automatically” licenses the contribution for distribution on the terms of the project’s existing license—what Richard Fontana of Red Hat calls “inbound=outbound”—United States law doesn’t recognize any such rule. Strong copyright protection, not permissive licensing, is the default."

In other words the fork + pull request + merge flow does not work on a project unless you have an explicit step like a CLA, or an alternative solution.

We faced this problem early on in ZeroMQ, that asking contributors to take this extra step increased the work for maintainers (to check, is this the first time person X contributes, and have they made a CLA?) It also scared off contributors from businesses, where this often took approval (which took time and was often denied).

Our first solution in ZeroMQ was to ask contributors to explicitly state, "I hereby license this patch under MIT," which let us safely merge it into our LGPL codebase. Yet, again, another extra step and again, needs corporate approval.

Our current solution is I think more elegant and is one of the arguments I've used in favor of a share-alike license (xGPL originally and MPLv2 more these days) in our projects.

That works as follows:

* When you fork a project ABC that uses, say, MPLv2, the fork is also licensed under MPLv2.

* When you modify the fork, with your patch, your derived work is now also always licensed under MPLv2. This is due to the share-alike aspect. If you use MIT, at this stage the derived work is (or rather, can be) standard copyright. Admittedly if you leave the license header in the source file, it remains MIT. Yet how many maintainers check the header of the inbound source file? Not many IMO.

* When you then send a patch from that inbound project, the patch is also licensed under MPLv2.

* Ergo there is no need for an explicit grant or transfer of copyright.

I wonder if other people have come to the same conclusion, or if there are flaws in my reasoning.

[int_19h]

For Microsoft GitHub repos, there's some kind of automated tool that enforces CLAs. Whenever there's a new pull request, it checks whether the author is a Microsoft employee or not. If not, it checks whether there's a CLA for that person, and if there isn't one, posts a link to a page that handles signing, and records the result for future uses. Repo owners are also notified accordingly.

It also seems to have some kind of threshold for code size, because for small contributions, it says that CLA was not required.

You can see it in action from users' perspective in pretty much any repo under https://github.com/Microsoft/, if you search for "MSBOT" in pull requests. E.g.:

https://github.com/Microsoft/PTVS/pulls?page=1&q=is%3Apr+MSB...

(note the labels)

[rando832]

And note the Microsoft CLA says "you grant Microsoft a patent license covering your contribution", while Microsoft grants no patent licenses over (edit: most) of their open source code, and are currently profiting from patent licenses against open source code in android etc.

When it comes to patents, MIT is a closed source proprietary license, while Apache 2.0 and GPL are open source and free software. All these companies spewing bs about how open MIT is bugs me to no end.

[vsl]

> It also seems to have some kind of threshold for code size, because for small contributions, it says that CLA was not required.

That's because all this copyright stuff is needed only for things that can be protected by copyright in the first place. One of the elements required is creativity of the work and if you only make a trivial change, e.g. Adding an obvious make file rule or adding a file to a project, that's not creative (there's just one obvious way to do it), so not protected, so not needing a CLA.

[teamhappy]

> In other words the fork + pull request + merge flow does not work on a project unless you have an explicit copyright assignment step (CLA), or some alternative.

FWIW, the Apache license contains a section dedicated to that (5. Submission of Contributions): http://www.apache.org/licenses/LICENSE-2.0

[PieterH]

That is excellent.

[pash]

> I wonder if other people have come to the same conclusion, or if there are flaws in my reasoning.

Unfortunately, it doesn't work the way you've hoped. Although there are some licenses (e.g., Apache) that purport to apply automatically to new code submitted to the licensed codebase, the MPL doesn't make that claim, and such clauses are legally dubious anyway.

So just because I write some code that can be applied as a patch to your MPL-licensed codebase, my code is not automatically subject to the MPL. By default, I hold the copyright, with all rights reserved, and the MPL license on your code does nothing to change that. You still need explicit agreeement from me to place my code under a compatible license.

Github, Gitlab, et al., should really put a checkbox on pull requests that says, "I hereby license this code under $REPO_LICENSE."

[snuxoll]

Actually, you're wrong about the MPL. The MPL is a file based copyleft license, the share-alike clause applies to any modifications made to a file already containing MPL'ed code. This is only an issue when you add new files to the project, and any MPL project should be vigilant about accepting patches to ensure new files added contain the MPL header.

[ensignavenger]

Why do you think the Apache license clause regarding contributions is legally dubious?

[philip1209]

Here's a CLA assistant tool - it blocks merging a Github PR until a specified CLA is signed:

https://cla-assistant.io/

[semi-extrinsic]

I was discussing this once with the maintainer of an MIT licensed scientific software. The solution in the end IIRC was to require all first-time contributors to agree in writing to a Contributor Agreement that states (among other things) that all code submitted to the project would be licensed under the project license.

It's not much of an obstacle really, just whenever someone submits a PR for the first time, say "I'll look at your code and comment anything that may need improvements. Also, you have to agree to these conditions [link]."

Is this a suboptimal solution?

[PieterH]

I explained the ways it's suboptimal, worst IME is for drive-by contributors from larger firms.

[makomk]

I imagine that issue will give some lawyers a hell of a time if it comes up, because by sending someone a pull request on GitHub you're actually sending them a copy of the modified file including any header claiming that the contents are under the MIT license or whatever other license it was under - even though the pull request displayed as a simple diff. Except that behind the scenes it may be stored as some kind of diff again.

[morgante]

> It also scared off contributors from businesses, where this often took approval (which took time and was often denied).

This is one of my biggest reasons for not working at Google/Facebook/etc. I really don't want to have to get management approval for every random PR I submit in my free time.

For people working at big companies, how do you handle this? Do you just stop contributing to open source?

[Radim]

I'm not from the US and don't know the US employment law, but you generally don't have to ask permission from your employer on things you do in your free time.

Unless you signed a contract that specifically forbids you from contributing to open source / other software projects (why would you do that? what is the exact wording? is such clause even legal?), your free time is your own, to freelance or work for other employers.

Working on open source on your employer's time and money is a different thing, and asking for permission makes perfect sense there.

[tbirdz]

Small correction, but a CLA is a contributor licensing agreement, not a copyright assignment. The contributor still owns the copyright to their code, they've just explicitly allowed the project to license their code under the terms of the project license.

[johncolanduoni]

Depends on the CLA. Many CLAs (for example the one that RoboVM used that allowed them to switch their GPL licensed compiler to a closed source model more easily) do require copyright assignment.

[PieterH]

I've fixed it. There are various models, CLA, assignment, etc. I didn't want to get into details of that.

[kemitchell]

You may be interested in the CLA alternative I'm working on:

https://github.com/berneout/berneout-pledge

It's still very much experimental, and very much open to feedback.

[cloudjacker]

Is it possible there is a collective that software engineers could all join, where the membership process includes accepting certain licenses

(And then we could collectively negotiate salary and equity stakes too hint hint)