[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.

[daveguy]

It takes a really warped interpretation of open source to claim MIT is a closed source license. Not even Stallman agrees with that. In his essay on selling exceptions to GPL he gave this argument[0]:

" If that implication is valid, it would also apply to releasing the same program under a noncopyleft free software license, such as the X11 license. That also permits such embedding. So either we have to conclude that it's wrong to release anything under the X11 license -- a conclusion I find unacceptably extreme -- or reject this implication. Using a noncopyleft license is weak, and usually an inferior choice, but it's not wrong.

In other words, selling exceptions permits some embedding in proprietary software, and the X11 license permits even more embedding. If this doesn't make the X11 license unacceptable, it doesn't make selling exceptions unacceptable "

It seems everyone except you, including the father of copyleft, agrees that the MIT license is a free and open source license.

[0]:https://www.fsf.org/blogs/rms/selling-exceptions

[pjmlp]

Other than I can take a MIT licensed project used to build my product, sell it and never give the anything back, not even the code.

Seems pretty close source friendly to me.

[opk]

And many open source developers are just fine with that. If someone finds a use for my code and even if they make lots of money off it then good for them. It's not like they've stopped me from using it in the original form. I've also had cases at work where we want to use open source and copyleft licences have caused clueless managers to get panicky despite the fact that we don't redistribute anything, only make use of it internally. They also often initially tell me not to contribute anything back but after the work is done and I explain multiple times about the effort of porting the changes to subsequent newer releases they agree (often with the proviso of using my personal e-mail). In summary, I don't follow the RMS line of closed source being morally evil or whatever so a license like ISC or MIT is the best practical match to my wishes when I release stuff.

[int_19h]

>> while Microsoft grants 0 patent licenses over any of their open source code

PTVS is licensed under Apache 2.0.

https://github.com/Microsoft/PTVS/blob/master/LICENSE

[rando832]

I stand corrected.

[johncolanduoni]

Most of the big MIT licensed Microsoft projects I know (.Net Core VM and libraries) are licensed under MIT with a separate, explicit patent grant. For example look at the PATENTS.TXT file in this repo: https://github.com/dotnet/corefx

[rando832]

Interesting. It's a non-legally binding patent promise. But honestly, I think MS has waded too far into open source to have the bad publicity of breaking that promise, unless MS gets into very bad finances. Anyways, good enough for me.

And it actually makes my point about the MIT license, it's inadequate for patents.

[johncolanduoni]

What makes you think it's not legally binding? As far as I can tell it's as binding as the MIT provisions.

[rando832]

Looks like I was wrong.

According to these links, they will probably work in an actual case. They can be revoked at any time, making them inapplicable to future patent use which was not already going on for some period of time.

http://en.swpat.org/wiki/Equitable_defence, http://en.swpat.org/wiki/Patent_promises

Definitely not anywhere near as binding as the MIT license, but it's not a good comparison anyways, MIT addresses only covers only copyright and patent law is a very different and separate area of law.

[rando832]

As others have pointed out, MS does have explicit patent promises, so my characterization was wrong.

[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.

[pash]

Yes, there's a good argument that the license would apply automatically to modifications to an existing file, but even in that case it is somewhat questionable. Is the modification substantial enough that it could be considered a new, stand-alone, derived work? If so, the pre-existing license may not apply. Was the modification submitted as a patch in a file format that does not incorporate all of the pre-existing code? If so, it may be a new, stand-alone work to which the pre-existing license does not apply. Etc., etc. Very little of this stuff has been well tested in court, so there's a lot of room for facially plausible legal challenges.

And it's fairly clear that new files are new works. So, really, in all cases, unless you're getting an explicit statement from contributors that they have placed their contributions under the relevant license, there will be a a lot of uncertainty about whether they really have been—particularly if the contributor (or his or her employer) later challenges your claim.

That's why Github and other platforms for projects on the pull-request model should really build explicit consent to licensing into the process.

[mintplant]

> And it's fairly clear that new files are new works. So, really, in all cases, unless you're getting an explicit statement from contributors that they have placed their contributions under the relevant license, there will be a a lot of uncertainty about whether they really have been

For a project using the MPLv2, new files added to the project would include the following header at the top:

> This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

Wouldn't that cover this?

[PieterH]

You cannot modify a work so much that the original licence no longer applies, unless you in effect create a new work.

[pash]

Yes, absolutely a code file can be transformed enough that the original license no longer applies. Copyright law in the United States applies the same tests to code as to textual works and works in other media: is the transformation substantial enough to consider the transformation a new (derived) work, copyrightable in its own right? If so, its author holds its copyright completely independently of any copyrights or licenses attached to the work from which it is derived.

The case law on what constitutes a new, derived work is not at all well developed in the context of software. But looking at analogues from other media—and that's what the law does—it is easy to imagine that a very substantial refactor, touching basically every line, or a less substantial refactor with substantial additions, might qualify as a new, separately copyrightable work.

The claims of copyleft are almost entirely untested in court, and it's very likely that many of them will prove empty if they're ever challenged. Indeed, many of copyleft's claims, those which place obligations on users and contributors, are more TOS-style claims than claims that look like ordinary "reserved rights" under copyright law, and therefore presumably have a legal basis of enforcement in contract law, not in copyright law.

Explicit agreement by contributors to be bound by a license, however, covers most bases, whether the license is interpreted as a license per se, pursuant to copyright law, or whether it's ibstead interpreted as a contract under contract law (or both).

[PieterH]

If you claim that copyleft is almost 'untested in court' you are either wilfully ignorant or trolling.

[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.

[morgante]

> 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.

Employment contracts for developers in the US, particularly at big companies, are very broad and try to lay claim to any development work you do (regardless of whether it's in your "free time" or not). They often expressly forbid freelancing or open source work unless it is approved by the company.

[pjmlp]

And is it tested in court?

In most European countries those type of clauses are anyway invalid, even if written in the contract, as the company doesn't have a say on how you are supposed to live your private life.

Doing freelancing is another matter.

[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)