Say I have a project I've posted on Github and after having it online for a month, I get an email or pull request from someone recommending a small change (For example, they say that on line 123 of file Foo.cpp I should change a = b + c; to a = b - c;). I review this code and realize that they are correct. However, I'm also wary about accepting contributors since every new contributor expands the number of license holders to my code and who I may have to contact if I need to change the license.

What are my obligations in dealing with this fix? The change is so small, there is really only one way to do it. Since it has been brought to my attention, I can't really claim it is my idea, and yet this is something I would likely have eventually discovered and fixed. Do licensing restrictions require me to credit this? Do I have to completely rewrite this bit of code with a new algorithm just to avoid adding a new license holder?

  • @MadHatter Why doubt your esteemed colleague who wrote "there's a general understanding that contributing code to open source projects is assigning the open source project the rights to the code"? How could that not be true? Of course general understandings aren't universal and is this about strict law, or loose opinion? Commented May 25, 2020 at 19:19
  • 2
    How would you feel if someone tried to claim your work? Your obligations include acknowledging any and all contributions. If you really think it could matter that a change was so small, there was only one way to do it, can you explain how that works in general, or here in particular? Do you really think this being something you would "likely" have eventually discovered and fixed matters? Licensing restrictions are purely local but they generally do require you to give credit or completely rewrite that code "just to avoid adding a new license holder." Commented May 25, 2020 at 19:29
  • Add a policy to the project, to state what happens with a pull request. For this example, add a test to the test suite. Run the test, then fix the code to make the test pass. If the fix is the same as someone else work, but you did not copy it. It is not a copy, therefore not an infringement. Commented May 25, 2020 at 21:44

4 Answers 4


My esteemed colleague has written that "there's a general understanding that contributing code to open source projects is assigning the open source project the rights to the code". I'm not sure that's true, but even if it is, the problem with general understandings is that they're not universal, and it's the people that don't share them that can cause the trouble.

(S)he has also suggested that the pull request template or the contributor guidelines are good places to put a Copyright Transfer Agreement (or, presumably, a Contributor Licensing Agreement). We have examined the issue of clickwrap CTAs/CLAs before; they are not problem-free, as some jurisdictions remain really quite unsure about them.

