As per https://github.com/vurtun/nuklear/issues/285#issuecomment-260904217 there is an issue with forcing the user of xxHash to and I quote "reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution". This puts a burden on developers and in case of such a tiny code base does not seem to be that necessary.
Would you @Cyan4973 mind changing the BSD license to MIT, which requires referencing only in the source code?
Cc @darkuranium as per https://github.com/Cyan4973/xxHash/issues/49#issuecomment-242514392 .
@dumblob: This wouldn't achieve what you want. BSD and MIT licenses are legally pretty much equivalent — _both_ require attribution in binary form (emphasis mine):
The above copyright notice and this permission notice shall be included in _all_ copies or substantial portions of the Software.
What you're looking for is the Boost license (needs attribution in sources, but not binaries), or something like CC0/Unlicense (public domain-like). There is also the zlib license, but that one is legally ambiguous due to its wording.
I would like to clarify:
I thus propose that the library is relicensed from BSD to Boost, or from BSD to public domain (pref. via CC0 or Unlicense or the likes, for internationalization).
There is nothing gained (from a legal standpoint) by relicensing from BSD to MIT.
Of course, @Cyan4973 — you're the author here, and thus the final decision is yours. Though if you opt _not_ to relicense, I'd ask that you at least document it, so that I can finish my (re)implementation of LZ4 (as per #49).
Thank you @darkuranium for your comments. I'm coming from the Fedora waters and we somehow instinctively used MIT only for source distribution, but as devs did not care much about it in case of binaries as it was enough to add a copy of the license file to the binary package. Even such huge project as LLVM uses MIT as an additional license solely because they don't want users to have any redistribution constraints as in BSD.
On the other hand, to some people is MIT not clear in what everything the "Software" includes in case of compiled outputs (not necessarily object files, but e.g. distribution in intermediate languages, DSLs, bytecode, generated documentation from markup languages, etc.). In the very specific case of compiled pure C code to object files (i.e. CPU instructions) the Boost Software License makes sense with it's definition "machine-executable object code generated by a source language processor". But because of this very specific definition, Boost Software License can't be used for interpreted languages nor for generated documentation, nor any projects mixing DSL languages with C/C++, etc. in case one does want to redistribute the license statement only with sources.
To wrap up, for xxHash I would recommend Unlicense in case @Cyan4973 comes from a country not recognizing SW patents and CC0 otherwise (as CC0 explicitly covers patents as not being touched/influenced by the license).
Cc @cbuschardt to read the LLVM statement.
@dumblob I agree with respect to the MIT being an improvement over BSD. I remember Chris Lattner discussing MIT licensing for LLVM when I became involved in the project circa 2002. Part of the motivation was likely GPL compatibility [as he was pushing for its use in GCC], but the attribution was also cause for discussion. The fact is, the looser wording in MIT does matter to companies.
That said Unlicense and CC0 would be great choices, and would be preferred over MIT.
Tiny code, but this is a very important software.
Even if it is one line of code, he should get credit for that.
I don't see how a change of license would help anything.
MIT and BSD licenses are widely regarded as compatible and fully equivalent.
Apparently, this section seems to cause some worries :
"Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution."
but MIT has an equivalent clause :
"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
and so does BOOST :
The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software
In the case of xxHash project, the text of the license is provided both as a stand-alone file, for clarity, and is also already included in the source files headers, so there is no need to repeat it.
BSD-2 is a highly permissive license, it can't get any better and simpler.
For more details :
https://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29
https://tldrlegal.com/license/bsd-2-clause-license-(freebsd)
https://tldrlegal.com/license/mit-license
https://tldrlegal.com/license/boost-software-license-1.0-explained
Be cautious of less common options, which carry different risks, mostly due to their lack of experience, but hide them behind a curtain of goodwill.
CC0 text is _much_ larger, and consequently more complex to grasp the implications :
https://tldrlegal.com/license/creative-commons-cc0-1.0-universal#fulltext .
There is even an explicit provision which allows using CC0 to disseminate submarine patents.
It also has a _variable_ scope which depends on the country where it's applied.
Public domain is forbidden in some regions of the world.
In most cases, author must be named, and is not protected from direct and indirect liabilities. Say, a plane crashes for example, scapegoating becomes a possibility ...
So let's be clear, license shuffling is a game for lawyers.
When not, select the biggest, proven, supported and battle-hardened fishes in the pond.
Needless to say, no license change is planned at this stage.
@Cyan4973, you're right but one thing:
Public domain is forbidden in some regions of the world.
In most cases, author must be named, and is not protected from direct and indirect liabilities. Say, a plane crashes for example, scapegoating becomes a possibility ...
You omitted the "as close to public domain as the local legislation allows" licenses headed by Unlicense which actually
Btw, I'm in personal contact with several laywers participating in the development of Creative Commons licenses portfolio (which is deliberately cooperatively developed world-wide to satisfy needs of all existing legislations) and even if they always prefer CC BY 4.0 over CC0 because CC BY 4.0 retains copyright and is explicit in all the tiny shadow corners of different legislations, they admit, that licenses promoting the "as close to public domain as the local legislation allows" principle (headed by Unlicense) might work as well, but will be more work for layers and court in case of an incident.
So, if you are a very careful person as you seem to be, the safest and smartest solution is CC BY 4.0 (or a newer version in case it will exist). If you're a person, who believes in lawyers being nice people, Unlicense is the best choice (in legislations, where public domain does not exist or is shady, the distributor is encouraged to relicense the work under any conditions as Unlicense allows it - this is by the way how it's done with a lot of SW in Fedora by Red Hat where public domain SW is relicensed to MIT). If you want your name everywhere at all cost, stay with MIT/BSD.
So, if you are a very careful person as you seem to be, the safest and smartest solution is CC BY 4.0 (or a newer version in case it will exist).
One, that license is not meant for software. Two, it's not GPL-compatible (in fact, it's not _anything_-compatible). Three, I refuse to use CC-BY stuff ever since they _explicitly and knowingly_ hid the DRM clause from the users of said license. Now, I'm as much against DRM as the next man, but I will _not_ support shady practices of hiding clauses from the very authors who would use such a license. They've fixed that problem since (in that they no longer try to hide the fact that it has that clause — though it still exists), but the damage has been done.
When I learned that hiding that clause from users was a conscious decision was when I lost pretty much all respect for CreativeCommons. Combat DRM through information or persuasion if you want — but do _NOT_ even _think_ about ever attempting what CC did, by putting clauses in licenses and then going out of your way to hide them. I'll still use CC-0 because I think it's a good license, but I avoid the rest.
In case you think the DRM clause is not a problem, some lawyers believe that due to its wording even *.apk files might be considered DRM (since it's not obvious they're ZIP files). Hell, even *.zip files themselves might, nevermind more closed formats such as RAR or embedding the images as resources. I guess I could _kind of_ understand that clause in a -SA license or similar, but for the "base" CC-BY? Absurd.
Sorry for that rant, but I feel very strongly on that issue, esp. since many authors are _still_ unaware of the clause.
@Cyan4973 is mostly correct, by the way. MIT and BSD are generally considered to be completely equivalent (even the 3-clause BSD, because the "no endorsement" clause of that one is typically implicit in law). Just because $PROJECT considers MIT to be a source-attribution-only license does not make it so.
Boost is not equivalent, however — that one only requires attribution _in sources_.
@Cyan4973: Unfortunately, there _is_ a need to repeat the BSD and MIT licenses. You see, when it comes to binary distributions, people can't see the source text, which means you need to distribute its LICENSE file _somehow_. That's a problem for embedded. Hell, read the text of the BSD license (the same holds for MIT, though it's more implicit): it _explicitly_ states it must be provided in documentation or similar. It's also why I'm waiting for a documentation of xxHash, to be able to finish my LZ4 implementation (as per https://github.com/Cyan4973/xxHash/issues/49#issuecomment-242514392).
Again, you're the author, so it's up to you on whether you want to permit lack of attribution for binaries. If you want that attribution, I respect that, though if you do, please say so, so that we can stop discussing this issue (and please document xxHash!).
You see, when it comes to binary distributions, people can't see the source text, which means you need to distribute its LICENSE file somehow.
That's correct, though when sources are not provided, the text must merely be accessible _"in the documentation and/or other materials provided with the distribution"_ . So it's generally present at the end of some documentation, typically in an "Open Source section". I suspect that even a (working) hyperlink would qualify as _"other materials provided with the distribution"_ .
If you want that attribution, I respect that, though if you do, please say so,
It's not "attribution" in the sense "I want to be famous",
rather I want to follow the safeguards present in the license, with a very clear liability disclaimer, which is its main point. I don't feel entitled to create an exception.
As another note on licenses, please keep in mind that some if not most of these licenses have not yet been tested in court. That is, there are many "properties" they advertise which are effectively wishful statements, which _might_ be defeated in some future court action.
The reason to stick with a famous and widely used license is that in case something fishy happen, all projects using the same license would be impacted, compelling them to act. When many companies are involved, it means a significant number of lawyers and resources will be involved. This fact alone acts as a deterrence to anyone willing to play fishy things with the yet untested limits of these licenses.
In my case, BSD is also the license selected by my company, which means that all its open-source projects would be impacted. If anything happen, I can count on direct support from a team of expert lawyers in the field. That's also a strong argument to stand with the license.
and please document xxHash!
Yes, I wanted to refresh lz4 first, which is happening right now.
xxHash will follow.
Most helpful comment
I don't see how a change of license would help anything.
MIT and BSD licenses are widely regarded as compatible and fully equivalent.
Apparently, this section seems to cause some worries :
but MIT has an equivalent clause :
and so does BOOST :
In the case of xxHash project, the text of the license is provided both as a stand-alone file, for clarity, and is also already included in the source files headers, so there is no need to repeat it.
BSD-2 is a highly permissive license, it can't get any better and simpler.
For more details :
https://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29
https://tldrlegal.com/license/bsd-2-clause-license-(freebsd)
https://tldrlegal.com/license/mit-license
https://tldrlegal.com/license/boost-software-license-1.0-explained
Be cautious of less common options, which carry different risks, mostly due to their lack of experience, but hide them behind a curtain of goodwill.
CC0 text is _much_ larger, and consequently more complex to grasp the implications :
https://tldrlegal.com/license/creative-commons-cc0-1.0-universal#fulltext .
There is even an explicit provision which allows using CC0 to disseminate submarine patents.
It also has a _variable_ scope which depends on the country where it's applied.
Public domain is forbidden in some regions of the world.
In most cases, author must be named, and is not protected from direct and indirect liabilities. Say, a plane crashes for example, scapegoating becomes a possibility ...
So let's be clear, license shuffling is a game for lawyers.
When not, select the biggest, proven, supported and battle-hardened fishes in the pond.
Needless to say, no license change is planned at this stage.