Re: [libreplanet-discuss] Potential of the Sleepycat License

[Michael Pagan]

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

> 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.

> 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:

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

> However, if we can find people with the knowledge to write/modify
> licenses ('cause I for sure will not be able to do that) then I think
> that this license could be modified to fix those two problems (for
> example, instead of requiring that code be disclosed, all 4 freedoms
> could be required).

The 4 essential freedoms are already required by the Sleepycat license,
and this fact is what makes the Sleepycat license a free software
license.  I would agree with you that the license itself should make it
more clear to its users what their freedoms actually are point-by-point,
instead of just laying out such details inside of a single sentence.

Many people, however, like lax and permissive licenses like these,
because they are more concise than the GPL, even though they are not as
profound and as ethical as the GPL is.

If a developer wants to release a program under a license that provides
the 4 essential freedoms for all versions of a program AND that
specifies in-depth which freedoms they actually have, then why not just
use the GPL?

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?

> I am not an expert in licensing, which is why I brought this up here.
> Hopefully someone here has the ability, time, and will to do this (if it
> is possible). (^_^)
>
> [0] https://en.wikipedia.org/wiki/Sleepycat_license

If someone does decide to do it, then what would such a modified license
bring to the table that is not already provided by existing free
software licenses?  What would be the advantage?

There exists [a list of free software licenses][4] that anyone can use
for their programs or libraries.  Are none of these licenses suitable
for what you or someone else is trying to accomplish?

[4]: http://www.gnu.org/licenses/license-list.html

Please note that _I am not a licensing expert_, either, so your opinions
are just as valid as mine are.  I am interested in free software
licenses, but I'm curious as to why there is a need for another.


I welcome your feedback
-- 
Michael Pagan (pegzmasta) [71B46D72]
B942 AD12 82B1 6D14 27A0  86AE 119E 451E 71B4 6D72
Free Software Hacker, <https://savannah.nongnu.org/users/pegzmasta>

_Please consider the following before replying to me_:
Avoid *proprietary* attachments; see 
<https://www.gnu.org/philosophy/no-word-attachments.html>.
Consider using Email encryption; try <https://emailselfdefense.fsf.org/>.
Support software freedom today; join <https://my.fsf.org/join?referrer=835840>.

signature.asc
Description: PGP signature