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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Returning Values from Bash Functions
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Managing Linux Using Puppet
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