| SCO fights on |
Jul. 18, 2006
You have to give The SCO Group Inc. credit for persistence, if nothing else. Even after Magistrate Judge Brooke Wells strongly dismissed the majority of the company's claims that IBM had contributed Unix code to Linux, SCO keeps on fighting.
In its latest move, the Unix company filed an expected appeal to Judge Wells' ruling.
According to SCO's corporate communications manager, Blake Stowell, SCO's "Objections to Order Granting in part IBM's Motion to Limit SCO's Claims" makes several points.
First, "SCO copyright claims... do not involve methods and concepts. The copyright claims concern literal and non-literal copying and the disclosure of methods and concepts 'constitutes a breach of contract.'"
Therefore, "SCO is essentially being sanctioned here for not having deduced the source code that IBM developers had in mind when they disclosed a method and concept without using source code, but expressly stated that the contribution came from Dynix or another UNIX derivative system."
SCO is also claiming that "There is no basis... for the Magistrate Judge's conclusion that SCO willfully ... refused to provide the source code information IBM contends it was obligated to provide. To the contrary, the record evidence shows that SCO provided all the identifying information it had..."
Since it's exactly this point that Judge Wells hammered on over and over again, it's hard to see what SCO is getting at here. Nevertheless, SCO requested of the court, and is still requesting in its objection, that an evidentiary hearing take place where the court can consider "on an item-by-item basis the specificity of the disclosures made" by SCO.
SCO also claims that the court's orders plainly did not state that the "version, file and line" in source code must be provided so as to identify the item with specificity.
Further, SCO now states that none of these orders or interrogatories says what the Magistrate Judge now holds was required -- that all misused material of any type, even material that did not include source code, must be identified by "version, file and line of code."
Therefore, according to the Lindon, Utah-based company, "It is clear error for SCO to be sanctioned so severely for failing to meet the standard that this Court itself rejected in its Order."
Once more, after several rounds of discovery, SCO is claiming that IBM, not SCO, is the one guilty of not providing enough information. The company declares that IBM did not provide any "methods" or code in response to this request, let alone identification of methods it contributed to Linux by "specific lines or portions of code."
"In short, contrary to the Magistrate Judge's assumption, IBM did not provide 'specific lines or portions of code' in response to SCO's discovery request, and SCO certainly did not ask the Court to compel IBM to identify the methods it disclosed by 'specific lines or portions of code' when the method was not disclosed to the Linux community with that level of specificity," SCO continues.
Now, however, SCO is also upping its ante. SCO is claiming that IBM destroyed evidence.
SCO now declares that "Weeks after SCO filed its lawsuit, IBM directed dozens of its Linux developers within its Linux Technology Center and at least ten of its Linux developers outside the Linux Operations Center to delete the AIX and/or Dynix source code from their computers. One IBM Linux developer has admitted to destroying Dynix source code and tests, as well as pre-March 2003 drafts of source code he had written for Linux while referring to Dynix code on his computer."
Therefore, "SCO intends to raise the issue of IBM's spoliation of evidence before this court at the appropriate time."
A full copy of the material that SCO has released to the public in its latest claims can be found on Groklaw, here.
-- Steven J. Vaughan-Nichols
Do you have comments on this story?
Talkback here NOTE: Please post your comments regarding our articles using the above link. Be sure to use this article's title as the "Subject" in your posts. Before you create a new thread, please check to see if a discussion thread is already running on the article you plan to comment on. Thanks!
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|