scsi target, likely GPL violation

scsi target, likely GPL violation

[Andy Grover]

Nick,

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.

http://www.risingtidesystems.com/storage.html
http://www.linux-iscsi.org/wiki/VAAI

Private emails to you and RTS CEO Marc Fleischmann have not elicited a
useful response.

You are subsystem maintainer for the in-kernel SCSI target support
(drivers/target/*), and your company appears to be violating the GPL.
Please explain.

Regards -- Andy

Re: scsi target, likely GPL violation

[Jon Mason]

On Wed, Nov 7, 2012 at 9:50 AM, Andy Grover <agrover@redhat.com> wrote:
> Nick,
>
> 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.
>
> http://www.risingtidesystems.com/storage.html
> http://www.linux-iscsi.org/wiki/VAAI
>
> Private emails to you and RTS CEO Marc Fleischmann have not elicited a
> useful response.
>
> You are subsystem maintainer for the in-kernel SCSI target support
> (drivers/target/*), and your company appears to be violating the GPL.

The peanut gallery needs more information, as this is quite an
incendiary claim to be making on a Linux kernel forum.  How are they
violating the GPL?  I'm not a lawyer, nor do I play one on TV, but if
I understand the GPL correctly, RTS only needs to provide the relevant
source to their customers upon request.  Are there customers (perhaps
Redhat) that they have not provided this to?  If so, then they need to
be publicly shamed (gpl-violations.org would be a good place to go as
well).  If not, then they are within their rights to behave the way
they are currently behaving.

Again, we need more info before we start flinging the tomatoes at them.

Thanks,
Jon

> Please explain.
>
> Regards -- Andy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi target, likely GPL violation

[Chris Friesen]

On 11/07/2012 07:02 PM, Jon Mason wrote:
> I'm not a lawyer, nor do I play one on TV, but if
> I understand the GPL correctly, RTS only needs to provide the relevant
> source to their customers upon request.

Not quite.

Assuming the GPL applies, and that they have modified the code, then 
they must either:

1) include the source with the distributed binary

or

2) include with the binary an offer to provide the source to *any* third 
party

Chris

Re: scsi target, likely GPL violation

[Andy Grover]

On 11/07/2012 05:57 PM, Chris Friesen wrote:
> On 11/07/2012 07:02 PM, Jon Mason wrote:
>> I'm not a lawyer, nor do I play one on TV, but if
>> I understand the GPL correctly, RTS only needs to provide the relevant
>> source to their customers upon request.
> 
> Not quite.
> 
> Assuming the GPL applies, and that they have modified the code, then
> they must either:
> 
> 1) include the source with the distributed binary
> 
> or
> 
> 2) include with the binary an offer to provide the source to *any* third
> party

So you'd have me find one of their customers, and then get the source
via your #2 method...

...and then turn around and submit it to Nick since he's the target
subsystem maintainer? Nick is probably the one who wrote it!

I'm happy to do that, but we should recognize something is seriously
skewed when the person nominally in charge of the in-kernel code also
has a vested interest in *not* seeing new features added, since it then
competes better with his company's offering.

RTS is trying to use an "open core" business model. This works fine for
BSD-licensed code or code originally authored entirely by you, but their
code (all of it even the new stuff) is a derivative work of the Linux
kernel source code, and the GPL says they need to contribute it back.

Regards -- Andy

Re: scsi target, likely GPL violation

[Nicholas A. Bellinger]

On Thu, 2012-11-08 at 08:57 -0800, Andy Grover wrote:
> On 11/07/2012 05:57 PM, Chris Friesen wrote:
> > On 11/07/2012 07:02 PM, Jon Mason wrote:
> >> I'm not a lawyer, nor do I play one on TV, but if
> >> I understand the GPL correctly, RTS only needs to provide the relevant
> >> source to their customers upon request.
> > 
> > Not quite.
> > 
> > Assuming the GPL applies, and that they have modified the code, then
> > they must either:
> > 
> > 1) include the source with the distributed binary
> > 
> > or
> > 
> > 2) include with the binary an offer to provide the source to *any* third
> > party
> 
> So you'd have me find one of their customers, and then get the source
> via your #2 method...
> 
> ...and then turn around and submit it to Nick since he's the target
> subsystem maintainer? Nick is probably the one who wrote it!
> 
> I'm happy to do that, but we should recognize something is seriously
> skewed when the person nominally in charge of the in-kernel code also
> has a vested interest in *not* seeing new features added, since it then
> competes better with his company's offering.
> 
> RTS is trying to use an "open core" business model. This works fine for
> BSD-licensed code or code originally authored entirely by you, but their
> code (all of it even the new stuff) is a derivative work of the Linux
> kernel source code, and the GPL says they need to contribute it back.
> 

Andy,

Accusing us of violating GPL is a serious legal claim.  

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.

As you know, we contributed the Linux SCSI target core, including the
relevant interfaces, to the Linux kernel.  To be clear, we wrote that
code entirely ourselves, so we have the right to use it as we please.
The version we use in RTS OS is a different, proprietary version, which
we also wrote ourselves.  However, the fact that we contributed a
version of the code to the Linux kernel does not require us to provide
our proprietary version to anyone.

If you want to understand better how dual licensing works, perhaps we
can talk off list.  But we don’t really have a responsibility to respond
to untrue accusations, nor to explain GPL, nor discuss our proprietary
code.

We’re very disappointed that Red Hat would not be more professional in
its communications about licensing compliance matters, particularly to a
company like ours that has been a major contributor to Linux and
therefore also to Red Hat’s own products.  So, while I invite you to
talk about this with us directly, I also advise you – respectfully – not
to make public accusations that are not true.  That is harmful to our
reputation – and candidly, it doesn’t reflect well on you or your
company.

--nab

Re: scsi target, likely GPL violation

[Dave Airlie]

>> ...and then turn around and submit it to Nick since he's the target
>> subsystem maintainer? Nick is probably the one who wrote it!
>>
>> I'm happy to do that, but we should recognize something is seriously
>> skewed when the person nominally in charge of the in-kernel code also
>> has a vested interest in *not* seeing new features added, since it then
>> competes better with his company's offering.
>>
>> RTS is trying to use an "open core" business model. This works fine for
>> BSD-licensed code or code originally authored entirely by you, but their
>> code (all of it even the new stuff) is a derivative work of the Linux
>> kernel source code, and the GPL says they need to contribute it back.
>>
>
> Andy,
>
> Accusing us of violating GPL is a serious legal claim.
>
> 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.

Just to clarify since I'm not a major GPL expert. Are you:

a) distributing a Linux kernel

b) with a module built against it to be linked into it, whether
completely written in house or not?

Then the module is under the GPL, if you think you are like nvidia or
someone then think again, the corner case they live under is that they
don't distribute a Linux kernel with their module *ever*, and they
have a clear call for non-derived work status since its 90% the same
code as in their Windows drivers.

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.

Dave.

Re: scsi target, likely GPL violation

[Andy Grover]

On 11/08/2012 12:05 PM, Nicholas A. Bellinger wrote:
> Accusing us of violating GPL is a serious legal claim.  
> 
> 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.

Hi Nick, thanks for finally responding.

I believe your argument is wrong for two reasons.

First, LIO is a derivative work of the Linux kernel. It uses kernel APIs
and headers. You ship Linux as part of RTS OS. Even if you had not asked
for LIO to be included in mainline, this would still be true and would
require you to publish your changes under the GPLv2.

Second, you claim you hold exclusive copyright for the code. Not true.
One example: on http://www.risingtidesystems.com/storage.html you claim
support for FCoE. You didn't build tcm_fc, Intel did. Under the GPLv2.
Furthermore, SRP support came from SCST, iirc. None of these
contributors gave RTS any right to use their copyrighted code except
under the conditions of the GPLv2.

> As you know, we contributed the Linux SCSI target core, including the
> relevant interfaces, to the Linux kernel.  To be clear, we wrote that
> code entirely ourselves, so we have the right to use it as we please.
> The version we use in RTS OS is a different, proprietary version, which
> we also wrote ourselves.  However, the fact that we contributed a
> version of the code to the Linux kernel does not require us to provide
> our proprietary version to anyone.

In addition to the two reasons above, how does it make any sense that
you are spending time maintaining in-tree LIO when none of that code can
theoretically benefit RTS's proprietary product? The more likely
scenario is you are basing your product on mainline LIO.

> If you want to understand better how dual licensing works, perhaps we
> can talk off list.  But we don’t really have a responsibility to respond
> to untrue accusations, nor to explain GPL, nor discuss our proprietary
> code.

All the contributions and improvements (there have been a LOT) since LIO
entered mainline are GPLed by their authors. If you incorporated any of
those improvements or fixes into RTS OS, then there's a third reason why
your code is subject to the GPL.

> We’re very disappointed that Red Hat would not be more professional in
> its communications about licensing compliance matters, particularly to a
> company like ours that has been a major contributor to Linux and
> therefore also to Red Hat’s own products.  So, while I invite you to
> talk about this with us directly, I also advise you – respectfully – not
> to make public accusations that are not true.  That is harmful to our
> reputation – and candidly, it doesn’t reflect well on you or your
> company.

I tried the private route but you and your CEO stalled, and then stopped
talking to me.

Please just start behaving properly w/r/t the GPL so we can all get back
to coding.

Regards -- Andy

Re: scsi target, likely GPL violation

[Nicholas A. Bellinger]

On Thu, 2012-11-08 at 13:22 -0800, Andy Grover wrote:
> On 11/08/2012 12:05 PM, Nicholas A. Bellinger wrote:
> > Accusing us of violating GPL is a serious legal claim.  
> > 
> > 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.
> 
> Hi Nick, thanks for finally responding.
> 
> I believe your argument is wrong for two reasons.
> 
> First, LIO is a derivative work of the Linux kernel. It uses kernel APIs
> and headers. You ship Linux as part of RTS OS. Even if you had not asked
> for LIO to be included in mainline, this would still be true and would
> require you to publish your changes under the GPLv2.
> 
> Second, you claim you hold exclusive copyright for the code. Not true.
> One example: on http://www.risingtidesystems.com/storage.html you claim
> support for FCoE. You didn't build tcm_fc, Intel did. Under the GPLv2.
> Furthermore, SRP support came from SCST, iirc. None of these
> contributors gave RTS any right to use their copyrighted code except
> under the conditions of the GPLv2.
> 

Andy,

Support for certified VAAI is part of our commercial target core. The
target core constitutes a stand-alone kernel subsystem of which we are
the sole copyright owners. In addition, our target contains a number of
backend drivers, of which we are also the sole copyright owners, and a
number of fabric modules, of which some we are the sole copyright
owners, and of which others we are not, as you pointed out. A
substantial fraction of the code of which we own the sole copyright was
certified by BlackDuck Software as early as in 2007. 

We contributed our target to the Linux kernel in 2010, at which point we
forked it into the upstream version and our commercial version. These
target versions have been diverging over time, as we keep maintaining
either one of them independently.

For our commercial target core, we only use Linux kernel symbols that
are not marked as GPL. In addition, we define the API between the target
core and its backend drivers and between the target core and its fabric
modules, we define the ABI between the target core and user space, and
we have done so years before our code went upstream into the Linux
kernel.

We have been contributing substantially to the upstream target version
to keep improving Linux. We have also been improving our commercial
target version to afford the considerable effort and expense involved in
our ongoing Linux contributions, and to compensate other top Linux
kernel developers for their contributions to the upstream target
version.

RTS OS is based on a stock Linux enterprise kernel. This Linux kernel
has naturally the ability to load either one of our standalone
self-contained target module versions without any modifications.

Again, we’re very disappointed by these untrue and highly damaging
accusations from Red Hat. We have generously contributed to Linux, and
we have generously supported the Linux community for their contributions
to our upstream target and other Linux kernel parts. You have mostly
just incorporated our work into Red Hat’s products.

So yes, Andy, please start behaving properly, so that at least we can
get back to making Linux better.

--nab

Re: scsi target, likely GPL violation

[Alan Cox]

> For our commercial target core, we only use Linux kernel symbols that
> are not marked as GPL. In addition, we define the API between the target

And this has what meaning ?

The Linux kernel is a GPL work, any derivative work is a GPL work. The
symbol tags are just a guidance.

You do not have permission to build a non GPL derivative work of any code
I own. The licensing determination is *derivative work* not symbols
marked with _GPL. This has been stated publically by many developers many
times.

So either your work is truely not derivative of the kernel (which I find
wildly improbable) or you have a problem and since you are aware of the
complaints publically I guess probably a triple damages sized problem. But
that's one for your lawyers and whatever opinion they have on the subject.

You do btw have a second thing to consider - there are US patent grants
for some functions in the kernel that only extend to GPL code so utilising
some of the subsystems in the USA may give you other problems even if you
can somehow manage to demonstrate your work is not derivative.

> RTS OS is based on a stock Linux enterprise kernel. This Linux kernel
> has naturally the ability to load either one of our standalone
> self-contained target module versions without any modifications.

That's not the usual test for derivative work I've heard applied.

I fail to understand the maintainer question however. If you were trying
to block people adding target features that competed that would be a
different thing.

Alan

Re: scsi target, likely GPL violation

[Andy Grover]

On 11/09/2012 03:03 AM, Alan Cox wrote:
> I fail to understand the maintainer question however. If you were trying
> to block people adding target features that competed that would be a
> different thing.

You think it's ok for us to have an unrepentant GPL violator as a
subsystem maintainer??

If that's really what you're saying then I think that's crazy.

-- Andy

Re: scsi target, likely GPL violation

[Alan Cox]

On Fri, 09 Nov 2012 11:52:19 -0800
Andy Grover <agrover@redhat.com> wrote:

> On 11/09/2012 03:03 AM, Alan Cox wrote:
> > I fail to understand the maintainer question however. If you were trying
> > to block people adding target features that competed that would be a
> > different thing.
> 
> You think it's ok for us to have an unrepentant GPL violator as a
> subsystem maintainer??
> 
> If that's really what you're saying then I think that's crazy.

If he was a GPL violator and had been shown so it would be.

However it's alleged GPL violator, and we could have the same argument
about say Nvidia or half a dozen other contributors and companies before
we get to things like the GPLv2 versus DRM question (all the necessary
scripts including the key).

But RH could always sue him, or simply provide an open alternative I
guess (or indeed let secure boot and the RHEL plans for it put him out of
business) ;)

Alan

RE: scsi target, likely GPL violation

[Lawrence Rosen]

Alan Cox wrote:
> So either your work is truely not derivative of the kernel (which I find
> wildly improbable) or you have a problem and since you are aware 
> of the complaints publically I guess probably a triple damages sized 
> problem. But that's one for your lawyers and whatever opinion they 
> have on the subject.

Hi Alan and others,

I've been advising Rising Tide Systems (RTS) in this matter. Please let me
reassure you that RTS is acting on advice of counsel.

RTS (and specifically Nicholas Bellinger) wrote the scsi target code and
owns its copyright. We registered that copyright at the Library of Congress.
RTS contributed a version of the scsi target to Linux for distribution under
the GPL. On behalf of Marc Fleischmann, CEO of RTS, I can reassure you that
RTS remains committed to the Linux project and will continue to contribute
to it. We are pleased that RTS software is a part of the Linux distribution
under the GPL.

RTS also has a commercial software business. It distributes versions of its
scsi target code that support features and functions not officially in Linux
(or at least, not yet). That commercial RTS business includes the licensing
of those derivative works of its own code to its own customers. Nothing
whatsoever in the GPL or in the policies of the Linux Foundation prohibits
that.

I would also like to address some comments made on these lists by Andy
Grover and Bradley Kuhn. 

First, I hope that we can tone down the arguments about whether the use of
Linux APIs and headers automatically turns a program into a derivative work
of Linux. I think that argument has been largely debunked in the U.S. in the
recent decision in Oracle v. Google, and in Europe in SAS v. World
Programming. Does anyone here question whether the original work that RTS
contributed to Linux (and that *is* under the GPL) is an original work of
authorship of RTS despite the fact that it links to other GPL code using
headers and APIs?

Second, we are grateful for the efforts that Bradley Kuhn and others put in
to enforce the GPL. As I said above, RTS owns and has registered the
copyright on its scsi target and will enforce it if necessary. So Brad, we
may solicit your assistance if we find any third party who is distributing
an unauthorized non-GPL derivative work of the scsi target now in Linux.
RTS, of course, retains the exclusive right to do so, but no third party can
do so without a license from RTS.

Best regards,

/Larry

P.S. In accordance with my obligations as an attorney when communicating
with a represented person, I am copying attorneys for Red Hat and Linux
Foundation on this email.  If anyone wishes to respond to me, please copy me
directly since I am not subscribed to these lists.

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242

Re: scsi target, likely GPL violation

[Julian Calaby]

Hi Lawrence,

On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen <lrosen@rosenlaw.com> wrote:
> Alan Cox wrote:
>> So either your work is truely not derivative of the kernel (which I find
>> wildly improbable) or you have a problem and since you are aware
>> of the complaints publically I guess probably a triple damages sized
>> problem. But that's one for your lawyers and whatever opinion they
>> have on the subject.
>
> Hi Alan and others,
>
> I've been advising Rising Tide Systems (RTS) in this matter. Please let me
> reassure you that RTS is acting on advice of counsel.

It's nice to hear from legal counsel on this matter.

I don't think that the *usage* of the kernel APIs is the biggest issue
here. There are many examples where proprietary code uses these APIs
and is not violating the GPL.

As I see it, one of the main concerns is because the proprietary and
in-kernel target systems are, from what I understand, quite similar,
there is the possibility that GPL licensed contributions to the
in-kernel target code may have "leaked" into to the proprietary code.
That said, proving this is a very difficult problem, but the question
must still be asked:

Can Rising Tide Systems assure us that there is no GPL licensed code
within their proprietary target code?

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: scsi target, likely GPL violation

[Dave Airlie]

On Mon, Nov 12, 2012 at 8:41 AM, Julian Calaby <julian.calaby@gmail.com> wrote:
> Hi Lawrence,
>
> On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen <lrosen@rosenlaw.com> wrote:
>> Alan Cox wrote:
>>> So either your work is truely not derivative of the kernel (which I find
>>> wildly improbable) or you have a problem and since you are aware
>>> of the complaints publically I guess probably a triple damages sized
>>> problem. But that's one for your lawyers and whatever opinion they
>>> have on the subject.
>>
>> Hi Alan and others,
>>
>> I've been advising Rising Tide Systems (RTS) in this matter. Please let me
>> reassure you that RTS is acting on advice of counsel.
>
> It's nice to hear from legal counsel on this matter.
>
> I don't think that the *usage* of the kernel APIs is the biggest issue
> here. There are many examples where proprietary code uses these APIs
> and is not violating the GPL.
>
> As I see it, one of the main concerns is because the proprietary and
> in-kernel target systems are, from what I understand, quite similar,
> there is the possibility that GPL licensed contributions to the
> in-kernel target code may have "leaked" into to the proprietary code.
> That said, proving this is a very difficult problem, but the question
> must still be asked:
>
> Can Rising Tide Systems assure us that there is no GPL licensed code
> within their proprietary target code?

Its a bit of both actually.

The problem is if you design a kernel subsystem specifically for the
Linux kernel, even if you use the internal APIs, you are most likely
creating a derived work of the Linux kernel.

questions that would need to be asked:
Can the scsi target code work completely separate from a Linux kernel?
Does it work with another operating system? was it designed for that
operating system?

The whole in-kernel version under the GPL isn't the problem here and
has nothing to do with the violation. Its the one they distribute
separately with their RTS OS kernel, and if they distribute it in one
combined work, then a GPL violation is possibly indicated.

The reasons for non-derived work status that have been suggested (but
not accepted by all the community):
a) AFS, a file system clearly not developed for Linux, where it being
a derived work of something that came after it would be a bit crazy,
b) binary GPU drivers, built from the same source base on their
Windows platform, and the code existed on Windows before Linux,
arguing this driver is a derived work is difficult as well. Also
nvidia specifically don't distribute this driver linked against the
kernel, and distros who have done this in the past have been on the
end of cease-and-desist letters.

So really this is purely a derived work issue, whether they release a
trailing edge version of their code afterwards under the GPL isn't
significant, other than a this might keep the community off our back.

(Yes the secondary issue of people who contributed code and cleanups
back to that code base and if they integrated it back into their
internal code base, is a problem, but I don't believe its the primary
issue).

Dave.

Re: scsi target, likely GPL violation

[Bradley M. Kuhn]

Lawrence Rosen wrote at 17:13 (EST) on Sunday:
> First, I hope that we can tone down the arguments about whether the
> use of Linux APIs and headers automatically turns a program into a
> derivative work of Linux. I think that argument has been largely
> debunked in the U.S. in the recent decision in Oracle v. Google, and
> in Europe in SAS v. World Programming. Does anyone here question
> whether the original work that RTS contributed to Linux (and that *is*
> under the GPL) is an original work of authorship of RTS despite the
> fact that it links to other GPL code using headers and APIs?

My point remains that most of us simply don't have enough facts to know
at this point what case law applies to the situation.  Andy is seeking
facts to determine if a violation occurred, and I hope he gets them.

As I said in my previous email at 10:15 (EST) on Sunday:
>> lawyers disagree, and will often just take the position their client
>> wants them to take ...

I realize fully, Larry, that you're taking the position of your client,
whom you've identified as Rising Tide Systems.  Meanwhile, obviously, I
know many lawyers who disagree with your widely known interpretation of
the implications of the two cases you mention.

I'd suspect that most lawyers looking at this situation would probably
agree with me that the facts aren't fully known enough to make an
assessment about the derivative nature of any code involved (other that
the code that Rising Tide Systems pushed upstream already).  While the
facts regarding other code are presumably fully known to you, Larry,
because you have extra information under attorney-client privilege from
your client Rising Tide Systems, no one else can make an independent
evaluation of the facts yet.

I therefore suggest that Andy be permitted to continue seeking facts on
this question without being squelched, and we see what the facts bear
out.  If some copyright holders believe a violation has occurred,
provided the facts can be ascertained (which might prove difficult,
given the political climate this thread has created), I'm sure those
copyright holders will take up the matter at that point.

> Second, we are grateful for the efforts that Bradley Kuhn and others
> put in to enforce the GPL.

Thank you.

> So Brad[ley], we may solicit your assistance if we find any third
> party who is distributing an unauthorized non-GPL derivative work of
> the scsi target now in Linux.

Conservancy is a 501(c)(3) charity in the USA and is thus not able to
engage in copyright enforcement action on behalf of for-profit companies
like Rising Tide Systems.  However, individual copyright holders who
wish to put their copyrights forward as part of the coalition described
in Conservancy's May announcement at
http://sfconservancy.org/news/2012/may/29/compliance/ are welcome to do
so, provided those copyright holders agree in writing that their
copyrights will only be enforced to advance the public's access to Free
Software. (Details of that can be discussed in private email; feel free
to contact me if you're an individual copyright holder in Linux and
interested in discussing it.)

Larry, Conservancy *could* accept a charitable donation of
copyright assignment to Conservancy if Rising Tide Systems wishes to
do that.  Feel free to contact my privately if your client is
interested in that.

> RTS, of course, retains the exclusive right to do so, but no third
> party can do so without a license from RTS.

I'm sure you agree that Rising Tide Systems has already granted a
license under GPLv2 for their contributions to Linux, so parties
redistributing the derivatives of their code that are part of upstream
Linux already have a license under GPLv2 for that specific code.

> P.S. In accordance with my obligations as an attorney when
> communicating with a represented person, I am copying attorneys for
> Red Hat and Linux Foundation on this email.

This inclusion seems a bit more than necessary to me, but I'm always
happy to have Karen Copenhaver's and Richard Fontana's input on any
situation where they're willing to opine. :)
-- 
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy

Re: scsi target, likely GPL violation

[Andy Grover]

Hi all,

First, I do not, and did not, have access to the proprietary OS, which
has been referred to. Otherwise, I would have checked it.

Second, I appreciate that my questions and tentative inferences may not
have been perfect, given that I did not have the complete facts, but I
did try to obtain them from RTS before raising questions in this forum.
But I was not successful.

Third, in retrospect, I think a more measured approach to the dialog
may have been a better course. I am interested in understanding the
situation. My primary goal was to avoid duplicating a lot of work, if
RTS plans to open-source the new features they have added to the
proprietary version.

Fourth, my questions about the GPL’s requirements in this context remain.

Finally, I was, in this thread, speaking on my behalf alone and
at my initiative-- not Red Hat’s, as some may have incorrectly
concluded. I'll be using a personal email account (CC'd) for this issue
in the future, in order to make this more explicit.

Regards -- Andy

Re: scsi target, likely GPL violation

[Andy Grover]

On 11/08/2012 06:08 PM, Nicholas A. Bellinger wrote:
> Support for certified VAAI is part of our commercial target core. The
> target core constitutes a stand-alone kernel subsystem of which we are
> the sole copyright owners. In addition, our target contains a number of
> backend drivers, of which we are also the sole copyright owners, and a
> number of fabric modules, of which some we are the sole copyright
> owners, and of which others we are not, as you pointed out. A
> substantial fraction of the code of which we own the sole copyright was
> certified by BlackDuck Software as early as in 2007. 

See this:

http://www.gnu.org/licenses/gpl-2.0.html from section 2

"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program, and
can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based on
the Program, the distribution of the whole must be on the terms of this
License, whose permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who wrote it."

Is your code an independent and separate work from the Linux kernel?
Some tests might be: can it be used without the Linux kernel? Can it be
used with alternative kernels? Even if the answer to these questions is
YES (which it isn't) then that second quoted sentence would still put
your code under the terms of the GPL, since RTS OS distributes its
changes along with the Linux kernel.

I've spent enough time arguing the factual basis of this issue. It seems
crystal clear to me, and I have a hard time seeing how anyone could
disagree.

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.

-- Andy

Re: scsi target, likely GPL violation

[Bradley M. Kuhn]

This thread is certainly fascinating.  As someone who has enforced the
GPL for over a decade, and who coordinates a coalition of Linux
developers who do GPL enforcement, I am very concerned about any
accusation of GPL violation, and I hope that this situation can be
resolved reasonably and swiftly.

While I usually encourage private discussion about GPL violations -- at
least to start -- I've also often found it's nearly impossible to
maintain perfect secrecy about alleged GPL violations; openness and
public discussions are the standard manner of group communication in the
Free Software community.  I hope that Rising Tide Systems and its agents
are cognizant of this nature of the Free Software community.
Furthermore, now that the discussion is public anyway, I hope Rising
Tide Systems and its agents will welcome it and avoid any further
actions to squelch such discussion.

I suggest, though, that perhaps one of the mailing lists that Harlad
Welte runs for his GPL Violations Project (such as
http://lists.gpl-violations.org/mailman/listinfo/legal/ ) might be a
better forum for this thread, rather than the technical discussion
mailing lists for Linux and the subsystems in question.

Meanwhile, I don't have too much to comment on in detail on this thread
publicly at this time, but I do have a few points below:

Nicholas Bellinger wrote at 21:08 (EST) on Thursday:
> A substantial fraction of the code of which we own the sole copyright
> was certified by BlackDuck Software as early as in 2007.

Often in my work enforcing the GPL, companies have unsuccessfully
proposed a Blackduck review as a defense of copyright infringement.  I
don't think Blackduck's system does anything to determine whether or not
something is a derivative work under copyright law and/or whether a
violation of GPL has occurred.

Indeed, I know of no algorithmic way to make such determinations, and
I'm quite sure they're undecidable problems (in the computability theory
sense).  To my knowledge, Blackduck's proprietary tool is merely an
scanning tool examining source code for copyright header information and
to pattern-match against other codebases in Blackduck's private
database.  (Although, since Blackduck's software is proprietary,
trade-secret software, it's impossible to know for sure what it actually
does, but we can be sure it doesn't solve any problems that are known to
be unsolvable.)  Thus, citing a Blackduck certification is simply
off-point in refuting an accusation of any form of copyright
infringement.  Blackduck's software might be able to tell you if you *have*
plagiarized someone's source code that appears in their databases, but
they can't possibly tell you that you haven't infringed any copyrights.
I'm quite sure Blackduck doesn't give away certification on the latter
point.

> So..., Andy, please start behaving properly ...  [you aren't] be[ing]
> ... professional in ... communications about licensing compliance
> matters,

I don't think it's reasonable to chastise Andy for raising these
questions.  While I personally (and Conservancy as an organization)
don't usually raise accusations of GPL violations publicly until other
methods of private communication are attempted, I believe public
discussion is an important component of GPL compliance. Thus, Andy's
strategy of discussing it publicly early in the process -- while not my
preferred strategy -- is still a reasonable one.  His attempt to raise
these serious and legitimate concerns and questions is in no way
unprofessional, nor should it be squelched.
-- 
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy

Re: scsi target, likely GPL violation

[Andy Grover]

On 11/07/2012 05:02 PM, Jon Mason wrote:
> On Wed, Nov 7, 2012 at 9:50 AM, Andy Grover <agrover@redhat.com> wrote:
>> 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.
>>
>> http://www.risingtidesystems.com/storage.html
>> http://www.linux-iscsi.org/wiki/VAAI
>>
>> Private emails to you and RTS CEO Marc Fleischmann have not elicited a
>> useful response.
>>
>> You are subsystem maintainer for the in-kernel SCSI target support
>> (drivers/target/*), and your company appears to be violating the GPL.
> 
> The peanut gallery needs more information, as this is quite an
> incendiary claim to be making on a Linux kernel forum.  How are they
> violating the GPL?  I'm not a lawyer, nor do I play one on TV, but if
> I understand the GPL correctly, RTS only needs to provide the relevant
> source to their customers upon request.  Are there customers (perhaps
> Redhat) that they have not provided this to?  If so, then they need to
> be publicly shamed (gpl-violations.org would be a good place to go as
> well).  If not, then they are within their rights to behave the way
> they are currently behaving.
> 
> Again, we need more info before we start flinging the tomatoes at them.

Look at the marketing material on their website. They demonstrate how
RTS OS fully implements vSphere 5 VAAI features. We know to a very high
certainty that this must have been implemented with kernel code, so
therefore this must be a GPL violation, since these changes have not
been made public.

-- Andy

Re: scsi target, likely GPL violation

[James Bottomley]

On Wed, 2012-11-07 at 08:50 -0800, Andy Grover wrote:
> Nick,
> 
> 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.
> 
> http://www.risingtidesystems.com/storage.html
> http://www.linux-iscsi.org/wiki/VAAI
> 
> Private emails to you and RTS CEO Marc Fleischmann have not elicited a
> useful response.
> 
> You are subsystem maintainer for the in-kernel SCSI target support
> (drivers/target/*), and your company appears to be violating the GPL.
> Please explain.

Can we please cool it with the inflammatory accusations.  Please
remember that statements which damage or seek to damage the reputation
of a company amount to libel even under US law ... and using phrases
like "appears to" doesn't shield you from this.

I also note that whatever their website says RTS OS isn't in VMware's
certified compatibility list:

http://www.vmware.com/resources/compatibility/pdf/vi_io_guide.pdf

Plus it's a grey area what you actually have to support to make that
list (especially as XCOPY has now been removed from SBC-3 in favour of
token copy), so I'd say that the chain of reasoning you've used to come
up with this hearsay allegation of copyright violation is tenuous at
best.

Anybody who does enforcement will tell you that you begin with first
hand proof of a violation.  That means obtain the product and make sure
it's been modified and that a request for corresponding source fails.
In this case, since I presume Red Hat, as a RTS partner, has a bona fide
copy of the RTS OS, please verify it does indeed implement or issue the
commands which are not in the public git repository and that whoever
owns the copy makes a request for the source code.

I would really appreciate it if the next email I see from you on this
subject is either

     1. Yes, I've got first hand proof of a GPL violation (in which case
        we'll then move to seeing how we can remedy this) or
     2. A genuine public apology for the libel, which I'll do my best to
        prevail on RTS to accept.

Because any further discussion of unsubstantiated allegations of this
nature exposes us all to jeopardy of legal sanction.

James

Re: scsi target, likely GPL violation

[Theodore Ts'o]

On Sun, Nov 11, 2012 at 09:34:16AM +0000, James Bottomley wrote:
> Anybody who does enforcement will tell you that you begin with first
> hand proof of a violation.  That means obtain the product and make sure
> it's been modified and that a request for corresponding source fails.
> In this case, since I presume Red Hat, as a RTS partner, has a bona fide
> copy of the RTS OS, please verify it does indeed implement or issue the
> commands which are not in the public git repository and that whoever
> owns the copy makes a request for the source code.

It should also be noted (although I have no idea if this is what is
going on here; this is a generalized statement and not one where I
have attempted to apply the facts to the law --- that requires the
expertise of a lawyer, and please let's not play lawyer on LKML)
that it *is* possible for the copyright owner to license the code
under more than once license.  Yes, once the code has been contributed
to a GPL'ed project, and changes have been accepted from other people
which touch said code, things get muddied --- but if someone were to
keep an original copy of the code where they own 100% of all of the
lines of code, and then use that in a proprietary project, that can be
perfectly OK from a copyright perspective.

(I say this speaking as someone who once did exactly this with the
resizing code found in e2fsprogs.  That work was sponsored and was
made possible by the company which wrote Partition Magic, a long time
ago, and the work-for-hire contract I signed with them precisely
spelled out how it could be released for commercial use as well as
under the GPL.  As far as I know they may still be shipping resizing
code for ext2 and ext3 --- but not ext4, since those changes were
contributed later, under a GPL-only license.)

The bottom line is that copyright licensing can get *complicated* and
so before you start flinging about accusations, one would be wise to
be 100% sure of the facts.  You need to make sure that they have
distributed lines of code which came from the *Linux* kernel, and not
just from code which they may have originally contributed to the Linux
kernel.

Best regards,

					- Ted

Re: scsi target, likely GPL violation

[Bradley M. Kuhn]

> On Sun, Nov 11, 2012 at 09:34:16AM +0000, James Bottomley wrote:
>> Anybody who does enforcement will tell you that you begin with first
>> hand proof of a violation.  That means obtain the product and make
>> sure it's been modified and that a request for corresponding source
>> fails.

I agree with James that the text quoted above is generally good advice.
However, sometimes, it's very difficult to follow this advice.  In such
cases, it's worth raising the issue directly with the company to learn
the facts.  The discussion thread here indicates there's a very good
chance that this situation was one of the times when such was necessary.
Thus, Andy's actions seem pretty reasonable to me given the facts that
seemed to be before him when he wrote his first email earlier this week.

Theodore Ts'o wrote at 08:05 (EST):
> this is a generalized statement and not one where I have attempted to
> apply the facts to the law --- that requires the expertise of a
> lawyer, and please let's not play lawyer on LKML

I agree fully with that.  IANAL either. :) I'd add, though, that lawyers
aren't magicians -- they simply have an area of expertise and it's worth
seeking a copyright law specialist in matters related to copyright.

But, such lawyers don't necessarily know better how the GPL works simply
because they passed a bar exam; I'm sure no bar exam that has questions
about the GPL.  For example, many copyright law experts understand how
copyright law works with regard to music but are lost when it comes to
applying it to software.  Also, lawyers disagree, and will often just
take the position their client wants them to take even if it's asinine
and unsupported by the law.  I've seen it happen many times.

> [I]t *is* possible for the copyright owner to license the code under
> more than once license.
...
> The bottom line is that copyright licensing can get *complicated*

I think the second sentence I've quoted above is the most salient.
While Ted's right that it *is* theoretically possible for a copyright
holder to release code under more than one license, that copyright
holder may however be confined to a single license choice due to the
fact that his/her work is derivative of another work.  The detailed
facts of a given situation, plus the license text in GPLv2§2¶2-3 and
GPLv2§7, all become very important in such situations.  In short, the
details always matter in such situations, and it's IMO impossible to
generalize beyond that.

> and so before you start flinging about accusations, one would be wise
> to be 100% sure of the facts.

Andy's initial email ended with the request: "Please explain."  Thus,
Andy's email seemed designed to seek facts, which I think is a
reasonable and good thing to do here.  Meanwhile, the facts *still*
aren't clear here yet.

James wrote:
>> [I'd like to see] a genuine public apology for the libel...
>> Because any further discussion of unsubstantiated allegations of this
>> nature exposes us all to jeopardy of legal sanction.

That's a gross overstatement.  I've seen nothing on this thread
that IMO puts anyone on the hook for libel or legal sanctions.  Can you
show us the statue that you believe was violated here?
-- 
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy

Re: scsi target, likely GPL violation

[James Bottomley]

On Sun, 2012-11-11 at 10:15 -0500, Bradley M. Kuhn wrote:
> James wrote:
> >> [I'd like to see] a genuine public apology for the libel...
> >> Because any further discussion of unsubstantiated allegations of
> this
> >> nature exposes us all to jeopardy of legal sanction.

Hey that's a complete misrepresentation.  I expressed no such opinion in
the email.

What I said was:

> I would really appreciate it if the next email I see from you on this
> subject is either
> 
>      1. Yes, I've got first hand proof of a GPL violation (in which case
>         we'll then move to seeing how we can remedy this) or
>      2. A genuine public apology for the libel, which I'll do my best to
>         prevail on RTS to accept.
> 
> Because any further discussion of unsubstantiated allegations of this
> nature exposes us all to jeopardy of legal sanction.

That asks for moderation until we have a better investigation of the
facts.  It definitely doesn't try to prejudge them or express preference
for a specific outcome as your misquote makes out.

James

Re: scsi target, likely GPL violation

[Alan Cox]

> >      1. Yes, I've got first hand proof of a GPL violation (in which case
> >         we'll then move to seeing how we can remedy this) or
> >      2. A genuine public apology for the libel, which I'll do my best to
> >         prevail on RTS to accept.
> > 
> > Because any further discussion of unsubstantiated allegations of this
> > nature exposes us all to jeopardy of legal sanction.
> 
> That asks for moderation until we have a better investigation of the
> facts.  It definitely doesn't try to prejudge them or express preference
> for a specific outcome as your misquote makes out.

So how can you demand a public apology for libel or instant first hand
proof and now claim you just wanted moderation ? It's not hard to see why
your position was misinterpreted ?

Alan

Re: scsi target, likely GPL violation

[James Bottomley]

On Sun, 2012-11-11 at 18:32 +0000, Alan Cox wrote:
> > >      1. Yes, I've got first hand proof of a GPL violation (in which case
> > >         we'll then move to seeing how we can remedy this) or
> > >      2. A genuine public apology for the libel, which I'll do my best to
> > >         prevail on RTS to accept.
> > > 
> > > Because any further discussion of unsubstantiated allegations of this
> > > nature exposes us all to jeopardy of legal sanction.
> > 
> > That asks for moderation until we have a better investigation of the
> > facts.  It definitely doesn't try to prejudge them or express preference
> > for a specific outcome as your misquote makes out.
> 
> So how can you demand a public apology for libel or instant first hand
> proof and now claim you just wanted moderation ? It's not hard to see why
> your position was misinterpreted ?

So you want me to be less definite to avoid misinterpretation?

OK, here it is:  I'd really appreciate it if there was more rigour
behind the initial investigation before going public with suspicions of
GPL violation.  Based on what I read on the internet is a bit too low a
bar for me, particularly when, I believe, Red Hat has the proprietary
target OS and can check directly.

We now have a whole runaway train of suspicion and lawyer involvement
before anyone has actually confirmed there is a problem.
James

Re: scsi target, likely GPL violation

[Theodore Ts'o]

On Sun, Nov 11, 2012 at 10:15:02AM -0500, Bradley M. Kuhn wrote:
> Andy's initial email ended with the request: "Please explain."  Thus,
> Andy's email seemed designed to seek facts, which I think is a
> reasonable and good thing to do here.  Meanwhile, the facts *still*
> aren't clear here yet.

... and the statement, "When did you stop beating your wife?" is also
a request for information?

							- Ted

Re: scsi target, likely GPL violation

[Alan Cox]

On Mon, 12 Nov 2012 09:08:43 -0500
"Theodore Ts'o" <tytso@mit.edu> wrote:

> On Sun, Nov 11, 2012 at 10:15:02AM -0500, Bradley M. Kuhn wrote:
> > Andy's initial email ended with the request: "Please explain."  Thus,
> > Andy's email seemed designed to seek facts, which I think is a
> > reasonable and good thing to do here.  Meanwhile, the facts *still*
> > aren't clear here yet.
> 
> ... and the statement, "When did you stop beating your wife?" is also
> a request for information?

Ted can you explain what this has to do with the original discussion ?

Re: scsi target, likely GPL violation

[Douglas Gilbert]

On 12-11-11 04:34 AM, James Bottomley wrote:
> On Wed, 2012-11-07 at 08:50 -0800, Andy Grover wrote:
>> Nick,
>>
>> 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.
>>
>> http://www.risingtidesystems.com/storage.html
>> http://www.linux-iscsi.org/wiki/VAAI
>>
>> Private emails to you and RTS CEO Marc Fleischmann have not elicited a
>> useful response.
>>
>> You are subsystem maintainer for the in-kernel SCSI target support
>> (drivers/target/*), and your company appears to be violating the GPL.
>> Please explain.
>
> Can we please cool it with the inflammatory accusations.  Please
> remember that statements which damage or seek to damage the reputation
> of a company amount to libel even under US law ... and using phrases
> like "appears to" doesn't shield you from this.
>
> I also note that whatever their website says RTS OS isn't in VMware's
> certified compatibility list:
>
> http://www.vmware.com/resources/compatibility/pdf/vi_io_guide.pdf
>
> Plus it's a grey area what you actually have to support to make that
> list (especially as XCOPY has now been removed from SBC-3 in favour of
> token copy), so I'd say that the chain of reasoning you've used to come
> up with this hearsay allegation of copyright violation is tenuous at
> best.

The SCSI EXTENDED COPY command (also known by the abbreviation "XCOPY")
is specified in the SPC (SCSI Primary Commands) series of standards, not
the SBC (SCSI Block Commands) series. Yes, it has been enhanced in the
SPC-4 drafts (what you term as "token copy") but as far as I can
determine, still allows for the original EXTENDED COPY command usage.
EXTENDED COPY was first standardized in SPC-2 (ANSI INCITS 351-2001) in
2001. The most recent SPC standard is SPC-3 (ANSI INCITS 408-2005) and
if VMWare don't mention some other SCSI standard or draft, then the
SPC-3 specification of the EXTENDED COPY command should be the
reference. And that is prior to the addition of the "token copy"
functionality.

The latest released version of my sg3_utils package (1.34) contains
a contributed sg_xcopy utility that invokes the SCSI EXTENDED COPY
command. At this time it does not support the recently added "token
copy" functionality.

> Anybody who does enforcement will tell you that you begin with first
> hand proof of a violation.  That means obtain the product and make sure
> it's been modified and that a request for corresponding source fails.
> In this case, since I presume Red Hat, as a RTS partner, has a bona fide
> copy of the RTS OS, please verify it does indeed implement or issue the
> commands which are not in the public git repository and that whoever
> owns the copy makes a request for the source code.
>
> I would really appreciate it if the next email I see from you on this
> subject is either
>
>       1. Yes, I've got first hand proof of a GPL violation (in which case
>          we'll then move to seeing how we can remedy this) or
>       2. A genuine public apology for the libel, which I'll do my best to
>          prevail on RTS to accept.

Sorry to add another category.

Doug Gilbert

> Because any further discussion of unsubstantiated allegations of this
> nature exposes us all to jeopardy of legal sanction.
>
> James