From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753797Ab2KKWmO (ORCPT ); Sun, 11 Nov 2012 17:42:14 -0500 Received: from mail-ee0-f46.google.com ([74.125.83.46]:56254 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752637Ab2KKWmM (ORCPT ); Sun, 11 Nov 2012 17:42:12 -0500 MIME-Version: 1.0 In-Reply-To: <14c701cdc059$d6fd28b0$84f77a10$@rosenlaw.com> References: <509A915B.30105@redhat.com> <509B117A.6070708@genband.com> <509BE460.6010404@redhat.com> <1352405111.29589.476.camel@haakon2.linux-iscsi.org> <509C22B2.8010600@redhat.com> <1352426896.29589.512.camel@haakon2.linux-iscsi.org> <20121109110336.41833034@pyramind.ukuu.org.uk> <14c701cdc059$d6fd28b0$84f77a10$@rosenlaw.com> From: Julian Calaby Date: Mon, 12 Nov 2012 09:41:49 +1100 Message-ID: Subject: Re: scsi target, likely GPL violation To: lrosen@rosenlaw.com Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, kcopenhaver@choate.com, Richard Fontana , Marc Fleischmann , Nicholas Bellinger , alan@lxorguk.ukuu.org.uk, agrover@redhat.com, bkuhn@sfconservancy.org, tytso@mit.edu Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lawrence, On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen 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/