August 13, 2018

Licensing Edgecases

Filed under: digital,documentation,interfaces,linux,mozilla,work — mhoye @ 4:37 pm

While I’m not a lawyer – and I’m definitely not your lawyer – licensing questions are on my plate these days. As I’ve been digging into one, I’ve come across what looks like a strange edge case in GPL licensing compliance that I’ve been trying to understand. Unfortunately it looks like it’s one of those Affero-style, unforeseen edge cases that (as far as I can find…) nobody’s tested legally yet.

I spent some time trying to understand how the definition of “linking” applies in projects where, say, different parts of the codebase use disparate, potentially conflicting open source licenses, but all the code is interpreted. I’m relatively new to this area, but generally speaking outside of copying and pasting, “linking” appears to be the critical threshold for whether or not the obligations imposed by the GPL kick in and I don’t understand what that means for, say, Javascript or Python.

I suppose I shouldn’t be surprised by this, but it’s strange to me how completely the GPL seems to be anchored in early Unix architectural conventions. Per the GPL FAQ, unless we’re talking about libraries “designed for the interpreter”, interpreted code is basically data. Using libraries counts as linking, but in the eyes of the GPL any amount of interpreted code is just a big, complicated config file that tells the interpreter how to run.

At a glance this seems reasonable but it seems like a pretty strange position for the FSF to take, particularly given how much code in the world is interpreted, at some level, by something. And honestly: what’s an interpreter?

The text of the license and the interpretation proposed in the FAQ both suggest that as long as all the information that a program relies on to run is contained in the input stream of an interpreter, the GPL – and if their argument sticks, other open source licenses – simply… doesn’t apply. And I can’t find any other major free or open-source licenses that address this question at all.

It just seems like such a weird place for an oversight. And given the often-adversarial nature of these discussions, given the stakes, there’s no way I’m the only person who’s ever noticed this. You have to suspect that somewhere in the world some jackass with a very expensive briefcase has an untested legal brief warmed up and ready to go arguing that a CPU’s microcode is an “interpreter” and therefore the GPL is functionally meaningless.

Whatever your preferred license of choice, that really doesn’t seem like a place we want to end up; while this interpretation may be technically correct it’s also very-obviously a bad-faith interpretation of both the intent of the GPL and that of the authors in choosing it.

The position I’ve taken at work is that “are we technically allowed to do this” is a much, much less important question than “are we acting, and seen to be acting, as good citizens of the larger Open Source community”. So while the strict legalities might be blurry, seeing the right thing to do is simple: we treat the integration of interpreted code and codebases the same way we’d treat C/C++ linking, respecting the author’s intent and the spirit of the license.

Still, it seems like something the next generation of free and open-source software licenses should explicitly address.


  1. The LGPL was created specifically to solve the linking problem.

    Comment by Michael Kaply — August 13, 2018 @ 7:31 pm

  2. Also not a lawyer, but it seems pretty reasonable to me that there’s two different questions here: how does the GPL affect programs and libraries written in an interpreted language, and how does the GPL affect the relationship between the interpreted code and the interpreter.

    I think the FSF has always held that a program is a derived work of a library if it’s written to use that library’s interface, and there’s no (or no major) alternative implementations of that interface; that’s how they used libreadline to encourage people to GPL their code, but you could link against a GPL’d libc (or other standard API with multiple implementations) without creating a derivative work. Both JavaScript and Python have the idea of “libraries” and declaring which libraries your program depends on, so “linking” would seem to be pretty well defined.

    The relationship between an interpreted program and its interpreter is murkier. If the language is standard, with multiple implementations (like JavaScript) then it seems likely that an interpreted program is not a derivative work of the interpreter… but what about a JavaScript program that uses Node.js-specific APIs? Since there’s only one Node runtime, doesn’t that make such a program at least morally a derivative work? Or is it OK because somebody else might someday independently re-implement those APIs? I think that’s what the GPL FAQ is getting at.

    Comment by Screwtape — August 13, 2018 @ 10:32 pm

  3. Isn’t linking about code at rest? We’d object to the act of distributing a bunch of transformed code in a single work covered by copyright that comes from incompatible sets of obligations on user, from multiple licences. “Mere aggregation” is the GPL’s boundary (see FAQ ) for where programs become a single work. In terms of works in human-readable form, they can have differing licences, notably, that put obligations on the recipient. She or he get to deal with that when they want to use, study, extend or redistribute those works. In human-readable form, that can be segregated and can be dealt with piecemeal.

    The question about shared address space and marshalling data between modules of a work is rightly raised by ScrewTape, above, a a greater issue. Redistribution very rarely happens to interpreted works in a transformed and aggregated state (obfuscated JS, WebAssembly, pickled python objects, yes, separable jars, might do so).

    Do pickling, webassembly or JS obfuscation apply?


    Comment by ken_lewis81 — August 16, 2018 @ 4:16 am

  4. I’d have to go back and read the full GPL again, but if I recall correctly: By anyone using the software under the GPL they are agreeing that the GPL does apply. Because if it doesn’t apply they have no license to actually use the software (barring then buying a proprietary license for a work that is dual licensed in that way)

    Comment by Anonymous — August 16, 2018 @ 8:00 am

  5. I really don’t know – I think the foundational problem here is that the text of the GPL and the model of of computation it’s based on antedates all of these questions.

    Comment by mhoye — August 16, 2018 @ 9:06 am

  6. Microcode and interpreters long predate GPL 1.

    It is entirely within the power of the legal authors of an interpreter to disclaim rights over code written to run on the interpreter, even if it is the only implementation; and as this is usually necessary to generate sufficient enthusiasm for a community of users to coalesce around the language, it is always done, if not always in just so many words.

    The authors of the interpreted code have their own copyrights to assert. The nature of the interpreter needed to execute it is anything but relevant. A great lot of text under wholly defensible copyright does not execute on any interpreter — this posting among it.

    Comment by Nathan Myers — August 17, 2018 @ 11:36 pm

  7. There are three conflated issues here:

    1. Copyright. Just because one calls the Python program a “configuration file for the interpreter” does not by itself prevent copyright from applying to this program. So you are are already in a legal state where a license is needed to use or redistribute this copyrighted work

    2. Does GPL apply here – yes, otherwise you would have zero rights to distribute this “config file”. All the GPL protections – same license on redistribution in particular still apply. And even if one distributes obfuscated version of the software, GPL forces them to provide source code “in the form prefered for modification”, so un-obfuscated.

    3. Does GPL prevent cross-imports from Python scripts with proprietary (or other GPL-incompatible) licenses? IANAL, but IMHO it does not in a general case because the “linking” definition does not quite apply cleanly and the aggregate work can be distributed in separate files with each of them keeping its own separate license. This is the only bit that is not 100% clear and could be argued in court if one was so inclined.

    Comment by Aigars Mahinovs — August 22, 2018 @ 9:22 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress