My Visit to SCO
The key to SCO's case against IBM appears to be an expansive notion of derivative works. SCO basically is arguing that any code developed on top of Unix is a derivative work of Unix. It is arguing that the contract with IBM, which SCO now owns, makes clear that any work derivative of Unix must remain confidential.
SCO is using a very extensive notion of derivative work. When I made that objection, SCO said it was for the court to decide. It is true that, so far as I know, no court has ever ruled on whether one piece of software is derivative of another. The question is whether a court would rule that even software entirely developed by IBM, such as JFS, is a derivative work of Unix because it was developed as a component of a Unix system. I think we can all agree that Unix with JFS is a derivative work of Unix; the question is whether JFS by itself is a derivative work.
In general, the issue is where the boundary lies between derivative works and independent works. All programs run on Unix use a Unix API; do they therefore become derivative works? Presumably not. However, when writing a program that runs on Unix, I might look at Unix source code if I have access to it; does that make my program a derivative work? It seems, from SCO's comments, that it might claim this is so.
I am not a lawyer. However, I hope the courts will not accept SCO's broad definition of derivative work. I think it would be dangerous for free software and for software development in general. Software thrives by extending work done by others. If adding a component to an existing piece of software means the component is owned by the owner of the existing software, then few people will add components. That would not be good for anybody.
It's worth noting that if a court does accept such a broad notion of derivative work, it will weaken SCO's defense against the allegations that Linux code was copied into UnixWare. That would seem to put SCO on the horns of a dilemma; I don't know how it plans to resolve it.
I asked a couple of times why SCO was being so secretive about everything. The answers were not particularly convincing. SCO said it was keeping its evidence secret because it is part of a legal action. The evidence will be presented in court. SCO doesn't want it to be tried in public before it is tried in court.
SCO said the Unix code always has been provided under confidentiality agreements, despite its wide distribution. It said that until the parties go to court, it doesn't want the Linux community to remove the code in question. SCO thinks it's more than changing a few lines of code. As noted above, it feels large chunks are derivative. It argued that even a full replacement would be in part based on the prior effort, and thus would itself be derivative, at least under the terms of the IBM contract.
My guess is SCO would prefer not to have to reveal any of its evidence. My guess is it would prefer to settle with IBM and to use the spectre of liability to get licensing revenue from Linux users. After all, in court SCO might lose. The current situation, in which it makes people feel nervous, is better for SCO. I don't know if I'm right, and if I am right I don't know how it will play out.
Chris Sontag appeared confident when he spoke to me. However, my sense is SCO knows it has a weak hand, one it is playing as strongly as it knows how. I expect SCO to keep upping the pressure in the press, to announce a Linux licensing scheme and to hope to start getting more revenue.
IBM is a past master of the IP extortion strategy. For example, see this Forbes article about IBM's shakedown of Sun in Sun's early days. For SCO to attack IBM using IP is somewhat like trying to eat a live tiger.
If IBM starts to feel nervous about this suit, it will unleash its patent portfolio. SCO is certain to be violating a number of IBM patents. Unless some preexisting patent agreement exists between SCO and IBM, SCO surely will lose against IBM's countersuit.
However, for IBM to unleash its patent portfolio against Unix would not be a good thing for free software. After all, Linux probably violates a number of those patents as well. Once the beast is awakened, who knows when, or if, it will go back to sleep. The best hope in such a case is that IBM will recognize the danger of killing the goose with the golden eggs and lay off on its own accord.
It's worth noting that the people running SCO and their lawyers may not appreciate the power of software patents. In my experience, few people outside the profession understand the degree to which every program of any scope violates patents. The software industry today survives only through an unstated agreement not to stir things up too much. We must hope this lawsuit isn't the big stirring spoon.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The Many Paths to a Solution
- Nativ Disc
- Synopsys' Coverity
- Naztech's Roadstar 5 Car Charger
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Glass Padding
- Identity: Our Last Stand
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide