Hacker News Reader

Stallman is saying he's surprised-- probably in the same way many on HN always are-- that a judge would, you know, use judgment. I.e., one program that would trip the GPL chopped into two in an attempt to not trip the GPL part of the program which is still there! His lawyers are telling him the judge would a) see the part with the license the person wants to avoid, b) see the subterfuge to do an end run around it (in both cases they are asking Stallman directly abou it), and c) judge harshly as a result. I don't know if his lawyers were right, but that's the argument.

With Google vs. Oracle, part 'a' doesn't exist. Google did a clean room implementation under the Apache license-- there's no Oracle-licensed software behind the curtain of the headers. So Oracle's only chance was to claim that an API is copyrightable. If it's not, that's the ballgame. But in the examples you gave wrt Stallman, API copyright doesn't matter-- it'd still be subterfuge to avoid triggering a license for the 2nd part of the program (at least according to his lawyers).

Edit: clarification

Funnily enough, the current state of the art in understanding GPLv2 is completely opposite (albeit disputed, see SFC vs Canonical on ZFS in Linux).

The critical part is whether the software is derived, as that is the language used by GPL, and it can be hard to claim that optional line editor - as many other lisp implementations showed, you can really go far with dumb (loop (print (eval (read))))

However, RMS had an obvious agenda involved, and libreadline was one of the major cugels used by FSF for significant part of 1990s. There's a reason why the term "GPL virality" stuck.

I would not say this is "the current state of the art in understanding GPLv2", merely disputed (implying by a minority). A better representation would IMO to say that there is no concensus.

It's big enough for major projects like FreeBSD and Illumos - and for Linux itself (although due to no copyright assignment other than enforcing GPLv2 instead of "GPLv2 or newer" individual developers can and will dispute it).

But ultimately there's no ruling to fall back on, as far as I know all cases ended up without actually getting a court ruling.

Part A does exist: it's the J2ME license that Google did not want to follow, since doing so would require not being Android. Sun was entirely uninterested in Java being the programming language of other people's platforms, as Macromedia found out when they tried to license Java for ActionScript 3. They wanted to be a platform that subsumed everything else - "write once, run anywhere".

The entire point of using Apache Harmony was to evade a licensing regime, and in fact, Apache even avoided collaboration with other Free Java implementations specifically because they did not want to be covered by GPL. In fact, when the Apache Harmony team went to Sun to ask for a license to the Java 5 TCK (the thing you need to pass in order for Sun to license your JVM), Sun's response was to specifically announce the GPL-licensed OpenJDK and TCK terms that only extended to GPL-licensed JVMs. They specifically selected a license to exclude Harmony. So this case starts to look a lot more like readline!

Furthermore, I feel like the particularities of GPL copyleft might be confusing. The reason why the GPL is able to demand source code conveyance is because copyright law grants it exclusive ownership over derivative works. The GPL can't just say "you agree to release all software you ever write under GPL forever" - it can only talk about cases in which copies or derivative works are made of the software the GPL covers. Same with Java; Oracle only has a valid claim if a derivative work has actually been made - not merely that licensing compliance was demanded. If you change your program in such a way as to not make a derivative work, then you aren't engaging in subterfuge, you're just stopping the infringement!

What Bruno Haible was arguing, was that, if he wrote his own library implementing the same functions as readline, then he would be able to distribute CLISP with his own readline workalike library only. Then users would be able to take either library, with the caveat that distributing the combination of CLISP and GNU readline is forbidden by the GPL. The only way that RMS can be right is if some element of copyright extends beyond the implementation of GNU readline and into it's interface, such that anything that uses the interface can be reasonably expected to comprise a derivative work of the implementation. If RMS doesn't own the readline API, then he has no claim against CLISP.

The main difference between readline and Java would be the direction in which derivation flows: RMS is arguing that users of his interfaces are derivatives, while Oracle is arguing that providers of it's interface are derivatives. However, there is nothing stopping Oracle from also arguing that all Java-language programs are derivative works that need to now worry about license compliance. That's the Java trap, at it's most extreme!

> Part A does exist

It doesn't.

In the readline example, the author was explicitly saying, "Let users decide to link against a thing so I can do an end run around licensing issues." Stallman is claiming the judge would be harsh because the judge knows prog1 with "choice" of subterfuge.a or inconvenientLicense.a is really just prog1 trying to get around an inconvenient license with which they must comply. "inconvenientLicense.a" is "Part A" of my example, and the author knew that users will link to inconvenientLicense.a. (Otherwise why have the choice at all?)

