Towards a permissive copyleft license for dynamic languages

Tagged:  •    •    •    •    •  

The problem

With the recent increase in free-software releases for dynamic languages, a serious issue is there for people who would prefer to give their software the protection of copyleft. The issue is the difficulty of interpreting the Lesser GPL in the context of these languages.

The difficulties in turn from two different sources. First, it is hard to interpret the language of the Lesser GPL in the context of languages that have no object files but only source code files.

Second, some languages do not have a way to combine code in a way that resembles C's dynamic linking. Smalltalk code is usually deployed in a self-contained image file; Perl and Python code is also often deployed in a single executable under Windows; tools such as HipHop boost performance of dynamic languages by also combining their source code in a single executable file. It is then harder to comply with the requirements of the Lesser GPL, since only the static linking option applies.

[An aside: some of these problems are also there for C++ code that heavily uses templates.]

This has led to an increase in the use of non-copyleft licenses for dynamic languages. But wait, there is an interesting twist: proponents of non-copyleft licenses say that it is "morally wrong" for GPL projects to adopt non-copyleft code, because improvements cannot then be contributed back.

First of all, this is wrong—the copyright holders can always choose to relicense their code, and even contributors to FSF projects such as GNU Smalltalk retain this right when they assign copyright to the FSF. Second, it looks like people are avoiding copyleft but actually wished they had some similar kind of protection. This brings us back to the original problem; the solution then is, in my opinion, to develop a copyleft license that avoids the problem of the LGPL.

The solution

The GPLv3 includes a system of granting Additional Permissions. This system has been used so far by GCC and Autoconf.

It should not be hard to develop a set of additional permissions that do not extend beyond a reasonable concept of "using" (as opposed to "extending") library code. We can do this with a technical mindset, to avoid a proliferation of IANAL responses. I'm myself interested in using this for GNU Smalltalk, so I should be able to run this by Richard Stallman as well as (more importantly) the FSF licensing experts.

Here's a start. In the following text, the "work" is something licensed under this GPL+exception.

  1. An "extension" of the work is part of a derivative of the work that includes the following:
    a) subclasses of classes defined by the work;
    b) code that augments classes defined by the work or that redefines entry points provided by the work;
    c) source code, data files or other ancillary content that are required for proper operation of other parts of the extension.
  2. A "modification" of the work is a subset of an extension that includes redefinitions of entry points defined by the work, and ancillary content (as defined in item 1c) that is required by these redefinitions.
  3. Parts of a derivative of the work, that do not constitute a "modification" of it, do not need to be licensed under the GPL.

So what?

The above text is just a start. Please answer with possible loopholes, as well as cases in which you think this proposal is too restrictive.

If there is sufficient response to this blog post, I'll create another post to summarize the main points, and take the project on to the FSF lawyers.

User login