From 2f17f1a93b9ee14f6f096f0b10070233b73417e0 Mon Sep 17 00:00:00 2001 From: Sean Barrett Date: Tue, 14 Apr 2015 01:58:25 -0700 Subject: [PATCH 1/6] Update why_public_domain.md --- docs/why_public_domain.md | 72 +++++++++++++++++++-------------------- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/docs/why_public_domain.md b/docs/why_public_domain.md index 141e4b6..5b6df6f 100644 --- a/docs/why_public_domain.md +++ b/docs/why_public_domain.md @@ -3,47 +3,47 @@ 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. + 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. + 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. + 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. + 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". \ No newline at end of file + 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! From 31461003c7d89fa6a814d5d741477719c84a5fa7 Mon Sep 17 00:00:00 2001 From: Sean Barrett Date: Tue, 14 Apr 2015 02:00:59 -0700 Subject: [PATCH 2/6] Update why_public_domain.md --- docs/why_public_domain.md | 65 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/docs/why_public_domain.md b/docs/why_public_domain.md index 5b6df6f..902e766 100644 --- a/docs/why_public_domain.md +++ b/docs/why_public_domain.md @@ -47,3 +47,68 @@ in the public domain: 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. 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 used to have +a page with a list of all of these on their web site, +and it was insane, and obviously nobody ever looked +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 in the public domain. Where that dedication is not +// recognized, you are granted a perpetual, irrevocable license to copy +// and modify 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. :( From d44e52d3638b8dd3eaaa7958c5352976f4ffaa12 Mon Sep 17 00:00:00 2001 From: Sean Barrett Date: Tue, 14 Apr 2015 02:03:22 -0700 Subject: [PATCH 3/6] Update why_public_domain.md --- docs/why_public_domain.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/why_public_domain.md b/docs/why_public_domain.md index 902e766..661ba1f 100644 --- a/docs/why_public_domain.md +++ b/docs/why_public_domain.md @@ -50,16 +50,18 @@ in the public domain: 4. discussion from stb_howto.txt on what YOU should do for YOUR libs -EASY-TO-COMPLY LICENSE +```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) + 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 @@ -112,3 +114,4 @@ 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. :( +``` From 8fece213ee9a00f6037852a0fd50e4fcb02897f0 Mon Sep 17 00:00:00 2001 From: Sean Barrett Date: Tue, 14 Apr 2015 02:04:44 -0700 Subject: [PATCH 4/6] Update why_public_domain.md --- docs/why_public_domain.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/why_public_domain.md b/docs/why_public_domain.md index 661ba1f..9c7c77b 100644 --- a/docs/why_public_domain.md +++ b/docs/why_public_domain.md @@ -50,7 +50,8 @@ in the public domain: 4. discussion from stb_howto.txt on what YOU should do for YOUR libs -```EASY-TO-COMPLY LICENSE +``` +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 From 0a3b6adb32ad1f65aa8fb3cea7f3acb474d9b6e6 Mon Sep 17 00:00:00 2001 From: Sean Barrett Date: Tue, 14 Apr 2015 02:05:18 -0700 Subject: [PATCH 5/6] Update why_public_domain.md --- docs/why_public_domain.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/why_public_domain.md b/docs/why_public_domain.md index 9c7c77b..2962e7d 100644 --- a/docs/why_public_domain.md +++ b/docs/why_public_domain.md @@ -59,9 +59,7 @@ 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 From 8f4958e1f0e85cd6274cb37f2789f039d2512c9b Mon Sep 17 00:00:00 2001 From: Sean Barrett Date: Tue, 14 Apr 2015 02:05:54 -0700 Subject: [PATCH 6/6] Update why_public_domain.md --- docs/why_public_domain.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/why_public_domain.md b/docs/why_public_domain.md index 2962e7d..8636921 100644 --- a/docs/why_public_domain.md +++ b/docs/why_public_domain.md @@ -48,7 +48,7 @@ in the public domain: you have problems it's not my fault, but also please report bugs so I can fix them"--so dumb! -4. discussion from stb_howto.txt on what YOU should do for YOUR libs +4. full discussion from stb_howto.txt on what YOU should do for YOUR libs ``` EASY-TO-COMPLY LICENSE