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
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
In fact, we are not violating GPL. In short, this is because we wrote
the code you are referring to (the SCSI target core in our commercial
RTS OS product), we have exclusive copyright ownership of it, and this
code contains no GPL code from the community. GPL obligations only
apply downstream to licensees, and not to the author of the code. Those
who use the code under GPL are subject to its conditions; we are not.
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:
But if you distribute a kernel and a module in one place which I
assume RTS OS does, then you are in dangerous territory and could be
hit with cease and desist notices, which has happened to people
shipping kernels and linked nvidia binary drivers before.
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
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
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
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
dangers were overblown, and suggested that Grover continue to "seek
As of November 13, no further responses from Bellinger or Rosen have been
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:
But let's forget licenses and talk community. Looking back, can anyone
say that your push to get LIO accepted into mainline as the kernel
target was in good faith? Back before LIO was merged, James chose LIO
over SCST saying to the SCST devs:
"Look, let me try to make it simple: It's not about the community you
bring to the table, it's about the community you have to join when you
become part of the linux kernel."
RTS behaved long enough to get LIO merged, and then forget community.
James is right, community is more important than code, and licenses
enforce community expectations. RTS has appeared just community-focused
enough to prevent someone else's code from being adopted, so it can
extract the benefits and still maintain its proprietary advantage.
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
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
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.
to post comments)