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


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

  • 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
    Commented Aug 5, 2016 at 23:00

2 Answers 2


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.

  • 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
    Commented Aug 8, 2016 at 16:18
  • 2
    1. 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
    Commented Aug 8, 2016 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 <you> 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
    Commented Oct 20, 2018 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
    Commented May 23, 2020 at 0:39

Legally speaking it's absolutely a mess.

First of all we have to take under account that there is no legal precedent and until that happens all answers are going to be more or less hypothetical, limited by knowledge and interpretations of said knowledge.

Before we can even start talking about the contributors we have to understand that the license only goes for the initial code and it can be licensed only by the copyright owner. It is assumed that the contributions go by the same license but by law that's not necessarily the case.

While it is true that the contributors have their own copyright, it doesn't mean that the license of the project can't be changed. It depends entirely how someone (and legally speaking - how some judge) interpret the law. Because it could be argued either that the contribution was for the project or it was for the license. In either case, both the license can be changed and contributions could be withdrawn any time. Justification for the changing of license is that the copyright holder can do just that and it can be assumed that the contributions were for the project. After all, it's written in the license who the copyright holder is.

The reason for Contributor License Agreement is that for most license cases the contributions are not licensed at all. Remember, the license was only for the initial code. So in order to stop contributors to withdraw their unlicensed code (meaning they have copyright), they make them sign these agreements, in order to get them under a license too.

A) It depends how significant your changes were not what license it was under. Few changes here and there for the most part would mean the same license. On the other hand, if you rewrite most of it, change the functionality of it so it's hardly recognisable, and soon is going to change even more, then you could even write yourself as the copyright owner and license it as you see fit. This is true regardless of the original license. Some people try to mislead you to think like public licenses are somehow stronger or better than permissive licenses but the very opposite is true. The very same people think that if they make few changes to a code that they magically own the copyright - while that's outright illegal. As rule of thumb - permissive licenses will lead you to less legal trouble than restrictive ones. Besides many other, that's one legal reason why most new open source projects choose permissive licenses. Since MIT license is the most permissive, people tend to choose that.

B) What you are talking about here has absolutely nothing to to with law nor the license. MIT license does not require to attribute contributors. The reason many projects with permissive licenses do this is ideological. These people are liberal and democratic in nature. The sort of people who try to attribute even CC0 licensed authors. One reason they do this is to show their gratitude since permissive licenses do not require anyone to contribute to begin with. Another reason is to express the equality between the contributors and the initial copyright holder. It's just a nice gesture because legally speaking this attribution has no meaning since the license already gives everyone all the liberties. It has more to do with community spirit than anything else.

C) If you are planning to fork a MIT licensed project that has lot of contributors listed then you would be safest if - you only add yourself as a contributor. If even that. Do not change the license! Do not erase any names from the contributor list! Regardless how significant your changes are. This is not for legal reasons but for your own safety. Because while most of them are really nice and friendly, there are always some extreme anarchists and hackers in the bunch. Besides, MIT license gives you all the liberties you can ever imagine and there is no reason why to tick off names from the list or do anything like that. (Legally speaking we are talking about one project with one license + lots of contributions with each one of them being copyrighted, but for the meanwhile you could count as part of the same entity - While correct, I don't think this answer is going to help you much in your situation.)

  • 1
    Under the Berne convention, copyright protection is automatic and does not require a mention of the author. The implication of this is that the copyright line does not have to reflect who owns copyrights on (parts of) a work. Commented Apr 15, 2019 at 20:15
  • @BartvanIngenSchenau That's true for most cases, but open source is special case. If copyright infringement wouldn't be rampant by certain people in the open source community, then I wouldn't have come here. You can also read some conversation under my answer on this topic here: opensource.stackexchange.com/questions/5730/…
    – Smart455
    Commented Apr 16, 2019 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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