13 lines
5.8 KiB
HTML
13 lines
5.8 KiB
HTML
|
<p>Recently I came across the <a href="https://en.wikipedia.org/wiki/Sleepycat_License" target="_blank" >Sleepycat License</a>, which I believed to be a copyleft Free Software license that only requires any projects using the Sleepycat licensed software to disclose source code (not necessarily forcing any particular license on the user). I thought that this would be a great license for a library, since unlike the (A)GPL it doesn't force the developer using my library to use the same license (many people who like permissive licenses prefer to be able to choose their own license for their project), but at the same time whoever uses my library must at least disclose their source code (freedom #1... kinda). So I thought that with some slight modifications (since the license is also extremely specific to the BerkleyDB software) that the Sleepycat License would be a great license for libraries (better than GPL or LGPL). So after <a href="https://lists.gnu.org/archive/html/libreplanet-discuss/2017-04/msg00012.html" target="_blank" >a very long discussion on the LibrePlanet-Discuss mailing list</a> I figured out that <a href="https://lists.gnu.org/archive/html/libreplanet-discuss/2017-04/msg00035.html" target="_blank" >the Sleepycat License wasn't exactly what I thought it was</a>.</p>
|
||
|
|
|
||
|
|
<p>However, during the mailing list someone mentioned something about <a href="https://en.wikipedia.org/wiki/License_proliferation" target="_blank" >license proliferation</a>, which got me thinking that perhaps instead of looking for some new obscure license maybe I could do this with existing licenses, using conditional dual-licensing. With this I thought of the <a href="https://www.gnu.org/licenses/why-not-lgpl" target="_blank" >GNU article on using (A)GPL instead of the LGPL for libraries</a>. The two licenses in question are the LGPL and the (A)GPL. The LGPL has the advantage that it does not force any particular license on the developer using the library and remains copyleft with regards to the library's source-code itself, but it has a flaw that is fixed by the (A)GPL, which is that the LGPL can be used by non-free projects as well as free projects, which to some of us is not something that settles well with our concious. However, the (A)GPL forces the project using the library to carry the (A)GPL as well. So, both of these had elements that I wanted, but they both had drawbacks. With this I finally thought of a dual-licensing scheme that could work to have the best of both licenses. It consists in <a href="https://lists.gnu.org/archive/html/libreplanet-discuss/2017-04/msg00019.html" target="_blank" >licensing your library with the (A)GPL and offering an LGPL dual-licensing (with static linkage) to any project licensed exclusively with FSF approved licenses</a>.</p>
|
||
|
|
|
||
|
|
<p>Given this kind of dual-licensing this means that it is impossible for a non-free licensed project to use your library, while at the same time allowing free projects to use whichever license they wish. If the software is non-free then it will be forced to be free, if it is free then they can use the library to their heart's desire without having to change their project's license and not having to worry about legal issues of whether they can use a (A)GPL library with other kinds of licenses.</p>
|
||
|
|
|
||
|
|
<p>The one inconvenience this licensing scheme has for those who like permissive licenses is that any derivative of their work will also have to be free if they want to make use of my library. Although this is true, one must consider that the derivative work can choose between a large selection of free licenses, and if they only wish to borrow parts of the code that are independent from my library then they are able to do so. That is, let's say that I create a C++ networking library and use this licensing scheme. Someone uses my library in their game and licenses the game with the MIT License. Another party can still create a non-free derivative of the game so long as they get rid of the networking modules and replace them with a different networking library (which should truly be a small part of the game as a whole). Therefore it is not completely unattractive to use such a library for a permissively licensed project so long as the code is not absolutely reliant on the library using this licensing scheme.</p>
|
||
|
|
|
||
|
|
<p>All that aside, you may have noticed that I say "(A)GPL" a lot when referring to the first license which this scheme would use. This is because either of these two licenses (the AGPL or the GPL) will work just fine for this matter and will have about the same affect. However, I would personally suggest using the AGPL instead because it <a href="2017-03-25-reasons-to-not-use-the-gpl.php" >sends a clearer message about the intentions</a>. Technically, if the license is only GPL then they can put their software on a server and have the user interact with it over the network (<a href="https://www.gnu.org/philosophy/who-does-that-server-really-serve.html" target="_blank" >SaaSS</a>) and they will not be forced to disclose the sources despite it being licensed with the GPL. By using the AGPL instead they can still do this technically (because of the dual-licensing) and even license the project under the MIT License, but it makes your intentions (if you do indeed think that server sources should also be shared) clearer to the user, although it will not truly have any legal effect. Therefore I would suggest using the AGPL despite this.</p>
|
||
|
|
|
||
|
|
<p>I believe that this licensing scheme solves the eternal problem in library licensing between copyleft and permissive licenses without compromising a good concious, more copyleft than permissive licenses (such as MIT), not as strict about how projects using the library license themselves (such as GPL), and no compromising on ethics by not helping in any manner a non-free project (such as LGPL).</p>
|
||
|
|
|