Earlier quoted context omitted.
> 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.
Ask HN: Are GitHub pull-requests governed by the original repository license?
21–30 of 33 posts
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#22Earlier quoted context omitted.
> 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.
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)
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#23Earlier quoted context omitted.
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?
(Friend Of A Friend) != (Fuck Around Find Out)
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#24(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 you…
https://www.gnu.org/licenses/why-assign.en.html
https://softwareengineering.stackexchange.com/questions/1857...
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#25> 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…
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.
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#26It 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.
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#27However, 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.
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#28In 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 m…
Not just big companies. I have CLA assistant set up on all of my public repos.
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#29> 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…
> 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:/…
Re: Ask HN: Are GitHub pull-requests governed by the original repository license?
#30(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 you…
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...