decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Straight From The Horse's Mouth: Was SCOsource about UnixWare?
Tuesday, March 11 2008 @ 09:57 PM EDT

SCO's new position is that UnixWare is just another interchangeable name for UNIX and that SCOsource was about UnixWare, not Unix System V, but here's some more evidence that they are not the same thing and that SCOsource was primarily about UNIX System V. In this article, I'll restrict myself to things SCOfolk used to say about what SCOsource was about. As you will see, before the Honorable Dale Kimball ruled in August that the UNIX copyrights didn't pass from Novell to SCO, SCO said SCOsource was about UNIX System V source code. Now that it's time to pay Novell for those System V licenses, SCO says they were really UnixWare licenses.

As I told you in the previous article, I didn't have enough space to say everything in rebuttal in just that one article, and I'm still not done with this one.

Let's start with a slide from Darl McBride's keynote at SCOforum 2004, shall we? Here's where he lays out what he claimed SCO owned:

See the emphasis on Unix System V? Does he even mention UnixWare copyrights?

And here's a bit of an interview with Darl McBride by Robert McMillan at SCOforum 2004:

IDGNS: Why did SCO recently decide to file a trademark claim for AT&T Corp.'s old Unix subsidiary, Unix Systems Laboratories (USL)?

McBride: There are a couple of reasons around going back to the USL part of the business. It's really a situation of going back to the future, if you will. We look into the future and fully expect that we're going to have some sort of a win against IBM in the courtroom. We know we've got another year and a quarter before we end up in front of a jury trial here in Utah, but we are preparing ourselves right now that as we move forward and as we do get justice in the courtrooms, what is our business going to look like?

Part of what we're modeling right now is a return to our licensing business. Last year, we had a couple of good licensing deals in the form of Sun (Microsystems Inc.) and Microsoft (Corp.) You're now hearing those guys talking about incorporating the Unix technology into Longhorn. Sun's been able to do things with it. We have other licensees that are off doing things with the core Unix System V technology.

We think that there's a very bright future in the company to return to the model that we had in the past with Unix Systems Laboratories.

IDGNS: Would that be a division within your company, or a separate company that did this licensing?

McBride: Both are possibilities. We're still doing what USL was doing. We have the same offices back in Murray Hill, New Jersey, right across the street from AT&T Bell Labs; we have the same great kernel-level programmers that are on our team that came out of AT&T; we have the core licensing business intact. Really the only thing that's not there is the brand, which was associated with USL.

IDGNS: But don't you already have licenses with all the Unix vendors today?

McBride: Around technologies that we've had up to this point, but we have new things we're working on, and are seeing an opportunity to continue to advance it in the form of upgrades.

IDGNS: In what areas?

McBride: Unix kernel development. Let's go back to the 64-bit side of things: 64-bit on Intel (Corp.) was why IBM had come in and partnered up with us on Project Monterey (IBM and SCO's aborted effort to jointly develop Unix for Intel's IA-64 processors). We have a lot of development know-how around that. We have other things that we're focused on that we'll talk about in the future. Primarily, as you look at the new higher end chipsets coming out on the AMD (Advanced Micro Devices Inc.) or the Intel architecture, we expect that we can add some real value in that space.

So, did he say a word about UnixWare? Did he not instead speak as clear as a bell about UNIX source code? About doing what USL did? About kernel development? And in the context of the Sun and Microsoft licenses and the later SCOsource deals, he mentions "the core Unix System V technology" being what they were using. And in the previous article I showed you that USL did *not* do UnixWare. That was Univel.

SCO now says that UnixWare and UNIX System V are interchangeable terms. At SCOforum 2004, that wasn't the case. Here are some graphics, taken from the talks at SCOforum 2004, beginning with a couple of slides from Chris Sontag's presentation about all the litigation, starting with the SCO v. IBM case:

It says the IBM case is all about Unix System V source code, not UnixWare. And could anything be any clearer than this graphic, the one SCO used to present its position as to what it claimed it owned:

Going from perfectly clear to completely obvious, look at this SCO graphic, where it showed UNIX as the tree trunk, and UnixWare and OpenServer branches off the tree trunk, just like AIX and Solaris and BSD:

Obviously if you say UNIX or UNIX System V, you don't mean Solaris. Similarly, if you say UNIX or UNIX System V, you don't mean UnixWare. And please notice USL in the next chart:

After reading the previous article, what did Novell acquire from USL? System V, not UnixWare. It developed that with Univel.

Gentlemen, I rest my case. Kidding. I'll be here all week.

: D

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )