SAS Institute: functional compatibility and copying protected expression

A second program with similar behaviour

SAS supplied an analytical system. World Programming developed a product capable of running its users' scripts. According to the findings described in the reference, WPL had no access to SAS source code and did not decompile its object code; it studied the program's behaviour and consulted documentation. The dispute also concerned manuals and licence terms (paragraphs 23–28 and 44). ^[1]

Methodologically, a product name does not identify a single protected subject matter. Code, a function call, a command description in a manual and a test dataset may require different questions. A report saying that a program was copied should first explain the specific material and acts hidden within that shorthand.

Three answers given on 2 May 2012

The Court held that program functionality, programming language and the file format used to exploit functions are not forms of expression protected as that computer program. It permitted observation, study and testing by a licensee under the conditions stated in the judgment. Separately, reproducing creative expression in a manual could infringe copyright (paragraphs 39–46, 50–62 and 63–70). ^[1]

The judgment interpreted Directive 91/250. Its codified successor, Directive 2009/24, preserves the distinction between ideas and expression and the rules on observation and testing. Article 6 concerns a different mechanism: decompilation for interoperability, subject to conditions. Studying behaviour and decompilation should therefore not be presented as a single unrestricted activity. ^[2]

Absence of protection as expression of a program does not automatically exclude every form of protection. In paragraph 45 the Court preserved a separate assessment of language and format as works under Directive 2001/29 if they constitute the author's own intellectual creation. The legal basis and subject matter must therefore be identified precisely. ^[1]

Editorial method: an independent-implementation record

The proposed record starts with materials available to the team: lawfully obtained copies, public documentation, its own measurements and external libraries. For each item, record the source, version, acquisition date and restrictions. Repository history can help reconstruct code creation, but does not by itself explain whether the author previously consulted someone else's protected expression.

Next prepare a functional specification describing inputs, outputs, conditions and observable errors without transferring passages from a manual. Test authors should distinguish their own control cases from examples taken from documentation. Comparisons should preserve input data, environment parameters and product versions. One matching result establishes neither copying nor full compatibility between systems.

Separating specification work from implementation, with a record of material passing between teams, may be useful. This is an editorial suggestion for reducing evidential uncertainty, not a statutory guarantee of legality sometimes associated with the label clean room. The process label cannot replace information about who actually saw the material and what entered the product. Preserve mismatches and decisions to redesign independently as well.

Example: migrating a company's reporting system

A hypothetical company wants to run its own reporting scripts on a new system. Divide the project into command parsing, calculations, file import and the manual. Prepare a provenance card for each layer. An old manual may identify functions, but the new manual needs a separate review of wording, structure and examples.

The team tests empty files, invalid formats, national characters and boundary values. Its report explains which behaviours are needed for the user's task and which were reproduced merely out of habit. That does not automatically decide infringement. The exercise identifies the origins of technical decisions and matters requiring separate review of contracts, copyright or trade secrets.

Literature and the limits of comparing precedents

Gerald Spindler published Grenzen des Softwareschutzes: Das Urteil des EuGH in Sachen SAS Institute, Computer und Recht 28(7), 2012, 417–422, DOI 10.9785/ovs-cr-2012-417. The publisher confirms the bibliographic record. It is a route to further reading; we do not claim to have read an unavailable full text or attribute our project-management proposals to its author. ^[3]

Read SAS alongside, but separately from, the US Google v Oracle case. Their legal foundations and questions differ. For a Polish project, begin with EU law and its Polish implementation; use comparison to clarify the technical issue. Do not substitute the American fair-use test for the European distinction between ideas and expression, or the other way round.

Finish with a list of material intended for publication: functional descriptions, graphics, manuals, examples and error messages. Each needs a separate provenance check. Independently written code might otherwise be distributed with someone else's unreviewed manual or illustration. Product verification should include the documentary material reaching the user with it.

Sources and further reading

1. 1
   CJEU, SAS Institute v World Programming ↗

   C-406/10; ECLI:EU:C:2012:259; 2.05.2012; CELEX:62010CJ0406

   Primary source; facts paragraphs 23–28, protection 39–46, testing 50–62, manual 63–70.

2. 2
   Directive on the legal protection of computer programs ↗

   Directive 2009/24/WE, art. 1 paragraph 2, art. 5 paragraph 3, art. 6 and 8; CELEX:32009L0024

   Codified successor to Directive 91/250 examined in the case; distinguishes observation from decompilation.

3. 3
   Gerald Spindler, Grenzen des Softwareschutzes: Das Urteil des EuGH in Sachen SAS Institute ↗

   Computer und Recht 28(7), 2012, 417–422; DOI:10.9785/ovs-cr-2012-417

   Publisher metadata verified: print issue July 2012, online record 3 April 2013. No attribution of propositions from an unavailable full text.