UNIX licensees often distributed and used binary products that included code from multiple releases of System V. Novell and its successors required and allowed such licensees to pay only one set of royalties for the use or distribution of such a product. To identify the proper license under which such a product could be used or distributed and to calculate the appropriate royalty payments required for using or distributing such a product, Novell and its successors employed the "one line of code" rule.

Under the "one line of code" rule, Novell and then SCO determined whether there was as little as one line of code from the latest release of System V (including UnixWare) contained in a binary product and then calculated royalty payments for the entire product under that latest license. Novell and then SCO prohibited licensees from parsing out the relative amounts of code from different releases of System V and paying portions of the requisite royalties under multiple System V licenses.

Now let me show you what I found regarding how SCO, Santa Cruz, billed in complex situations, according to what it told the SEC.

Look how Santa Cruz says it itself billed when it sold both UnixWare and OpenServer to the same customer, in its 10K filed with the SEC November 8, 2000:

The Company has sold Unixware and OpenServer products separately and as a result for contracts involving the sale of Unixware and OpenServer which contain multiple obligations (e.g. deliverable and undeliverable products, maintenance and other services), the Company allocates revenue to each component of the contract based on objective evidence of its fair value, which is specific to the Company. The fair value of each element is based on the price sold separately. The Company recognizes revenue allocated to undelivered products when the criteria for product revenue set forth above are met.

So it knew how to allocate, and that is what it did when the situation got complicated. SCOsource was complicated. And there was more than one SCOsource offering, and some of them had nothing to do with UnixWare, as I'll show you. Actually, so far I can't find any SCOsource offering that was about UnixWare.

First, let's think about the one line of UnixWare concept. Remembering that SCO's story is that UnixWare, OpenServer and System V are all the same thing, if one line of code was the rule, every sale of anything would be a UnixWare sale, would it not? And yet, when SCO first offered SCOsource, it was for COFF libraries in Open Server only. It had zero to do with UnixWare. You can see that in this PowerPoint presentation someone at SCO forgot to remove from the Internet, where SCO's Jay Petersen announced and explained SCOsource to resellers in a webinar. Note the first offering and what they had planned for the future:

Slide 5

First Deliverable

* SCO’s UNIX Shared Libraries from for use with Linux

• Already in use among many enterprise customers
  
• Already encouraged by many Linux vendors
  
• Increases the number of UNIX applications available to Linux

Upcoming Plans for SCOsource
SCO System V for Linux

Slide 6

Example: OpenServer Application Environment

OpenServer System Calls
OpenServer Kernel
OpenServer
Application
OpenServer
Shared Libraries

Slide 7

Native Linux Application Environment Linux System Calls
Linux Kernel
Linux
Application
Linux Shared Libraries

Slide 8

Linux for Native and OpenServer Applications

Linux System Calls
Linux Kernel

OpenServer System Calls
Linux ABI

OpenServer
Application
OpenServer
Shared
Libraries

Linux
Application

Linux
Shared
Libraries

Slide 9

UNIX application details: Object File Formats

• There are two object file formats that have been used in UNIX

  • COFF: original format (SVR2, SVR3, SVR4)
  • ELF: improved format introduced around 1990

• Early versions of SCO UNIX (3.2v4.2, OpenDesktop, etc) used COFF only
• OpenServer supports both COFF and ELF
• UnixWare supports only ELF
• Linux native mode is also ELF

Slide 10

UNIX application details: Library Usage

• Libraries must match object file format of application (COFF or ELF)
• ELF libraries are dynamically linked
• COFF libraries may be statically linked
• UNIX applications can be created to use shared system libraries or to incorporate the libraries they need (self-contained)
• Standard practice is to use shared libraries

  • Reduces application size on disk
  • Reduces overall system memory usage
  • Allows library maintenance to be de-coupled from app

Slide 11

SCO System V for Linux Release 1
SCO UNIX Runtime Libraries

• First release includes COFF static shared libraries from OpenServer
• Compatible with SCO UNIX, OpenDesktop, all versions of OpenServer
• Packaged as an rpm installable on Linux
• License required and enforced (at install time) on non-SCO Linux systems

Slide 12

Customer benefits

• Preserves investment in legacy applications

  • Application licenses
  • End user training
  • Applications integration

• Same application runs on UNIX and Linux
• Allows migration of applications to Linux even if source is not available
• Permits movement to Linux without requiring simultaneous upgrade or conversion of apps
• Cost effective evaluation of Linux in production environment

Slide 13

Why start with OpenServer COFF static libraries?

• Most customer interest (some large accounts)
• Linux ABI Project interest/development focussed on SCO COFF applications
• Largest base of applications for SCO platforms
• Oldest legacy applications

  • Probably not the ISV’s latest release
  • Upgrade to Linux versions would be painful
  • Source code may not be available
  • Nonetheless, apps may be firmly entrenched in customers business practice

Slide 14

What about UnixWare Libraries?

• Next step is to investigate value and feasibility
• Customer demand?

  • UnixWare apps are newer, more likely to get ported?
  • More compatible with Linux versions?

• Confirm Linux ABI functionality

  • Not much discussion in Linux ABI project

• UnixWare libraries are a much larger set than the COFF static libraries
• Need to test some applications

Slide 15

Availability & Delivery Customer Pricing: $149 per processor

As you can see, there was at that time no UnixWare at all, not even one line of its code, in the first couple of SCOsource offerings as outlined. The date of the webinar is April of 2003. Note the age of the latest ELF, by the way, was 1990. So any money up to that point, and in fact until the testing the analyzing and deciding got done would be zero lines of UnixWare.

You'll also notice three other things -- first, that back then SCO knew that UnixWare and OpenServer were not the same thing and neither were they identical code. As I showed you in the previous article, they didn't use the same kernel even. And SCO was rather specific about Linux being part of SCOsource. Later it claimed not, but I see the slides itemizing it. And three, SCOsource appears to be indeed about licensing code, specifically named. It was a license to use it. Now, as it turns out, SCO appears to have had no copyrights, and no rights to ABI code as we have explained long ago, and SCO itself told us later that the ABI code it wanted to sue over dated from the BSDi settlement, and that's not theirs. Too old.

You can also see that the first offering was priced way lower than the later SCOsource offerings. That's because they were Not identical offerings. That didn't sell well, but SCO never announced that it was withdrawing the offering or increasing the price. So far, then, we see that at least two SCOsource offerings as presented in this presentation had nothing to do with even one line of UnixWare code. UnixWare was being considered for the future, for reasons that have more to do with money than infringement.

In May of 2003, SCOsource, the next iteration, seems to be only about System V, the source code that IBM licensed in the 1980s from AT&T, as you can see from this SCOsource page, the SCO Letter to Linux Customers:

SCO holds the rights to the UNIX operating system software originally licensed by AT&T to approximately 6,000 companies and institutions worldwide (the “UNIX Licenses”).

Here's a screenshot I took back then:

AT&T did not ever license UnixWare to anyone. Certainly not to IBM. So that SCOsource message to Linux users was all about System V UNIX, the original code that AT&T licensed to IBM. IBM had no UnixWare license from AT&T, so I think it's clear that what Linux users were supposed to buy was protection from infringed code from the AT&T code, not UnixWare. I'm quite sure that SCO can't put System V code into a product, code that is copyrighted to Novell, pre-1995 code, and charge for it because the same code is also in UnixWare simply because SCO put it there too later.

You can see the same thing in the wording of the SCO Intellectual Property Licence for Linux:

Many customers are concerned about using Linux since they have become aware of the allegations that Linux is an unauthorized derivative work of the UNIX® operating system.

Screenshot:

Notice the registered mark, UNIX®? UnixWare is trademarked also. But the offering doesn't say UnixWare®. And the UNIX mark (two of them, actually) was originally owned by AT&T, but it was transferred to the X/Open Company. That isn't talking about UnixWare, then. AT&T didn't license UnixWare. The federal registration symbol indicates with specificity that it is the old AT&T code SCO was offering a SCOsource license to cover. If you go to the USPTO, and search for UNIX, you'll find both. And you'll find that USL had a separate trademark for UNIX SVR4.2, by the way, later abandoned. So, if we apply a one line of UnixWare "rule", there would be zero lines of code covered by that offering, by my reasoning.

