Controversy in the kernel

Referring to this article, it appears that there is some issue with an important subsystem in the Linux kernel. The SCSI target code, specifically the new implementation pulled in by James Bottomley is the LIO framework based upon work of Nicolas Bellinger and Rising Tide Systems. This was chosen over the SCST implementation, which continues to soldier on. We did have a dog in that race, and would have preferred to have seen SCST included due to our familiarity with it. In both cases, there are companies behind the targets. In both cases, they have “proprietary” access, and I’ve not been quite sure what value this access provides apart from early access to patches, and some additional configuration code, largely which we can ignore as we have our own target management code that manipulates the underlying architecture. Briefly, SCST isn’t perfect … actually there are a number of things about it that are positively maddening, and I’ve largely stopped trying to get some things fixed (target ACLs that work the way they are supposed to … as they do in IETD and other codes). There are some massive gaps and missing features, as the leadership of that group doesn’t see the value in what … well … pretty much the rest of the industry/users see value in (iSER target) as they have a “competing” technology (SRP target) which they believe (incorrectly) is the preferred mechanism. Then there is the target updating mechanism, which forces you to turn off and on ALL targets to add or remove a target. Which happens to piss off a fairly large number of initiators, and in the case of SRP, we can reliably crash the target machine by doing this. So this is a win … how? This is not a blast at SCST, we work with them, occasionally contribute control scripts. This isn’t familiarity breeding contempt … we’ve worked with SCST for quite a number of years, and we know its warts. Our kernel has LIO capability built in as well. Our plan has been to slowly add support to our management tool/api, so we can control both with a single interface. I don’t like the concept of two different SCSI targets in the kernel, but neither one addresses everything, and each has their own warts/issues. But this isn’t about LIO vs SCST. That issue has been settled. The issue is, really, about whether or not RTS, the folks behind LIO, have been violating the GPL. This is where stuff gets sticky. I won’t weigh in on whether or not a violation has occurred. That’s not the real issue. Its the perception of a violation that is the issue. I’ve spoken with Marc and Nicolas (via email) over LIO, and it looks to be a good framework. Marc did speak about the value add for the commercial bits (as the SCST team did with me as well). I agree there is value in these tools, and the added commercial bits. However, we like a strictly open kernel and module set, and toolchain, … whenever possible. I understand the desire for open-core for business model bits. I understand the desire to keep some of it back for proprietary customers. But I think there has been some distinctive lack of clarity and transparency, which opened up the possibility of consideration of GPL violation, irrespective of any likely or alleged violation. Its compounded, to a degree, by the fact that the subsystem maintainer for LIO has an economic interest in making sure his companies version is “superior” in some respects. Artificial scarcity is the M.O. of closed source software vendors, and you need a hook, a reason, why yours is better than the “free” one. This might be artful illusion, as its based upon and linked to GPL code, and may be, despite any discussion to the contrary, completely GPL whether or not RTS likes it (or not). Had they re-implemented their modules for *BSD, chances are their argument would be completely valid, and there would be nothing the kernel community could do. However, it appears that the modules in question are closed source, non-GPL being linked to a GPL Linux kernel, branded as RTS OS, built atop CentOS 6.3. Um … yeah. I don’t consider that terribly good … doesn’t help the argument. And it pisses other kernel folks off. Does it in a way that I’d expect them to take effectively punitive action against at some point, not unlike what goes on with NVidia drivers. So there’s a controversy. And there is, at least on the exterior, a very obvious conflict of interest going on here. I hope it gets resolved, but somehow, seeing lawyers weigh in on public mailing lists … leads me to think that this is going in the ugly direction, unless there is further private face to face or phone communication and de-escalation.