Novell says waiver cancels SCO's claims on Linux

The Salt Lake Tribune ^ | February 13, 2004 | Bob Mims

[cc2k]

Novell says waiver cancels SCO's claims on Linux

By Bob Mims
The Salt Lake Tribune

    Novell Inc., claiming it sold only limited rights to the Unix operating system in 1995, has issued a waiver it says negates the SCO Group's claims on the offshoot, freely distributed Linux operating system.
    Claiming the purchase excluded control of "derivative works," or improvements to the program's code by independent developers, Novell had given SCO until noon Wednesday to retract its claim that Unix code was illegally imported into Linux.
    That allegation is at the heart of SCO's federal lawsuit against IBM, which seeks damages and penalties of up to $50 billion for Big Blue's distribution of allegedly tainted versions of Linux.

    After SCO ignored the deadline, insisting it held all rights to Unix, Novell wrote the Lindon-based software company late Wednesday stating it "waives any purported right SCO may claim" to restrict use of the 1995 Unix code.
    "This doesn't change a thing," SCO spokesman Blake Stowell said Thursday. "It remains SCO's strongly held legal position that Novell has no rights to step in and change or alter the source code license agreements that SCO owns and holds with its Unix licensees."
    Contrary to Novell's claims that it had a contractual right to issue the Unix-use waiver on a recalcitrant SCO's behalf, Stowell said that "SCO has no intention of waiving any of its rights against . . . IBM."
    As for Novell's claims to retain certain Unix rights, "We will deal with Novell on all of these issues in court," Stowell added.
    IBM spokesman Mike Darcy declined to comment, as did Novell's Bruce Lowry. "Our letter speaks for itself," Lowry said.
    Novell also is seeking dismissal of a corporate title-slander lawsuit filed by SCO, which in turn is being sued by leading Linux distributor Red Hat Inc. over its Unix-Linux claims.
    The flare-up with Novell came as SCO and IBM await U.S. Magistrate Brooke Wells' potentially decisive rulings possibly today or early next week on competing motions to compel evidence.
    IBM attorneys argued last Friday that SCO has failed to provide specific, detailed proof for its Unix-Linux allegations; SCO contends it cannot do so without IBM providing code requested in an earlier motion.
    bmims@sltrib.com
   
   

[cc2k]

Novell's letter (link to PDF) dated Wednesday, February 11, 2004, doesn't say precisely what this article implies. The article says the letter claims "the purchase excluded control of 'derivative works,'"

The letter actually states: "Accordingly, pursuant to Section 4.16(b) of the Asset Purchase Agreement, Novell, on behalf of The SCO Group, hereby waives any purported right SCO may claim to require Sequent (or IBM as its successor) to treat Sequent Code as subject to the confidentiality obligations or use restrictions of Sequent's SVRX license."

Novell's previous letter defined "Sequent Code" as code developed by Sequent or licensed by Sequent from a third party, which Sequent incorporated into its Unix variant, but which itself does not contain proprietary UNIX code supplied by AT&T.

Novell claims that AT&T made this clear in a newsletter that was sent to Sequent (and all UNIX licensees) in 1985.

So, Novell is saying that according to the terms of the licensing agreement, Dynix (which contains both AT&T code and Sequent code) is covered by the "derivative works" clause(s), but that things like the NUMA scheduler and RCU code (which were developed entirely by or for Sequent and contain no AT&T code) are not covered by any obligations by the AT&T UNIX license.

In the case of JFS and EVMS, which are IBM additions to UNIX that were incorporated into AIX, the supplemental agreements with IBM make this same clear statement that IBM owns code that IBM developed or code that was developed by others specifically for IBM. That code is also not subject to the confidentiality requirements of the AT&T UNIX license agreement.

[cc2k]

Another nail for the SCO coffin

[isthisnickcool]

Note to self. Short SCO/Caldera/David Boise Inc. stock.

[Boundless]

> Another nail for the SCO coffin

And the nails are being collected and discussed at:
http://www.groklaw.net/

Other smoking guns can be found at:
http://sco.tuxrocks.com/

I'm waiting for the SEC to weigh in on this.
The disparity between SCO PR and SCO SEC
filings, added to the timings of same, and
insider sales, needs looking at.

[Boundless]

> Note to self. Short SCO/Caldera/David Boise Inc. stock.

If you can find any to short, according to
those who have looked.

Further, the price of this stock does not
correlate with the reality in court. My
impression is that, lacking a Las Vegas line
on SCOX, the gamblers are all playing this one
in the stock market. Sit at that table at your
own risk.

[steve-b]

Note to self. Short SCO/Caldera/David Boise Inc. stock.
If you can find any to short, according to those who have looked.

The current bubble in SCO stock prices is a classic "short squeeze". (Selling a stock short is, to simplify it down to its essentials, borrowing shares and selling them in the hope of replacing them at a lower price later. However, if lots of people need to obtain shares when the loan comes due, the effect on the stock price is the same as if lots of people buy it for any other reason -- it goes up, at least for the time being.)

[eno_]

Calling all MicroShills!

Helloooooo?

< sound-of-crickets >

Very hilarious. Probably too late to short SCOX. The death spiral has begun. Schiller & Flexner are sending in the benchwarmers to play this one out.

[adam_az]

b2k is still smarting from the whooping I gave him on another thread. I don't expect us to hear a peep from him for a while.

[Bush2000]

Another nail for the SCO coffin

So what. Novell could issue a waiver on gravity and it wouldn't matter.

[eno_]

SCOX apperently have no idea what they bought.

