Copyright

Filtering the Code: How Computer Associates v. Altai Brought the Idea-Expression Line to Software

Computer Associates v. Altai adapted the idea-expression dichotomy to computer programs through its abstraction-filtration-comparison test, filtering out elements dictated by efficiency, external constraints, and the public domain.

Lines of computer source code displayed on a dark monitor in a developer workspace
Altai asked how much of a program's nonliteral structure is protectable expression once efficiency and external constraints are stripped away. Shutterstock
Educational content, not legal advice. This article explains general legal concepts. It does not create an attorney–client relationship. For your specific situation, consult a licensed attorney.

On June 22, 1992 (with an amended opinion issued December 17, 1992), the United States Court of Appeals for the Second Circuit decided Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693, on appeal from the Eastern District of New York. The panel comprised Circuit Judges Frank Altimari, Daniel Mahoney, and John M. Walker, Jr.; Judge Walker wrote the opinion. The decision answered a question that Baker v. Selden and Nichols v. Universal Pictures had framed for older media but never for software: how far does copyright protect the nonliteral elements of a computer program — its structure, sequence, and organization — once the literal source code is set aside? The court’s answer, the abstraction-filtration-comparison test, became the dominant analytical framework for software copyright in the United States.

At a glance

  • Case: Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992) (amended Dec. 17, 1992)
  • Court: United States Court of Appeals for the Second Circuit, on appeal from E.D.N.Y.
  • Author: Judge John M. Walker, Jr., joined by Judges Altimari and Mahoney
  • Holding: Nonliteral elements of a computer program may be protected expression, but a court must apply abstraction-filtration-comparison — breaking the program into levels of abstraction, filtering out elements dictated by efficiency, by external factors, and by the public domain, and comparing only the protectable core. On the facts, Altai’s rewritten OSCAR 3.5 did not infringe.
  • Legacy: The leading framework for nonliteral software infringement, adopted or adapted by numerous circuits; a direct application of § 102(b) and the BakerNichols idea-expression tradition to code.

The dispute: a programmer, his old employer, and a rewrite

Computer Associates marketed a job-scheduling program, CA-SCHEDULER, which included a component called ADAPTER. ADAPTER served as an operating-system interface, translating a program’s requests into the commands a particular operating system understood, so that the larger program could run across different IBM environments. A CA programmer left for Altai and, in writing Altai’s competing scheduler, ZEKE, created an interface component called OSCAR. He had taken ADAPTER source code with him, and roughly thirty percent of OSCAR version 3.4 was copied literally from ADAPTER.

When Altai’s president learned of the copying, the company undertook a “clean room” rewrite: eight programmers who had never seen ADAPTER code reconstructed OSCAR’s functionality from specifications, producing OSCAR 3.5. The district court (Judge George Pratt, sitting by designation) found that OSCAR 3.4 infringed and awarded damages, but held that OSCAR 3.5 did not infringe. Computer Associates appealed, contending that even the rewritten OSCAR 3.5 copied protected nonliteral structure. The Second Circuit affirmed.

Reasoning: a three-step method for code

Judge Walker began where Baker v. Selden and § 102(b) require: copyright protects expression, never the idea, process, system, or method a program implements. The difficulty is that a program’s nonliteral elements — its architecture, the way modules call one another, its organization — can be expression or can be the functional skeleton dictated by the task, the hardware, and the demands of efficiency. To sort one from the other, the court announced a three-step test, expressly grounded in Learned Hand’s abstractions approach from Nichols.

Abstraction. First, the court dissects the program much as one would a literary plot, retracing the designer’s steps in reverse. At the most detailed level sits the literal code; above it lie the program’s structure of parameter lists and macros, then its modules and their interactions, then its overall function — the program’s “ultimate function” being the most abstract level, equivalent to a story’s bare theme. This produces a series of levels of abstraction along which protectable and unprotectable material can be located.

