In the case when there is no explicit mention regarding the rules for such case in the project policy (like, f.e. GitHub has), what is the status of the code/patch submitted for the review (using mailing list or some other platform)? Is it automatically licensed under the same license as the target project (I can see it being the case for "viral" licenses but what about others?)? Does anyone have the same rights (copy, distribute) regarding it as they do with mainline project (even if it'll end up not being accepted)?
1 Answer
I'm not aware of any legal cases about this in particular, so I'll try to answer from the basic principles of copyright law.
The copyright in the contribution automatically belongs to the person who wrote it, and stays with them unless they make a written transfer.
Whether a patch is a derivative work is an interesting question. At one extreme, a patch that adds new functionality to a project so that the bulk of the contribution is completely new is clearly a new work; the fact that it is designed to work in the context of pre-existing code does not change this. At the other extreme if I contribute a patch which makes a large number of small changes in different places then my contribution cannot be meaningfully separated from the existing code and the result should therefore be considered derivative of the original. In between is a big grey area.
If the patch is a derivative work then it can only be distributed with permission of the original copyright holder, which in the case of an open source project means the relevant license. However this doesn't mean that the work is automatically licensed: the patch creator still has to license for distribution as well, and in theory the patch creator could withhold that license.
If the patch is not a derivative work then of course the creator can distribute it under any license at all.
When the patch is combined with the original code the result is a derived work of both the original code and the patch. Hence this derived work can only be distributed under a license which covers both. In practice this means the same license; an open source project maintainer would be very ill-advised to accept patches under any other license.
A license can only be created by the copyright owner. In the case of an open source contribution the license cannot be created by any decision of the existing project, so the acceptance or otherwise does not create a license (unless this is a specific term of an agreement, but the question stipulates otherwise).
In the UK it is possible to create an implied license by a mixture of positive and neutral acts. (In this context a "neutral act" seems to be the absence of a negative act). See page 48 of this thesis (PDF), which looks at implied licenses in UK law. In this case the contribution of a patch to an open source project is a positive act indicating an intention to license the patch under the same terms as the project, and the neutral act is the failure to raise an objection when the patch is incorporated in the project. Together these create an implied licence for the patch under which the composite work can be distributed.
Whether this license exists if the patch is not accepted is more arguable. As I said above, the decision to accept or reject the patch doesn't create the license, but the "neutral act" of not objecting to its incorporation doesn't happen, so by the logic above the license has not come into being. OTOH if someone else picks it up and distributes it separately under the same license as the original project (e.g. in a fork) then as long as the patch author was notified they would have the same opportunity to object and hence the license would be created.
US law is similar, although seems to be less specific about positive and neutral acts. The following extract from a BitLaw article sums it up:
The purpose of an implied license is to allow the licensee (the party who licenses the work from the copyright owner) some right to use the copyrighted work, but only to the extent that the copyright owner would have allowed had the parties negotiated an agreement. Generally, the custom and practice of the community are used to determine the scope of the implied license.
In this case the "community" would be open source in general and the project in particular, so the license would depend on the facts of custom and practice within the community. As the submission of a patch is customarily done with the intention of contributing to the larger work this would imply that the patch is licensed accordingly.
answered Aug 19, 2019 at 13:57
-
Thanks for the great response. I was wondering originally whether simple act of patch submission for code review/further discussion is enough to count it as "contribution", but you've cleared that up for me. Also, are there any guidelines/limits on the extent of the neutral/negative act? Basically, what if the original author decides to raise an objection several years down the line? Or will it be treated as revoking the license instead of never granting it in the first place (if so, when is the line)?– Dan M.Commented Aug 19, 2019 at 15:43
-
@DanM. I don't know; probably the license would be deemed granted if the patch author doesn't object in a reasonable time, such as before the release. After that it would depend on whether the license was considered irrevocable. These would be questions of fact for a court, if it ever came to that. In the absence of precedent we can only speculate. Commented Aug 19, 2019 at 16:24
-
One problem not addressed here is that edits can be made to both the posted code and answers, so an author could, at any time, change or revoke a license. Without a history of licenses, and a way to verify a snapshot of the code was taken during a specific license, I fear serious complications could arise.– duanevCommented Apr 29 at 16:36