In addition to Novell's latest, are you in denial that AT&T clarified that their license does not cause the license holder to take ownership of technologies created by licensors?

[Bush2000]

SCOX apperently have no idea what they bought.

It's nice to know that you believe that. But your opinion of what SCO thinks is irrelevant. You ain't SCO.

In addition to Novell's latest, are you in denial that AT&T clarified that their license does not cause the license holder to take ownership of technologies created by licensors?

I've already said this a million times: SCO has never claimed that they own technologies created by licensors. What they have said is that the contract signed by IBM gives SCO the right to prevent IBM from redistributing those technologies. That doesn't mean that IBM no longer owns them.

[eno_]

What they have said is that the contract signed by IBM gives SCO the right to prevent IBM from redistributing those technologies. That doesn't mean that IBM no longer owns them.

That makes no sense: Does IBM lose the right to distribute JFS in OS/2? In OS/370? In Linux?

[Bush2000]

That makes no sense: Does IBM lose the right to distribute JFS in OS/2? In OS/370? In Linux?

As long as the source eminated from OS/2 or OS/370, there is no problem. But if they took the JFS code from AIX -- as I believe they did -- they were in violation of contract.

[RagingBull]

The IBM/JFS for linux code is based on the OS/2 JFS code:

The new Journaled File System, on which the Linux port was based, was first shipped in OS/2 Warp Server for eBusiness in April, 1999, after several years of designing, coding, and testing. It also shipped with OS/2 Warp Client in October, 2000. In parallel to this effort, some of the JFS development team returned to the AIX Operating System Development Group in 1997 and started to move this new JFS source base to the AIX operating system. In May, 2001, a second journaled file system, Enhanced Journaled File System (JFS2), was made available for AIX 5L. In December of 1999, a snapshot of the original OS/2 JFS source was taken and work was begun to port JFS to Linux. [1]

[eno_]

Any comment on that?

It is also dead certain that if the above statement is true, it can be supported by records of source code management systems.

This is, of course, on top of AT&T's previous clarification that companies that add their own technologies to UNIX retain rights to those technologies elsewhere.

And that is itself merely a clarification of the common interpretation of such clauses as giving a licensor access to, e.g. bug fixes so that a licensor's customers cannot gradually take over the intellectual property in a product through fixes and enhancements. SCO started from this weak point and carjacked an industry for a wild, but ultimately pointless, ride. For that, SCO and the people financing SCO, should pay very very very dearly.

[Bush2000]

Read that same FAQ:

A1. IBM introduced its UNIX file system as the Journaled File System (JFS) with the initial release of AIX Version 3.1. This file system, now called JFS1 on AIX, has been the premier file system for AIX over the last 10 years and has been installed in millions of customer's AIX systems. In 1995, work began to enhance the file system to be more scalable and to support machines that had more than one processor. Another goal was to have a more portable file system, capable of running on multiple operating systems. Historically, the JFS1 file system is very closely tied to the memory manager of AIX. This design is typical of a closed-source operating system, or a file system supporting only one operating system.

The new Journaled File System, on which the Linux port was based, was first shipped in OS/2 Warp Server for eBusiness in April, 1999, after several years of designing, coding, and testing. It also shipped with OS/2 Warp Client in October, 2000. In parallel to this effort, some of the JFS development team returned to the AIX Operating System Development Group in 1997 and started to move this new JFS source base to the AIX operating system. In May, 2001, a second journaled file system, Enhanced Journaled File System (JFS2), was made available for AIX 5L. In December of 1999, a snapshot of the original OS/2 JFS source was taken and work was begun to port JFS to Linux.

It is unlikely that IBM started from scratch on the OS/2 version of JFS. Very few engineering projects throw away working code. They probably started with the original AIX sources and added/discarded whatever they needed. Either way, the reference cited is inconclusive one way or another.

[eno_]

N.B.: some of the JFS development team returned to the AIX Operating System Development Group in 1997 and started to move this new JFS source base to the AIX operating system

"Working" code is often discarded, especially in performance-critical areas like file systems where a new architectural approach can yield huge performance gains.

[eno_]

Or you could check out this interview response from 2001:

Steve Best: The JFS for Linux is a port from OS/2 and has an OS/2 compatibility option. The OS/2 source was also used for the JFS2 just release on AIX 5L. There is a JFS1 on AIX and we didn't use this source base, since the OS/2 source base was a new "ground-up" scalable design started in 1995. The design goals were to use the proven Journaling File System technology that we had developed for 10+ years in AIX and expand on that in the following areas: Performance, Robustness, and SMP support. Some of the team members for the original JFS designed/developed this File System. So this source base for JFS for Linux is now on the following other Operating Systems:

The heritage of the Linux implementation appears to clearly be the OS/2 implementation.

[Bush2000]

The heritage of the Linux implementation appears to clearly be the OS/2 implementation.

If this is true, then at least JFS could be free and clear. But call me skeptical. It wouldn't surprise me if the developers on the OS/2 JFS project used at least the AIX header files as a starting point. I doubt that they would have thrown away that existing code. Consequently, I'd like to see all notes, specs, journals, emails, and other content regarding JFS made part of discovery.

[Bush2000]

"Working" code is often discarded, especially in performance-critical areas like file systems where a new architectural approach can yield huge performance gains.

Very rarely do engineering projects scrap an entire codebase. The more efficient thing to do is identify the "hotspots" in a particular codebase and reengineer those points of tension. Occasionally, it turns out that code is a total loss but, in my experience, that is seldom the case.