McKenney and Slingwine, while at Sequent, invented the
technique called Read-Copy Update, or RCU, which is "an operating
system synchronization mechanism that allows concurrent reading and
updating data while maintaining data coherency". Sequent patented it. Mr. McKenney has some news for SCO:

In developing RCU, I did not review or use any code, methods or
concepts from the Unix System V operating system. I developed RCU
using publicly described operating system primitives including
locking, memory allocation, and scheduling-clock interrupts, for
example, as provided by DYNIX (a Berkeley Software Design-based)
operating system. In fact, to the best of my knowledge, System V
does not contain code, methods or concepts relating to RCU.

The RCU material that IBM has contributed to Linux was original IBM
or Sequent work; it did not include Unix System V material; it was not
a modification or derivative work of Unix System V; and it was not
made with reference to Unix System V.

Dynix is based on BSD, not System V, he tells the court.

I'll pause a moment let that sink in.

BSD code is not the same thing as System V. Duh. All of SCO's elaborate theories about Dynix and infringing code, methods and concepts depend on it being based on System V. And McKenney says it's not. Dynix and Dynix/ptx are not the same, and he used Dynix, he testifies, which is based on BSD, not on System V, and "the Linux implementation of RCU is an implementation of concepts published in the RCU patent issued in 1995." RCU was all original work, he says. Wherever it was implemented later, that is the origin. Talk about hitting the ball right out of the park.

But, to stress an additional home-run point by McKenney, RCU code contributed to Linux doesn't violate any of SCO's precious System V code, methods or concepts for another reason:

In fact, to the best of my knowledge, System V
does not contain code, methods or concepts relating to RCU.

How, then, could RCU infringe it? Double Duh. Maybe SCO's experts will be able to find it. SCO is so skilled at coming up with precise lines, files and versions of code. Yes, I think this really is the stupidest lawsuit in the history of the world.

RCU was original code, so Sequent applied for the patent [PDF] in 1993 and it issued two years later, U.S. Patent No. 5,442,758. When you are issued a patent, it's supposed to mean that nobody did it before you did it. Nobody protested the patent in 1993 or 1995 or ever since to this day. Not only that, but McKenney lists and attaches as exhibits further patents granted later, based on the same patent application, U.S. Patent No. 5,608,893, U.S. Patent No. 5,727,209, and U.S. Patent No. 6,219,690, all PDFs.

If SCO's theory of contract were correct and Sequent was obligated to keep all Dynix and Dynix/ptx code confidential, how could that have happened? Sequent applied for patents related to Dynix/ptx too over the years. Over and over, and no one objected that the patents revealed confidential methods and concepts. McKenney testifies in another declaration, Exhibit 596 [PDF], that Sequent did not believe it was supposed to keep Dynix/ptx confidential for AT&T either:

3. Subsequent to the execution of the Agreements, Sequent invested in the development of its own operating system for multiprocessors, DYNIX/ptx. It did so based on the understanding that AT&T claimed no interest in Sequent's original works, even if such a work might be included in a modification or derivative work of UNIX System V.

If it had interpreted the Agreement that way, it could not have applied for those patents:

5. In addition, Sequent also applied for numerous patents for technologies related to DYNIX/ptx. Because Sequent understood that the Software Agreements did not require Sequent to hold DYNIX/ptx methods in confidence for AT&T, it was free to apply for patents related to DYNIX/ptx methods and thus disclose such methods to the public.

1993 is a year *before* the 1994 BSDI settlement agreement. That litigation was in full swing. Judge Debevoise's ruling in USL v. BSDi was in March of 1993, the same year Sequent filed for its patent on RCU. So I don't think anyone can argue that no one was paying attention. Yet USL didn't protest the patent. What might that tell us?

The statute of limitations for breach of contract is six years under New York law, which governs SCO's contract claims. IBM publicly disclosed the allegedly misused material relating to RCU in connection with a patent application and the resulting patent, which issued in 1995, more than six years prior to the date that SCO filed its lawsuit. Thus SCO's claims relating to RCU are barred by the statute of limitations.

And if you read the second Read-Copy Update article, which I just did, you'll find that there was a need for RCU precisely because there was nothing exactly like it. It was invent it or do without. "This paper proposes a novel and extremely efficient mechanism, called read-copy update, and compares its performance to that of conventional locking primitives." The article also would have been a breach under SCO's current interpretation of the contract, but no one complained at the time. Both the patent and the article revealed RCU's methods and concepts.
McKenney tells the court he wrote some other papers explaining all about RCU too. Nobody in the chain of System V owners, and I do mean chain, ever protested.

Yet RCU is, curiously, one of the items on SCO's list of allegedly infringed materials. It's been on SCO's list from the beginning of this litigation, mentioned when SCO showed the allegedly "infringing" code at SCOsource in August of 2003 -- remember that SCO fiasco, when some of the code they showed turned out to be BSD-licensed, among other gaffes? Still, in the face of overwhelming evidence to the contrary, like a hopelessly straggling entrant in Alaska's grueling Iditarod marathon who, despite realizing he has little hope of victory, refuses to give up and forces his poor sled dogs to trudge through the blizzard anyway, SCO plows ever forward, persisting in claiming rights over RCU. Mush, you Huskies! Unfortunately, that persistence forces IBM to deal with all the snow too. And there is the fact that lawyers are not supposed to persist with claims that are frivolous, because it costs everyone wasted time and money. You might start with a claim that you didn't know was frivolous, but once you do enough discovery to realize you goofed, you are supposed to let it go. We'll see what SCO does next in response to this IBM motion and all the exhibits. But the matter is before the judge now, and he has the power to grant IBM's motion and bring the RCU Follies to an end.

SCO's Sandeep Gupta claimed back in July of 2005 that he put Unix and Linux code side by side and they looked similar. Shades of SCOsource. The difference between the two testimonies is McKenney invented RCU, so he's not guessing about what he did or where the code came from. You'll remember that Dr. Brian Kernighan rebutted Gupta rather scathingly at the time, including this priceless bit:

Furthermore, in places, Mr. Gupta's conclusions of similarity depend on his selecting isolated lines of code from disparate places and putting them together as if contiguous blocks of code were involved (which they are not) and important differences did not exist (which they do).

If the code looked similar, it was only after it had been rearranged and cobbled together to make it seem so, he said. Randall Davis earlier also said that in his opinion, SCO had presented no "credible examples" of substantial similarity. But this Declaration by McKenney, the inventor of RCU, is even better, because it's all moot, if Dynix is based on BSD, not on System V. If SCO could somehow prove otherwise, then it faces the Kernighan issues.

Here IBM presents the inventor of RCU. It's not dueling experts now, Kernighan v. Gupta, mismatched as that is. And he says he didn't use or refer to System V when he invented RCU. Dynix is not a derivative of System V in any case, he explains. Dynix was BSD-based, something you can verify by looking at the famous Levenez chart, by looking for Dynix 1984. Just follow the arrow. Then look for Unix System V, same year. Note the white space where lines do not meet. RCU was original work anyway. SCO will now have to find a way to disprove all of those statements or at least raise a fact open to dispute. I can only imagine one conceivable way, and I'll never tell. This has dragged on long enough.

SCO's problem from the beginnning, from my standpoint, is they don't know their Unix/BSD history. They had the same problem when they showed the allegedly infringing code at SCOsource, lo these many moons ago.

And the worst of it is that McKenney told SCO all of this in his deposition. But does SCO say, "Oops. My bad. Never mind"? For that matter, Groklaw told the world back in November of 2003 that SCO had distributed RCU under the GPL in any case. Triple Duh. IBM makes the point that SCO released RCU under the GPL in UnitedLinux, beginning in paragraph 158 of its Memorandum.

But does SCO listen? It certainly can't pretend it doesn't read Groklaw. So at least from the winter of 2003, it likely knew about this. Releasing it under the GPL is a knockout punch all on its own. So why doesn't the RCU claim get dropped? I'll be fascinated to see what they say to the judge in response to this IBM motion.

Fourth, SCO's contract claims relating to at least some of the allegedly misused material (i.e., RCU) are barred by the statute of limitations. The statute of limitations for breach of contract is six years under New York law, which governs SCO's contract claims. IBM publicly disclosed the allegedly misused material relating to RCU in connection with a patent application and the resulting patent, which issued in 1995, more than six years prior to the date that SCO filed its lawsuit. Thus SCO's claims relating to RCU are barred by the statute of limitations....

257. IBM's Linux RCU contributions, and the earlier Sequent implementation of RCU in Dynix, do not include any UNIX System V code; they are not modifications or derivative works of UNIX System V; and they were not based on or created with reference to UNIX System V. They are original IBM work created independent of UNIX System V. (Ex. 231 ¶8; Ex. 258 ¶5; Ex. 291 ¶24.)

258. SCO has not specifically identified any UNIX System V material (by version, file, or line of code, or otherwise) that it alleges is contained in RCU. (See Ex. 54 Item 2.)...

261. Sequent engineers Paul McKenney and John Slingwine filed a patent application for RCU on July 19, 1993, and the patent was granted on August 15, 1995. (Ex. 231 ¶5; see Ex. 498.) The implementation of RCU in Dynix and the challenged implementation of RCU in Linux are implementations of the same general concept that is embodied in U.S. Patent # 5,442,758. (Ex. 231 ¶¶4-5; Ex. 291 ¶27; Ex. 268 at 117-21.)

Do you see how declarations are used? Each person tells what he personally knows. No more, just facts that the individual has personal knowledge of, fact, fact, fact. That's why they all include language to the effect that the individual makes this declaration based upon personal knowledge. That's the requirement and the limitation. Experts get to wax poetic, but in this kind of declaration, you can't include things you merely heard about or "know" because your best friend told you. Then IBM, in its memorandum, ties all the fact pieces together and explains what it all means, using the declarations and exhibits to support each fact it needs to make. If you were curious as to why some declarations don't say X or Y, it's probably because that particular declaration is being used solely for support of point Z, something the declarant knows personally. Others who know facts supporting X and Y can provide declarations for that proof.

You can find all the other exhibits listed on that same chart. A few are sealed. Not all, of course, are about RCU. Some are about JFS and other code SCO is claiming rights to. The one that seems most relevant is
Exhibit 258 - Declaration of Dipankar Sarma, dated September 13, 2006 [PDF]. He testifies that he never worked on Dynix when he was at Sequent, as SCO has alleged. After joining IBM, when making contributions relating to Linux RCU, he never reviewed or used any non-public code, methods or concepts from Unix System V. Everything that IBM contributed to Linux in the way of RCU material was original IBM or Sequent work, it didn't include any Unix System V material, nor was it a modification or derivative work of System V. And nobody peeked at System V as a reference. The McKenney deposition is sealed, unfortunately, Number 268. So is SCO's list of alleged infringements

104. Sequent also had certain contractual obligations and restrictions on its use of the UNIX System V code that it licensed from AT&T, SCO's predecessor. These restrictions, which are more fully stated in the Sequent Agreements, also restricted Sequent's use of the modifications they made to UNIX System V and derivative works of UNIX System V, including Sequent's Dynix/ptx. Like IBM, Sequent agreed to restrictions on Dynix/ptx, including that Dynix/ptx for or by others, and that it would not transfer any part of Dynix/ptx to parties who do not have a UNIX System V source code agreement with SCO. Sequent also agreed that they would maintain all of Dynix/ptx in confidence. In violation of these contractual restrictions, IBM provided entire files of Dynix/ptx source code as a patch to Linux 2.4.1-01, including Read Copy Update ("RCU").

105. RCU is a mechanism that can significantly improve the performance and scalability of multi-processor systems by allowing simultaneous access to data without the need for expensive and time consuming locking protocols. Dynix/ptx/RCU structures and sequences were originally offerred as a patch to the Linux 2.4 kernel by IBM, with rather limited functionality inside Linux 2.4. However, in the development of Linux version 2.6, the deployment of Dynix/ptx/RCU structures and sequences has spread into new uses inside Linux, including networking, device drivers, list management, and directory access. This demonstrates how improper contribution of a few hundred lines from Dynix/ptx has had a massive impact on Linux kernel efficiency, particularly relating to multi-processor functionality and processor memory synchronization. Virtually the entire files identified in Table C that originated in Dynix/ptx were published as a patch to Linux 2.4.1-01, with only minimal changes.

Table C

DynixV v4.6.1 Files

Linux 2.4.1-01 files

kernel/sys/rclock.h

include/linux/rclock.

kernel/os/rclock.c

