HN Explorer

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

45 points by dmulholl ↗ HN
This is a question for our legal friends here on HN. Imagine this scenario: I have an open source project on Github with an MIT license. I've cargo-culted the

   Copyright (C) 2022 My Name
line from every MIT-licensed project I've ever seen.

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

32 comments

[ 3.0 ms ] story [ 76.8 ms ] thread
matthews2
> are their contributions automatically licensed under the same MIT license as the original repository?

Yes. GitHub clarify this in their terms of service: https://docs.github.com/en/github/site-policy/github-terms-o...

> 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. They still own the copyright to their change (unless it's a trivial, un-copyrightable change).

It's not uncommon to require contributors to reassign copyright.

bryanlarsen
I think the OP is wondering why, since the two answers seem to be contradictory positions.

IANAL, but here's my understanding: in the US copyright is automatic. You gain the copyright in anything you write automatically unless you explicitly give it up. A PR does not have this explicitness so it doesn't transfer the copyright. OTOH, the license choice is not an automatic right. By PR'ing on a repo with a license, you are implicitly choosing that license.

The GitHub Terms and Conditions make this implicitness more explicit, but AFAICT it's not theoretically necessary. However clarity is always super useful in a legal context.

dspillett
> I think the OP is wondering why, since the two answers seem to be contradictory positions.

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.

rectang
> 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.)

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.

chrismorgan
The real kicker in OSI’s judgement of Unlicense is that it seems that the only reason they approved it is because it was written so badly that it failed in its goal of being a public domain dedication, and will probably be interpreted as a license instead. (That’s how I read their wording, which is very slightly ambiguous, but seems to be talking about the document as a whole rather than just the intended fallback license aspects.)
ensignavenger
The Unlicense doesn't even resolve the questions OP has any differently than the MIT license or any other standard Open Source license would.

What I usually do for the copyright attribution on my own projects is "Copyright My Name and Contributors". That makes it clearer that there may be contributions from others merged into the code and I'm not claiming copyright over everything.

NoGravitas
> 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.

I personally like the FOAF license, which is like the original JSON license, but specifies that "what's evil" is determined by the originator of the project.

Anon1096
I would not consider that an open source license, and it's almost no different than a proprietary license.
rectang
Agreed. Specifically, that's not compatible with the Open Source Definition section 6.

https://opensource.org/osd

> 6. No Discrimination Against Fields of Endeavor

> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

NoGravitas
It is not intended to be an open source license. Ethical source licenses in general do not respect "Freedom Zero" of open source.
ta988
This opens the door for the originator to change their mind. So pretty much the opposite of a legal document where it is tried to make things unambiguous (of course there are exceptions and failures to do that)
NoGravitas
Yes, that's why it's called the FOAF (Fuck Around and Find Out) license. Do you feel lucky?
rectang
FOAF != FAFO

(Friend Of A Friend) != (Fuck Around Find Out)

tzs
> Copyright assignment is involved and needs more than that incidental quirk of that copyright notice in the MIT license template.

To elaborate on "is involved", you need to have it in writing that you are transferring ownership and that has to be signed. See 17 USC 104 [1] and/or page 3 of the "Copyright Basics" circular [2] from the US Copyright Office.

[1] https://www.law.cornell.edu/uscode/text/17/204

[2] https://www.copyright.gov/help/faq/faq-assignment.html

