linux-kernel - Re: scsi target, likely GPL violation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 11 Nov 2012 19:39:39 -0500
From:	Douglas Gilbert <dgilbert@...erlog.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Andy Grover <agrover@...hat.com>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	target-devel <target-devel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Marc Fleischmann <mwf@...ingtidesystems.com>,
	Nicholas Bellinger <nab@...ingtidesystems.com>
Subject: Re: scsi target, likely GPL violation

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/