6

Some points I know:

  • Contributors own copyright over their contributions, which means the author (= the owner of the repo and original author) cannot re-license the code (= change the license of the code) without asking every contributor.
  • That's why some companies require you to sign a Contributor License Agreement which - easily said - transfers your rights to them, so that they can do what they want with the code (relicense, make proprietary, ...).

Questions:

  • When making changes to another repo (you've forked) do you release your changes under the license (usually a file called LICENSE or similar) of that repo?
  • If so there is one abnormality: If contributing to an MIT licensed project means you release your changes under the MIT license, this still does not mean the contributor has to be attributed in the new code base, but this is a requirement of the MIT license.
  • If I fork a (MIT licensed) project where contributors contributed to it does this really mean I fork one project which is licensed under one MIT license or does it rather mean I fork one project licensed under multiple MIT licenses of all contributors? So is this rather splitting of a cake or can I consider the project a big block of a license?

I think a step-by-step explanation (from forking the repo until the Pull Request is merged) would be useful. Bonus points for any kind of metaphors.

This question has been cross-posted in law Stack Exchange as it overlaps.

Mureinik
  • 5,112
  • 3
  • 31
  • 42
rugk
  • 365
  • 4
  • 9
  • 1
    I think this is going to be hard for Law to answer (I have commented there), but it is completely relevant here. – Tim Malone Aug 05 '16 at 23:00

2 Answers2

5

When making changes to another repo (you've forked) do you release your changes under the license...of that repo?

You aren't required to unless your changes fall within the domain of the license's copyleft. If the repository you forked is Apache 2.0-licensed (or some other permissive license), you can release your modifications under whatever license you want, even full copyright, provided that you follow the license's terms. If it is under the Mozilla Public License, you have to release whatever modifications you make to the MPL source files under the MPL, but separate files that are entirely your own work can be under the terms of your choice. If it's under the GNU General Public License, all your changes must be under the GPL.

However, if you give your contributions back to the copyright holders, it is best that you do keep your changes under the same license that they use, for simplicity's sake. It's annoying if you have one file under the MPL and another under the MsPL and you can't static link with that module because it's under the LGPL...

If I fork a (MIT licensed) project where contributors contributed to it does this really mean I fork one project which is licensed under one MIT license or does it rather mean I fork one project licensed under multiple MIT licenses

Great question! You fork one project licensed under multiple MIT licenses (unless of course the contributors assigned copyright to some central entity). Each contributor owns the copyright to part of the work, and they have all granted you rights to use the code. The project as a whole is considered to be under the MIT license because all contributors agreed to license it that way, but projects don't have to be all under one license. Copyright holders can dual-license their works so recipients can use the work under the license of their choice; the MPL has a GPL-compatibility mechanism that causes files to be dual-licensed. If you're a Firefox user, just go to about:license for an example of lots of licenses governing one work.

I think a step-by-step explanation (from forking the repo until the Pull Request is merged) would be useful.

It's much easier than you think. All you have to do is say in your pull request "I agree to release these contributions under the MIT license", or something to that effect. If you don't want to release your contributions under the MIT license (say, you want to be a jerk by releasing them under the GPL and thus forcing the entire project to be under the GPL), that's another story, and the project will probably reject your changes.

EMBLEM
  • 2,518
  • 1
  • 11
  • 20
  • 1
    Nice of you providing a practical example (the about:license). Just two questions: 1. Actually I have not seen anyone writing "I release this PR under MIT/... license", so is this implied when creating a PR? Or can I - as a repo owner - just say: "By submitting PRs you agree to release your code under the MIT/... license."? 2. You say I fork multiple MIT licensed code-snippets. However I as a forker do not credit each contributor as it is required by the MIT license. (This is what I meant with the "abnormality" in the OP.) So how can this work? – rugk Aug 08 '16 at 16:18
  • 2
  • Legally speaking it's not implied; copyright holders must explicitly give rights to their works through a license. But nothing's going to happen, even if some copyright troll contributes code to your repository and then sues you for using his copyrighted code, because the MIT license disclaims liability. Also, you can use such a contributor agreement as a repo owner. 2. You've hit on something there. To cover your bases as much as possible, you should probably create a new license file in which you name every contributor.
  • – EMBLEM Aug 08 '16 at 16:29
  • BTW adding to this some years later, I think best-practice (or, at least, one practice) to prevent this "abnormally" is to state in your (MIT) license "Copyright and contributors". This is implied, AFAIK, but it's a nice signal to contributors. Then a file "CONTRIBUTORS" in the root dir can be used to list the names of all contributors.

    It's just totally impractical to create a new license file for each contributor and I have never seen that.

    – rugk Oct 20 '18 at 15:21
  • 1
    Inbound license = outbound license is the norm. However, I believe there is no law for this. For Github, TOS section 6 specifically states that, if a repo has a license, then Inbound license = outbound license, unless there is another agreement. Gitlab says nothing. Bitbucket TOS requires stating inbound license (section 1). "to create a new license file" - no, you do not need to create a new file every time. What you need to do is to give the (c) author year line. (Whether or not that line is required if the author did not provide it is a different story). – Max Xiong May 23 '20 at 00:39