Do I have to credit small changes to my source?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.