Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
On Mon, 12 Nov 2012 09:08:43 -0500 Theodore Ts'o ty...@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 ? -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
On Sun, Nov 11, 2012 at 09:34:16AM +, 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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
On Sun, Nov 11, 2012 at 09:34:16AM +, 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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
Hi Lawrence, On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen lro...@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.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
On Mon, Nov 12, 2012 at 8:41 AM, Julian Calaby julian.cal...@gmail.com wrote: Hi Lawrence, On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen lro...@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. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
On Fri, 09 Nov 2012 11:52:19 -0800 Andy Grover agro...@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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
On 11/07/2012 05:02 PM, Jon Mason wrote: On Wed, Nov 7, 2012 at 9:50 AM, Andy Grover agro...@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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
...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. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
On Wed, Nov 7, 2012 at 9:50 AM, Andy Grover agro...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi target, likely GPL violation
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
