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.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
- RSS Feeds
- It is quiet helping
25 min ago
42 min 4 sec ago
- Reachli - Amplifying your
1 hour 58 min ago
2 hours 47 min ago
- good point!
2 hours 50 min ago
- Varnish works!
2 hours 59 min ago
- Reply to comment | Linux Journal
3 hours 28 min ago
- Reply to comment | Linux Journal
5 hours 54 min ago
- Reply to comment | Linux Journal
9 hours 54 min ago
- Yeah, user namespaces are
11 hours 10 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?