Contemporary judges, including on the Supreme Court, aren't interested in reconciling Oracle's argument with Baker v. Selden; there's no love for Baker. Courts may pay lip service to the notion that ideas can't be copyrighted, but the prospect of ruling as a matter of law that specific, concrete categories of works are categorically not copyrightable (especially if they're not patentable) seems illogical to them. Previous hard exclusions, like those related to automobile designs, textiles, and databases are already on the way out, unfortunately, just like the idea that entry into the public domain is a one-way street. The case law has been slowly moving in this direction for at least 20 years, but it's too painful for many to admit despite judges (e.g. Ginsburg) being crystal clear about the direction they want to take things.

Judge Alsup's original opinion declaring APIs not copyrightable is brilliant and the best argument anyone could possibly make. It is the best argument, period, IMO. But the basic premise is just anathema to the majority perspective on courts' role regarding the application of copyright law.

> Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, including the choices of inputs needed and outputs returned. The same is true for classes. But such inventions — at the concept and functionality level — are protectable only under the Patent Act.

This mixes up the functional aspects of designing methods with the stylistic aspects of API design. Consider something like a 3D Graphics API. Some decisions are functional--for example, minimize call overhead or maximizing batching opportunities. That should not be copyrightable. But a lot of other decisions are stylistic. They make the API more elegant, or orthogonal, or intuitive, but are not functional in and of themselves. For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright.

> The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.

This is ipse dixit. How you view the "idea" depends on your generality. Direct3D and OpenGL have different ways of expressing the concept of creating a Z-Buffer. "Creating a Z-Buffer" is the "idea." There are myriad method specifications that can express that idea.

> To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function.

This is glossing over a major logical leap. It assumes you already have a method with a given signature, and writing the declaration is a mechanical process of specifying what signature corresponds to the method implementation. But what if you design the API by writing the declarations first, and filling in the methods afterwards? (Which is very often how its done!) You can write a method to do a particular thing but give it many different specific signatures.

Yes, it does mix them up. That's exactly what the merger doctrine is intended to do: the expressive character "merges" with the functional character.

From an abstract standpoint it seems that it gives short shrift to the purpose of copyright. But it's necessary if you want to maintain an effective distinction between ideas (including systems and processes) and creative expressions in determining copyrightable subject matter. In practice, if you look hard enough there's almost always some amount of creative originality in any piece of work, no matter how utilitarian it is; originality that by necessity must be copied. (Though Google didn't do itself any favors by stipulating to literally copy+pasting the Java API.) The whole point of the merger doctrine (at least an assertive application of it) is to prevent a court from looking too closely at certain classes of works which, through custom and experience, should be considered as having a principally functional character.

And that's why Google was bound to lose on this particular argument, because the experience and wisdom that begat the merger doctrine--that without a robust merger doctrine the distinction between idea and expression cannot be sustained in practice--has been forgotten. As time marches on earlier precedent has receded into the darkness and Feist becomes the first word on the matter; and all Feist really cares about is creative originality. The entire software industry, AFAICT, universally supports the notion that APIs, per se, shouldn't be copyrightable. (Contrast with software patents, where a substantial fraction do disagree.) But show me an actual implementation or API specification where you could with any degree of confidence [in litigation] separate the expressive from the functional character in a way that preserves the principle and allows you to reimplement the API with minimal risk. Ultimately it's really only viable if you have a special rule for APIs.

Of course, we still have Fair Use, similarity, and other defenses. But those are far more subjective, involve a substantial amount of litigation, and are generally high risk defenses. Without a bright line rule then as a practical matter people should and will be risk averse. Even if a court might judge a particular work functional, it'll never get the chance to say so.

The whole expression-idea dichotomy is a complete fiction. It's certainly not a law of nature. The idea of copyright is rather artificial as well. So it shouldn't be surprising that we will often face such dilemmas and inconsistencies where theory and practice meet. The purpose of the merger doctrine is to give "idea" its due when otherwise "expression" would almost always win out, despite what would be optimal for the promotion of new works. Theoretically the legislature could carve out exceptions, but legislatures suck at that sort of thing, despite what they often teach in law school. More often its the courts, who wrestle first-hand with the ugly technical details and the real-life interests at stake of applying (over years, decades, and even centuries) the abstract concepts, who are best positioned to carve out exclusions or to subtly put their thumbs on the scales to further the ultimate purpose of the law. But, again, this role of the courts is frowned upon today, at least in an area such as this.

I think the disagreement here is as a frequent API author I don't see any stylistic aspect in the design of API code. API code as an artifact itself is purely functional. This distinction becomes important because of the case precedent at hand.

Prior to creating any API, one must have a specification of the system the API is meant to model and control. If one skips writing the specification, that doesn't mean there isn't one, it's just largely in the brain of the implementer and possibly underspecified or inconsistent in spots. Every unit of API code therefore has an implied specification, whether or not a documented, written specification exists.

The API code is simply a mechanical translation of the specification into machine readable form. Parameter names, method names, those do not matter to the technical function of the system they are there solely to enhance use. The specification is possibly a patentable invention. A book describing the specification to a human audience is possibly a copyrightable work.

API code is neither of those things, rather it is an embodied practice of interacting with that specification in a machine-readable form and therefore IMO [IANAL] not eligible for copyright under Baker.

> For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright.

These structures are not inherent to the function of the API code, except incidentally due to implementation details. The purpose of these structures is to model the system being interacted with.

I think part of the misunderstanding here is the contemporary expectation that all code is self-documenting. Which is an admirable goal, but it obscures some important nuances about what an API as opposed to an API contract actually is.

API code, particularly old or highly specialized API code, has a TON of undocumented behavior, quirks, etc that exist. Where do they exist? Besides in the heads (optimistically) of the implementers, it also exists in the specification the API code together with its implementation translate.

> But what if you design the API by writing the declarations first, and filling in the methods afterwards?

Presumably it's the human and not the computer writing the API code so the human has some notion of what the API code is representing. The act of writing this code is translation. Just because the original is not always captured does not mean that it doesn't exist. It must exist for there to be API code in the first place.

* Star Athletica LLC v. Varsity Brands Inc., 137 S. Ct. 1002 (2017)

* DC Comics v. Towle, 802 F.3d 1012 (9th Cir. 2015)

* Golan v. Holder, 565 U.S. 302 (2012)

One of the most important cases for contemporary copyright law was Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991). It was a nominal a win for the defendant, but in fact the opinion set a very low bar and effectively condemned the types of bright-line subject matter exclusions that a robust merger doctrine demands, such as in Baker v. Selden.

IIRC, Alex Kozinski wrote some opinions that best reflect the majority perspective today, but I can't find any good citations right now. His arguments are persuasive, but sort of miss the point. Baker v. Selder and the merger doctrine are classic common law solutions to statutory rights that breed complex litigation and inhibit competition. They're not supposed to be intellectually pure or rigorous defenses of legislative powers. Quite the opposite. But courts are far more conservative today and not inclined to exercise their judicial powers this way, with the notable exception of the First Amendment. In fact, certain First Amendment defenses to infringement are slowly becoming more viable, where once upon a time they were dismissed out of hand.

Star Athletica LLC surprised me in particular. Stripes and chevrons!

I design an API for graphical coding and spend significant creative energy choosing the right words, calling conventions, result types to not only make something intuitive, but emotionally pleasurable to code with

Sometimes I'll spend days writing out possible forms of the API — changing words, tense, syntax, until it looks and feels "right." These aren't arbitrary or purely functional decisions

Do I want my users to "read" text from a file, or "open" the file? Do I want them to handle keyboard events in a simple global function or assign callbacks into a keyboard handler under each character name. How are those callbacks shaped? What's easy to understand?

APIs aren't just restricted simple functions and types. Some may involve the creation of a custom DSL to make it easy to declare functionality in part of your system, or clusters of protocols that work together in very specific ways so users can implement a complex system atop them

I disagree. I think the specification can be, but the API code itself is a mechanical translation of the specification into computer code. Note that abstractions, names, etc are conceived in the specification and are then translated into computer code. Even if you skip the specification step, as sometimes is done, you're then dealing with an implicit, ad-hoc specification.

Edit: To clarify what I'm saying, the "creative design" aspect of what you're talking about and that I'm in no way denying, is meant to be protected via the patentability and not the copyrightability of the end product. The creativity is in the behavior not in the mechanical translation of the behavior for computers to use.

> APIs aren't just restricted simple functions and types. Some may involve the creation of a custom DSL to make it easy to declare functionality in part of your system, or clusters of protocols that work together in very specific ways so users can implement a complex system atop them

Indeed. Yet you're still describing behavior here. A DSL is an example of a specification of one language in terms of another. This is a creative work, I strongly agree! The difference is where does the creativity reside? I don't believe it's in the API code, but in the specification whether written or unwritten and therefore implied.

But certainly the API code contains naming, which is a creative aspect of API design, and in this case naming is used by developers to code against either Oracle's Java implementation, or Google's. In order to allow this Google had to copy the naming created by Oracle for their version of the API in order to attract the large pool of developers who liked and were familiar with that design.

The names that we given our APIs are inherent to their behavior and not necessarily the code. Some languages, such as Swift, even mangle API names when they are used so that their names are non-sensical without de-mangling. So why is the name important? It's important for us to understand what the system is doing, but not to the function of the system itself. This might not seem important for us when doing our work, but in the case of copyrightability it's an important fact based on precedent law.

In this case the naming is an important factor, as that is the competitive advantage leveraged by Google in copying Oracle's Java API. They were able to tap into a developer resource who was familiar with the style, naming and conventions of Java

The API is the interface between the human and the code, and so copying a familiar interface design can be an advantage when building a platform

API Code = header file or interface files or source code artifacts you need to include in order to make use of the system underlying the API.

API design = a behavioral specification which the system represented by the API implements

> In this case the naming is an important factor, as that is the competitive advantage leveraged by Google in copying Oracle's Java API.

My point is it's an important factor in the design specification, not the code. This makes it an invention. Inventions cannot be copyrighted per Baker; they can however be patented.

> They were able to tap into a developer resource who was familiar with the style, naming and conventions of Java

The Baker case specifically addresses this point by saying embodied practices cannot be copyrighted. Java isn't a book, it's an invention so the proper avenue for protection is a patent and not copyright.

> The API is the interface between the human and the code, and so copying a familiar interface design can be an advantage when building a platform

Again this would be arguable as a patent infringement, but here we are discussing copyright and not patents. What you're describing applies to design patents IMO. [IANAL]

I think that's a distinction without a difference; you might as well say that a story is a creative work but translating that story into symbols written on a page is purely mechanical.

People don't seem to grasp that there is a distinction between semantics and representation. You can represent the number 85 in many different ways. In binary, in decimal, in hexadecimal. People can copyright a representation of a number but not the number itself. If you were the first human to invent numbers as a concept, you could indeed patent numbers.

Maybe it helps if we compare this to hardware instead. You can design a CPU. The design digital files are under copyright and if you want they can also be a trade secret. However the physical hardware (i.e. the thing whose representation is your digital design files) is not protected by copyright. If you give someone access to design files e.g. via GPL (or in this case by providing the Java standard library). Then any reader of the design files is allowed to look at the arrangement of transistors and then create their own proprietary design files even though your chip design is under GPL. Copyright doesn't protect semantics. It only prevents 1:1 copies of media. When you look at the min function and see a description of its behavior that is semantics. As it stands right now you are allowed to replicate those semantics. There is no monopoly on finding the smallest of two numbers. With the existence of software patents you could in theory patent these semantics.

Now lets get to the actual problem in question. Oracle is providing users with a representation of its java API via javadoc and the standard library deliverables at least under GPL (I am merely assuming this). What does this mean in practice? Well, first of all everyone has access to the representation of the API even if they don't intend to copy it. But as we already established, Google did not copy the java libraries (unless they did which is obviously a copyright violation and they should lose the trial because of that). They merely took the semantics of the java API and built their own independent implementation of the Java standard libraries. APIs cannot be protected under copyright because the semantics of the API can be copied without triggering copyright protections the same way copyrighting your hardware design files does not prevent someone making a copy of the physical manifestation of your hardware. In the hardware world this is solved by patents which do indeed grant a monopoly on semantics. In the software world this should be solved by patents as well.

TL;DR it is possible to create identical hardware without violating copyright of the design files, it is possible to create an identical API without violating copyright of the original source files

That's the opposite of what you're claiming in the rest of your post.

> However the physical hardware (i.e. the thing whose representation is your digital design files) is not protected by copyright.

That's absurd; if you can copy the physical layout then you can copy the design, so copyright protection for the design would be meaningless.

Unlike patents, which may confer proprietary rights in relation to general ideas and concepts per se when construed as methods, copyrights cannot confer such rights. [1]

[1] https://en.wikipedia.org/wiki/Idea–expression_distinction

https://en.wikipedia.org/wiki/Idea–expression_distinction#Me...

Which is perhaps not surprising, since you say you're an engineer. ;)

Nothing I've said should be construed as denying the richness and brilliance found in the design of software and software-based abstractions.

But that's not what it's about. Lots of things are a work of creative design but not copyrightable. Like a recipe for chocolate chip cookies.

[1]: https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...

See my other reply down thread, but my own reading of Baker seems to indicate this specifically is not a factor. 37 packages vs 1 method should make no difference. Copying one ledger template or copying hundreds is not a violation of copyright in the same way, because copyrights don't extend to methods of practice.

I'll have to read up on the SSO stuff as it appears there are more relevant & recent precedent cases there.

Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages — the "overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods." Copyrightability Decision, 872 F.Supp.2d at 999. The parties and district court referred to this taxonomy of expressions as the "structure, sequence, and organization" or "SSO" of the 37 packages.

The Baker ruling is specifically addressed in that one, and they call out exactly how it is relevant to Oracle v. Google: The Baker precedent says that the parts of a design that are strictly essential to its function are not copyrightable. But the parts that involve some art - such as - according to this opinion - the taxonomy introduced in a package structure - are copyrightable.

In other words, you can think of SSO as shorthand for, "The things that aren't covered by the Baker precedent."

We also have, in the same opinion:

When assessing whether the non-literal elements of a computer program constitute protectable expression, the Ninth Circuit has endorsed an "abstraction-filtration-comparison" test formulated by the Second Circuit and expressly adopted by several other circuits. ... This test rejects the notion that anything that performs a function is necessarily uncopyrightable.

(Disclaimer: This is not meant to imply that I think that Judge O'Malley's 2014 opinion is the final word on the case. I'm just picking some highlights from an opinion on this case that might shed some light on how the Courts are approaching the issue.)

(https://www.leagle.com/decision/infco20140509135)

> 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.

You see, in the US, derivative works are a thing. All languages that derive their APIs and perhaps even syntax from C would be derivatives. There's interesting legal arguments to be had there if APIs are ruled to be copyrightable....

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.

You can make this same argument for the function name or the parameter names. Nothing about the implementation of the max function requires it be named max to work, it just needs to link to a function pointer or some equivalent construct that acts in a way as defined by a specification for what max should do. A name like max is helpful for use though. So is arranging max, min, and other standard math functions in the same module. Treating method names as different from other forms of organization is inconsistent. They are all forms of organization.

You've also raise some points re interoperability, but I'm not really arguing about that. My own argument is more of a conceptual one based on the difference between an API and an API contract as well as on the role a system specification plays in API design & use. You could probably extend this concept to the interoperability question and I see no reason why it won't make sense, but that's not what I'm doing here.

> 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.

Why would Google bother keeping the JVM class hierarchy if they were implementing a different VM to run against anyway? That just seems to be asking for trouble. I can sort of see some merit to Oracle's argument now. It would be one thing if JVM byte code was treated as an Intermediary representation that then compiled to Dalvik... but it isn't even really that.

Damn, Google stepped in it. Hard.

Edit: Further research indicates Java Byte code is an intermediate representation compiled to Dalvik; so technically the Java Hello World would work coming out in Dalvik (or Android Runtime). So... Back to being confused again, because clearly, even if Google did copy pasta the Java APIs the end machine they are driving is drastically different; I.e., System.out.println() would generate no visible output on Android.

So I'm really back in Google's camp, Oracle is trying to copyright a steering wheel.

Oracle wants patent like protections for the output of Java, and overall API structure in all languages. They want copyright on a meta-pattern. Just trying to imply skulduggery to "look, they joined our API structure, and didn't even do a good job of it, so they should have to pay us for infringement" is a transparent farce. It's an entrenching power grab.

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.

I have designed hundreds of APIs and SDKs myself as well and I could not disagree with you more.

API design is about deliberately and creatively considering the domain model of your user (whether that domain is Int or Float for a user who is a low level system programmer or the domain is CheckingAccount and SavingsAccount for a user who is a banking application developer, or anything in between or beyond). You creatively set up APIs so that composition of the API primitives allows direct expression of solutions in the user’s domain.

This is exactly like arranging recipes in a recipe book, to organize sections for different styles, meals or amount of prep time, holiday themes, etc. That is exactly software API design to a tee.

This article highlights it for me:

https://blog.keras.io/user-experience-design-for-apis.html

Here, the Java APIs were copied literally. For example, say you’ve got a function to append an item to a list:

Append(item, list) Append(list, item)

If you changed the order of the parameters, you wouldn’t be literally copying, even though it’s the same basic signature. That’s the Baker case. You can’t monopolize the method of appending an item to a list by extending copyright to all possible permutations of the limited ways to write the signature.

But what happens if you do literally copy? That’s this case. Then, the question is whether these choices of where to put the parameter reflect any creativity.

I happen to think they do—I strongly prefer the first form, which is how it’s done in the Common Lisp standard library.

Though the choices are creative, it's necessary to replicate them exactly to produce a functioning interface for existing Java code. It's like a design for an electrical connector; maybe patentable, but it's essential to the function so shouldn't be copyrightable.

Interesting. This argument seems to imply that languages are copyrightable based upon creativity in ordering, punctuation, use of certain expressions such as `&`, etc. How is that different from your example? In fact a computer language itself is nothing but an API to a human-readable specification for machine behavior. I can see the specification being a creative work and hence being patentable. I don't see the same for the API code.

I'll have to think more about it. I can't offer a more substantive counter-argument now.

"The conclusion to which we have come is, that blank account-books are not the subject of copyright; and that the mere copyright of Selden's book did not confer upon him the exclusive right to make and use account-books, ruled and arranged as designated by him and described and illustrated in said book." [1]

[1] https://supreme.justia.com/cases/federal/us/101/99/

My reading is that the mere use of an API is a method of practice. It does not matter if the API is simple or complex, in the same as it didn't matter if a single page or multiple pages of account templates were used.

The problem is Google didn't merely use the API, it reproduced the API entirely and necessarily copied several thousand lines of code in the process. Code itself is generally copyrightable so it is difficult to argue that the specific type of code that makes up the Java API declaration is exempt from this.

Reproduction of an API in its entirety is no different from reproduction of an embedded practice. Any arguments I've seen so far that argued for parts of API code not being embedded practice were not taking into account how API code is used by software engineers.

Baker says that if you write a book that contains instructions on how to do something, you might own the copyright to that book, but your copyright doesn't extend to the results of other people following your instructions and creating their own versions of that thing. In the actual case it happened to be ledger templates, but it could have been anything else.

For example, if you write a book that describes in detail how to draw an owl, you own the copyright to that book. If I buy your book and then follow your instructions to draw my own owl, I own the copyright to that drawing, not you. Your copyright over your book doesn't also grant you the copyright to my owl drawing just because I followed your instructions.

If Oracle was only alleging that Google's implementation of Java (their version of the ledger templates/owl drawing) infringed on Oracle's copyright of its Java API (the instruction book), I could see how the reasoning in Baker might apply. But here they're alleging something further: that the API (instruction book) itself has been copied.

I would say it's the latter and not the former. APIs aren't instructions in and of themselves, they are instruction identifiers. And the instructions they identify correspond to interactions in a working system. If one wanted to recreate the working system, they'd be hard pressed to do so without recreating instruction identifiers. This isn't just an interoperability issue, but also because experienced practitioners have certain expectations re instructions semantics. Those semantics are often unexpressed directly and come from for example their organization into a given module.

> But here they're alleging something further: that the API (instruction book) itself has been copied.

This is where I'm really puzzled. The API is not the instruction book. The API is a method of interacting with an invented system. You cannot use the API in isolation from the system, by itself it's largely useless. You can't take the API, read it, and then be able to use the system. You need the API to use the system as well, by definition it cannot be used without an API. You could say that the instructions and the ledger templates are fused and inseparable here, but that's only in cases where no other documentation exists which is not the case for the majority of system on the level of Java.

True. Neither are 'ways of calling library functions" copyrightable.

But in the case of Java API what was copied was the actual Java-code in which the APIs are expressed.

Because the APIs are "fed" to the compiler as Java source-code, it is clear what was copied was not just the "way library-functions are called".

What was copied was Java SOURCE-CODE which allows a Java compiler to ENFORCE and INTERPRET such calling conventions.

Even if the API was rewritten in another programming language it would be a copyright violation if large parts of the structure of the API meaning how the methods are organized into classes and interfaces and how they refer to each other, was copied. That would clearly be a work of art that deserves copyright protection, in my view.

"The conclusion to which we have come is, that blank account-books are not the subject of copyright; and that the mere copyright of Selden's book did not confer upon him the exclusive right to make and use account-books, ruled and arranged as designated by him and described and illustrated in said book." [1]

I believe based on this reasoning, copying APIs or copying code is a distinction without a difference, so long as it's in the context of calling library functions.

[1] https://supreme.justia.com/cases/federal/us/101/99/

The Baker opinion can of course be used as argument pro-Google. But it is also just an "opinion". Each case must be decided on its own.

I believe there is a big difference between scale and structural complexity with the (inter-connected) Java API and some text-book examples of accounting layouts. At some point quantity becomes quality.

In both cases, they would have "copied" the API and both seem to me to be exactly the same case as in Baker/Selden.

So that case was about illustrating and explaining a method of doing accounting. There was no textual matter copied.

In Oracle vs. Google I believe the source-code of the APIs was copied.

Even if one would consider a way to do accounting an "API" an explanation and illustration of an API is not the same as the "API".

Explaining or illustrating a "structure" is not the same as copying that structure. Note that copyright applies to actual "works of art", not to abstract "methods". An API (as referred to in this case) is not an explanation of a way of doing things but an actual constructed artifact, source-code.

Think about books. Their content is copyrighted. You can not copy their content. But nothing prevents you from explaining and "illustrating" the content of a book, as long as you don't copy significant portions of the structure and ordering of its verbatim words.

This has until now seemed like it should also mean that the API as API is not copyrightable, and a straightforward implementation of something like `min` is also not, as it's just the only reasonable way to implement `min`. But an especially clever or creative algorithm to implement a part of an API might be.

I don’t think APIs should be treated differently than other code only because you need it to be so for your convenience. If APIs should be treated differently they need to be defined separately and licensed differently. Other languages and platforms makes this very clear by externalizing most APIs from the language and then adding support for the API to the language as though it is a foreign technology, because it’s definition and license are separate.

What? No. Most modern languages do the opposite. Usually everything is defined directly in the standard library and syntax is often merely sugar to call specific functions in that standard library or to refer to specific definitions in that standard library. Primitive numeric types like int, short, long are no longer hard coded directly into the compiler. Instead they are defined in the standard library and the compiler is just employing optimizations where possible to make them behave like primitive types.

Although Ceylon is dead I like to use it as an example. Almost everything was defined in the standard library. Even keywords in java like public, abstract, static are merely just annotations in Ceylon that were defined in the standard library.

That's true, but only in the case for the language's standard library. But what about the API of the language's top-level constructs? A class must have an initializer, for instance. Or protocol / interface has the notion of required as well as optional methods. Why is the latter (language APIs) not copyrightable but the former (standard library APIs) is? What is the substantive difference between them?

Unfortunately, Java is just such a perfect for this legal fight. It is proprietary and exists in this nebulous universe of wanting to make everything Java. It’s like Microsoft of the 90s.