My Visit to SCO
Here, we come to the meat of the issue: has code clearly derived from Unix been incorporated into Linux? Unfortunately, SCO was willing to show me only one example. I was shown a source file Sontag said was from SVR4, which was compared to a source file from Linux. The identical portions of the code were highlighted. There were indeed substantial similarities in the code: very similar comment text, the same variable names, the same algorithm. There also were some differences, but it seemed quite plausible that both pieces of code came from the same source.
SCO refused to show me the revision history of the Unix file. I pointed out this made it impossible to judge the order of derivation; SCO agreed, and said it was a matter of discovery for the court case. SCO said it is confident the code had not appeared in BSD and was developed internally at AT&T and successors.
The NDA I signed prohibits me from saying anything that would help identify the code in question or anything about how it got into Linux (I discuss the issue of secrecy further below). SCO did not permit me to type the code, but I was told the Linux file name, and I have a good memory for such things in any case.
Here is what I think I can say about the code I saw. The code is fairly trivial--the kind of stuff I wrote in school. The similar portions of the code were some 80 lines or so. Looking around the Net, I found close variants of the code, with the same comments and variable names, in sources other than Linux distributions. The code is not in a central part of the Linux kernel. The code does not appear to have been contributed to Linux by SCO or Caldera. The code exists in current versions of the Linux kernel.
Also, oddly, my recollection of the code SCO showed me is not precisely the same as any version I found in any Linux distribution. The differences were in parts of the code that were different from the Unix code. The copyright statement at the top of the file also appeared to be different, though probably not consequentially. However, because I was not permitted actually to type the code, my memory could be playing tricks on me here.
If this is SCO's only example of Unix code appearing in Linux, I very much doubt there is any real legal liability for Linux users. If the code is indeed derived from Unix, which is unproven, it is roughly equivalent to typing in some code from a basic computer programming text without permission. While I hesitate to predict the actions of the legal system, it is very difficult for me to believe that any judge actually would award damages on the basis of this code.
Naturally, SCO says many other examples exist, and it has found at least 10 to 20 specific examples of direct copying. SCO said there was much more derivative code. It claims there are cases in which copied code intentionally was obfuscated and rearranged to hide its origin. I commented I felt such a scenario would be difficult to prove, and indeed I sincerely doubt that anybody would bother.
SCO said that only in the last month or two has it really started analyzing Linux kernels for cases of copying. SCO claims it steadily is finding more cases and that all of this will come out in court.
It's difficult to know what to make of this type of argument. SCO showed me something that appears suggestive but that also apparently is inconsequential. SCO claims to have much more evidence, which I was not shown. It's tempting to conclude this is SCO's best case and it has no strong evidence. After all, if SCO can make its case to somebody like me, then it is in a stronger position for extracting revenue by licensing Linux to customers who are scared of lawsuits. But SCO may have other plans.
I admit that SCO's example unsettled me by what it implies. Although in itself trivial, it does suggest that some Linux contributors may have been careless about copyright infringement. That is unfortunate.
After the presentation was over, I asked a few questions. I asked SCO when it expected to go to court. The answer was document discovery and depositions have begun. No court dates are set.
I asked why SCO sent letters to commercial users of Linux distributions, but I was not given a satisfactory answer. SCO said the letter was to make Linux users aware that it believes Linux is tainted and contains unauthorized intellectual property. The letter was to tell the Linux users they may have some liability and should seek advice from counsel. SCO said Linux users then could go through the same process of discovery that SCO presently is going through--but, of course, the users can't, because they don't have the Unix sources. My guess is the letters were to set themselves up for Linux licensing.
I asked whether SCO has any plans to license the Unix code to Linux users, to remove the liability. SCO said it has no current program. It hopes to come up with something in which noncommercial use and educational use would be free, but for commercial use it wants some remuneration. SCO said it hadn't come up with a plan because it still is trying to figure out the scale of the problem. SCO hopes to have some sort of solution by as early as July.
SCO commented that Linux has no mechanism that ensures ownership of the IP which goes into it. It said most Linux developers are honorable, but some commercial entities are bending the rules for their own benefit.
I asked about the lawsuit between AT&T and BSDI. That lawsuit was not ended by a judgment, it was settled between the parties, and the settlement was in large part confidential. SCO, which I presume is the legal inheritor of the AT&T side of the settlement, claims some aspects of the settlement have not been enforced but would not describe it further. SCO has not yet looked into whether, in its opinion, the free BSDs legally are derivative of the Unix sources. I assume if SCO can get a handle on the Linux situation, it'll go after the free BSDs next.
I paused for a while, trying to think of my next question, and Chris Sontag said he had another meeting to attend and left.
Blake Stowell asked me what I would do if I owned some proprietary code, and it was being used by other people without permission. I said that Unix had been widely distributed for many years, had been published in books and was not, after all, actually written by anybody at SCO. I said I didn't think that was easily compared to more conventional situations. Incidentally, Blake Stowell worked at Lineo and joined Caldera in 2001. He agreed that the company had radically changed since that time.
That was the end of the meeting. The rest of this essay discusses a few relevant topics in more detail.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
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