> The Baker precedent says that the parts of a design that are strictly essential to its function are not copyrightable.
Since all parts of the API code are strictly essential to its function than they are not copyrightable, right? The parts that are not essential to its function lie in the behavior of the system in question instead of the API code, this behavior is codified in the specification of the system. The specification of the system isn't the same as the API code. I think this is a very compact form of what I was trying to convey in my other replies on the thread.
Its being placed into class named java.lang.Math, though, is not. That is a product of the way it is arranged, which is a matter of design, not of necessity. It's hard to imagine any particular reason why a function would need to have "java" in its name in order correctly calculate the maximum of two numbers.
The crux of the case, then, is the copyrightability of those design decisions about how the API members are arranged. The set of specific functions it performs is, as per Baker not the focus of the argument.
To take a hypothetical that cuts much closer to the accounting analogy: imagine if H&R Block came out with tax preparation software with exactly the same capabilities as TurboTax. That would, I believe, be fine, in and of itself, because the functionality itself is not copyrightable. However, if the interface to their tax preparation software were arranged identically to TurboTax's, to the extent that a set of automated UI tests written against TurboTax would also work with H&R Block's app, then we would likely be looking at a case of copyright violation.
But if you want to be interoperable with programs that expect to be able to find the max of two numbers using the specific name "java.lang.Math.max", then the name _is_ part of the function. It's kind of like an electircal outlet. The shape of the outlet doesn't really matter as far as delivering electricity, but if you want people to be able to plug in their existing devices, it needs to be in a shape that is compatible with those devices.
To add more to that, the opinion spends a while talking about why the precedent in the ruling in favor of Activition over making unlicensed games for Sega consoles doesn't apply here, and that's helpful for understanding why arguments about interoperability aren't going well over in the courts. In short, the Court recognized a clear distinction between making things to run on someone else's platform, and making your own platform that is designed to be incredibly cosmetically similar to someone else's, but not actually interoperable with it.
Incidentally, I'm looking to that detail for hope. Most my anxiety around this case concerns its potential implications for the legal standing of projects like WINE. But those projects are unambiguously good faith efforts at interoperability. If the Court ultimately rules against Google, but bases that ruling on the opinion that Google's claims about interoperability were smoke and mirrors, then that would seem to imply that they are specifically ruling against what Google did, and not what open source projects are typically doing.
That's not the full scope of it's function, at least in a technical sense. It's also meant to be a utility system-level method and in Java standard library utility methods follow a certain organizational scheme so as to designate their system-level status. This status implies certain aspects of behavior not codified in the API name. Therefore this sort of organizational scheme can be argued to be of necessity and not merely an arbitrary design decision.
I think the common gap in many comments here (not necessarily yours, but in sibling postings of your original reply to me) is of an understanding between engineers that mostly use APIs and ones that write them. I'm in the latter category, so my perspective differs. APIs do have explicit contracts that are reflected in their parameters, names, etc. They also have an implicit contract, equally critical to their actual functionality, which needs to be accounted for when in use. Many aspects of organization, etc are firmly in this category and I believe no experienced API author can credibly argue otherwise. Thus behavior like this
> a set of automated UI tests written against TurboTax would also work with H&R Block's app
is of necessity to a properly functional API satisfying an implied API contract. A better example would be H&R Block and TurboTax disputing their workflow for a particular tax form because the workflow is a commonly practiced one by accounting professionals. The software workflow codifies an existing practice. By the Baker standard that appears to me not to be a copyrightable item. API code, in my view, is not dissimilar.
Judge Thomas had an interesting exchange re football playbooks with one of the lawyers. In his example, wouldn't it make more sense to state that the proper protection for a football playbook and its associated techniques to be a patent and not a copyright? The truly valuable creativity is embedded in the practice of football tactics and not in the markings of a manual.
I think the key word in your argument is 'implies' and you didn't use the word 'requires'. If the authors of the API are implying the nature of these sets of functions by organizing them under 'system', they are doing so to convey information and an opinion as to the nature of the function. The fact that java.system.out is STDOUT, could be also put into java.io or java.system.unix.out, java.logging.out etc. The 'system' is arbitrary, its not 'required'. For example, the out function does not inspect its package name to determine that this out file outputs to STDERR.
> Its being placed into class named java.lang.Math, though, is not.
Its not essential to the function of the library function.
It essential to the function of the API, which is to interface between the code in the library and consuming code, including (in the case of the APIs used in Android) consuming source code (though not complete existing applications, for various reasons that Oracle wants to be given the weight of negating the idea that interoperability is the purpose at all, despite the fact that this is simply false) designed for the existing Java APIs.
> However, if the interface to their tax preparation software were arranged identically to TurboTax's, to the extent that a set of automated UI tests written against TurboTax would also work with H&R Block's app, then we would likely be looking at a case of copyright violation.
The problem with that analogy is that it is self-evident that being mechanically identical is not a functional requirements (though it may be advantageous) for a human-software interface to work, because humans are intelligent actors that can figure out a UI, within some bounds. On the other hand, a client code unit consuming an API cannot intelligently "figure out" a different API than the one it was designed for: the API is, to the extent that it is intended to support the same functionality, either identical or nonfunctional.
Well, the other problem is that the actual legal precedent on look and feel (while not necessarily decisive because the Supreme Court successfully dodged the issue) goes the other way, anyhow. But even if you were right that an identical interface would be infringing as copying expressive components not essential to functionality for a UI, the analogy fails for an API because of the different requirements for functionality.
It's absolutely essential for interoperability to preserve package layout, class/method names, and argument order. For any Java code you want to run on your Apache Harmony based mobile OS, you have to have the Java package names.
There's a whole section in that opinion I linked above titled, "Google's Interoperability Arguments are Irrelevant to Copyrightability," that's worth reading for a deeper treatment of the issue. In particular, Judge O'Malley (quite reasonably) calls bullshit on the very premise that Google copied the Java APIs in order to achieve interoperability, pointing out that Google did specific things to prevent such interoperability (as an aside, we now know that their desire to do so, and Sun's unwillingness to agree to that, is a major reason why they could not come to terms on a licensing agreement), and was unable to produce any examples of a pre-existing Java program that also runs on Android.
Using the AFC test [1], which seems common throughout the case law cited, how does one distinguish a design decision from a standard programming technique [2] in the context of a programming language's standard library API? By virtue of terminology, it's a standard. Is it defensible because it is a design decision concerning a programming language implementation? Then how does that square with computer languages not being copyrightable? What argument can one make so it can pass the filtration step of the test?
[1] https://en.wikipedia.org/wiki/Abstraction-Filtration-Compari...
[2] Computer Associates Int. Inc. v. Altai Inc.
https://web.archive.org/web/20120310144346/http://ftp.resour...
"in many instances it is virtually impossible to write a program to perform particular functions in a specific computing environment without employing standard techniques." 3 Nimmer § 13.03[F], at 13-65. This is a result of the fact that a programmer's freedom of design choice is often circumscribed by extrinsic considerations such as (1) the mechanical specifications of the computer on which a particular program is intended to run; (2) compatibility requirements of other programs with which a program is designed to operate in conjunction; (3) computer manufacturers' design standards; (4) demands of the industry being serviced; and (5) widely accepted programming practices within the computer industry."
> The crux of the case, then, is the copyrightability of those design decisions about how the API members are arranged. The set of specific functions it performs is, as per Baker not the focus of the argument.
To me, many of the analogies being bandied about don't really capture the distinction you're making. The football playbook for example. Rather than considering the playbook as a description of the game, and thus thinking of what Google did as analogous to copying the playbook, it seems to me that what Google did is analogous to copying the playbook's legend that describes the meaning of the Xs, Os, and arrows that comprise the playbook diagrams, as well as the playbook's table of contents, but none of the actual play diagrams.
To alter the metaphor a bit, Let's say that an author swipes the table of contents for the Lord of the Rings, and nothing else, and writes their own story that conforms to the LotR plot only to the extent that the ToC requires it. Characters and location names that appear in the ToC are used, but nothing else about them is the same. The page numbers don't even have to match as the new work is half the length. We also omit a few things from the ToC, like the several afterwords and appendixes, as well as anything that mentions Tolkien by name. Finally, the work itself isn't called "The Lord of the Rings", but "Doom of Shadows", or whatever.
The work isn't a parody or a satire, nothing is the same except to the extent necessary to make the identical ToC work (in terms of the name, order, and organization of the chapters).
To me, this is a good analogy. The two works are "compatible" in the sense that the ToC is an interface like an API, the ToC and the organization of the book were obviously copied verbatim, but nothing else was.
In this analogy (which presupposes that there are other works that use the ToC as an API), the same sort of questions from this case can be asked: 1. Is the ToC copyrightable per se (since there is obviously some creativity in naming, ordering, and grouping the chapters, but the ToC has slo), and 2. even if it is, is copying it to serve as the outline of a new work fair use?
Does the answer change if the book isn't fiction, eg. a cookbook (dish categories and recipe names, but not the actual recipes) or a textbook (only structure and organization of the subject matter copied, not the actual text or excercises)?
To me it seems fairly obvious that the correct answers are 1. mmmmaybe for the fiction example though I think not, but definitely not for the cookbook or textbook, and 2. It is absolutely fair use for all categories of works, even fiction
One could imagine alternate taxonomies where, e.g., the Math package is divided into Arithmetic, Trig, Comparison, and Advanced sub-packages. Or where they are placed into an Operators package insted of Math.
For example, Rust puts the Max function into the cmp (Comparison) crate of std. This associates them with comparison & equality rather than trigonometry and calculus like Java does.
This is the type of subjective decision-making that qualifies something as original and non-trivial.
