My Visit to SCO
This essay describes my visit to SCO on June 17, 2003, to discuss SCO's claim that Linux infringes on its intellectual property rights. I visited the SCO office in Lindon, Utah, for about one hour. I spoke with Chris Sontag, Senior Vice President, Operating Systems Division, and with Blake Stowell, Director of Public Relations. In order to speak with them, I signed a non-disclosure agreement.
The short version of this essay is SCO's claims are unproven, as I expected would be the case before I went. The amount of information SCO was willing to show me was extremely limited, and it did not by itself prove that SCO's claims were true nor that its claims were false.
I won't give the full background here, as it is well covered elsewhere, such as on Karsten Self's page. The short version, as of June 17, 2003, is SCO has sued IBM, alleging that IBM took work that was the intellectual property of SCO and incorporated it into Linux (when I say "Linux" in this essay, I mean specifically the Linux kernel, not a complete distribution). SCO is the current owner of Unix, which originally was developed by AT&T. SCO, which used to be named Caldera, purchased the rights to Unix from a different company named SCO, which has since changed its name to Tarantella. Along with Unix, SCO purchased a number of contractual agreements, including one with IBM. SCO is alleging that IBM has violated that contract.
SCO also sent a letter to some 1,500 commercial users of Linux distributions, warning them that Linux may be an unauthorized derivative of code owned by SCO. That is, SCO alleges that Linux actually to some extent is owned by SCO and may not be distributed under the GPL. The letter further claims that users of Linux may have legal liability because of this.
SCO said it would provide evidence that Linux is a derivative of Unix to independent analysts. With the help of Don Marti, Editor in Chief of Linux Journal, I contacted SCO and offered to be one of those analysts. SCO agreed, subject to my signing the NDA and traveling to its headquarters in Lindon, Utah.
SCO's legal case is complicated by the fact that when SCO was named Caldera it was itself a Linux distributor, and it may have distributed, under the GPL, the code which it now claims to own. It also complicated by allegations that SCO has incorporated Linux code under the GPL into UnixWare. These issues may indeed cause SCO's legal case to founder, but not in the way I would prefer it to founder.
I took the trouble to visit SCO because I care about what happens to free software in general and Linux in particular. The SCO claims have put a cloud over Linux. I have heard speculation from business acquaintances that the free versions of Linux will be shunned by corporate IT users, who will be unwilling to take the legal risk of using it. I don't think that would be good for Linux or for free software.
I remember the AT&T case against BSDI and the University of California, which arguably stalled BSD development for a few years. Indeed, it arguably was the root cause of Linux's popularity, because Linux development was not stalled. SCO's case against IBM is in some ways a reprisal of the AT&T case, and I fear that it has a similar potential to stall Linux development.
SCO was willing to speak only with people who signed a Draconian non-disclosure agreement (NDA), one which essentially permitted SCO to declare any information it provided to be confidential, regardless of whether the signer already knew it, and which offered no circumstances under which that information could be revealed. Most Linux developers are unable to sign such an NDA, as it easily could prevent them from ever again working on the kernel. Similarly, employees of any company that works with Linux cannot sign such an NDA.
I have never contributed to the Linux kernel myself. However, I have worked with free software for over 10 years, including acting as a maintainer for projects owned by the Free Software Foundation. I have plenty of personal knowledge of how free software development works. I currently am not employed by anybody, but simply working as a contractor on work not related to Linux.
Thus, I felt going in that I was in a good position to sign the NDA and to analyze the information that SCO presented to me. While SCO easily could have made it impossible for me to contribute to the Linux kernel, it had no reason to do so. In any case, I had no particular plans to do any kernel work.
Before going to meet SCO, I asked three times if it would be willing to change the NDA. I suggested that SCO should change the NDA to permit the disclosure of information when legally required by a court and to permit the disclosure of information when SCO specifically agrees to it. I also suggested the NDA should be changed so that information I already knew before meeting could not be treated confidential. The only response I received was SCO forwarded my suggestions to its counsel.
As it turned out, SCO actually showed me very little confidential information.
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
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