On Wed, Mar 23, 2016 at 3:53 PM, Rob Landley wrote: > On Wed, Mar 23, 2016 at 3:35 PM, Christopher Lane > wrote: > > On Tue, Mar 22, 2016 at 7:32 PM, Rich Felker wrote: > >> > >> On Mon, Mar 21, 2016 at 03:46:18PM -0700, Christopher Lane wrote: > >> > On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker wrote: > >> > > >> > > On Fri, Mar 18, 2016 at 07:47:21PM +0000, George Kulakowski wrote: > >> > Those paragraphs still reference public domain. We can't use the > things > >> > mentioned there. WRT the blowfish impl, there are other > implementations > >> > we > >> > can pull if we want / need that - though I'm not sure we even do want > >> > that. > >> > >> Did they miss the part about the fallback permissive license? I'm > >> pretty sure Solar's implementation of bcrypt (albeit the original, not > >> the one he modified for musl) is used in plenty of other places with > >> no problem. Complaining about copyright status on this is like > >> complaining about fdlibm. If it's really a problem I suspect he would > >> be willing to clarify its status for you. > > Upton Sinclair explained why lawyers aren't comfortable with the > public domain a century ago: > > http://www.goodreads.com/quotes/21810-it-is-difficult-to-get-a-man-to-understand-something > > As far as I can tell, to most lawyers a good license is one you can > sue to enforce, I.E. one which provides potential future litigation > employment opportunities for lawyers. This isn't necessarily a > conscious decision, but it's definitely part of the legal profession's > herd mentality. > From the license creation standpoint, AFAICT you're right. Google's on the receiving end of the musl license, so it seems a "good license" for us is one that provides clarity on what we can do with the code. So, the inverse, basically -- one that we _can't_ be sued over. A license that introduces ambiguity through conditionals that may be argued over is not one we can work with. > > So what I did was take a "safe" license and make a small specific > change to it, which is easy to analyze and hard to object to by > itself, so the result still looks "safe". Thus my license is a "good > license", even if the result is functionally equivalent to placing > code in the public domain. > > I.E. Zero Clause BSD (the Toybox license, which SPDX approved as > "0BSD" ala https://spdx.org/licenses/0BSD.html) took a prominent > variant of a widely approved existing license (the "OpenBSD suggested > template license, the text of which is in the first link from > http://www.openbsd.org/policy.html) under which you _can_ sue people > (in fact AT&T lost a very prominent lawsuit about it in 1993, > https://www.bell-labs.com/usr/dmr/www/bsdi/bsdisuit.html) and made a > single small edit that just removed half a sentence: > https://github.com/landley/toybox/commit/ee86b1d8e25c > > The result was a license which grants blanket permission while > requiring nothing in return, using existing and established legal > boilerplate. It had to be an acceptable license if BSD was an > acceptable license, unless you could coherently explain why the > deleted half-sentence caused a problem _other_ than no longer > providing future employment for lawyers. > > I replaced the "everybody dislikes this because everybody else > dislikes this" phrase "public domain" with the "everybody likes this > because everybody else likes this" phrase "BSD license". Instead of > fighting the herd mentality, I tried to leverage it. > 0BSD is awesome, so thanks for your contribution. It enables projects to release under something that's effectively public domain w/o scaring off the lawyers of big litigation target companies. > > So far, nobody's wanted to step into the spotlight and say > "eliminating this source of future litigation threatens my job > security", and I don't think most people consciously think that > anyway. (Besides, there's always patent trolls...) > > Rob >