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

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

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

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.

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

I would not consider that an open source license, and it's almost no different than a proprietary license.

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.

It is not intended to be an open source license. Ethical source licenses in general do not respect "Freedom Zero" of open source.

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)

Yes, that's why it's called the FOAF (Fuck Around and Find Out) license. Do you feel lucky?

FOAF != FAFO

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

> 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

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

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

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.

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

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

And this is why the GNU project, Fedora and others explicitly ask contributors for CLAs if I understand it correctly:

https://www.gnu.org/licenses/why-assign.en.html

https://softwareengineering.stackexchange.com/questions/1857...

Exactly. Although DCO is a lightweight alternative to CLA: https://en.wikipedia.org/wiki/Developer_Certificate_of_Origi...

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.

Not just big companies. I have CLA assistant set up on all of my public repos.

How did you set this up? I've been wondering about doing this sort of thing

https://cla-assistant.io/

Many CLAs are not a copyright assignment, but just a more explicit licensing and granting of rights.

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

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

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.

I think you should look at Apache License that is explicitly talking about contributions.

Add contributor.md file and put the criterias for a suitable pull request there.

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

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 itself has a copy-pasteable blurb) since technically in the US where I am it shouldn't really serve as a 'license' and thus the license-in=license-out standard for other things doesn't quite apply. So I'd ask a PR that didn't include it to comment with it before merging, or if there's disagreement either convince me to release a new version of "the work" with a real license, or refactor their change as an external library dependency. Still, house of cards.

youtube-dl is maybe the biggest Unlicensed project and solves this with a pull request template that includes a checkbox they ask contributors to check (see randomly https://github.com/ytdl-org/youtube-dl/pull/30690) and this is probably a good model to follow if you expect a lot of contributions. (youtube-dl has 768, its better fork yt-dlp is at 925.) On the other hand, sqlite is just released straight into the public domain, not even with a "no warranty don't sue me" clause, and is used worldwide by countless things. There are other widely used purely public domain projects too. All of our fretting with trying to pin down more legally certain edge cases with these alternate 'licenses' and agreements and so on is probably just a big waste of time.

For important software to yourself or one's company or contributor group (financial, social credit, control (including possibly control to relicense/dual license everything in the future), belief in weaponizing copyright to forbid taking away the 4 freedoms via the GPL) I'm basically in agreement with others about minimizing legal risk and just going with something popular and not "crayon" and to consider getting CLAs, it can legitimately not be a waste of time to think about all this. Though for other cases I also think it's important to remember how fragile this house of cards is, and weird 'licenses' like WTFPL or extra clauses like "prohibited to use this for evil" or "prohibited to use this if your name is [person I don't like]" or even a more normalized weird in the AGPL's "prohibited to have users using this by server proxy and not share your changes" all serve as a reminder as well as in some cases injecting a bit of light-hearted "don't be so serious, let's try to play nice" sentiment into the matter which is important long-term for any common culture among those calling themselves programmers.