RTS and the GPL

GPL violations, or allegations thereof, are typically handled in private—unless, of course, they get to the lawsuit stage. That makes it rather surprising to see a GPL violation accusation on the linux-kernel mailing list. The code in question is the LIO SCSI target implementation, which was merged for 3.1 after a prolonged struggle with another contender; the alleged violator is Rising Tide Systems (RTS), which was the original developer and contributor of LIO. As might be guessed, the dispute is rather messy; there are more questions than answers.

The opening salvo was from Andy Grover to SCSI target maintainer (and RTS CTO) Nicholas Bellinger, with a copy to linux-kernel: "Your company appears to be shipping kernel features in RTS OS that are not made available under the GPL, specifically support for the EXTENDED_COPY and COMPARE_AND_WRITE SCSI commands, in order to claim full Vmware vSphere 5 VAAI support." Bellinger, however, didn't quite see things that way. He maintains that RTS owns the copyright to the code it contributed to Linux, so it can license it to its customers any way that it wants:

But there is a wrinkle here. RTS is shipping a Linux kernel, along with its proprietary SCSI target module, as RTS OS. Proprietary kernel modules have always been controversial, but they have largely been ignored when they are descended from another operating system's driver (e.g. NVIDIA) and are not distributed with the kernel. If that doesn't hold, it could become a bigger problem, as Dave Airlie pointed out:

In response, Bellinger made a common mistake regarding the kernel's symbol export macros. The EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() macros are an advisory mechanism that kernel developers use in an attempt to show which symbols can only be used by GPL-covered modules. Importantly, avoidance of EXPORT_SYMBOL_GPL() symbols is not, in itself, an indication that a module is not a derived work of the kernel (and thus subject to the terms of the GPL). It's somewhat of a tricky distinction, but anyone releasing a proprietary kernel module should very likely be getting legal advice; lawyers should have little trouble understanding the intent.

Specifically, Bellinger responded: "we only use Linux kernel symbols that are not marked as GPL". That provoked a quick response from Alan Cox, who noted that the distinction lies in the question of whether the SCSI target module is a derivative work—"The symbol tags are just a guidance". Furthermore, "either your work is [truly] not derivative of the kernel (which I find wildly improbable) or you have a problem". Cox also mentioned one other potential problem for RTS, certain patents (notably read-copy-update) are only licensed for use by GPL-covered code.

There are some other things to consider as well. Bellinger clearly indicated that RTS maintains a separate repository for its proprietary SCSI target. The kernel's version of LIO has seen numerous changes and fixes from others, but those were contributed under the GPL; Grover questioned whether some of those changes were flowing back into the proprietary version. Without seeing the code, it's a little hard to say for sure.

Enter the lawyer

As it turns out, RTS has retained Lawrence Rosen, the well-known free software savvy attorney, for advice. He stepped into the thread in an effort to try to smooth things over a bit. He reiterated the RTS stance that it maintains a separate version that is completely owned by the company, which it licenses to its customers under non-GPL terms.

Rosen also maintains that Oracle v. Google in the US (and, in Europe, SAS v. World Programming) debunks the claim that using the Linux APIs automatically creates a derivative work. That's a bit lawyerly, as no one in the thread was making that particular argument. Cox, Airlie, Grover, and others were arguing that using the APIs could make a derivative work—in fact is likely to make one—but not that it automatically does so. In fact, Airlie gave two examples (the Andrew Filesystem and binary GPU drivers) where at least some in the kernel community believe derivative works are not created. In the end, though, the courts have not given us a definitive decision on what constitutes a derivative work in the software realm, which is part of the reason for the murkiness here.

Beyond that, Bradley Kuhn pointed out that Rosen's interpretation of those two cases is not universally held. He also noted that there simply isn't enough information available for anyone outside of RTS to make any real assessment regarding the proprietary code. Whether that code is a derivative work or not requires more information, which has, as yet, not been forthcoming.

There is yet another wrinkle here. Grover has been posting using his redhat.com email address, which could give the impression that this is some kind of official Red Hat accusation (though Grover never claims that it is). Both Bellinger and Rosen drag Red Hat into the conversation, as do others in the thread. In fact, Rosen's response is copied to lawyers for both Red Hat and the Linux Foundation. That escalates the issue further, of course.

Enter the SCSI maintainer

Kernel SCSI maintainer James Bottomley was not particularly pleased with Grover's accusation. He questioned some of Grover's assumptions about which SCSI commands were actually supported by RTS OS, but also strongly suggested verifying how the software worked before slinging any more potential "libel". Bottomley seems concerned—perhaps overly—that Grover needlessly "exposes us all to jeopardy of legal sanction". Kuhn, at least, thought the legal dangers were overblown, and suggested that Grover continue to "seek facts".

As of November 13, no further responses from Bellinger or Rosen have been posted. In his initial post, Grover noted that he had tried to discuss the problem with Bellinger and RTS CEO Marc Fleischmann via private email, without getting a "useful response". Grover's public post finally did elicit some response, one that he thinks clearly indicates a GPL violation. But he also pointed out another sticky issue:

It is an unprecedented situation and one that is likely to be messy to unwind. The Linux SCSI target appears to be missing features because its maintainer is adding them to a proprietary driver that ships with the GPL-covered kernel. There is certainly nothing that forces Bellinger or RTS to make their improvements available unless, of course, there is a GPL requirement to do so. But if some other developer were to come along with an implementation of the missing features, is Bellinger going to accept them into the mainline driver, forcing (further) divergence with the proprietary code?

The open nature of the accusation, and that it is associated with Red Hat (fairly or not), will also complicate the issue. It is unlikely that the company would set out to address a possible violation in this way, but it now finds itself in a sticky situation. Extracting itself may be difficult, and completely ignoring the problem may not be possible either.

If it turns out that there is no GPL violation, there has still been some damage done, it would seem. The idea behind the choice of the GPL for the kernel is that competitors all have equal access, but in this case RTS appears to be in a privileged position with respect to SCSI target features. That would seem to violate the spirit of Linux development, even if it doesn't violate the license.