[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libreplanet-discuss] Potential of the Sleepycat License
From: |
Nicolás A . Ortega |
Subject: |
Re: [libreplanet-discuss] Potential of the Sleepycat License |
Date: |
Mon, 17 Apr 2017 14:22:21 +0200 |
User-agent: |
Mutt |
On Sun, Apr 16, 2017 at 11:32:58PM -0400, Michael Pagan wrote:
> Nicolás A. Ortega <deathsbreed@themusicinnoise.net> writes:
>
> > I've tried having this discussion on #fsf and #gnu, and I think that
> > this license has the potential to be a great software license,
> > especially for libraries.
>
> How so? And why /especially/ for libraries?
>
> As a matter of strategy: A lax, permissive, non-copyleft (weak) free
> software license should only be used for a library if that library does
> not provide any advantages-- besides software freedom-- over using a
> proprietary (non-free) one.
>
> In essence, a "weak" license is most commonly used for a free software
> library, if that library already provides the same features which can be
> found in a non-free library; however, if a free library provides a
> unique feature, which is truly relevant for programmers AND which can
> not be found in a non-free library, then it makes sense to apply a
> copyleft license onto the library.
>
> The unique feature could attract new programmers to the library, and
> "copylefting" the library could ensure that this feature won't make it's
> way to a non-free library. Since said feature won't make it to non-free
> libraries, this creates another incentive for companies to contribute to
> the free library instead of the non-free one, since it is technically
> more advanced in this way and more supported via a free community.
>
> This is the direct strategy employed by the GNU Project. I believe RMS
> got it right when he decided that the license that should be chosen for
> a library should be based on whether it provides an advantage or not for
> the free software community. If the library does not provide an
> advantage (i.e. the library shares the same features as non-free
> libraries), then a "weak" license should be used; if the library *does*
> provide an advantage (i.e. pioneering a new significant feature), then a
> copyleft license should be used.
>
> Learn more about this strategy here:
> http://www.gnu.org/licenses/why-not-lgpl.html
>
The issue with this kind of method is that many people are put off by
the idea of using a GPLed library (mostly because that brings up a ton
of other legal concerns about the other libraries that you may be
using), so it makes things extremely messy. LGPL keeps the library code
Free, but does not ensure (legally) that the library is only used by
Free Software.
> > To my understanding the Sleepycat License[0] is a copyleft license in
> > which all derivatives of the work must be licensed likewise (under the
> > Sleepycat license) and works that use a project under this license must
> > disclose source code.
>
> I read the [Sleepycat license][0].
>
> [0]: http://directory.fsf.org/wiki/License:Sleepycat
>
> The author of the [Wikipedia article you cited][1] actually labeled the
> Sleepycat license incorrectly, to my surprise! The author was able to
> [cite a reference for what is copyleft][2], but must have been confused
> when he read the Sleepycat license-- assuming he/she even read it. The
> Wikipedia article in question needs to be revised. Any takers?
>
> [1]: https://en.wikipedia.org/wiki/Sleepycat_license
> [2]: https://en.wikipedia.org/wiki/Copyleft
>
> _The Sleepycat license is NOT a copyleft license_. I'll explain...
>
> In order for a license to be a copyleft license: The license must
> provide the user of the original work the 4 essential freedoms, and the
> license must make it clear that "derivatives" or "modified versions" of
> the work must be under the same license as the original work, too. The
> conditions for the Sleepycat license does not make any mention of
> "derivative works" or "modified versions"; instead, Sleepycat specifies
> that redistribution of the source code or binary must be under the same
> license.
>
> To be clear: A "redistribution" of a work is nothing more than an exact
> copy of a work. Sleepycats' conditions only affects exact copies of a
> program, not modified versions of a program. If it's an exact copy,
> then it hasn't been modified and Sleepycat is in effect; if it's been
> modified, then it's not an exact copy and Sleepycat is NOT in effect.
>
I see, I was unaware of this.
> > There are, however a couple problems with this license, the first one
> > (as you most likely have noticed while reading the above) is that
> > disclosure of source code does not mean free software, and secondly is
> > the issue that the license uses very specific terminology referring to
> > the BerkleyDB (the software that uses this license) and refers mostly to
> > DB software. Given, disclosure of source code is better (imo) than the
> > LGPL since it forces the disclosure of the sources (while LGPL only does
> > so in the case of static linking if there is no exception), and still
> > gives more freedom for the programmer to choose a license unlike one of
> > the GPL licenses (despite how much I love them).
>
> You've identified two supposed problems with the Sleepycat license:
>
> 1. Disclosure of source code does not mean free software
> 2. The Sleepycat license is too specific to BerkeleyDB
>
> For problem 1, I would say you are indeed correct. A program that only
> provides freedom #1 (disclosure of source code), which I assume is what
> you meant, is not enough to render a program as free, since freedoms #0,
> #2, and #3 are also required for having control of a program; however,
> although the Sleepycat license does not mention the "4 essential
> freedoms", it does provide them. Sleepycat does not restrict computer
> users that receive source code or binaries from exercising the 4
> essential freedoms, hence the license is a free software license.
>
> The clause that indicates that the Sleepycat license provides the 4
> essential freedoms, although in a vague fashion, is here:
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
>
What I was referring to with issue 1 is the requirements that Sleepycat
has for applications that use the Sleepycat licensed software. To my
knowledge (brief description on TL;DR Legal[0]) it only requires source
disclosure for such programs.
> For problem 2, there already exists a free software license similar to
> Sleepycat that contains the same 3-clause license structure: The
> [Modified BSD license][3]. This is what you are looking for if you want
> a more generic 3-clause license.
>
> [3]: http://directory.fsf.org/wiki/License:BSD_3Clause
>
Nope, goes a little further than that. To my understanding (however it
seems that I may have been wrong) Sleepycat is copyleft upon derivatives
and forces source disclosure on software that uses the Sleepycat
licensed software.
> There is such a thing as license proliferation. Creating another
> license that accomplishes the same mission as an already existing one is
> just a duplication of work (i.e. a waste of time), is it not?
>
Yup, answered this in a previous part of the thread.[0]
[0] https://lists.gnu.org/archive/html/libreplanet-discuss/2017-04/msg00019.html
--
Nicolás Ortega Froysa (Deathsbreed)
https://themusicinnoise.net/
http://uk7ewohr7xpjuaca.onion/
Public PGP Key:
https://themusicinnoise.net/deathsbreed@themusicinnoise.net_pub.asc
http://uk7ewohr7xpjuaca.onion/deathsbreed@themusicinnoise.net_pub.asc
signature.asc
Description: PGP signature
- Re: [libreplanet-discuss] Potential of the Sleepycat License, (continued)
- Re: [libreplanet-discuss] Potential of the Sleepycat License, Adonay Felipe Nogueira, 2017/04/17
- Re: [libreplanet-discuss] Potential of the Sleepycat License, Nicolás A . Ortega, 2017/04/18
- Re: [libreplanet-discuss] Potential of the Sleepycat License, Adonay Felipe Nogueira, 2017/04/21
- Re: [libreplanet-discuss] Potential of the Sleepycat License, Ineiev, 2017/04/22
- Re: [libreplanet-discuss] Potential of the Sleepycat License, Nicolás A . Ortega, 2017/04/22
Re: [libreplanet-discuss] Potential of the Sleepycat License, Michael Pagan, 2017/04/16
Re: [libreplanet-discuss] Potential of the Sleepycat License,
Nicolás A . Ortega <=