Later, after SCO registered copyrights that it turned out it didn't own, except for one, it began to speak about UnixWare and UNIX System V in connection with SCOsource, but that's after Microsoft and Sun took their licenses. And in fact, SCO so far as I can tell had no right to charge for any of this, by the way, since it has distributed Linux under the GPL. I was surprised Novell didn't argue that point. Whatever is in Linux, SCO either put it there or dolled it up and distributed it under the GPL, which makes any money collected money no one should have paid. I suppose Novell wants to be paid something, after all it's been put through, but for historians, at least, all this code is either stuff SCO didn't own at the time (or ever) or which no one had the right to charge for.

And one final proof that SCOsource was predominantly about System V source code dating from AT&T licenses, and not UnixWare that SCO itself wrote. At SCOforum 2003, there was also a presentation, the famous or infamous presentation purporting to show examples of infringed code. Heise published it, and it is still up and you can get a copy from Bruce Peren's site. So let me show you some slides that demonstrate that SCOsource was not principally about UnixWare, and to the extent it was about UnixWare, it had to be pre-1995 System V code. First, let's look at slide 10, and please notice the dates of the copyrights on the allegedly infringed code:

I think it's perfectly clear that when SCO said System V Code there in the header, it meant AT&T code and not UnixWare. Forget for a minute what it turned out to be and focus on what SCO thought it owned and what people had to pay it for. The next slide is slide 16, where SCO claimed the right to control all derivative works of System V:

Except notice that it claims its rights under copyright law. And as it turns out, it had no UNIX System V, the AT&T source code, copyrights. None. And it never claimed UnixWare infringement with any specificity in any court that I know of regarding a UnixWare copyright, so whatever it was offering in SCOsource, it was not about UnixWare, if this was about code, and we've already seen that it was. But, but, but, you say, didn't we learn that Sun, for example, got SCOsource with its UnixWare license agreement? OK. But if they had a license for UnixWare, and the right to open source Solaris, why would it also need a SCOsource license, if SCOsource was about UnixWare?

Take a look at the list of code SCO claimed was infringed, in slide 19:

OK, class. Which of the items on the list are from UnixWare? Remember, we can't count it unless it is something that SCO itself wrote after 1995. See anything there?

So despite there being no UnixWare code that we can find, or SCO either, SCO calls it a license for UnixWare 7.1.3, in slide 26:

Now, why did SCO do that, other than the obvious, that they didn't have to pay any royalties to Novell for UnixWare royalties? I think it's perhaps because they thought they did own the copyrights to System V or at least they were giving us a mighty good imitation of a company that thought it did, or said they did. The copyrights they claimed were infringed were for code that you can find in UnixWare in that it includes a SysV kernel, and because UnixWare was what SCO still sold at the time, they used that name. Assuming they believed they had the copyrights, they would want to name it UnixWare, because that is what they were selling that had System V code in it, the modern code, and you can not sue for infringement easily for damages over infringed code you no longer sell.

So I'm concluding it was misnamed, but for pragmatic reasons, but not because there was any actual UnixWare code of SCO's. They thought they owned both, and they told us that too, which hardly seems a basis for them to keep any of the money, to me anyway. Otherwise, we might reward a ripoff, and I'm pretty sure courts are not set up to reward ripoffs. Judge Kimball struggled to figure out what SCOsource was, and I hope the above makes it clearer, but this is what he concluded, so far:

The parties disputed at trial whether the SCOsource program was primarily concerned with SVRX or with SCO UnixWare. In litigating its claims against IBM, Novell, and a variety of other parties, the only infringing code SCO has identified is SVRX code. SCO's expert witness in the IBM litigation identified only UNIX SVR4 code in Linux. And SCO sued Novell for slander of title because Novell claimed ownership of the SVRX copyrights, not because it claimed ownership to the copyrights in SCO UnixWare. Many contemporaneous press releases, correspondence, and other material introduced at trial describe SCOsource as focused on SVRX infringement in Linux. SCO's internal memoranda and presentations also describe SVRX as the "trunk" from which SCOsource took its value, distinguishing SVRX from "branches" such as SCO UnixWare.

