Imagine I fork a MIT licensed project on GitHub, make some changes and submit a Pull Request (PR). I own the copyright of my changes. The PR is accepted.

A few years later, someone uses the software on something I don't like, and I sue the person for copyright infringement, saying I never licensed my software to that person.

In my understanding, my claims are completely baseless, because the moment I submitted the PR, I implicitly licensed my changes under MIT, because that is the license of the project. Is this the correct interpretation? Has this situation ever been tried in court?

If I am the maintainer, what language should I put in the README to make it explicit that any PRs sent to my project must be MIT licensed?

  • Was your hypothetical contribution to a file which included a header stating its contents were under MIT license?
    – Ángel
    Commented Apr 20 at 1:45
  • @Ángel I am not sure, I like to write diff patches by hand, so I never looked at the full file. I consider the patch file loaded into git to be my copyrighted work.
    – lvella
    Commented Apr 22 at 10:23

2 Answers 2


In my understanding, my claims are completely baseless, because the moment I submitted the PR, I implicitly licensed my changes under MIT, because that is the license of the project. Is this the correct interpretation?

As you stated that the project is on GitHub, the GitHub ToS has an important and relevant section:

6. Contributions Under Repository License

Whenever you add Content to a repository containing notice of a license, you license that Content under the same terms, and you agree that you have the right to license that Content under those terms. If you have a separate agreement to license that Content under different terms, such as a contributor license agreement, that agreement will supersede.

Isn't this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound". We're just making it explicit.

So, the answer to your question is, because you contributed to a project on GitHub that doesn't have a specific statement on how contributions to that project must be licensed, the GitHub ToS dictates that your contribution must have happened under the project's MIT license..

As a maintainer you can state in your README or other documentation that if a PR doesn't contain a statement to the contrary, then you expect the PR to be licensed under the project's license.

  • 1
    How bulletproof is the GitHub ToS nobody reads?
    – lvella
    Commented Apr 18 at 13:02
  • 8
    @lvella, The ToS is what you agree to by using GitHub's services. That is irrespective of actually having read it. Commented Apr 18 at 13:11
  • 2
    I suspect implicit in OP's comment question is, "how enforceable are GitHub's ToS [considered to be, if not directly tested]; this answer's clause in particular?" Is that best dealt with in a separate question? The answer to that question presumably has relevance to this answer, since if GH's ToS are not clearly enforceable, in OP's hypothetical scenario they could say "I never explicitly agreed to GitHub re-licensing my code / they had no right to it / etc" (clearly not all ToS terms are enforceable- "by using this website you agree to pay us $1M / hand over firstborn / etc")
    – bertieb
    Commented Apr 19 at 10:04
  • 1
    @bertieb, I believe this clause is enforceable. It does not grant GitHub excessive power (it actually doesn't grant them anything), nor does it unduly penalize you. As stated in the second paragraph, it merely codifies a practice that is already common in the open-source community. Commented Apr 19 at 10:57
  • 7
    @lvella: The ToS is pretty bulletproof, because the question assumes a lawsuit. The defendant claims they got the source code from GitHub, and this itself will not be disputed. Then the defendant claims GitHub had the right to distribute this code under the MIT license, and then the claimant has the burden of proof to dispute this. But the claimant uploaded the source to GitHub. Under what terms could that have happened, other than the ToS? If the claimant didn't accept with the ToS, then they didn't even have the right to upload the problematic source.
    – MSalters
    Commented Apr 19 at 12:38

I rather thought this would be a duplicate question, but I can't currently find anything that fits exactly.

Outbound=inbound is a traditional custom and practice in the free-software community, but it's not necessarily legally-binding.

This website is pretty clear:

Some projects never collect CLAs or CAs from their contributors. Instead, they accept code whenever it seems reasonably clear that the contributor intended it to be incorporated into the project.

This can seem to work for a long time, as long as the project has no enemies. But I don't recommend it. Someone may eventually decide to sue for copyright infringement, alleging that they are the true owner of the code in question and that they never agreed to its being distributed by the project under an open source license.

which is the exact scenario you ask about, I think. Copyleft licences don't have this problem, but if as a maintainer you're going with a permissive licence, and you don't want to take this risk, clarifying the licence on contributions as part of the contribution process is probably a good idea.

You could (as you suggest) do this by adding some text to your project's source tree, but this sort of implicit declaration is never terribly bulletproof. Instead, best to include an explicit "I confirm that I make these contributions available under an MIT licence and that I have the right to do so" step as part of the contribution process. Although CLAs tend to raise hackles on at least some contributors, this one's pretty harmless, and anyone who's trying to contribute but won't make such a declaration should probably be regarded with some suspicion.

  • 4
    I don't feel my point is substantial enough for an additional answer, but: I might augment your note about copyleft immunity to this problem by noting that Apache 2 is one permissive license that proactively tackles this problem by requiring any opt-out of inbound=outbound to be labeled "not a contribution".
    – apsillers
    Commented Apr 18 at 15:21
  • An excellent point, thank you!
    – MadHatter
    Commented Apr 19 at 7:37
  • With a copyleft license you still could get someone contributing code they copied from somewhere else, without the agreement of the copyright holder. Though that can't be prevented by a CLA. Commented Apr 19 at 22:54
  • I don't think the outbound=inbound problem is only immune to copyleft license, it's really whether the license has tried to address the problem. For example, apache v2 section 5 explicitly states the agreement of the license of submitted contributions. Perhaps some people get the impression that this problem as non-existent only in copyleft licenses because the proliferation of extremely simple permissive licenses such as MIT, which doesn't attempt to address complicated scenarios.
    – xuhdev
    Commented May 1 at 6:43
  • @xuhdev yes, apsillers points that out above, and I have already accepted his excellent point.
    – MadHatter
    Commented May 1 at 7:49

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.