Ask HN: Are GitHub pull-requests governed by the original repository license?

   Copyright (C) 2022 My Name

A random contributor forks my repository and sends me a pull-request. They haven't altered the license file in any way.

So, Question 1: are their contributions automatically licensed under the same MIT license as the original repository? (Note that their fork, which I'm being asked to merge, contains the identical license file.)

Question 2: have they (almost certainly inadvertently) assigned copyright over their changes to me? (They're asking me to merge changes from a repository which contains a copyright declaration in my name.)

Question 3: if one, why not the other?

Disclaimer -- personally I hate even having to think about these kinds of questions, which is why I try to make most of my open-source code available under the Unlicense [1]. I've recently discovered the Zero-Clause BSD licence [2] which may be a better alternative as it avoids the potentially problematic concept of a 'public domain' -- I'd love to hear an informed legal analysis of their differences.

[1]: https://unlicense.org

[2]: https://opensource.org/licenses/0BSD

Yes — that is the common understanding, a foundation upon which vast amounts of collaborative Open Source projects are built.

> Question 2: have they (almost certainly inadvertently) assigned copyright over their changes to me? (They're asking me to merge changes from a repository which contains a copyright declaration in my name.)

No. Copyright assignment is involved and needs more than that incidental quirk of that copyright notice in the MIT license template (which is confusing).

> I'd love to hear an informed legal analysis of their differences.

Go with a standard, popular FOSS license. Avoid "crayon licenses" which are poorly drafted, because they lead to legally ambiguous situations which serve both users and contributors poorly. Resist the urge to cut your nose off to spite your face by adopting a purposefully rebellious license.

The original JSON license is the crayon license whose flaws are easiest to understand. It contains the phrase "shall be used for Good, not Evil", which begs the question "who decides what's evil?" and opens up any user to a potential lawsuit.

The OSI ultimately approved the Unlicense, but with a critique. It's flaws are not as easy to understand as those of the JSON license, but here you go:

https://lists.opensource.org/pipermail/license-review_lists....

> There is general agreement that the document is poorly drafted. It is an attempt to dedicate a work to the public domain (which, taken alone, would not be approved as an open source license) but it also has wording commonly used for license grants. There was some discussion about the legal effectiveness of the document, in particular how it would operate in a jurisdiction where one cannot dedicate a work to the public domain. The lawyers who opined on the issue, both US and non-US, agreed that the document would most likely be interpreted as a license and that the license met the OSD. It is therefore recommended for approval.

(2) There is no implicit copyright assignment. The author of the change retains copyright in that code, and you retain copyright in your code. You may want to look in to copyright license agreements in which you get your contributors to agree to allow you to use their code in your project and maybe agree not to revoke that permission.

Boilerplate headers have no real legal standing: copyright applies the minute you type the text of the source code and is only worth what you can prove in a court of law. Should you wish to change the distribution licensing at some point in the future, you will need to secure the permission of all copyright holders. In the absence of copyright assignment or copyright license agreements that means everyone who has ever contributed a line of code.

(2) No, unless they have stated that they have transferred ownership to you they own the copyright of their changes.

They aren't really contradictory as they are separate concepts so covered by different conventions.

Copyright: the new contributor has copyright of the code they produced because this is automatic (in most jurisdictions at least), and they keep that unless they explicitly reassign it.

Licence: as the licence has not been changed in their fork, the old licence remains. If they change the licence in future then things are a little more grey for future contributions, and it depends on the licence. But they can't change the licence of your code unless the existing licence explicitly allows that. There may be limits on whether they can change the licence at all (i.e. if the original license is GPL).

With MIT all is well in this circumstance. A problem will occur if the core project wants to change their licence at a later date. Again IIRC with MIT this is fine, but with stronger licences they would need to get permission from the copyright holder of parts they are not officially the copyright holder of already, just as the new contributor wouldn't be able to arbitrarily relicense code taken from the primary branch.