With the Google example, the devs said, "Let's do a clean room implementation so that the entire VM has our preferred license." There was no equivalent inconvenientLicense.a on any Android device. You can talk about J2ME existing in general, but that was what I mean by saying that "Part A" doesn't exist.

It's an important distinction-- it's the reason why Oracle basically was reduced to arguing copyright of an API. That's the only conceivable thing that could have inconvenientLicense on the device.

Edit: clarification

So, if I'm understanding this correctly, is the argument is that providing the user with a choice of library to link to, effectively "induces" the user to violate the GPL?

I'm using the concept of inducement as a theory of contributory copyright liability, even though it wasn't a concept of law at the time that RMS and Bruno had this discussion. It feels like an inducement argument, though - the idea that telling your users to break the license is just the same thing as breaking the license.

However, I don't think Bruno's argument hinges entirely on telling the user to break the GPL on his behalf. There is an API boundary, and in the time following this argument, people have written actual readline replacement wrappers that use BSD-licensed line-editing libraries (e.g. editline). The way I interpreted Bruno's argument was with the implication that he would actually reimplement readline instead of just, say, writing a functionality-free shim to induce the user to replace it with a functional but GPL'd library.

Not a lawyer or anything, but ...

Not inducement but rather intent. The question would be what the genuine intent of the author was behind the decision to so conveniently choose to place an API boundary right in that particular spot. The precise layout of the API also seems like it would be relevant - if no non-GPL libraries conforming to that particular API existed at the time of the decision, then what would the non-infringing justification be for choosing to implement that specific API in the first place?

(Aside: In Google's case, IIUC the non-infringing justification is code portability. Also, there's the bit where they (re)implemented the entire system - I don't believe they were linking against or otherwise using anything owned by Sun. Other than the API layout itself ... allegedly.)

Presumably questions about the decision making process itself, the technical merit of the final decision, and the state of any alternative implementations would all need to be considered.

I don’t think you can conclude that lawyer said anything about whether APIs are copyrightable.

I think that lawyer said “if you create that interface for the sole/main purpose to get away with having to license your code under the GPL, judges will consider it subterfuge”.

It’s like arguing “I didn’t take a cookie out of your cookie jar. I turned the jar around and later found a cookie lying on my desk”. Saying that’s stealing doesn’t imply that eating cookies you find lying on your desk is stealing.

I would think that, if a third party created a common interface to them to give users choice as to what UI they provide (releasing the GNU readline wrapper under the GPL, the BSD readline wrapper under a BSD license, etc), CLISP could say “feel free to replace the BSD readline we ship with with another one)

I don't think that's actually the argument being made. It's the standard "color of your bits"[1] distinction: intent matters. If you use GPL licensed code in your program (that does not fall into an explicit exception, eg. syscalls on linux) you must follow the GPL. No amount of technical trickery allows you to circumvent this. If however, you reimplement an API, that may or may not be copyrighted (watch for the final result on that google vs oracle case).

1: https://ansuz.sooke.bc.ca/entry/23

The language of the license doesn't talk anything about technical methods used, only whether the program is derived from GPLed code or not.

This has some !FUN! possibilities, in Dwarf Fortress meaning.

On one side, currently more common line of thought (promoted among other things by Linus, when non-GPLed code ended up in Linux through AFS) is related to actual functionality of the program being specifically dependant on GPLed code, vs. being a case where a common interface that existed in non-GPLed code might be used in between. This also makes moot any concern about syscalls that aren't linux-specific, as the programs using them have obvious defense of "I was following UNIX standards".

On the maximalist interpretation... well, it doesn't matter if the code runs on separate machine and you talk to it over IPC.

The trouble seems to stem from FSF itself misinterpreting derived to have direct application to technical specifics of linking. Whether by mistake or on purpose.

Here's Linus's actual words:

> anything that was written with Linux in mind (whether it then also works on other operating systems or not) is clearly partially a derived work

> Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did?

> Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.

If we take this logic and apply it to this situation, we can see that the GPL always applies if you are intentionally designing for and using GPLed code in your program, even if you "run on separate machine and you talk to it over IPC".

Now, if there happened to be some common readline API, with readline_gpl.so and readline_mit.so, then you could use it. But making up a hypothetical about readline_doesnotexist.so, when the only implementation you actually are using is readline_gpl.so is not going to convince a judge that the GPL does not apply.