Filtration. Second, and this is the analytical heart of the opinion, the court examines each level of abstraction and filters out what copyright cannot protect. Three filters operate:

  • Elements dictated by efficiency. Where the most efficient way to implement a given function leaves the programmer with only one or a very few choices, the merger doctrine applies — efficient design and the idea of the function merge, and the expression is unprotectable. Walker drew this directly from merger’s lineage in Baker.
  • Elements dictated by external factors. The mechanical specifications of the computer, compatibility requirements with other programs, the demands of the industry, and accepted programming practices are the software analog of scènes à faire; structure compelled by these constraints is not protectable.
  • Elements taken from the public domain. Code or design borrowed from common sources or freely available material is, like any public-domain content, outside the program’s protectable core.

Comparison. Third, what survives filtration — the “golden nugget” of protectable expression — is compared against the accused program to assess substantial similarity and to gauge the copying’s qualitative importance to the plaintiff’s program as a whole.

Applying the method, the court found that once ADAPTER’s unprotectable elements were filtered, little of its remaining protected expression survived in OSCAR 3.5; the similarities that persisted were largely attributable to the common operating-system services both interfaces had to accommodate and to functional constraints. OSCAR 3.5 therefore did not infringe.

A second strand of the opinion is its candid policing of copyright’s outer limit. Walker stressed that copyright is “not a substitute for, but is, instead, complementary to” patent protection, and warned against allowing copyright to capture the functional, problem-solving aspects of a program — precisely the Baker v. Selden concern that copyright not become a surrogate patent over a useful art. The court was openly skeptical that copyright is well suited to protecting the utilitarian ingenuity in software, suggesting that if existing doctrine inadequately rewards that ingenuity, the remedy lies with Congress, not with an expansive reading of copyright. That posture has framed software copyright debates ever since.

The court also vacated the district court’s holding that the federal Copyright Act preempted Computer Associates’ state-law trade secret claim, remanding for further analysis — a reminder that functional material denied copyright may still find protection under other regimes.

Open questions

  • How rigorously must courts filter? Critics contend filtration can be applied so aggressively that almost nothing survives, leaving program structure effectively unprotectable; the depth of filtration remains contested across circuits.
  • Where does interoperability end? The “external factors” filter excuses structure compelled by compatibility, but how much copying interoperability justifies is unsettled — a tension that echoes through later interface disputes.
  • Is abstraction-filtration-comparison the right tool for modern software? The test was devised for procedural code on mainframes; its fit for object-oriented design, APIs, and machine-generated code continues to be debated.

Implications

  • Nonliteral structure is protectable in principle but thin in practice. A program’s architecture can be expression, yet efficiency, external constraints, and public-domain filters often leave only a narrow protectable core.
  • Merger and scènes à faire have software analogues. Efficiency-dictated design maps to merger; hardware, compatibility, and industry-standard constraints map to scènes à faire — both rooted in the BakerNichols tradition.
  • Clean-room reimplementation works. Altai’s specification-driven rewrite, performed by programmers with no exposure to the original code, defeated the nonliteral claim and remains a template for lawful reimplementation.
  • Copyright is not a patent. The opinion polices the boundary firmly, leaving the protection of functional innovation to patent law and, where applicable, trade secret.

Frequently asked questions

Did Altai escape liability entirely? No. The court affirmed that OSCAR 3.4, which contained roughly thirty percent literally copied ADAPTER code, infringed. Only the clean-room rewrite, OSCAR 3.5, was held non-infringing.

What is abstraction-filtration-comparison? It is a three-step test for nonliteral software infringement: break the program into levels of abstraction; filter out elements dictated by efficiency, by external factors, and by the public domain; then compare only the remaining protectable expression to the accused program.

How does Altai connect to Baker v. Selden and Nichols? It applies the same idea-expression principle to code. The abstraction step adapts Learned Hand’s Nichols ladder; the efficiency filter embodies the merger doctrine traceable to Baker; and the external-factors filter is the software version of scènes à faire.

Authorities and sources