kernel/rclock.c

kernel/sys/kma_defer.h

include/linux/kmemdef.h

kernel/os/kma_defer.c

kernel/kmemdef.c

106. As stated, the entire files specified above show direct line-by-line copying of the files with the same name in Dynix as in Linux, with slight changes made to reflect some variations between the two operating systems. That the code in Linux comes from Dynix/ptx is further confirmed by the commentary in the Linux patch that expressly states that it is "[b]ased on a Dynix/ptx implementation by Paul McKenney..." Mr. McKenney was formerly an engineer at Sequent, and is now employed at IBM following IBM's acquisition of Sequent. After the first initial improper contribution of RCU by IBM, RCU became more widespread in the Linux kernel.

107.Code from Dynix/ptx files, but less than the entire file, was also copied line-for-line from DynixV v4.6.1 to Linux 2.4.1-01, with the file name and file line number in each code base identified appropriately.

Table D

DynixV v4.6.1 Files

Line #s

Linux 2.4.1-01 files

Line #s

kernel/os/kern_clock.c

2028-2059

arch/i386/kernel/apic.c

25-28, 662-664 676-684

kernel/os/kern_clock.c

2028-2059

kernel/timer.c

26-29, 681-683 688-697

kernel/i386/locore.s

1487-1497

arch/i386/kernel/entry.S

199-205

kernel/i386/trap.c

1554-1563

arch/i386/kernel/traps.c

52-54, 244-247, 331-334, 542-545, 659-662, 718-721

kernel/i386/startup.c

2054

init/main.c

30-33, 609-616

108. Although the actual count of lines of code in each of these contributions appears small, the impact is significant for a number of reasons: (a) In the case of JFS and EVMS, the number of lines that can be conclusively proven with the evidence currently available is shown. ther is much more copying that is anticipated to be found in discovery; (b) In the case of RCU, a highhly valuable and effective technological improvement can be expressed rather succinctly in computer code; and (c) In most cases, simple changes to code can have far reaching effects, and once the technology is revealed, thousands of developers can apply the technology to a myriad of places in the kernel.

None of that matters, if Dynix is based on BSD, even if it were all accurate. SCO fought so hard to get every version of Dynix. You can read about SCO's "need" for all the Dynix code in discovery in this Memorandum Re Discovery from June of 2004, in which SCO told Magistrate Judge Brooke Wells, in response to her request in her March 3, 2004 Order, why it asked for and "needed" all the Dynix code from its beginnings, again relying on Gupta:

A. SCO's Breach of Contract Claims.

SCO claims that IBM breached its software agreement (AT&T Technologies, Inc. Software Agreement, executed on Feb. 1, 1985 ("Agreement") [Exh. 1]) by, among other actions, distributing parts of the AIX and Dynix operating system software programs to Linux. Because the Agreement does not permit IBM to lease or transfer any parts of the AIX and Dynix programs, IBM's contribution of AIX and Dynix code to Linux violates that Agreement. (1) Such contributions to a public forum also violate the requirement to maintain the "resulting materials," AIX and Dynix, as confidential. Id. at § 7.06.

SCO also claims that IBM's contribution of parts of AIX and Dynix to Linux breached the Agreement because both the AIX and Dynix programs, as whole programs, are modifications or derivative works of UNIX System V, so no parts of those programs may be sold, leased or otherwise transferred. See note 3. Again, for example, because the Agreement prohibits the transfer of software programs in whole or in part, IBM's contributions to Linux from AIX and Dynix -- as derivative works of UNIX System V -- violate the Agreement. SCO is entitled, under the Federal Rules, to evidence relevant to these claims....

II. ADDITIONAL ITEMS REQUESTED(8)

SCO requests that this Court order IBM to produce the following:

all revision control system information (including documents, data, logs, files, and so forth) for AIX, Dynix/ptx, ptx, and Dynix from 1984 to the present

source code and log information for all interim and released versions of AIX, Dynix, ptx, and Dynix/ptx from 1984 to the present

In addition, SCO requests that this Court order IBM to produce all design documents, whitepapers and programming notes, created from 1984 to the present, related to the following: ...

As to Dynix, ptx, and Dynix/ptx:

read-copy update (RCU)

non-uniform memory access (NUMA)

