7 ms·

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

by PieterH 10y ago

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.

teamhappy 10y ago
> 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 http://www.apache.org/licenses/LICENSE-2.0
- PieterH 10y ago
  That is excellent.
makomk 10y ago
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.
tbirdz 10y ago
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.
- PieterH 10y ago
  I've fixed it. There are various models, CLA, assignment, etc. I didn't want to get into details of that.
- johncolanduoni 10y ago
  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.
pash 10y ago
> 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."
- deleted 10y ago
  [deleted]
- snuxoll 10y ago
  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 10y ago
    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.
philip1209 10y ago
Here's a CLA assistant tool - it blocks merging a Github PR until a specified CLA is signed: https://cla-assistant.io/ https://cla-assistant.io/
semi-extrinsic 10y ago
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 10y ago
  I explained the ways it's suboptimal, worst IME is for drive-by contributors from larger firms.
int_19h 10y ago
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/ 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+MSBOT&utf8=%E2%9C%93 https://github.com/Microsoft/PTVS/pulls?page=1&q=is%3Apr+MSB... (note the labels)
- rando832 10y ago
  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.
  - int_19h 10y ago
    >> 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 https://github.com/Microsoft/PTVS/blob/master/LICENSE
    - rando832 10y ago
      I stand corrected.
  - daveguy 10y ago
    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 https://www.fsf.org/blogs/rms/selling-exceptions
morgante 10y ago
> 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?
- deleted 10y ago
  [deleted]
- Radim 10y ago
  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 10y ago
    > 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 10y ago
      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.
cloudjacker 10y ago
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)
kemitchell 10y ago
You may be interested in the CLA alternative I'm working on: https://github.com/berneout/berneout-pledge https://github.com/berneout/berneout-pledge It's still very much experimental, and very much open to feedback.

by PieterH 10y ago

teamhappy 10y ago

> 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 http://www.apache.org/licenses/LICENSE-2.0

PieterH 10y ago
That is excellent.

makomk 10y ago

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.

tbirdz 10y ago

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.

PieterH 10y ago
I've fixed it. There are various models, CLA, assignment, etc. I didn't want to get into details of that.
johncolanduoni 10y ago
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.

pash 10y ago

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

deleted 10y ago
[deleted]
snuxoll 10y ago
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 10y ago
  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.

philip1209 10y ago

Here's a CLA assistant tool - it blocks merging a Github PR until a specified CLA is signed: https://cla-assistant.io/ https://cla-assistant.io/

semi-extrinsic 10y ago

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 10y ago
I explained the ways it's suboptimal, worst IME is for drive-by contributors from larger firms.

int_19h 10y ago

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/ 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+MSBOT&utf8=%E2%9C%93 https://github.com/Microsoft/PTVS/pulls?page=1&q=is%3Apr+MSB... (note the labels)

rando832 10y ago
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.
- int_19h 10y ago
  >> 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 https://github.com/Microsoft/PTVS/blob/master/LICENSE
  - rando832 10y ago
    I stand corrected.
- daveguy 10y ago
  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 https://www.fsf.org/blogs/rms/selling-exceptions

morgante 10y ago

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

deleted 10y ago
[deleted]
Radim 10y ago
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 10y ago
  > 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 10y ago
    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.

cloudjacker 10y ago

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)

kemitchell 10y ago

You may be interested in the CLA alternative I'm working on: https://github.com/berneout/berneout-pledge https://github.com/berneout/berneout-pledge It's still very much experimental, and very much open to feedback.