Red Hat Developer Demands Competitor's Source Code 394
sfcrazy writes "A very serious argument erupted on the Linux kernel mailing list when Andy Grover, a Red Hat SCSI target engineer, requested that Nicholas A. Bellinger, the Linux SCSI target maintainer, provide proof of non-infringement of the GPL. Nick is developer at Rising Tide Systems, a Red Hat competitor, and a maker of advanced SCSI storage systems. Nick's company recently produced a groundbreaking technology involving advanced SCSI commands which will give Rising Tide Systems a lead in producing SCSI storage systems. Now, RTS is blocking Red Hat from getting access to that code as it's proprietary. What's uncertain is whether RTS' code is covered by GPL or not — if it is then Red Hat has all the rights to get access to it and it's a serious GPL violation."
is it shipping to customers ? (Score:3, Insightful)
thats what makes the difference...
if its just something he is developing at the moment AFAIK then he does not have to release it until he gives it to others...
Epic grammar fail (Score:5, Insightful)
Now, RTS is blocking Red Hat for getting access to that code as its proprietary.
What is this I don't even
Comment removed (Score:5, Insightful)
Red Hat can surely do better than speculate... (Score:4, Insightful)
From the LKML [lkml.org]
I've heard such statements before. They remind me of SCO and their lawyers back in the last decade, when they accused Linux of containing copyrighted source code.
Result: Not good. I hope it isn't the case for Red Hat.
Re:Moral: Never look at, much less touch, GPL code (Score:5, Insightful)
The same issue can occur with commercial code too.
It's basically a risk for any non-completely-free licence, including explicitly non-paid-for ones.
You can be put in exactly the same position by being accused by a commercial vendor of using their code.
And the solution for the vendor is the same - sue for copyright infringement, and it'll come out if the code is infringing or not.
Re:Moral: Never look at, much less touch, GPL code (Score:4, Insightful)
Are there companies out there leaving their copyrighted code on the net just trying to get you to fix it for them for free?
It's not exactly the same thing. Also note: This is code they contributed to Linux. They retain rights and can dual license.
With commercial code I sign an explicit non-compete, have no doubt who owns the code and (wait for it) get paid.
Re:is it shipping to customers ? (Score:4, Insightful)
The version we use in RTS OS is a different, proprietary version, which we also wrote ourselves.
This is probably what Red Hat thinks needs to be proven.
Pure hypothetical in contradiction of RTS's statement follows. Entirely fictional. However, I'm betting this is what Red Hat is worried about.
RTS writes Linux SCSI core driver. Contributors improve it. RTS backports Linux SCSI core driver, including contributed improvements, to RTS OS and then closes it off as proprietary.
This scenario would be a GPL infringement. This is probably what Red Hat suspects. This is contrary to RTS' claim, which is: The RTS OS codebase is clean, and is not a derivative product of the GPLed Linux codebase (with other contributions).
But I agree... the burden is on Red Hat to prove it. Demanding a code audit of a proprietary software codebase just because you suspect non-compliant backporting doesn't sound like it would work. In the meanwhile, they've poisoned relationships with a major code contributor. I hope it was worth it.
Re:is it shipping to customers ? (Score:4, Insightful)
The comment would be purely theoretical problem.
Unless it can be seen in the binary, RTS will tell anyone involved: 'No, you cannot see our source. You've made a serious public accusation. Do you own your house? Any other assets? What was your net worth prior to today?'
Re:Let's not be so un thankfull (Score:2, Insightful)
Re:Guilty until proven innocent? (Score:4, Insightful)
This is a no lose political play by RedHat; they never expected there was a real licensing violation. Consider the two outcomes here:
-Rising Tide Systems says that it developed their EXTENDED_COPY and COMPARE_AND_WRITE commands under a different license, walled off from the main code they contributed to the kernel under the GPL. (That's what they've done now). Then RedHat's sales position is that people who buy Rising Tide's Linux are getting a licensed closed-source product. It is guaranteed not to integrate smoothly with the *real* Linux kernel because of the architecture needed to keep it licensed differently, it's not getting community review for features and security issues, and if Rising Tide goes out of business their customers are screwed--good old fashioned vendor lock-in.
-Rising Tide rolls over and releases their code into the mainline kernel. Now RedHat benefits from it being available too.
RedHat makes much of its money from companies that are moving to open-source because they are sick of the downsides of commercial software, which go from quality issues to vendor lock-in. They're compelling Rising Tide to either give away somethings they're trying to keep closed, or to shame themselves by admitting they're not really an open-source team player. RedHat can launch that sort of acusation safely because they are operating very transparently. We know that companies are not locked in to RedHat from how many clones of it exist. When CentOS and Scientific Linux work, clearly RedHat is sharing all the important parts. And if you've made that part of your competing position, preaching down to people who are not sharing as being sellers of inferior products is very easy to do.
It isn't clear cut. (Score:5, Insightful)
First off this is nothing like the Oracle case. That was a case about reimplementing APIs, and has nothing to do with linking against someone-else's code that provides APIs. Secondly, it is a stretch to say that the RTS SCSI target is just including APIs. It is using all sorts of internal kernel functions that go far beyond what most reasonable programmers would consider to be an API to the kernel. If you interpret things that liberally, then any proprietary modifications to a GPL application would be allowed by just bundling up the list of functions you happen to use and calling it an API.
Re:Let's not be so un thankfull (Score:4, Insightful)
weeeeell... +0.5 since it was a collaboration with IBM. :)
Comment removed (Score:2, Insightful)
This is why the GPL should die (Score:2, Insightful)
and be replaced by the BSD license. What RH is doing is sickening and as another pointed out, very much SCO like. And lets not pretend that there is no software released under the BSD or similar license either (see PostgreSQL for one). While I loved Slackware for over a decade, one of the reasons I switched to FreeBSD was the GPL (and the legions of Stallman). It will be a very happy day when FreeBSD is rid of the last of remains of GPL.
Re:Should be easy to resolve. (Score:5, Insightful)
Yup, and if found innocent they'd countersue for defamation and slander. You can't just go around accusing people of committing a crime without proof.
Can you prove to me that you didn't beat your wife this morning? How about we find a third party and have them set up cameras and monitor you 24x7 at home for a few weeks just to be sure?
You can't go around accusing people without proof and expect them to jump through hoops to prove their innocence.
Re:is it shipping to customers ? (Score:4, Insightful)
But there is no evidence that step three happened. It is mere speculation that it might have happened.
Re:is it shipping to customers ? (Score:5, Insightful)
Besides, its only the back-flow of contributed changes that would make the GPL apply to their original code, and perhaps not even that
would be sufficient. Does a contributed two line patch drag the entire original proprietary source into the GPL?
Not quite - if the proprietary module links into the Linux subsystems, as seems extremely likely, then the whole module likely becomes a derivative work, the exact details become very important in that case. The nVidia drivers walk this line, which is why you don't see them integrated into with any Linux distro - doing so would tilt the balance towards the derivative work interpretation and is likely to elicit a cease-and-desist letter.
Re:is it shipping to customers ? (Score:4, Insightful)
I think you got the who needs evidence switched. They didn't release any evidence it wasn't because they never accused anyone or anything. It's the onus on the accuser to prove the cause.
It's not guilt until proven innocent.
Re:Let's not be so un thankfull (Score:4, Insightful)
For interactive software? Everything.
For batch software? Nothing.
Re:It isn't clear cut. (Score:4, Insightful)
First off this is nothing like the Oracle case. That was a case about reimplementing APIs, and has nothing to do with linking against someone-else's code that provides APIs.
Actually, the Oracle case is pretty relevant. Oracle's argument was that the API itself of java - the structure, sequence and organization of it - was copyrightable, not just the code that implemented the API. Google clean room re-implemented the code that made up the API, but kept much of the structure of the API itself. The court decided that the API wasn't copyrightable, a good decision. Ergo, anything that merely USES an API cannot be a derivative work of the code that implements the API, as the API itself isn't copyrightable - if that wasn't the case, that would open up a really huge can of worms. In effect, the API becomes a firewall between two differently licenced bits of code. Which is of course what nvidia use for their binary blobs, for example.
Anyway, even if we assume the scsi target code in question static links to code beyond the API and does thus become a derivative work, then the upshot would be the code in the kernel... would have to be under the GPL v2. Which it already is. So it's rather a moot point.
As long as the code in RTS' private repository has no back-ported GPL code from the kernel, i.e. they haven't imported 3rd party written GPL covered patches into
their own private code, then they can dual licence their private version however they like. Putting a version of their scsi target software into the kernel under the GPL makes no impact whatsoever on their copyright of said code, even if it is subsequently modified in the GPL kernel version by others. They can't of course fork the GPL version with others contributions and take it private without every contributors permission; but that's not what they're doing by the sounds of it.
As long as the code-flow was one-way - i.e. private to GPL, not two-way including GPL into private, they can write performance improvements to their commercially licenced one all day long and not port them to the GPL version in the kernel as much as they like.
And so what, anyway? Linux gets a decent SCSI target (I've used it a few times in production; it does what it says on the tin) it wouldn't otherwise have; and RTS have a commercial product for those wanting a higher performance product for high-end usage, thus allowing them to actually stay in business. Most code in the kernel, and the gnu/linux platform comes from individuals working for or sponsored by companies; those companies make money by various means, and that's what pays for the coders. Hobbyist coders do produce quite a bit of course, but linux wouldn't be where it is without commercial support.
And I've just realised why the API argument is important. If using the API makes code a derivative work, then the commercial version of the SCSI target module using the GPL kernel APIs would also have be GPL licenced. But given the Oracle-google case, that seems a hell of a reach, and certainly APIs were not considered to create derivative works before anyway - that's rather the point of an API, to allow two pieces of code to communicate without getting up in each other's business...
Re:Bruce Perens on Red Hat (Score:4, Insightful)
Red Hat contributes heavily to Linux, but they use tons of code which have been written by people who haven't been paid by them & they make money off it. But they don't want Oracle to make money off code Red Hat wrote. So they make it difficult for Oracle. What if the millions of people who wrote free Linux code had made it difficult for Red Hat in the first place.