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 <a href="https://stackoverflow.com/legal/terms-of-service#licensing" rel="nofollow">https://stackoverflow.com/legal/terms-of-service#licensing</a>) 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.<p>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.<p>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.<p>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 <a href="https://github.com/ytdl-org/youtube-dl/pull/30690" rel="nofollow">https://github.com/ytdl-org/youtube-dl/pull/30690</a>) 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.<p>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.