Async I/O, MPIO and Standard I/O

SMP and all other changes related to MP functionality

performance enhancement tools and methods

SVR4 features in Dynix and/or PTX

debugger and statistics gathering for both kernel and user-space functionality

inter-process communications

hot swapping

virtual file system

MP enhancements to network file system

System V file system

SCO needs the discovery requested in this Memorandum for at least three reasons:

1. To respond further to IBM's discovery requests. IBM claims discovery misconduct and delay by SCO in providing discovery responses, while IBM has the information SCO needs to respond.

2. To gather evidence relevant to IBM's theory of SCO's contract claim, under which IBM appears to assert that to establish IBM's breach of the Agreement at issue, SCO requires specific evidence of derivation from UNIX System V lines of code through the versions of AIX and Dynix code to Linux.

3. To gather relevant evidence in support of SCO's theories of its contract case against IBM, including without limitation: (a) that every transfer from AIX and Dynix, as whole programs, into Linux constitutes a breach of the Agreement, and/or (b) that AIX and Dynix are derivative works of UNIX System V, and consequently, IBM's contributions to Linux from AIX and Dynix are breaches of the Agreement.
...

Identification and tracing of certain multiprocessor lock-avoidance code (RCU) from Dynix/ptx to become modified, derivative multiprocessor lock-avoidance code (RCU) in Linux that appears to be based on proprietary UNIX-based code, methods or concepts....

They got Dynix code, as you'll recall, all interim versions, the whole ball of wax. But the funny part is, IBM has just informed them, through Mr. McKenney's declaration, that Dynix isn't based on System V after all. So all SCO's arguments go poof. It doesn't matter who had access or who mighta, coulda, shoulda or what looks like what. Dynix is based on BSD, McKenney says, and to survive this IBM motion, SCO is going to have to prove otherwise or at least present something that has to be decided by a jury, some debatable fact. Good luck with that, guys. I am guessing that this information about Dynix being based on BSD might also have a bearing on SCO's spoliation claim, if it has anything to do with Dynix. Wouldn't that be a laugh riot?

In that memorandum, SCO claimed that if it could get all the code it wanted, here's what it would be able to prove:

SCO will also be able to complete the following when in possession of the requested materials:

Provide a more detailed identification of IBM's improper contributions of AIX code, methods and concepts to Linux.

Provide a more detailed identification IBM's improper contributions of Dynix/ptx code, methods and concepts to Linux.

Provide a more detailed identification of IBM's improper use of SCO's copyrighted information improperly contributed to Linux by others.

Conduct a detailed evaluation of the code similarities between System V ES/MP code base and all produced versions of Dynix/ptx, which will yield a view of the subset of System V code that is contained in the Dynix/ptx code.

Conduct a detailed evaluation of the code similarities between System V ES/MP code base and all AIX/AIX5L code bases, which will yield a view of the subset of recent SVR4 code recently added to AIX and AIX5L by IBM.

Accordingly, in order for SCO to fully trace the derivation of AIX and Dynix from UNIX System V, IBM must produce their revision control systems in a format that will allow SCO to track the derivation and modification of UNIX System V source code in AIX and Dynix.

Mr. Gupta
provides specific examples of SCO UNIX source code which can be found
in Linux. Mr. Gupta
does not discuss whether any of the Linux code he observed infringes
any of SCO's
copyrights. Mr. Gupta's declaration provided factual testimony in the
following areas.

1. The UNIX Read-Copy-Update ("RCU") Routines Can be
Found in Linux

Paragraphs 5-23 of Mr. Gupta's declaration explain what the
Read-Copy-Update ("RCU") routine is and present facts which show that
the source code implementing the RCU routine can be found in both UNIX
and Linux. For example, Mr. Gupta
testified:

"RCU (Read-Copy-Update) is one of the methods used to
synchronize
access to shared data in a multiprocessing environment." Gupta
Declaration at ¶7.

"Each of the five acts of the UNIX RCU -- and of the Linux RCU
--
routine is expressed in one or a few lines of code." Gupta Declaration
at ¶15.

"The first act, 'allocating a new data structure of a certain
size,' is
expressed in UNIX RCU and Linux RCU by a single line of nearly
identical code. From a
software programmer's perspective, the UNIX RCU expression of the act
of
allocating a new data structure has been identically copied into Linux
RCU. As can be
seen in

