On Mon, 2003-08-25 at 23:30, Paul Tansom wrote:
Tell me about it :o)
Well it's like this, after a short spell working commercially with free software I've ended up starting my own business,... :-)
... as a comedian? :o)
A fair point if Caldera(SCO) were simply distributing the code with an amount of customisation to the distribution. In this case they were actually involved with the kernel development and as such had a close working knowledge of both the code and the process. (*)
The above doesn't sit well with....
I which case it would be down to the UnixWare group to look at the Linux code. It's not as if they wouldn't have had access to it. It would be down to the upper management to ensure that they were properly briefed on the implications of running the two groups - they were certainly aware enough to separate the divisions.
... since you are saying that their Linux developers should be spotting the stolen code, but that the UnixWare team should be the ones reviewing Linux. Doing either/both would be suicidal for SCO, so I don't agree with either scenario. IBM are in the same position (developing Linux and AIX), as are Sun (I would guess), HP (to an extent) and probably all the guys doing embedded work.
If you have one team working on a proprietary kernel and one on a free software kernel, I don't see how the two can be allowed to mix, and one to review the code from the other. I don't think any companies mentioned previously would countenance doing it, either.
If the UnixWare chaps were reading the Linux code, they would have to be doing this regularly to pick up any copying (given the vast size of the code). To do this well, they would become immersed in the code to a sufficient degree that they may well copy it into UnixWare unthinkingly. SCO would never allow that, neither would any other developer. There is no onus on them whatsoever to do it. If they keep things separate themselves, they have no reason to look for cross-pollenation.
I will agree that it is an extremely difficult situation for a company to be in. If a third party takes code from one group (UnixWare) and puts it into code being worked on by the other group (Linux) then the Linux group will have no way of realising this. The action should then be against the third party though.
That's exactly what's happening. They're not taking action against users. I also think SCO's licensing system is subtley clever: they are ensuring it continues to be infringment to run Linux, but not to use it (if you have a SCO licence). This doesn't conflict with the GPL, AFAIK (in terms of use of the software).
The problem they have with their licensing system is that it would be impossible to reconcile the conflict with the GPL for distribution going forwards, but I don't think they would care about that: they're going after the Linux distributors, so blocking distribution would suit them fine. I think it's fairly clear that if they did find Linux 2.4+ to be infringing, then we would pretty much be back to Linux 2.2 - I don't think the subsequent code could be salvaged, except maybe device drivers, without a lot of work, which would involve starting with 2.2 and pulling in newer stuff.
I'm wavering a bit on my stance having written this in that if SCO can prove that none of their programmers had any involvement whatsoever with the sections of the Linux kernel containing the offending code then they have not made it available under the GPL license. If on the other hand they have hand involvement with that code then SCO, however unwittingly, have released the code under the GPL license.
How can you release something unwittingly? Only if they released the actual code in question, would they be doing that. I would go back to my previous example of stolen video recorder.
I just don't see how they could be expected to detect the code, if it was indeed copied from Unix. Their Linux programmers wouldn't know what it looked like, even if they came across it.
If SCO had redistributed their Unix code as free-as-in-beer proprietary closed-source software, what would happen in your scenario? Are they still liable, even though they cannot actually see the source code and verify it? Or, are they not liable? If they are not, then you're making proprietary software much, much easier to deal with. Free software would become even more distasteful.
From reading my above comments the answer would be clear to this - no they would not be liable since they have not worked with the source code. If they had been involved with the code of the closed source software then yes they would have released it under the license used. There would be less of an issue here though, as the code would still be closed source so the license would only apply to the binary and not the source code.
Less of an issue how? Their code has still been nicked. Source and binary are not licensed differently (in fact, they might fall under 'translations' - not sure).
It seems to be that you are setting a barrier of detection: that there are certain scenarios in which you expect them to detect the stolen code, and others in which you don't. Quite apart from the fact that the hurdle you set is arbitrary, I also don't see that it is relevant. If someone steals something from you, it remains stolen under all circumstances (statutes of limitations not withstanding). The flagrancy of the theft doesn't matter.
I wouldn't say distasteful, in fact I don't follow the 'more distasteful'
Distasteful to companies who are already scared of the GPL. If the result of this case is that your proprietary code can be lost as a result of someone else stealing it and publishing it, then that will make Free Software verboten in a huge number of companies. It would perpetuate this 'GPL IP virus' meme; to a horrible extent. The only 'crime' SCO would be guilty of - in your world - is not detecting the theft soon enough. But, they have lost their 'valuable' proprietary code. If other companies see that happen, that would serve to kill off a huge amount of development that could otherwise happen. I can't think of many worse scenarios.
Cheers,
Alex.