riedel
BTW: as a German I cannot transfer the German equivalent to copyright ("creator's right" would be the literal translation) at all. Any transfer is indeed licencing (the equivalent to copyright transfer would be exclusive licencing).
ageitgey
In the US, you automatically have copyright over code you create yourself (assuming there's 'authorship' to make it something deserving of copyright). Sending someone a PR doesn't mean you lose your copyright. You end up in a murky area where the norms of OSS are that your contribution is now part of the package, but they don't have clear ownership over the copyright of all the code in the repo.

This is exactly why most big companies require new contributors to sign a copyright assignment before any of their PRs can be merged. Gray areas don't work when lots of money is at stake.

detaro
Many CLAs are not a copyright assignment, but just a more explicit licensing and granting of rights.
bregma
(1) If you accept their contributions and distribute your project under the MIT license, your project is distributed under the MIT license.

(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.

[deleted]
(comment deleted)
charcircuit
(1) Not necessarily. The other person may license it under multiple licenses or even under a proprietary one.

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

jitendrac
Add contributor.md file and put the criterias for a suitable pull request there.
gls2ro
I think you should look at Apache License that is explicitly talking about contributions.
pcthrowaway
Other people have already answered your questions, and I agree with them:

(1): probably, but not necessarily; they could choose a different license for their contributions, though it would be unlikely to get merged

(2): no, they still have copyright on their changes unless they reassign it

But if the repo was GPL then their contributions would automatically be GPL also

phkahler
>> But if the repo was GPL then their contributions would automatically be GPL also

Because the GPL requires all (conveyed) derivative works to be GPL licensed. If they intended it to be anything else they would be in violation of the GPL.

Jach
IANAL and I don't have much of value to add to what's already been said, just some rambling thoughts... First I want to reiterate that broad sentiments somewhat resembling "can't we just get along and get on with real work" underpins so much, both in open source and proprietary software, run directly by the user or via server proxy. Take just the question of Stack Overflow. There is a ton of code out there (open source and proprietary) that is directly copied from (or sometimes "inspired by", perhaps with a language change or trivial variable renames) SO posts. This is not really legally allowed except in limited circumstances (see https://stackoverflow.com/legal/terms-of-service#licensing) yet it's done anyway, even at big multi-billion/multi-trillion dollar companies you've heard of. Sometimes a comment will helpfully link to the source (and it really can be helpful, even if only in the crude way of identifying it to lawyers/linters as something to rip out, but usually more by way of providing context and discussion) yet it has all the legal significance of "no copyright infringement intended" on copies of videos or music on youtube. If SO had an all-seeing eye and actually went after all prohibited uses out there, it might take down the whole industry. When you add all the other sources of code people copy or reference in various ways (other fora, blogs, different countries, books, papers, code/etc predating the 70s/80s decisions making code copyrightable at all in the US, code that is directly mathematical in nature and not copyrightable, totally anonymous authors, and so on) it's clear this is all built on a house of cards.

It may be worth thinking of "the work" as the code + the revision history. Historically this was done by actually embedding something like a changelog with different author information in the code itself, so that there's version A of the work with just you and your code, and other version B of the work with you and someone else and their changes with their changes called out explicitly. With version control we don't usually bother with such embedding because it's part of the history, but you still have version A of the work with just you and version B with you + the other author, even if nothing in the source code itself (or the license file) indicates the presence of another author. The revision history alone is enough to establish their partial authorship and any copyright claim. And probably implicit agreement to the original license, barring any signs to the contrary, per your question 1 and github's official doc on the matter -- adding something to your readme for a public domain project like "contributions implicitly agree to relinquish their copyright and dedicate changes to the public domain" seems like it'd be in the realm of weird EULA clauses that may or may not be enforceable.

I like the Unlicense too since I learned of it. I mean, I like the public domain and screwing thinking more about this license stuff, but I also like putting in a "don't sue me if something bad happens while using this" disclaimer, and even if it's "clumsily worded" as others have said when it comes to countries that don't recognize the public domain, it seems less clumsy than some of my prior attempts at "this is public domain or MIT if your country doesn't recognize such a thing". The CC0 is also acceptable as public-domain-unless-your-country-sucks-then-as-close-as-possible, even if it's not exactly meant for software. In a recent Unlicensed library of mine that I think has a slightly-greater-than-epsilon chance of ever seeing a pull request someday, I decided in the readme to call out a request that contributions include a blurb explicitly relinquishing to the public domain (Unlicense's site it...

brudgers
My standard answer: if it matters, hire a lawyer and if it doesn't matter, it doesn't matter.

However, I believe this is exactly the scenario the GPL and Apache address. The GPL by copyleft and Apache by contributor agreements.

Neither is a free lunch. Then again neither are lawyers.