7

attached Exhibit A, the Linux RCU code (column 4) for the first
act is nearly identical to the UNIX RCU code: (column 1) for the first
act." Gupta Declaration at ¶16.

"In Linux RCU, in contrast, the fifth act of deferred deletion
is achieved by a callback function that is automatically called when no
current users remain so that the old data structure may be deleted."
Gupta Declaration at ¶21.

2. Sequent Employees Had Access to UNIX RCU and Could
Have Copied that Into Dynix, Which was Released into Linux

Paragraphs 25-29 of Mr. Gupta's declaration explain that Sequent
employees who had worked on Dynix RCU had worked on UNIX RCU when they
worked under the Multiprocessor Software Agreement and had access to
the UNIX RCU to
copy it into the Dynix RCU. Mr. Gupta presented these facts to support
SCO's argument
that UNIX source code was placed into Linux via such intermediate
products as Dynix. Mr.
Gupta also presented facts which show that an IBM employee (and former
Sequent employee)
used the Dynix version of RCU to create a patch for Linux RCU which was
incorporated into Linux.
For example, Mr.
Gupta testified:...

"IBM thereafter released Dynix, with a copied and modified UNIX
RCU in
Dynix, into Linux. More specifically, the Dynix version of RCU was used
by IBM
employee (and former Sequent employee) Dipankar Sarma to create a
software patch
for placing a substantially similar version of RCU into
Linux. I believe that the first
patch appears to be for Linux version
2.4.1 and was contributed
by Mr. Sarma. See Exhibit E. A paper entitled 'Read-Copy
Update' also lists Mr. Sarma
along with Mr. McKenney and others as authors. See Exhibit F.
Another patch was also
provided to Linux version 2.5.44 by IBM employee Mingming Cao. See
Exhibit G. This
patch appears to be incorporated into the Linux version 2.6." Gupta
Declaration at ¶29.

They'll have to prove all that now, starting with RCU being based on or a derivative or modification of System V. Discovery is over. It's too late for arguments about what SCO could prove if it only had more discovery. It's time to put the conclusions on the table, the proof. Even if they could trace "code similarities", with respect to Dynix it doesn't mean anything anyway, because Dynix isn't related to System V, McKenney says. It's based on BSD. Is that not funny? And RCU is original work.

I suppose SCO thought it was making IBM's life harder with onerous discovery requests. Perhaps it thought it could force IBM to settle that way. But in actuality, SCO dispatched itself on a wild goose chase, and SCO paid the lawyers for every billable minute of it, money I'll bet SCO wishes it had right about now. This is why I keep asking, is there nobody at SCO, let alone at BS&F, who knows anything about the history of Unix and BSD? To be fair, SCO doesn't have access to the inventor of RCU the way IBM does. From what jungle drums are telling me, it doesn't have access to a lot of engineers any more period.

Well, SCO's in a crash course now. And this IBM motion is the pop quiz. It's time to answer meaningfully, not with guesses or maybes or could have happened but with some proof, including evidence that Dynix is *not* based on BSD or that SCO has some claim on it anyway. Even if SCO could prove that, it still doesn't matter, because IBM points out that the contract is to be interpreted according to New York law, which law is that contract claims must be brought within six years or you lose the claims. How can SCO get past that one hurdle alone? They certainly can't show that New York's statute of limitations isn't 6 years for contract claims. Can they try to say the contract wasn't to be enforced under New York law? I'm sure they are racking their brains trying to think of something. If you go to Groklaw's Contracts page, you'll find the Sequent agreement [PDF] and a couple of additional documents, and sure enough on page 6 of the agreement, you find:

7.13 The construction and performance of this Agreement shall be governed by the law of the state of New York.

One can't help but wonder why no one on the SCO team thought to check which law the Agreement was to be enforced under or what the statute of limitations is in New York for contract claims. You don't need to be a tech genius to do that.

Poor SCO. Foiled again. And as ever, even if it climbs every mountain, there, just before the summit, stands the mighty GPL, blocking SCO from victory anyway. And, just as an ironic aside, it seems to me SCO is in a bit of a pickle. If they were successful in demonstrating that RCU is in System V and that by touching System V code, Sequent lost its independent code to SCO's control, and if SCO could also prove that the GPL is void, considering that it is the GPL license that allows anyone use of Sequent's patented RCU, and the patent remains in Sequent's name, the end result of their effort would seem to be that then SCO would then be in violation of Sequent's patent. Oh, joy.

