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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- BitTorrent Inc.'s Sync
- The Death of RoboVM
- The Humble Hacker?
- Open-Source Project Secretly Funded by CIA
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- New Container Image Standard Promises More Portable Apps
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The US Government and Open-Source Software
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide