118 lines
5.0 KiB
Markdown
118 lines
5.0 KiB
Markdown
My collected rationales for placing these libraries
|
|
in the public domain:
|
|
|
|
1. Public domain vs. viral licenses
|
|
|
|
Why is this library public domain?
|
|
Because more people will use it. Because it's not viral, people are
|
|
not obligated to give back, so you could argue that it hurts the
|
|
development of it, and then because it doesn't develop as well it's
|
|
not as good, and then because it's not as good, in the long run
|
|
maybe fewer people will use it. I have total respect for that
|
|
opinion, but I just don't believe it myself for most software.
|
|
|
|
2. Public domain vs. attribution-required licenses
|
|
|
|
The primary difference between public domain and, say, a Creative Commons
|
|
commercial / non-share-alike / attribution license is solely the
|
|
requirement for attribution. (Similarly the BSD license and such.)
|
|
While I would *appreciate* acknowledgement and attribution, I believe
|
|
that it is foolish to place a legal encumberment (i.e. a license) on
|
|
the software *solely* to get attribution.
|
|
|
|
In other words, I'm arguing that PD is superior to the BSD license and
|
|
the Creative Commons 'Attribution' license. If the license offers
|
|
anything besides attribution -- as does, e.g., CC NonCommercial-ShareAlike,
|
|
or the GPL -- that's a separate discussion.
|
|
|
|
3. Other aspects of BSD-style licenses besides attribution
|
|
|
|
Permissive licenses like zlib and BSD license are perfectly reasonable
|
|
in their requirements, but they are very wordy and
|
|
have only two benefits over public domain: legally-mandated
|
|
attribution and liability-control. I do not believe these
|
|
are worth the excessive verbosity and user-unfriendliness
|
|
these licenses induce, especially in the single-file
|
|
case where those licenses tend to be at the top of
|
|
the file, the first thing you see.
|
|
|
|
To the specific points, I have had no trouble receiving
|
|
attribution for my libraries; liability in the face of
|
|
no explicit disclaimer of liability is an open question,
|
|
but one I have a lot of difficulty imagining there being
|
|
any actual doubt about in court. Sometimes I explicitly
|
|
note in my libraries that I make no guarantees about them
|
|
being fit for purpose, but it's pretty absurd to do this;
|
|
as a whole, it comes across as "here is a library to decode
|
|
vorbis audio files, but it may not actually work and if
|
|
you have problems it's not my fault, but also please
|
|
report bugs so I can fix them"--so dumb!
|
|
|
|
4. full discussion from stb_howto.txt on what YOU should do for YOUR libs
|
|
|
|
```
|
|
EASY-TO-COMPLY LICENSE
|
|
|
|
I make my libraries public domain. You don't have to.
|
|
But my goal in releasing stb-style libraries is to
|
|
reduce friction for potential users as much as
|
|
possible. That means:
|
|
|
|
a. easy to build (what this file is mostly about)
|
|
b. easy to invoke (which requires good API design)
|
|
c. easy to deploy (which is about licensing)
|
|
|
|
I choose to place all my libraries in the public
|
|
domain, abjuring copyright, rather than license
|
|
the libraries. This has some benefits and some
|
|
drawbacks.
|
|
|
|
Any license which is "viral" to modifications
|
|
causes worries for lawyers, even if their programmers
|
|
aren't modifying it.
|
|
|
|
Any license which requires crediting in documentation
|
|
adds friction which can add up. Valve has a huge list
|
|
(http://nothings.org/remote/ThirdPartyLegalNotices_steam_2019.html)
|
|
of all of these included in each game they ship,
|
|
and it's insane, and obviously nobody ever looks
|
|
at it so why would you care whether your credit
|
|
appeared there?
|
|
|
|
Permissive licenses like zlib and BSD license are
|
|
perfectly reasonable, but they are very wordy and
|
|
have only two benefits over public domain: legally-mandated
|
|
attribution and liability-control. I do not believe these
|
|
are worth the excessive verbosity and user-unfriendliness
|
|
these licenses induce, especially in the single-file
|
|
case where those licenses tend to be at the top of
|
|
the file, the first thing you see. (To the specific
|
|
points, I have had no trouble receiving attribution
|
|
for my libraries; liability in the face of no explicit
|
|
disclaimer of liability is an open question.)
|
|
|
|
However, public domain has frictions of its own, because
|
|
public domain declarations aren't necessary recognized
|
|
in the USA and some other locations. For that reason,
|
|
I recommend a declaration along these lines:
|
|
|
|
// This software is dual-licensed to the public domain and under the following
|
|
// license: you are granted a perpetual, irrevocable license to copy, modify,
|
|
// publish, and distribute this file as you see fit.
|
|
|
|
I typically place this declaration at the end of the initial
|
|
comment block of the file and just say 'public domain'
|
|
at the top.
|
|
|
|
I have had people say they couldn't use one of my
|
|
libraries because it was only "public domain" and didn't
|
|
have the additional fallback clause, who asked if
|
|
I could dual-license it under a traditional license.
|
|
|
|
My answer: they can create a derivative work by
|
|
modifying one character, and then license that however
|
|
they like. (Indeed, *adding* the zlib or BSD license
|
|
would be such a modification!) Unfortunately, their
|
|
lawyers reportedly didn't like that answer. :(
|
|
```
|