It certainly does appear that the RCU Follies, as I call this aspect of the litigation, are soon to be over, unless SCO can come up with something new and monumental. In a perfect world, it never would have come up in the first place.

Attorneys for Defendant/Counterclaim-PlaintiffInternational Business Machines Corporation

IN THE UNITED STATES DISTRICT COURTFOR THE DISTRICT OF UTAH

_______________________________

THE SCO GROUP, INC.,

Plaintiff/Counterclaim-Defendant,

v.

INTERNATIONAL BUSINESS MACHINES
CORPORATION,

Defendant/Counterclaim-Plaintiff.

_______________________________

DECLARATION OF PAUL MCKENNEY

Civil No. 2:03CV-0294 DAK

Honorable Dale A. Kimball

Magistrate Judge Brooke C. Wells

I, Paul McKenney, declare as follows:

1. I am currently employed by International Business Machines Corporation
("IBM") as a Distinguished Engineer in IBM's Linux Technology
Center ("LTC"). I have worked for IBM since 1999.

2. This declaration is submitted in connection with the lawsuit brought by
The SCO Group, Inc. ("SCO") against IBM, titled The SCO Group,
Inc. v. International Business Machines Corporation, Civil No.
2:03CV-0294 DAK (D. Utah 2003). I make this declaration based upon
personal knowledge.

3. I understand that SCO has alleged in Item 2 of its Final Disclosures
that I disclosed DYNIX/ptx RCU (Read-Copy Update) to Linux.

4. Before it was acquired by IBM, I worked for Sequent Computer Systems,
Inc. ("Sequent"). At Sequent, John D. Slingwine and I invented a
technique called Read-Copy Update ("RCU"). RCU is an operating
system synchronization mechanism that allows concurrent reading and
updating data while maintaining data coherency.

