Hel is distributed under the GPLv3. The license of the interpreter does not impose any restriction on the licenses of the programs it runs, so there is no requirement for Hel programs to be GPL'd too. However, Hel will (I hope) soon get libraries, and the licenses of the libraries may affect the licenses of the programs importing them. So I have to decide: which license to use for the Hel standard libraries?
The obvious choice would be the LGPL (the GNU Lesser General Public License), a license meant for libraries to allow linking to proprietary programs. I don't think I have ever released anything under the LGPL before. While I have a pretty good idea of what the GPL means, the LGPL was not so clear to me, especially about what it means for statically vs. dynamically linked libraries, and how this distinction applies to languages other than C/C++. This post is my attempt to understand it.
The other option I have thought about is the MPL (Mozilla Public License). However, I think the MPL's copyleft may be way too weak for my tastes. I intend to write about it in the future.
[Disclaimer: I am not a lawyer, this is not legal advice, etc.]
Most licenses are written in a hard-to-read legalese. I find the GPLv3 and LGPLv3 particularly hard to read; this is partly because the FSF has tried to make definitions more precise and to avoid terminology which could be interpreted in different ways in different countries.
By contrast, the GPLv2 and LGPLv2 are some of the most "written by/for humans" licenses around; they are truly a pleasure to read, so much so that, were it not for some important guarantees added in GPLv3, I would be tempted to keep using the GPLv2 for my software.
These important guarantees include:
An anti-anti-circumvention clause: Most countries nowadays have legislation criminalizing the circumvention of DRM mechanisms (such as copy protection in some e-book readers, music players, streaming clients, and so on). Section 3 of the GPLv3 basically states that no work under the GPLv3 is to be considered part of a DRM mechanism for the purposes of such legislation, i.e., if GPLv3 code is used to implement DRM, it is not illegal to circumvent the DRM.
(Curiously, Brazil does not seem to be a signatory of the WIPO Copyright Treaty, but Art. 107 of Law 9.610/1998 imposes similar restrictions on DRM circumvention.)
An anti-tivoization clause: Tivoization is the use of hardware protections to forbid modification of the software running in a system, despite the software being free (for example, a cell phone which runs free software, but which you can't modify without having keys provided by the phone vendor; or, say, a processor running an entire built-in operating system with special privileges which you cannot change or disable). Section 6 of the GPLv3 has provisions which state that if the software is distributed in object code form with a user product (e.g., a phone), any installation information (authorization keys, procedures, etc.) required to install a modified version of the software in the product must also be provided.
Patent protections: The GPLv3 has provisions to preclude discriminatory patent deals, such as the infamous one celebrated by Microsoft and Novell in 2006, in which Microsoft essentially charged Novell for the right to distribute GNU/Linux without being sued for infringing Microsoft patents, which Microsoft claimed to have over the Linux kernel. Section 11 of the GPLv3 precludes such deals.
For all of these reasons, I prefer to use the (L)GPL version 3 nowadays. End of digression.
The LGPLv3 is defined by inclusion of the terms of the GPLv3 plus a number of overrides. For this reason, it is relatively short compared to the GPLv3. I will try to summarize each section as I understand it below.
Section 0 defines a bunch of terms. "The Library" refers to the work released under the LGPLv3. An "Application" is an application which uses interfaces provided by the Library, but the application is not derived from the Library itself. A "Combined Work" is the work produced by the combining or linking the Application with the Library. (Some more terms are defined, but we'll see them later.)
Section 1 allows distributing the library without being bound by Section 3 of the GPL. That's the anti-anti-circumvention clause, and I find it somewhat surprising to see it waived here, but there it is.
Section 2 states that if you modify the library in such a way that it depends on data or functions provided by the application (other than as arguments passed to the library), you must either make sure the library still works in the absence of such data/functions, or release the modified version under the GPL (without the extra permissions granted by the LGPL).
The idea here is to preclude a legal trick. Someone might want to extend the library with proprietary code, and escape LGPL's copyleft by leaving the proprietary code as part of the application, and then making the library call the application's proprietary extensions. Section 2 requires that either the external application code is inessential for the library's operation, or else that the library be distributed under the GPL (and thus the application would also have to be distributed under a GPL-compatible license to be usable with the library).
Section 3 states that if your compiled program incorporates significant portions of header files from the library, it has to carry a notice saying it uses the library and that the library covered by the LGPL, and the program must be acompanied with a copy of the text of the GPL and LGPL.
One problem here is that "header file" is not defined in the license. It works for C/C++, but how it applies to other languages is debatable. Does calling a
syntax-rulesmacro from the library trigger this clause?
Section 4 covers the distribution of a combined work consisting of the application plus the library. Besides the usual requirements to carry a notice and accompany the work with copies of the licenses, it also requires that you either (1) use a shared library mechanism to link with the library, so that the user can use modified versions of the library with the program; or (2) distribute the source code for the library and the source or object code for the application in such a way that the user can recombine a modified version of the library with the application object code.
The goal here is to ensure that the user still has all the freedoms to change the library (which is free), even if the application is proprietary. That's great in principle, but again it raises the question of what this means for macro expansion (which happens at compile time); there is no 'uncombined' object code when the application invokes macros from the library.
It also complicates static linking as a form of deployment; you still can do it (macros notwithstanding), but the packaging tool must also generate an uncombined application object code to be distributed with the fully statically-linked version.
Section 5 deals with combining multiple libraries (with similar requirements to provide an uncombined version too).
Section 6 deals with future versions of the LGPL, allowing the author to choose to release the code under LGPL "version 3 or later", and also allowing the author to specify a proxy who can decide whether later versions apply.
The difficulties of applying the LPGL to Lisp-like languages have been recognized before. Franz Inc. created a Lisp Lesser General Public License, which adds a preamble to LGPL (v2.1, not v3) overriding some definitions of the LGPL to terms more appropriate to Common Lisp, and instructing that static linking is to be treated as a "work that uses the Library", not a "derivative of the Library" (i.e., an Application and not a Combined Work, in LGPLv3's terms), effectively treating static linking the same way as dynamic linking.
Interestingly, the LLGPL is not a simple weakening of LGPL's copyleft: it also states, for example, that redefinitions of functions of the library (something you can do in Common Lisp) do constitute modification of the library itself, and therefore the new definitions are subject to copyleft.
The LLGPL uses definitions that are appropriate to Common Lisp, but a similar set of definitions and exceptions could be crafted for Hel (although I would prefer to avoid language-specific terminology as much as possible).
In a future post, I intend to have a look at the Mozilla Public License and evaluate if it may be a good idea for Hel libraries.
Copyright © 2010-2024 Vítor De Araújo
O conteúdo deste blog, a menos que de outra forma especificado, pode ser utilizado segundo os termos da licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.
Powered by Blognir.