You could maybe get away with it if you originally designed for inputline.so, some non-GPL library that had similar functionality to readline but with a different API, and then ported to readline.so - it would be situation dependent and I'd probably talk to a lawyer here. However, that wasn't what happened here either.

A couple years or so after that, Stallman seems to have changed his mind on compatible libraries.

Someone started distributing a program called RIPEM which was an implementation of the PEM (Privacy Enhanced Mail) standard, using RSA.

At the time RSA was patented and could not be legally used without permission in free software in jurisdictions that recognized the patent. RSA (the company) provided a library, RSAREF, that could be used for things like personal and noncommercial use, but could not be distributed on terms that were compatible with GPL.

RIPEM was public domain. The user was expected to get RIPEM, separately get RSAREF, and compile and link them on the BSD or Linux system. You also needed a bigint library.

The source code for RIPEM was written so it could work with either the BSD bigint library or the GNU bigint library. Something like this (but I'm making up the names):

  #ifdef BSD_BIGINT
  struct bsd_bigint_stricture * x;
  #endif

  #ifdef GNU_BIGINT
  struct gnu_bigint_structure * x;

  #endif

Same sort of thing at places that called the bigint library functions to operate on bigints.

Stallman objected. He said that the RIPEM author could not distribute that source code because on Linux systems the user would build it with GNU_BIGINT set, and link it with the GNU bigint library and RSAREF, and RSAREF licensing was incompatible with the licese of the GNU bigint library.

A lot of us thought that Stallman must be claiming some kind of interface or API copyright, because that was the only way we could see to try to make a copyright argument against distributing the RIPEM source code. Distributing a binary of RIPEM linked with RSAREF and the GNU library? Sure...that would clearly be not allowed. But source?

To be a derivative work of the GNU library, the RIPEM source code would have to incorporate some copyrighted elements of that library. Contrary to popular belief, it is not enough that work X is not useful without work Y to make X a derivative work of Y. It's got to actually take something from Y.

So unless the names of the library's functions, the calling sequences, and things like that are copyrighted (i.e., the API is copyrighted), RIPEM source could not be a derivative work.

What it turned out that Stallman was arguing is that when a Linux users ends up with a binary that combines RIPEM, RSAREF, and the GNU bigint library, that would not have have happened if not for the code in the GNU_BIGINT ifdef. Because that code has no use or purpose other than the building of those binaries, that code induces or causes people to make GPL violating binaries. The RIPEM author would be vicariously liable for those violations.

What finally resolved this was that someone wrote a library for BSD that implemented the GNU library's interface on top of BSD's bigint library. Now you could build RIPEM on BSD with GNU_BIGINT defined but not actually linking any GPL code.

This satisfied Stallman because now defining GNU_BIGINT had a use other than building a GPL violating binary.

There actually is vicariously liability in copyright law in the US. You can be found liable for enabling someone else's copyright infringement. That generally requires either you have control over them, or you provided them the means to infringe and there is no substantial non-infringing use for whatever it was you provided.

Vicarious infringement only works though if there is someone who is directly infringing so that there is someone whose liability you can be vicariously responsible for.

Stallman was not saying the the user who downloaded RIPEM, separately download RSARREF, and theb compiled them and linked to the GNU bigint library was infringing. GPLv2 generally allowed the user to whatever they wanted as long as they were not distributing any GPL code. Only when you distributed were GPL conditions imposed. But with no direct infringement on the part of that user, it is hard to see how you can hang vicarious infringement on the RIPEM developers.

> The RIPEM author would be vicariously liable for those violations.

I don't think so?

As you noted, part of the source code would have no purpose other than interacting with GPL'd code. Therefore, the RIPEM source would necessarily be a derivative work and thus fall under the GPL itself.

So the RIPEM author would be guilty of distributing source code with a bogus and misleading licensing statement at the top. Which might get them into legal trouble I guess? If someone was misled and suffered damages as a result, they could presumably turn around and sue the RIPEM developer. Or maybe not. I don't know.

A thought experiment. Clone the Linux kernel repository. Add a single small changeset for something fairly trivial. Then change every instance of the GPL in the repository to the WTFPL instead. Build and redistribute the resulting binary alongside your adulterated sources.

Also (nitpicking) you used the phrase "GPL violating binaries" which AFAIK isn't a thing. To be fair, you do later acknowledge the fact that the existence of binaries themselves doesn't violate the GPL, just the act of redistributing them without the source code.

The NetBSD libedit, which offers similar functionality, dates to 1994. Since 1997 it has implemented the readline API as well.