IBM's summary judgment motion [LWN.net]

The core of the suit filed by the SCO Group against IBM is a set of breach-of-contract allegations. SCO is saying that IBM, through its contributions to Linux, has violated the Unix licensing contracts signed with ATT years ago. SCO's rather broader public claims have tended to overshadow the much more restricted nature of the actual case at hand, but that is what the real issue is. IBM has concluded that the time has come to put an end to those charges, however, and has filed for a partial summary judgment which would dispose of the contract case. The supporting memorandum is available as a 100-page PDF file. Your editor, who has not had a chance to rip into this sort of meaty legal document for a while, has been through the whole thing; the following is a summary of what IBM is saying.

IBM goes on at great length on why it believes the judgment should be entered. The core of the argument reads this way:

There is very little of the original Unix code in either AIX or Dynix.
Of that code which remains, IBM has contributed none of it to Linux.
SCO's interpretation of the license, which would give SCO rights over any code which ever went near AIX or Dynix, is nonsensical. SCO has no rights over IBM's code which it developed itself.
Even if the license agreement did, somehow, give SCO those rights, Novell has the right to waive licensing enforcements, and has done so in this case.
SCO, by virtue of continuing to publish the contested code itself, has forfeited any rights it may have had to keep others from doing so.
SCO's right to terminate IBM's AIX and Dynix license (the basis of two of SCO's charges) does not exist, and, if it did, it would be overridden by Novell's waiver.

As followers of the flotilla of SCO cases have been reminded many times by now: a motion for a summary judgment must show that there are no disputed facts at issue. For IBM to prevail here (and avoid a longer trial on these charges), it must show that all the facts are on the table and are not contested. The standards are high for this sort of motion; if you want to short out a real trial and dump a set of charges against you, you must have a truly convincing argument.

Direct copying of code

The first two points above (direct copying of code) are argued early on, in ¶7:

SCO alleges that it has found approximately 74,000 lines of UNIX System V code in AIX and approximately 78,000 lines of UNIX System V code in Dynix... SCO does not contend (and in any case has no evidence) that IBM has misused any of these lines of code.

One of the best ways of establishing an "undisputed" fact, obviously, is to use the opposite side's statements against them. IBM does not stop there, however; the company brought in its own MIT scientist (and a high-profile one at that: Randall Davis) to compare IBM's Linux contributions against the SYSV code base. Mr. Davis concluded that, as one might expect, there is no SYSV code (or even similarities to SYSV code) in IBM's work, which is, thus, not a derived work of SYSV. The memorandum does not state whether Mr. Davis developed a deep semantic theory to that effect, however.

Finally, IBM repeatedly points out that SCO was never able to provide any examples of SYSV-derived code contributed to Linux, and that SCO is not arguing that such a contribution has occurred:

Moreover, SCO's responses to IBM's interrogatories do not identify any UNIX System V source code from which any of the code IBM contributed to Linux is allegedly derived. Indeed, SCO refused to provide such information because it "is not part of SCO's claims". (¶59).

Thus, says IBM, the lack of any direct use of SYSV-derived code in violation of the license agreement is undisputed.

What the license says

SCO still seems to believe that it has a case, however. That case depends on a very broad reading of the Unix license contract signed between ATT and IBM almost 20 years ago. From ¶62:

SCO's contract claims instead rest entirely on the proposition that "[t]he AIX work as a whole and the Dynix/ptx work as a whole are modifications of, or are derived from [UNIX] System V". Under SCO's theory of the case, all of the tens of millions of lines of code ever associated with any technology found in AIX or Dynix, even if that code does not contain any UNIX System V code, is subject to the restrictions of the IBM and Sequent Software Agreements.

SCO, in other words, claims to own anything which ever might have breathed the same air as SYSV Unix. This interpretation has been clear for some time, and IBM has gone to great lengths to get SCO to commit itself (in court) to that position. IBM now hopes to demonstrate that, beyond any possibility of dispute, the license contracts do not give SCO the rights it thinks it has.

The first step in that process was to hold depositions with all of the people involved in the writing and signing of those contracts. So they tracked down all of the IBM, Sequent, and (crucially) ATT people who were involved in the process and queried them about the intent of the license language. Everybody involved, on both sides of the table, agreed that the contract was never intended to give ATT (or any of its successors) power over code which it did not develop. There are many pages of quotes to this effect. Here is one example, from Michael DeFazio, who ran ATT's Unix product management, marketing, and licensing group, and who said:

The [software] agreements did not (and do not) give AT&T, USL, Novell, or any of their successors or assigns the right to assert ownership or control over modifications and derivative works prepared by its licensees, except to the extent of the original Unix System V source code included in such modifications and derivative works.... I do not believe that our licensees would have been willing to enter into the software agreement if they understood Section 2.01 to grant AT&T, USL, Novell, or their successors or assigns the right to own or control source code developed by or for the licensee. (¶90).

Several of the ATT people involved are also quoted as stating, flat out, that SCO's claims are wrong.

IBM notes that, under New York law (which is the law governing its agreement with ATT), sworn statements from both parties to a contract are the most compelling evidence with regard to the intent of the contract. So, if there were any ambiguity in what the contract means (which, says IBM, there is not), the testimony from the relevant IBM, Sequent, and ATT people would be more than sufficient to straighten things out.

Not content with that, however, IBM argues this issue from several other points. It brings up the old issue of $ echo describing ATT's intent, and the "side letter" signed with IBM and various other licensees. ATT also redrafted the paragraph in question at some point; the people involved stated that the change was only to make the intent clearer, and did not actually change the license terms. IBM states that SCO's interpretation of the contract is simply absurd and unreasonable, and thus not enforceable. And finally, IBM cites federal copyright law and its provisions regarding rights over derivative works.

Waivers

IBM believes that it has shown that there is no possible interpretation of the ATT license contract which favors SCO's position. But, says IBM, even if that argument were to fall apart entirely, it doesn't matter: Novell has waived any alleged breaches by IBM. The agreement between Novell and the Santa Cruz Operation ("old SCO") is murky in several ways, but it seems clear that Novell retained the right to shut down enforcement of Unix license agreements at its will. Says IBM:

Novell's letters to SCO establish as a matter of law that even if SCO had the right under the IBM and Sequent Software Agreements to prevent IBM from disclosing its or Sequent's original code, Novell explicitly waived that right.

If that isn't enough, IBM also claims that SCO, itself, has waived any enforcement rights through its own distribution of Linux.

In this case, SCO's acts and conduct are plainly inconsistent with an intention to assert a breach of contract against IBM based on the code allegedly at issue. Both before and even after SCO sued IBM, SCO sold to customers and made publicly available on the Internet the code that it claims IBM improperly contributed to Linux. Indeed, this code was still available on SCO's website as recently as August 4, 2004. SCO cannot on the one hand market and sell the source code IBM contributed to the Linux operating system, and on the other hand claim that IBM was prohibited by its licensing agreements from contributing that code to Linux.

In support of this position, IBM has dug up old SCO press releases and such proclaiming features like journaling filesystems, SMP scalability, asynchronous I/O, etc. As many people have pointed out over the last year, SCO has dug itself into a deep hole with its own Linux distribution activities.

License termination

Two of SCO's charges against IBM have to do with SCO's "termination" of IBM's Unix licenses. This termination, says SCO, deprives IBM of the right to distribute AIX or Dynix. It also, incidentally, is said to deprive all users of those operating systems the right to keep running them - a risk of proprietary code that, one assumes, most users were not expecting to have to deal with.

IBM's motion deals with these actions almost as an afterthought. If IBM has truly not breached the Unix agreements, then SCO's "termination" is clearly beyond its powers. IBM states that SCO has no right to terminate the license in this way in any case, however; quoting Novell:

Pursuant to Amendment No. X, however, Novell and SCO granted IBM the 'irrevocable, fully paid-up, perpetual right' to exercise of of the rights under the IBM SVRX Licenses that IBM then held. IBM paid $10,125,000 for the rights under Amendment No. X. Novell believes, therefor, that SCO has no right to terminate IBM's SVRX Licenses, and that it is inappropriate, at best, for SCO to be threatening to do so.

Even without this argument, however, Novell's waiver of enforcement rights should be adequate to counteract this "termination."

Conclusion

IBM's motion for a partial summary judgment is thoroughly and comprehensively argued; the company would appear to have covered all of the bases. If IBM's argument holds water with the judge, the core of SCO's case will have been demolished, and the collapse of the entire house of cards will not be far away. This motion is an ambitious attempt to put an end to this whole affair.

It is interesting to see which arguments do not appear in this memorandum. In particular, there is no reference to the whole issue of who really owns the Unix copyrights other than little digs like saying that SCO "purports" to have acquired them. The copyright ownership issue could, by itself, torpedo everything SCO is trying to accomplish. But the ownership of the copyrights is very much a disputed fact, and, as such, it is not a useful argument in support of a summary judgment.

If IBM succeeds with this motion, the SCO case is done. It would be far too soon to conclude that this will come to pass, however. The next step will be a response from SCO, followed by arguments in front of the judge. SCO will do its best to drag up facts which, it will claim, remain in dispute. We may see expert witnesses claiming that, testimony from the principals involved notwithstanding, the ATT license agreements have a broader meaning than IBM is claiming. SCO may try to claim that it hasn't been able to come up with the facts because IBM has been "stalling discovery." And so on. If SCO can create enough fog around IBM's arguments, it might just succeed in defeating this motion and forcing the whole thing to go to a full trial. In that case, we would have to wait until next year for the outcome.

(Log in to post comments)

IBM Memo has interesting implications for GPL interpretation

Posted Aug 17, 2004 23:08 UTC (Tue) by ami.ganguli (subscriber, #9613) [Link]

This has occurred to me as well. One thing to notice, however, is that not every GPL user believes this.

The bottom line is that the definition of 'derivative work' is a question of copyright law. Presumably it's easier to make the case that your work is not derivative if the binaries are not linked, but there may be cases where a separate binary _is_ derivative, and there may be cases where a linked binary is not derivative. It will depend on the specifics of the code and how the court interprets the situation.

IBM Memo has interesting implications for GPL interpretation

Posted Aug 18, 2004 1:15 UTC (Wed) by melevittfl (guest, #5409) [Link]

"If you read the memorandum carefully, you will note that at one point
IBM discounts the notion that including Sys V code into AIX fails
to make the rest of AIX a derivative work. "

No, you're misunderstanding the issue.

SysV + Other code = AIX. IBM has never disputed that AIX contains Unix code. Therefore, AIX, as a whole, is a derivitive work of Unix.

IBM is pointing out that Other code on it's own is a) not a derivitive work under copyright law, and b) not intended to be covered by the contract.

The GPL uses the same definition:
GPL code + Your code is a derivitive work of the GPL code.
You code on it's own is still yours. If you remove all the GPL code from your code, you can do what you want with it.

Exactly ... furthermore

Posted Aug 18, 2004 3:25 UTC (Wed) by AnswerGuy (subscriber, #1256) [Link]

If I create a derivative work of GPL then all of the code I wrote myself is still mine and can be cross-licensed under any terms that I like (and that anyone would be silly enough to accept).

You are both mistaken, sorry.

Posted Aug 18, 2004 5:43 UTC (Wed) by hummassa (subscriber, #307) [Link]

Both you and the parent poster are mixing derivative works with
"compilation" (or anthology) works.

I will try to explain this to you based on Brazilian law, but
this /should/ apply equally to USC17 (USofA law) and other
jurisdictions', also. Anyway, IANAL and TINLA.

Derivative works are works that have identity (they are novel
intellectual works) but are the result of some (non-automated -- or else
they wouldn't be intellectualy novel) transformation on the original
works.

Anthology works have intellectual merit on the selection or the
organization of the contents... but the contents, per se, are other
separated works.

The copyrights of derivative works are not exclusive -- they are
"blended" (condominium?) between the authors of the original and the
derivative works.

The copyrights of anthology works, OTOH, ARE exclusive -- the original
works' authors have the copyrights to it, and the anthologist has the
copyrights of the selection/organization/etc.

Linux -- the kernel, obviously -- is an example of derivative works.
Everytime you get a patch included in the kernel, you have the copyright
on your patch in a non-exclusive manner: all the copyright owners of the
version of Linux you based your path on (ie, you TRANSFORMED by applying
your patch to) are co-copyright-owners of your patch (this is a
simplification -- you can prove, for instance, that your patch is not
based on iptables/alsa/some other part of the kernel or does not
transform it -- but there is a large part of the kernel that your patch
transforms, so it *is* a derivative work of).

Debian -- the distro -- is an example of compilation/anthology works. The
selection/organization of its packages are copyrighted by the Debian
project; while the pacakges individually are copyrigthed by the upstream
authors, and probably by the packagers/maintainers also.

The GPL tries (wrongly) to determine what is or not a derivative work by
saying "if you link, it's a derivative work", but this is *not* true. The
better way to read the GPL is: "If you don't link, then it's not a
derivative work. But if you do, you are generally augmenting your program
by using my program/library and augmenting my program/library by using
your program, so it has a great probability of being a derivative work."

HTH

Massa

Terminology.

Posted Aug 18, 2004 7:03 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

The GPL tries (wrongly) to determine what is or not a derivative work by saying "if you link, it's a derivative work", but this is *not* true. The better way to read the GPL is: "If you don't link, then it's not a derivative work

I think you're getting muddled. The GPL does not mention linking at all, except in passing in the final paragraph. It defers to copyright law on the matter of what a derivative work is.

I wish people would stop using the term 'derived work' as if it were equivalent to "work which GPL terms require to also be GPL'd".

The 'infection' of the GPL does not apply only to derived works. If you have a collective work which is based on a GPL'd Program, and identifiable sections of that work can reasonably be considered independent and separate works in themselves, then the GPL doesn't apply to those sections when you distribute them as separate works.

But when you distribute the same sections as part of a whole which is a collective work based on the GPL'd Program, the distribution of the WHOLE must be under the terms of the GPL. The permissions for other licensees extend to the entire whole; to each and every part regardless of who wrote it.

For "a whole which is a collective work based on the GPL'd Program" consider, by way of example, the firmware for an embedded Linux router. For "independent and separate work distributed as part of that whole" consider a binary-only kernel module distributed as part of that whole.

I disagree.

Posted Aug 18, 2004 8:06 UTC (Wed) by hummassa (subscriber, #307) [Link]

One contradiction: " The GPL does not mention linking at all, except in passing in the final paragraph. " The fact is: the GPL mentions linking, in its last paragraph. It's the last paragraph of the "postamble", it's true, but it mentions it in a very authoritative way.

Now another part of your argument: " The 'infection' of the GPL does not apply only to derived works. "... Section 0 defines a "work based on the Program" authoritatively as "either the Program or any derivative work under copyright law" -- the "that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language" is an explanation (begins with that is to say), but not only this, it's a *wrong* explanation because it mixes derivatives and anthologies. IMHO the "explanation" part is a NOOP because of that.

IRT the same argument, there is still the question of the "explanations" contained in the postable for the section 2: The 2nd paragraph explains that "the intent is to exercise the right to control the distribution of derivative OR COLLECTIVE works based on the Program" (emphasis mine -- sorry for the caps) but the 3rd paragraph comes to contradict it, saying that "mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License" which, basically, defines what a collective (=anthology) work is.

Linus has done his homework, and studied USC 17 (I don't have the pointer right now); so have I, studying Brazilian applicable laws (Author's Rights Act [9610/98], Computer Programs Act [9609/98], and Industrial Property Rights Act [9279/96]). And I have a very clear opinion that is "in tune" with Linus': the GPL only restricts redistribution of derivative works -- the "mere aggregation" clause encompasses anthology works; to determine what is a derivative work, you have to follow the steps of abstraction, filtration and comparison. Linking does not make a derivative work. The GPL, in last paragraph of the postamble, exempts non-linking works from being considered derivative works, [reference: estoppel].

One last comment on _why_ I think the "mere aggregation" clause encompasses _all_ anthology works: if it doesn't, you fall in the "slippery slope" thing. The "gold standard" for determining what is a derivative work exists (abstraction, filtration, comparison). Other than that, a license can waive rights, but not try to acquire other rights (ok, in some jurisdictions, it can, but a Free license shouldn't anyway and the GPL has the intention of being a Free license).

I disagree.

Posted Aug 18, 2004 9:27 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

One contradiction: " The GPL does not mention linking at all, except in passing in the final paragraph. " The fact is: the GPL mentions linking, in its last paragraph. It's the last paragraph of the "postamble", it's true, but it mentions it in a very authoritative way.

The final paragraph looks like just an advert for the LGPL to me:

This General Public License does not permit incorporating your program into
proprietary programs.  If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library.  If this is what you want to do, use the GNU Library General
Public License instead of this License.

It is restating a restriction. I certainly can't see any support for your claim that it "exempts non-linking works from being considered derivative works".

I disagree with your assertion that the 'mere aggregation on a volume of a storage or distribution medium' clause contradicts the part about collective works. The GPL clearly intends to make a distinction between the act of collecting a handful of software packages onto a CD for distribution, and the act of producing a coherent work which is based in part on the GPL'd work.

Not only is it clear that this is what is intended, it is also clear that the author of the GPL'd code in question has the right to do so -- it's perfectly within the rights of the author to state that the work may only be redistributed as part of a larger work if certain conditions are met.

One last comment on _why_ I think the "mere aggregation" clause encompasses _all_ anthology works: if it doesn't, you fall in the "slippery slope" thing.

That sounds more like a reason why you think the "mere aggregation on a volume of a storage or distribution medium" clause should encompass all anthology works; not a reason why it does. The GPL clearly makes a distinction between what we shall abbreviate to "mere aggregation" and the production of a more coherent collective work. The precise boundary between those two may indeed be a grey area, but it is not for us to declare that this means it doesn't exist.

IANAL and TINLA

Posted Aug 18, 2004 11:02 UTC (Wed) by hummassa (subscriber, #307) [Link]

I am just a (now-working-in-another-field) paralegal, but I am pretty sure my research is valid, at least WRT Brazilian Law; I am very certain that my arguments hold in other jurisdictions, too, because basically all copyright law are some "translation" of the Geneva convention. That said,

" The final paragraph looks like just an advert for the LGPL to me "... but it's part of a section name "how to apply this terms to your program", denouncing the intentions behind the license.

" I certainly can't see any support for your claim that it "exempts non-linking works from being considered derivative works" "... my claim is: *nothing* that is *not* a (non-automatic-,intelectually-novel-) transformation is a derivative work. the GPL specifically uses the "links to" property as a means of attributing some transformation over the works, that I think does not exist. is main(){printf("hello, world\n");} derivative of glibc? I don't think so.

Now, one can argue that when the last para of the GPL attributes derivation to works that link with GPL'd works AND the section 2 attribute derivation to works containing the original work or parts or translations of it except in the case of mere aggregation, it exempts the rest of the universe of works from being derivative. When you try to define what colors are blue, you are implicitly defining that the other colors aren't.

" The GPL clearly intends to make a distinction between the act of collecting a handful of software packages onto a CD for distribution, and the act of producing a coherent work which is based in part on the GPL'd work. "... this I can believe if it comes from Eben Morglen, but in any case, the distinction is not a very practical one. Debian, to me, is a coherent work that functions as a whole, not just the aggregation of separated parts. But who does this distinction? Copyrights law. And copyrights law makes dispositions about the division of copyrights when works are derivative and separation of copyrights when works are anthologies (=collections, =mere-aggregations)

" The GPL clearly makes a distinction between what we shall abbreviate to "mere aggregation" and the production of a more coherent collective work. The precise boundary between those two may indeed be a grey area, but it is not for us to declare that this means it doesn't exist. "... My argument is precisely the opposite. The precise boundary exists, it's defined in the copyright law, and that is what has to be used. Abstraction, filtration, comparison.

Terminology.

Posted Aug 18, 2004 22:21 UTC (Wed) by Ross (subscriber, #4065) [Link]

No. The GPL does not claim to have rights over "mere aggregations". The
combined work must somehow be a derivative of the original GPLed work.

You are both mistaken, sorry.

Posted Aug 19, 2004 12:17 UTC (Thu) by mmarsh (subscriber, #17029) [Link]

My understanding of the GPL is that if you write a piece of code from scratch, it's yours to license as you see fit. If you link it against a GPL'ed library and distribute the resulting binary, then you must abide by the GPL for that work, necessitating the release of your source code. If you release just the source, and no GPL'ed code is included, then you can use any license you like, regardless of how the users compile and link the code. Linking thus only applies to binary distribution.

Returning to the subject of IBM's claim re: AIX and SVRX, even under the GPL, IBM's code for AIX would not be a derivative work of SVRX, even though the OS as a whole, when compiled and linked, is. Using the example of a program that calls printf, writing code that calls printf doesn't create a derivative work, since it could be linked against any library that provides a function called "printf" that has the same semantics. Only when distributed with the actual _version_ of printf from glibc does the latter's license come into play. At worst, IBM might have to accept some relatively small amount of "glue" code in AIX as derivative of SVRX, if SCO could convincingly argue that the semantics of the call to SVRX code are sufficiently unique. Even then, we'd be talking about individual lines, and possibly some structs, that would need to be sanitized to become free of the SVRX restrictions.

You are both mistaken, sorry.

Posted Aug 22, 2004 23:47 UTC (Sun) by dberkholz (subscriber, #23346) [Link]

It could also be argued that AIX is a "transformative" derivative work and as a result no longer subject to the copyright issues.

IBM Memo has interesting implications for GPL interpretation

Posted Aug 18, 2004 9:10 UTC (Wed) by dkite (guest, #4577) [Link]

Both the GPL and the original AT&T contract had to do with conditions
where the original works could be used and distributed.

IBM has shown here that the intent of the AT&T contract was simply to
maintain AT&T ownership of the original code, anything else would belong
to and be controlled by IBM. Everyone involved knew what the deal was,
the terms, etc. They paid AT&T presumably for the privilege, and later
paid Novell 10m or so for an irrevocable license. Hence SCO has no
interest at all in any of IBM's code.

The GPL is essentially an agreement where if IBM were to include some
GPL'd code in an application, or built on an existing application, they
would own the code they wrote, but to be able to distribute the whole
they would have to abide by the terms of the GPL, ie. make source code
available.

If IBM didn't like the terms of the GPL, they have two options. Take the
original GPL'd code out and rewrite (the copyright standards of
derivative works applying here), hence owning all the body of code, or
they could negotiate a relicense with the original authors.

IBM indeed says it would be unreasonable to assume an understanding of
the original AT&T contract to be something as broad as what SCO is
saying, especially when the intent of the parties was obvious. However,
say 20 years from now there is a suit where the original parties, you or
I as a developer released some application under GPL, including
contributions from a dozen other developers, and a large corporation
takes our application and starts contributing substantial amounts of
code, each file marked with the GPL. The suit argues ownership and
control, so you or I and the dozen other developers are interviewed. The
intent of the GPL was clear to all who contributed.

What IBM said doesn't invalidate the GPL. IBM is only stating that you
cannot impose a drastic and unreasonable interpretation on contract
wording.

The GPL is very clear in it's intent.

Derek

IBM Memo has interesting implications for GPL interpretation

Posted Aug 19, 2004 1:16 UTC (Thu) by ekj (subscriber, #1524) [Link]

Sort of.

First, what a "derivative" work is, is an issue of copyrigth-law, not an issue of what the GPL (or any other license) says.

Assume I buy some code X from you, and then add my own code Y to that to produce and sell product XY. Later I contribute some of my code Y to a third project Z, producing ZY.

Now, XY migth quite reasonably be a derivative work of X. That is reasonable. What is *NOT* reasonable, and what SCO is attempting, is to say that ZY (which contains no traces of X) nevertheless is a derived work of X.

IBM Memo has interesting implications for GPL interpretation

Posted Aug 19, 2004 4:41 UTC (Thu) by hummassa (subscriber, #307) [Link]

It depends. Remember that the definition of derivative is "transformation of". If Y was not just added to X, but transformed somehow till the point that XY was possible, then Y *is* a derivative work of X; if Z was transformed in a way that made YZ possible, then Z also is a derivative of X, by way of being a derivative of Y. And this *is* reasonable.