Let me try to explain again, even thought parts of explanations are already scattered throughout the the issue tracker.

TweetNaCl.js is a port of the original TweetNaCl project — https://tweetnacl.cr.yp.to. The original code is written by the following authors, and it's in public domain. There is no sense in adding additional licenses on top of it: the original authors released the code under public domain, and if people can't use software released as "public domain", they automatically can't use this project anyway (because I don't own copyrights to the original software, and this project is a derivative work). No amount of Unlicenses/CC0/MIT/whatever will solve this problem — even though I could publish my part of work under any license I want, my work is still the derivative of the original — and my license will only hide the problem from the legal point of view, making people and automatic tools happy until their legal department digs deeper. (Maybe I should just actually do this? For example Go "hides" some public domain code under their BSD license).

I cannot put "Public domain" into the "license" field in package.json because NPM won't let me do this — they only support SPDX licenses there, and these people refuse to add public domain — see #107 (comment). The only valid value for this case is "SEE LICENSE in <filename>", otherwise it shows a warning.

This is why I added clear public domain dedication to COPYING.txt file and put "SEE LICENSE IN COPYING.txt". I called the file COPYING.txt file instead of LICENSE.* because public domain is not a license — it's a public domain dedication, and by having it in "LICENSE" file will most likely confuse people/lawyers, because it will look like instead of dedicating copyrights, I still claim them by licensing the work. COPYING.txt for this case is a nice and accepted name — e.g. GPL licenses are usually put into COPYING files. Maybe I'm wrong here, so I'm happy to take expert opinions. Question: will these automatic tools recognize Unlicense by text even if I put it in COPYING.txt?

I don't know what to do with automated tools, and I'm sorry that they are flagging this package — maybe we can work some standard on how to mark "public domain" works so that such tools display it correctly. Still, flagging is probably the right thing to do, as "public domain" is not a universally accepted concept, and probably requires an intervention from a legal department in big companies.

Please understand that I'm not trying to be difficult, I'm just trying to do the right thing, legally. Have the original authors published their code under a different license, even CC0, I'd use it. But the only statement they published is "TweetNaCl is a self-contained public-domain C library, so it can easily be integrated into applications." For my part, I added "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission" wording, but obviously I can only apply it to the work of this project, not the original. Unlicense wording looks quite similar, so maybe that's what I should use.

If a copyright lawyer (familiar with international laws since the authors are located all over the world) has a better advice, I'd be happy to follow it. (I'm trying to find one, who's willing to give a free consultation).

PS Many folks sent pull requests with license changes, but this doesn't just magically work, legally! You'll have get all the authors of this library to agree to relicense their code. (I think your PR is actually okay, because it basically says the same thing as COPYING.txt, so this PS doesn't apply to it)

@CharlieHess does your tool recognize a LICENSE file without .md extension?

@dchest yeah it recognizes LICENSE, but doesn't recognize COPYING. While IANAL and I agree with you that software copyright is a cesspool I'd rather not wade into, I don't see any harm in adding an additional file that notes Public Domain. I don't (that is, the automated tool we are using) doesn't require a license field in package.json.

Thanks! I think I'll have a solution soon (I'm in contact with a person who's helping with legal stuff.)

Closing in favor of #111, which I'll let sit for a few days (maybe someone has feedback) and will merge. Thanks, @CharlieHess!