Nonetheless, there was also testimony and evidence at trial demonstrating that SCOsource was not solely focused on SVRX. In January 2003, when SCO formally announced the SCOsource program, SCO was still focused on licensing both SCO UnixWare and Openserver technology. In February 2003, SCO created a "SCO V for Linux Sales Guide." The guide repeatedly refers to SCO's concern that "UnixWare" and "OpenServer" technology had been improperly used in Linux. The guide refers generally to "SCO System V," it did not specifically identify which technology comprised SCO System V. Also, in a December 2002 slide presentation, in describing the proposed "SCO System V for Linux" deliverable, SCO identified "SCO's shared UNIX Libraries from Open Server and UnixWare for use with Linux."

There is competing evidence as to whether in the SCOsource program SCO was attempting to increase revenue based on the SVRX technology or to protect its latest releases of UnixWare and OpenServer from competition with Linux. The court can only conclude that both factors played a role in SCO's determination to pursue the SCOsource licenses.

Whatever it was, it had no rights to protect, as it turns out. SCO argued that if SCO didn't have copyrights to UNIX System V pre-1995, then licensees just got less than they thought. But what if they got nothing at all? Even if someone can scrape through the barrel and find some UnixWare code somewhere, the fact is SVRX code can hardly be deemed "incidental" to UnixWare. If anything, even giving SCO every benefit of every doubt, it's the opposite. It was all about everything but UnixWare. And the SCOsource people paid for was arguably only about code SCO was supposed to pay over all royalties to Novell when it licensed it. Judge Kimball wrote:

Separate from its licensing of products, SCO began entering into SCOsource licensing agreements that were unique in that they did not involve product. Instead, these license agreements were waivers and releases of conduct based on the buyer's use of Linux.

They were about code, as far as Linux end users were concerned. In fact, Darl McBride told the media that if Linux folks stripped out the infringed code, they were free as a bird from any claim from SCO. Kimball continues:

Although Novell asserts that these provisions should be viewed as a license because a license insulates a party from liability, the release terms of the SCOsource agreements, including Section 2 of the Microsoft Agreement and Section 12 of the 2003 Sun Agreement, are not licenses to product. Unlike the licenses to products included under the APA, these releases are not royalty-bearing SVRX Licenses. SVRX Licenses involved in the APA gave licensees rights to use and modify SVRX code to create royalty-bearing UNIX derivatives. SCOsource licenses did not grant a right to use or modify any UNIX source code to create such derivatives. SCOsource agreements did not give any licensee the right to use any UNIX IP apart from binary code in Linux. The agreements are only releases of claims that SCO was entitled to bring.

Well. I'd argue with the "entitled to bring" part. After all, Linux end users all have the GPL license, which gives them the right to use all the GPL code freely. And SCO had no copyrights to any code it has claimed was infringed. I can't speak to the Microsoft and Sun licenses, because they are not public, but the other licenses were quite different. And folks had to pay for each CPU, just like if you bought a binary copy of UnixWare, which you couldn't modify either. Yet, those folks who got boxed versions of UnixWare certainly had a license, not a release of claims. SCO was structuring the offering to make it look like UnixWare was part of the problem, and they sure talked about UnixWare a lot, but where is there any such evidence? SCO said a lot of things in press releases and teleconferences and interviews and speeches. But in court, they said very little to match. Surely they don't get the right to scam people without evidence, and in the face of the GPL? I find only to the contrary, that SCOsource was not about post-1995 UnixWare, not even with respect to public statements. And that's been true since 2003. Just saying it in 2008 doesn't make it so, particularly if Novell is right and it was all a scam to begin with.

Since that has been stated in court, shouldn't SCO have to at least show some UnixWare code? No. Really.

Finally, there is evidence that SCO itself thought that SCOsource was about code under the APA, code it should pay Novell for. Remember that detail? It's mentioned in the order, that when SCO approached Novell asking it to join it in going after Linux, it tried to tempt Novell by saying it would increase their royalties. Novell got paid by SCO for SVRX royalties. Can it get any clearer than that? Only after Novell said no did it morph into what I view as a pretense about being about UnixWare. Perhaps SCO wasn't desirous of sharing? If they called it a UnixWare license, regardless of what it really was, then they wouldn't have to.

Of course, this is just me. Look at the evidence for yourself. You can draw your own conclusions, as have I.