<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 29 Mar 2020 at 16:42, <<a href="mailto:osi-license-review@jaeckel.eu" target="_blank">osi-license-review@jaeckel.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The Unlicense exists since 10 years [1] to give projects the possibility<br>
to dedicate their code into the public domain in jurisdictions that<br>
don't have an understanding of the public domain. The homepage at<br>
<a href="https://unlicense.org/" rel="noreferrer" target="_blank">https://unlicense.org/</a> lists a wide variety of software that already<br>
uses said license. A search on GitHub for projects using The Unlicense<br>
[2] returns by the time of writing 133,188 repositories using it (not<br>
including forks of repositories).<br></blockquote><div><br></div><div>The Unlicense was discussed on this list back in Jan–Mar 2012, in the wider context of the much better written CC0 license (which didn't get approved either). E.g. you can read the Jan 2012 archive in mailbox format, for easy grepping [1]. At some point, Bruce Perens highlights the general problems with crayon licenses [2]. Rick Moen mentions some specific issues with the Unlicense [3]. The issues in jurisdictions without public domain dedications are also well known [4]. Since then, nothing about the Unlicense's problems has changed.<br></div><div><br></div><div>The Unlicense is not safe to use and likely fails to achieve its stated goals, so it would be good if OSI won't lend it legitimacy by approval. If it were to be approved, hopefully only as an explicitly discouraged or deprecated license.</div><div><br></div><div>However, I think that the Unlicense is a (bad but still) OSD-compliant device, modulo the lack of a patent license [5], that it may not even be a license, and assuming that its problems are not fatal (I'll let the lawyers discuss that). The FSF [6] was probably right to recognize it as a free software license, but to recommend the “more thorough and mature” CC0 instead.<br></div><div><br></div><div>[1]: <a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2012-January.txt" target="_blank">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2012-January.txt</a></div><div>[2]: <a href="https://web.archive.org/web/20150921224734/https://lists.opensource.org/pipermail/license-discuss/2011-December/000039.html" target="_blank">https://web.archive.org/web/20150921224734/https://lists.opensource.org/pipermail/license-discuss/2011-December/000039.html</a></div><div>[3]: <a href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2012-January/001386.html" target="_blank">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2012-January/001386.html</a></div><div>[4]: Since the Unlicense is potentially contradictory and defective, I effectively have to treat Unlicense-covered software from e.g. German authors as proprietary, quite contrary to the intent of the license. I might change my opinion when there's good case law on it.</div><div>[5]: The Unlicense does allow “use” in paragraph 2, which has been argued to be an implicit patent grant in the MIT license. But the rights relinquished by the Unlicense only involve copyrights per paragraph 3.<br></div><div>[6]: <a href="https://www.gnu.org/licenses/license-list.html#Unlicense" target="_blank">https://www.gnu.org/licenses/license-list.html#Unlicense</a></div><div></div></div></div>