My own feeling is that the analysis should go:

  1. Is the contribution copyrightable? I'd argue that, in the above case, it is, because it embodies considerable insight and makes the program go from less-well-working to more-well-working. One could, however, argue that this change came in the only form it could: there may not be any other ways in this language to easily express the idea that b should be getting smaller by the amount of c, and such absence would argue against the copyrightability of that contribution.

  2. Do you want the right to relicense the entire project? If so, then get GPG keys and GPG-signed agreements from contributors before examining or accepting their contributions. Note that there is anecdotal evidence (though it's from a big project) that CTAs are a major turn-off for contributors. You could do what you want with a mere CLA that gives you the right to relicense the code, but even CLAs are an impediment to contribution (see same article; full disclosure, I wrote the article).

So think hard about what you're doing here, and why. If you don't have any real intention to relicense, it might be good to shrug and rule it out, or you might pick a weak free licence such as MIT for your project, which would place little impediment on the path to productisation. If you're sure you want this right, then be clear about it to your contributors, and ensure they signify assent before you even look at what they submit; you may well find, though, that such a decision ensures that the annoying problem of having contributors simply goes away.

  • Thanks. My main reason for potentially wanting to relicense is that I am finding the topic of licenses confusing and may decide a few months after I've released my project that I picked the wrong one.
    – kitfox
    Commented May 25, 2020 at 7:57
  • Regarding point 1, while I agree that this change would require specialized insight, I would also claim that it is an insight that I as the original developer also possess, and that I would likely have discovered and fixed this bug myself given enough time. However, now that someone has brought it to my attention, it now seems almost toxic - like copyright is now leagaly forbidding me from fixing this bug. Am I understanding this correctly?
    – kitfox
    Commented May 25, 2020 at 8:04
  • 1
    @kitfox I agree you could have done what the contributor did, but copyright in a created work is conferred on the person who did create it (assuming it qualifies for protection). And yes, you are understanding that correctly, which is why I several times in my answer stressed the importance of having any CTA/CLA you use in place before you examine any given contributor's offering. Many creators and creative organisations have clear policies against unsolicited submissions for that very reason.
    – MadHatter
    Commented May 25, 2020 at 8:09
  • (To be clear, it's not that you'd be prohibited from fixing that bug, but you might well invite copyright problems by then fixing it in the same way the submission did. That issue might in turn engender an annoying rewrite to permit the bug to be addressed in a different, unencumbered, way.)
    – MadHatter
    Commented May 25, 2020 at 8:12

This is regulated in the ToS of GitHub, Section D, §6:

6. Contributions Under Repository License
Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms. If you have a separate agreement to license your contributions 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 unless you have another contributor license agreement that contributors agree to, this part of the ToS applies and that means their contributions are under the same license as your code.

Note that you can not relicense your repo anymore without the consent of all contributors.


The example you gave is very unlikely to be copyrightable. Copyright covers expression of ideas, not ideas themselves. However it would be courteous to put a thank you somewhere (eg. in the git commit message).

In terms of contributions in general, this will largely depend of several factors. The norm in open source is that the inbound license = the outbound license. However, this is more of a community standard rather than a legal stance (I don't think this implied license has been challenged in court). If you are hosting on GitHub, the GitHub ToS states that inbound = outbound is the explicit default. If you are hosting on BitBucket, the ToS requires you to specify an inbound license. I did not find anything in GitLab ToS, so you will need a CLA.

An additional point of consideration is the requirement to maintain copyright line in many licenses. If the contributor adds a copyright line, you need to store it somewhere. It is unclear what happens if the contributor does not specify a copyright line whatsoever. It would be preferable to leave copyright lines in the project root, so that users of your project do not have to search the source files to comply with the license when searching for a binary. Alternatively, your CLA can specify that you require contributors to agree that the copyright line "(c) xxx and contributors, xxxx" is sufficient, or that they waive the requirement to retain the copyright line.

I have just became aware that there are certain licenses that specify an inbound license. This should be a viable option as well. Such an example is the BSD-3-Clause-LBNL license, which states the following:

You are under no obligation whatsoever to provide any bug fixes, patches, or upgrades to the features, functionality or performance of the source code ("Enhancements") to anyone; however, if you choose to make your Enhancements available either publicly, or directly to Lawrence Berkeley National Laboratory, without imposing a separate written license agreement for such Enhancements, then you hereby grant the following license: a non-exclusive, royalty-free perpetual license to install, use, modify, prepare derivative works, incorporate into other computer software, distribute, and sublicense such Enhancements or derivative works thereof, in binary and source code form.

This effectively asks for a public domain dedication from contributors. Of course, you should change the reference to "Lawrence Berkeley National Laboratory" to something more sensible to your project.

  • "it would be courteous to put a thank you in a comment next to the line" -- no, please don't, that is not what comments are for, and imagine doing this for many contributions, ruining the readability of the codebase. Git already handles this with git blame. Commented Jan 28, 2021 at 21:57
  • 1
    Changed the example to leaving the credit in the git commit message instead. For Apache-licensed projects I guess you could also use the NOTICE file to keep the attribution downstream.
    – Max Xiong
    Commented Jan 28, 2021 at 22:07

This depends how your repository is run...

In some repositories the person submitting a fix (or even large features) is implicitly or explicitly transferring the copyright of the code the the repository owner - Typically this would be in the contributing guidelines or pull request template.

In other cases the copyright is held collectively by all the contributors to the project with something like Copyright The MyAwsomeProject Contributors, 2020. and then the repository owner/administrators/senior collaborators decide the licensing, hopefully with consultation with all active developers.

As a side note, some projects include a separate authors list as a kind of acknowledgement of contributions, independent of legal copyright.

In my experience there's a general understanding that contributing code to open source projects is assigning the open source project the rights to the code, although if there's any doubt, just ask your contributor to state in the pull request that he's assigning the copyright to your or your project, as you see fit.

  • Thanks. But what if they refuse to sign anything or simply ignore any further communication I make? Am I now prevented from making this change to my code?
    – kitfox
    Commented May 25, 2020 at 6:22

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.