Here is IBM's Unsealed Opposition to SCO's Motion for Leave to File a Third Amended Complaint Pursuant to Federal Rules of Civil Procedure 15(a) and 16(b). In it, IBM says, enough is enough. SCO is just gaming the courts, seeking to delay a final determination in the case, so as to spread FUD.
The evidence will establish, IBM says, that there is no merit to SCO's new claim it wishes to file that IBM infringed SCO's purported UNIX copyrights by copying IBM's "AIX for Power" operating system.
It then lists all the reasons SCO's proposed new claim has no merit. First, IBM has a valid license to the UNIX source code included in its AIX products, "a license obtained as part of the Joint Development Agreement entered into by IBM and SCO's alleged predecessor-in-interest, the Santa Cruz Operation, Inc. ("Santa Cruz") in 1998."
SCO's motion was filed 8 months after the deadline set by the Court for such motions, more than 19 months after it filed its original complaint. SCO must abide by Rule 16(b) and 15(a) of the Federal Rules of Civil Procedure. 16(b) says a court should not modify a scheduling order except upon a showing of good cause; 15(a) says the court may deny leave to amend where there is a showing of undue delay, undue prejudice to the opposing party, bad faith or dilatory motive, or futility of the proposed amendment.
SCO can't meet 16(b) because it hasn't shown good cause. It disingenuously claims to have only recently discovered facts supporting its new claim, but it knew these facts long ago, before it even filed its original complaint, as materials SCO produced to IBM in discovery and publicly available industry reports and IBM publications at the time AIX for Power was released in 2001 make clear.
It can't meet 15(a) because SCO unduly delayed, given the above knowledge, plus its motive is just to prolong discovery, IBM would be prejudiced by adding a new claim at the 11th hour, just before discovery was set to close in a case pending already more than a year and a half, and SCO's new claim is futile anyway, because they aren't bringing it in the right place (according to the contract) and it's barred by the applicable statute of limitations.
SCO has not shown it even owns valid copyrights, for starters, and it has to in order to prevail, as well as having to show IBM copied protectable elements of its copyrighted work. A footnote reminds the court that Novell challenges SCO's copyright ownership claims.
As to the latter, IBM offers a Shaughnessy declaration that the JDA "specifically gave IBM a royalty-free license to include such UnixWare/SV4 code in its products, including AIX for Power", and a memo, dated September 10, 1998 from Geoff Seabrook, Santa Cruz's Senior VP for Development, memorializing the parties' understanding on that point:
Both companies [Santa Cruz and IBM] will exchange technology to be used in [Santa Cruz's] UnixWare 7 on the IA 32 and [IBM's] AIX on PPC [Power]. The purpose of these exchanges is to create a compatible family of products, together with the resultant IA64 product [that was to be developed jointly by Santa Cruz and IBM]. It is intended that the efffective value of these exchanges will be equivalent, and that no royalties will be due to either company as a result of these exchanges. The zero royalty agreement is also to allow our engineering teams to freely select the best available technology, without worrying about any royalty impact.
Even if there were no express permission, SCO was well aware, or should have been, that IBM did in fact incorporate the code into the AIX for Power product.
The documents SCO turned over to IBM in discovery include the following:
1. An undated joint Santa Cruz/IBM document entitled "Genus: an IBM/SCO UNIX Project Marketing Plan Development" which outlined the parties' intent to create a family of UNIX products, UnixWare, AIX for Power and IA64 (the Monterey product). The document says that the UnixWare/SV4 and AIX for Power products were to be "significantly enhanced by cross pollination of technologies".
2. A November 4, 1998 Santa Cruz presentation on Project Monterey that stated that the plan was to create a "single UNIX product line that spans IA-32 (that's UnixWare/SVR4), IA-64 (that's Monterey) and IBM Power processors (that's AIX for Power). The presentation said that Santa Cruz would be "supplying IBM with UnixWare 7 APIs and technologies for [inclusion in] AIX [for Power]".
3. "Monterey-64 Release 1 Product Requirement Specification", released by SCO and IBM on February 19, 1999, that states that one of the principle objectives of Project Monterey was to develop a family of UNIX products, including IBM's AIX for PowerPC and that the Monterey product would "maximize the amount of common source code shared with AIX PPC."
4. A document "IBM-SCO Family Unix Technical Proposal" dated September 2, 1998 that sets forth specific "Technology from U[nix]W[are]" intended to be incorporated into AIX for Power.
5. An October 1999 presentation by IBM's UNIX Marketing Program Director (again, this is in the list of documents SCO had in their possession and turned over to IBM in discovery) that noted that the partners' intent was to "aggressively grow and enhance [the] AIX-Power offering" by including "[c]ontributions from SCO's UnixWare."
IBM lists other documents created by Santa Cruz that SCO didn't produce in discovery which all reflect the same truth: that SCO knew or should have known that Santa Cruz and IBM intended a single UNIX product line that ran on IA-32, IA-64 and Power:
1. A 1999 Santa Cruz-drafted joint statement with IBM that included the following wording: "IBM is providing [Santa Cruz] with AIX technology for inclusion in UnixWare and [Santa Cruz] is providing UnixWare technology to IBM for inclusion in AIX."
2. A February 2000 presentation prepared for the Santa Cruz Partner Conference in which Santa Cruz's Tamar Newberger stated that "[e]nhancements from SCO's UnixWare" would be included to "aggressively grow and enhance [the] AIX-Power offering".
3. An August 10, 2000 email from John Boland of Santa Cruz, which distributed internally a press release prepared by IBM about AIX 5L, the AIX release that included SVR4 technology. The release clearly said that AIX 5L for Power, like AIX 5L for IA-64, contained "key technologies" from UnixWare and UNIX System 5 [SVR4], and it lists the SVR4 printing subsytem by name.
4. A May 2001 webpage for AIX 5L jointly sponsored by IBM, Intel and Santa Cruz which states that AIX 5L for IBM Power combined AIX "with the best technologies from [Santa Cruz's] UnixWare operating system."
5. An undated joint Santa Cruz/IBM document that said that both AIX for Power and AIX for IA-64 had the "[UnixWare] SVR4 print system."
So SCO knew, or should have known, IBM points out, at least 3 years ago about AIX for Power using SVR4 tech, so they can't show good cause for their delay. They even disclosed some of the internal documents to the media back in August of 2004, improperly in IBM's view. Yet they come to court claiming they just learned about it and on that basis claim they should be allowed to amend their complaint once again, but the evidence belies their assertion.
That is just the beginning. IBM then lists five more examples of publicly available product announcements and industry reports issued years ago that reflect the inclusion of UnixWare/SVR4 code in AIX for Power, and 6 product announcements and manuals published openly by IBM that were equally explicit.
Thus, even if IBM didn't have a license to use that code, SCO can't pretend it didn't know or couldn't have known with the most basic due diligence. So it "has failed abjectly" to demonstrate good cause for its untimely filing, and its claim that it only just learned of inclusion of SVR4 in AIX for Power is "unquestionably and demonstrably false."
Rule 15(a) says the court can deny a motion to amend where there is a showing of undue delay. For that matter, all three other factors in the Rule also weigh against SCO, undue prejudice to IBM, bad faith or dilatory motive, and futility of the proposed amendment.
That's legalese for "SCO waited too long, has no good reason for not including this junk in the first complaint, is lying about when it first learned about these facts, is just trying to delay a final outcome, and can't win even if you let them amend now." I wonder if the Court has finally understood that accepting what SCO says at face value is unwise? If not before now, surely this filing ought to make it very clear. IBM tells the court that "it has been SCO's strategy from the outset of this litigation to seek to delay the proceedings, apparently to further the fear, uncertainty and doubt that SCO has created concerning Linux and IBM's products and services. The instant motion is just part and parcel of SCO's delay tactics." It then lists all the SCO motions and requests for extended discovery and notes that this motion to amend came just two weeks after the Court denied SCO's "emergency" request for a scheduling conference, at which SCO said it intended to propose yet another extension of discovery. IBM does not view that as a coincidence. It views it that SCO is seeking to gain an extension still, just in a new way. If the court grants SCO's motion, IBM predicts they will shortly thereafter ask for more delay for more discovery.
In short, IBM accuses SCO of gamesmanship, and it uses that word. The courts are not really set up for such tactics, and it has taken a while for the court to wake up to what it is being asked to be a party to. Further complicating the picture is that the system assumes good faith on the part of a plaintiff in a civil action, and all the delays are part of a system that tries to make sure justice is really done and that a plaintiff has a fair chance to present its case. But I hope Judge Kimball gives due weight to making sure he is not manipulated into becoming a party to such a misuse of his court as IBM posits.
"SCO should not be allowed to continue to perpetuate the fear, uncertainty and doubt it has created in the marketplace concerning Linux simply by devising new ways to delay the resolution of this case," IBM writes, and concludes, "We respectfully submit that enough is enough. SCO should be required to complete the discovery process concerning the claims and counterclaims that were timely pled in this case. Its consistent efforts to delay and derail that process should finally be put to rest."