| |||||||||||||
RTS and the GPLRTS and the GPLPosted Nov 15, 2012 7:35 UTC (Thu) by ttonino (subscriber, #4073)Parent article: RTS and the GPL
Would there be someting against also adopting SCST now? Either that, or adding code from other sources to the mainline version of RTS.
Competition would be a much better driving force than lawyers.
But the core of the problem seems to be in the 'single source of code'. The 'derived work' claim seems a bit of a slippery slope to me. Better to fix this through multiple authors - which may bell happen over time as the code is adjusted to match changes in the kernel.
(Log in to post comments)
RTS and the GPL Posted Nov 15, 2012 8:03 UTC (Thu) by airlied (subscriber, #9104) [Link]
what do you mean a slippery slope?
Like if you are going to have an opinion that is wrong, then you could at least clarify it!
the GPL derived work stuff hasn't changed since the GPL was written, so not sure how you think a slope suddenly appeared.
RTS and the GPL Posted Nov 16, 2012 23:46 UTC (Fri) by SLi (subscriber, #53131) [Link] It's not about "the GPL derived work stuff", but the copyright law derived work stuff. No license gets to define derived work (or can apply at all to works that are not derived works, since the author of an original work does not need the permission of the author of anybody else to distribute his original work). That is, whatever FSF or the copyright owner of a work opines about whether, and in which cases, linking constitutes making a derived work is, unfortunately, largely irrelevant. Now, that is certainly not to say that their opinion would be in my opinion bogus. In fact I find the FSF interpretation of copyright law fairly well founded, even after Oracle v. Google, but it is still in reality fairly unsettled territory. And while FSF's FAQ re: derived works may not have changed, there certainly has been some case law development (like Oracle v. Google) about what is a derived work and what is not.
RTS and the GPL Posted Nov 15, 2012 18:59 UTC (Thu) by xxiao (subscriber, #9631) [Link]
I for one fully support SCST as an alternative. Solid, easy to use,etc. I recently did a 10G iSCSI project based on SCST(no LIO) and it performed extremely well.
Tried to use LIO, it's a pain to pull together the kernel, and its user space and all that together(RTS repo keeps changing, document out of date,..). Wish I will never be forced to do that in the future.
RTS and the GPL Posted Nov 15, 2012 19:42 UTC (Thu) by agrover (subscriber, #55381) [Link]
I'm fine with LIO the code. The fact that it's in upstream now makes many integration issues easier, and lets us all work on it to improve it.
I've been working on improving the out-of-box user experience for the LIO user tools as well. With my enhanced version of targetcli (in Fedora 17+, repos on github) configuring a scsi target can be pretty painless. I've done some Youtube screencasts on it, and added a manpage for targetcli.
At this point, I'm definitely not in favor of dumping LIO, but we need to get these license and maintainer potential conflict-of-interest issues straightened out.
(not speaking for my employer)
|
|||||||||||||