5. Sequent
filed a patent application for RCU on July 19, 1993, and the patent
was granted on August 15, 1995. (See Exhibit 1 (U.S. Patent
#5,442,758 (describing the parallel RCU infrastructure)).) In
subsequent years, further patents were granted based on the same
patent application. (See Exhibit 2 (U.S. Patent #5,608,893
(describing the use of RCU to synchronize data between a pair of
SMP/NUMA computer systems)); Exhibit 3 (U.S. Patent #5,727,209
(describing doing an atomic update by copying the data item,
updating the copy,

2

and then substituting the updated copy into the
data structure)); Exhibit 4 (U.S. Patent #6,219,690 (describing the
"change in mode" aspect of RCU)).)

6. I have published a number of papers on RCU. One of these papers was
"Read-Copy Update: Using Execution History to Solve Concurrency
Problems" (with John D. Slingwine), which describes and analyzes
the RCU mechanism in DYNIX/ptx, describes application to linked list
update and log-buffer flushing, defines 'quiescent state', and
includes both measured and analytic evaluation. (See Exhibit 5).

7. In developing RCU, I did not review or use any code, methods or
concepts from the Unix System V operating system. I developed RCU
using publicly described operating system primitives including
locking, memory allocation, and scheduling-clock interrupts, for
example, as provided by DYNIX (a Berkeley Software Design-based)
operating system. In fact, to the best of my knowledge, System V
does not contain code, methods or concepts relating to RCU.

8. The RCU material that IBM has contributed to Linux was original IBM
or Sequent work; it did not include Unix System V material; it was not
a modification or derivative work of Unix System V; and it was not
made with reference to Unix System V.

9. I am familiar with the Linux implementation of RCU. As I previously
testified in my deposition in this case, the Linux implementation of
RCU is an implementation of concepts published in the RCU patent
issued in 1995. (See Deposition of Paul McKenney at 117-121.)

3

10. I declare under penalty of perjury that the foregoing is true and
correct.

Attorneys for Defendant/Counterclaim-Plaintiff International Business Machines Corporation

________________________________

IN THE UNITED STATES DISTRICT COURTFOR THE DISTRICT OF UTAH

_______________________________

THE SCO GROUP, INC.,

Plaintiff/Counterclaim-Defendant,

v.

INTERNATIONAL BUSINESS MACHINES
CORPORATION.

Defendant/Counterclaim-Plaintiff.

___________________________

DECLARATION OFPAUL MCKENNEY

Civil No. 2:03CV-0294 DAK

Honorable Dale A. Kimball

Magistrate Judge Brooke C. Wells

I, Paul McKenney, declare as follows:

This declaration is submitted in connection with the lawsuit
brought by The SCO Group, Inc. ("SCO") against IBM, titled The
SCO Group, Inc. v. International Business Machines Corporation,
Civil No. 2:03CV-0294 DAK (D. Utah 2003). I make this declaration
based upon personal knowledge. I previously provided testimony
in this case, which I incorporate herein.

I am currently employed by International Business Machines ("IBM").
Prior to joining IBM, I worked for Sequent Computer Systems,
Inc. ("Sequent"). I understand that SCO claims IBM has
breached the UNIX licensing agreements between AT&T and Sequent
(the "Agreements") by using, exporting, disclosing or
transferring DYNIX/ptx source code, regardless of whether IBM
has used, exported, disclosed or transferred any protected UNIX
System V source code. That theory is inconsistent with both how
I understand the AT&T Agreements and how, by their own account,
AT&T's representatives explained them.

Subsequent to the execution of the Agreements, Sequent invested
in the development of its own operating system for
multiprocessors, DYNIX/ptx. It did so based on the understanding
that AT&T claimed no interest in Sequent's original works,
even if such a work might be included in a modification or
derivative work of UNIX System V.

Sequent invested tens of millions of dollars in and devoted
hundreds of person-years to developing DYNIX/ptx, including
writing substantial amounts of original source code. Had Sequent
understood AT&T to have control over not only the UNIX System V
code in DYNIX/ptx, but over all material that Sequent developed
itself, Sequent would not have made such investments of money
and manpower.

2

In addition, Sequent also applied for numerous patents for
technologies related to DYNIX/ptx. Because Sequent understood
that the Software Agreements did not require Sequent to hold
DYNIX/ptx methods in confidence for AT&T, it was free to apply
for patents related to DYNIX/ptx methods and thus disclose such
methods to the public.

I declare under penalty of perjury that the foregoing is true
and correct.

Attorneys for Defendant/Counterclaim-Plaintiff International Business Machines Corporation

________________________________

IN THE UNITED STATES DISTRICT COURTFOR THE DISTRICT OF UTAH

_______________________________

THE SCO GROUP, INC.,

Plaintiff/Counterclaim-Defendant,

v.

INTERNATIONAL BUSINESS MACHINES
CORPORATION.

Defendant/Counterclaim-Plaintiff.

___________________________

DECLARATION OFDEPANKAR SARMA

Civil No. 2:03CV-0294 DAK

Honorable Dale A. Kimball

Magistrate Judge Brooke C. Wells

I, Depankar Sarma, declare as follows:

I am currently employed by IBM India Private Limited, a wholly owned subsidiary of International Business Machines Corporation ("IBM"), as a Senior Software Engineer. I have worked for IBM since 1999. Before it was acquired by IBM in 1999, I worked for Sequent Computer Systems, Inc. ("Sequent").

This declaration is submitted in connection with the lawsuit
brought by The SCO Group, Inc. ("SCO") against IBM, titled The
SCO Group, Inc. v. International Business Machines Corporation,
Civil No. 2:03CV-0294 DAK (D. Utah 2003). I make this declaration
based upon personal knowledge.

I understand that SCO has alleged in Item 2 of its Final Disclosures that I disclosed Dynix/ptx RCU (Read-Copy Update) to Linux. While at Sequent, I did not work on RCU.

In 2000 I joined IBM's Linux Technology Center, where I have personally made Linux contributions relating to RCU. In developing the Linux RCU, I never reviewed or used any non-public code, methods or concepts from the Unix System V operating system.

The RCU material that IBM has contributed to Linux was original IBM or Sequent work; it did not include Unix System V material; it was not a modification or derivative work of Unix System V; and it was not made with reference to Unix System V.

2

I declare under penalty of perjury of the laws of the United States that the foregoing is true
and correct.