The problem for Google on the copyrightability front is that "compilations" of non-copyrightable items can be copyrightable even if the underlying items themselves are not, if the "selection, coordination, or arrangement" of those items involves sufficient creativity to be considered an "original work of authorship".

For example, individual recipes are generally not copyrightable, but if you compile a set of recipes and publish them in a cookbook, the cookbook itself becomes copyrightable.

As applied to Java, individual method signatures like min and max might not be copyrightable, but someone had to go in and organize those individual methods into classes, and organize those classes into packages. That act of organization likely implies that the Java API (taken as a whole) constitutes a copyrightable work, even if the individual method signatures are not.

What's worse for Google is that code has always been considered copyrightable so arguing that APIs are non-copyrightable is essentially carving out an exception for a specific type of code.

As is common when HN discusses legal matters I see a lot of people blaming the judges for not understanding tech, but the problem here isn't really the judges so much as the law itself. We should not be surprised if Oracle ends up winning here, at least on the question of copyrightability. Google may have an out related to fair use, but that seems like a long shot as well.

Perhaps my understanding of APIs is different because I'm an engineer and not a lawyer, but how is this not an open and shut case?

The cookbook analogy is not applicable for the same reason one could not apply it in Baker, accounting methods are not of themselves copyrightable creative works. (They may be patentable, but I believe patentability is NOT at issue here.)

Selecting and arranging recipes requires creativity. I do not believe API code of a math library is in any way the same level, having designed hundreds of APIs and several SDKs myself. Perhaps creating a specification upon which the API design based upon is, but that leads right back to Baker. What am I missing here?

[1] https://en.wikipedia.org/wiki/Baker_v._Selden

Edit: And if you think about it, an API code is really just a set of templated forms for conveyance of data between systems. In this sense it is really no different from the accounting ledger templates in Baker.

Second edit: It would be worthwhile to enlighten the judges on the early history of computer programs and their ties to recipes which should make the cookbook analogy and its potential misapplication here even more obvious.

Third edit: Another line of enquiry would be to discuss differences between API contracts and APIs. They are not the same, though often confused, even by practicing software engineers.

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?

But what is discussed here is not the cookbook but just the table of contents. The actual recipes are different.

Making another cookbook with chapter 1: salads, chapter 2: soups etc. is common practice. The question is how much detail you are allowed to copy in order to allow for interoperability.

For instance, a dinner might call for the Oracle potato salad of Section 1.3 and Oracle tomato soup of Section 2.2. If your cookbook has your recipes (not Oracle's) in the same Sections in your book, that is useful for your readers/chefs, since they can easily switch their menus to your book.

Are you allowed to do that? That is the question.

> arguing that APIs are non-copyrightable is essentially carving out an exception for a specific type of code.

Disagree. APIs are talking about code but not code by themselves alone. Just like "The potato salad recipe is in Section 1.3" talks about a recipe but is decidedly not a recipe by itself.

If the law currently thinks that should be copyrightable, then the law should be changed.

> But what is discussed here is not the cookbook but just the table of contents.

You probably can't copy that either. That's like Oracle's example of making a new Harry Potter book with all the same chapter titles.

I don't know if there are any good examples of APIs one can make based on books..

Chapter 1: Introducing the main character .. Chapter 6: Introducing side character Chapter 7: Arrival at the main story place .. Chapter 17: The final chapter

In fact there are whole classifications of literature that identify basic storylines, tropes, structure etc. . The reason you couldn't copy the harry potter chapter titles exactly is because they contain specific titles, e.g. "the boy who lived", but "<my own catchphrase for main character>" as the first chapter title is again very, very common.

Also, the argument is about reuse/interoperability. Recipes are something you use and the naming is functional and it is important that it is similar enough. I am not aware of harry potter chapters being used like that, but if authors start talking about "The sorting hat" chapter as a term of the art , then yes you should be able to use that term. Similarly to how you can introduce a weapon in your novel without paying royalties to Chekhov.

I agree very much. I just don't think books are very useful for expressing those ideas. Interoperability is rarely an important consideration when writing a book.

Rename java.lang.String to google.java.lang.String and make google's dex compiler automatically look in the google namespace by default.

Not allowed? How about we just hash the Java API names and then let the compiler automatically apply a mapping from hash to google name.

In the worst case Google is probably still allowed to ship a tool that renames uses of the java api directly in the source code and switches it over to whatever Google's naming scheme is. If this wasn't allowed it would be equivalent to making it illegal to not use the Java api because doing the same chance by hand would is not meaningfully different.

> But what is discussed here is not the cookbook but just the table of contents. The actual recipes are different.

We should be very cautious about trying to tackle the subject in this way. Illustration by analogy can be useful for explaining subtle concepts, but argument by analogy will only introduce more confusion.

The fact is that lots of things can be "work" but that we as society do not want to bestow copyright for them. Again, the question is not "did someone put in work to make a good API?" but "are APIs something that should be copyrightable?".

Going with the recipe analogy: Society might be willing to give you some kind of recognition for "Joe's sandwich with this detailed recipe", but it is not going to give you an exclusive monopoly over "any and all dishes consisting of (bread, topping, condiment, vegetable)". Copyright is intended to reward creation, not to stifle any sort of however far away competition.

You may disagree but here they are before the supreme court to rule about this. So the only thing I'm confident about is that it's not trivial question.

As said by others fair-use is a totally other point and if granted could offer Google some relieve.

Oracle must win on both points.

"Google's lawyer, Robert van Nest, asked Schwartz whether, during his tenure at Sun, Java APIs were considered proprietary or protected by Sun."

"'No,' Schwartz said in explaining the nature of open software. 'These are open APIs, and we wanted to bring in more people...we wanted to build the biggest tent and invite as many people as possible.'"

https://www.cnet.com/news/former-sun-ceo-says-googles-androi...

ATTORNEE is evolving!

ATTORNEE evolved into JUDGEON!

Thus Schwartz's beliefs are and should be relevant

The justices that brought up the case’s procedural history were all unanimously skeptical that the Federal Circuit correctly set aside the fair use verdict in favor of Google. I think the most likely outcome of this case (especially with the absence of Justice Ginsburg) is a remand to the Federal Circuit with instructions to pay more attention to the trial court’s findings.

Remember that copyright exists solely for the purposes of increasing the production of otherwise-easily-copyable works that take time to create but then are "worthless" (i.e. the marginal cost of each additional copy is ~0 or negligible).

From the Constitution itself:

"[the United States Congress shall have power] To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."

I can see how one can argue that software itself - the actual code - will benefit in the same way (though the myriad successful open source projects and SaaS platforms seem to suggest it's not necessary......). However, I think it's pretty dang clear that limiting the copying of APIs will broadly lead to less software being created. It's well established that, for software, ideas are cheap, and that competitive advantages primarily come from excellent execution and excellent VC funding. If someone re-implements your API and your business folds, it's not because your API was your secret sauce and they stole it. It's because their re-implementation - which, by definition of an API, must be "the exact same thing" - was better than yours. They produced a better product, and the market rewarded them for that.

So, for a legal framework whose purpose, as outlined in the constitution, is to promote the arts and sciences, I think it's pretty clear what the path forward is.

Copyright is not just about software.

Imagine a world in which you write a novel, let's call it Harry Potter, and publish it. And then I see people liking it, so I publish it too, but I can sell it cheaper because I don't have to recoup the costs of having written it.

Or imagine you write and record a song, let's call it Revolution. A shoe company can use that exact recording in an advertisement without paying you.

I respect the radicality of your position, but I hope you understand you are proposing to burn the creative arts to the ground.

However, society should use IP laws to maximize the societal goods of creation, not to keep the entrenched players' businesses profitable.

There are hundreds of ways to monetize creative works. It's laughable to think that creativity will cease if we don't allow 70 year rent-seeking on the products of that effort.

I think 90%+ percent of "societally useful" IP revenue would be preserved if copyright terms were only 1 year. If it was eliminated entirely, artists would move to crowdfunding and commission based methods of getting paid for creation.

I think the first half of last century's music industry is an interesting example: back then the vast majority of artists rose to prominence by playing already-popular songs before transitioning into their own songwriting. How much is creativity squelched by the current system where licensing is at the arbitrary discretion of the IP owner, and how should society weigh this against the potential reduced economic incentive to create works if cultural products become freely distributable?

Video games are protected by copyright but it doesn't have much teeth, modulo occasional arrests of crack authors. What happened was not that people gave up on charging for video games, but rather it created a market for sufficiently secure platforms that piracy was very hard.

10 years from creation = automatic and free. More than that for an exponentially rising yearly fee. 11th year 100 dollars, 12th year 200 dollars, 13th year 400 dollars etc.

There would be another advantage, a searchable database of copyrighted items older than 10 years.

And there are changes that aren't even all that radical, that are enough to make a counterpoint here. For example, with a sufficiently generous UBI, a lot more people would be able to pursue arts for the sake of arts. One could reasonably argue that removing the profit motive would not only not break such an arrangement, but improve the quality of the output.

I don't see how this type of creative expression is any more or less worthy of protection than any other code.

There are some other silly things mentioned in the proceedings. One is about monopolies, clearly that's wrong because there are multiple platforms and Apple and Microsoft clearly didn't need to copy these Java libraries. The QWERTY keyboard analogy is also not a good one since there's a clear difference between something that is written and consists of tens of thousands of pieces vs. a relatively simple organization of characters that's also not written (it's physical). So that would probably go under a design patent. Another is about transformative use. There were cell phones using these Java libraries before Google decided to use them as well -- the Jasper S20 using the SavaJe OS for instance. Also the doom and gloom that the industry will break is absurdly doomsday. Simple libraries or SSO wouldn't constitute the level complexity and creativity of Oracle's Java libraries.

Google could have invested in creating its own libraries and only using the 57 or so classes that make up the Java language, made its own methods, classes, and packages. But that would have been a large effort to design them, get them battle tested, and to attract a developer community around it. It was easier to cheat to get ahead and ride the coattails of Oracle's community that were familiar with the Java libraries they had created. Google knew what they were doing was wrong at the time, but the cost to get to market meant it was worth it. Google didn't stop there, they continued to copy the changes that Oracle did to its libraries and copied new packages that Oracle created.

Finally, Google had the option to take the community license, but they didn't want to contribute back. I say, hard cheese Google, pay up.

I guess I must be hallucinating all those S3-compatible libraries and services.

> As the justices pointed out, it's a one-way interoperability.

It makes a large majority of the same code work on both. That's not one-way. Porting in either direction is vastly improved versus them making their own APIs.

Also copyright protections aren’t given up because it makes a third party’s life easier. That’s also what was said during the hearing.

Yeah but if your mandate is to promote the arts and sciences then you desperately want interoperability to be easy and encouraged.

[1] https://en.wikipedia.org/wiki/Antiword

>why should only the implementation be protected?

Because copyright only protects authorship. You are the owner of your own creative works but you are not the owner of other people's creative works. What Oracle wants is to prevent independent reimplementation of Java libraries which is clearly a case of patent law not copyright law.

The Java standard library casts a "shadow". That shadow is the API but the standard library is not the API. Someone who only looks at the shadow can rebuild their own version of the standard library without directly copying the standard library. This is called clean room design and it is done all the time. Patents are the primary way of preventing clean room designs by competitors.

The fact that people on HN are insisting on bloating copyright even further makes my blood boil. IP law already created lots of solutions for all these problems. Stop trying to shoehorn everything into copyright.

Sun had a mobile platform at the time, J2ME. If you wanted to use Java on mobile, it had to be J2ME. There was no option back then to just pay money and pick'n'choose which bits of Java you wanted. In fact there still isn't, the Java guys are zealous about compatibility.

And J2ME was in turn a slow, multi-vendor, standards oriented kind of thing with multiple implementations. It was (a) very limited, (b) very buggy, (c) very poor developer UX. The issue wasn't Java itself but rather the huge variety of bugs and missing APIs between different phones. See the issues Android faced with fragmentation and multiply it by a million. In fact it was an attempt to fight fragmentation that led Sun to take the hard-line "our way or the high way" approach!

Additionally, J2ME was not open source but Google or rather Andy Rubin felt strongly that Android had to be open source under non-GPL licenses because mobile vendors hated the GPL. They could just about tolerate Linux but that was the limit. So Google was going to go to Sun and say, hey, please release one of your own profitable Java products under an open source license, so we can make more money out of Google Maps? No way.

Could Google have made Android using J2ME? Maybe. Perhaps? But it'd have been a huge ball and chain around their ankles and Android would have been radically different, likely different enough to have killed it. For instance J2ME had a simple GUI library but it was limited by the need to run on feature phones. They'd have never been able to make it as advanced as the Android GUI toolkit was, and competing with the iPhone? Forget it.

To some extent this situation was inevitable. From a technical perspective using the Java platform worked out very well for Android. But given Sun's business model at the time and the history of J2ME there was no way to take it to the next level. In hindsight we can say that Google could have replaced the entire revenue stream of J2ME, but what company wants to replace a many-vendor many-customer ecosystem with a single revenue source? Nobody would do that!

They could have yes, with Java SE actually

> The SavaJe OS was a monolithic OS-and-Java platform, an implementation of Sun Microsystems' Java Standard Edition, as opposed to the more limited Micro Edition usually offered on mobile phones.

https://en.wikipedia.org/wiki/SavaJe

Also the Nokia and Sony-Ericson extensions to J2ME were quite good, while keeping compatibility with J2ME related specifications.

So much that they eventually rebooted the whole thing with ART.

Apparently Swing was appropriate for SavaJE, go figure.

Well, the original lawmakers agree. They set a 14 year maximum. In other words: They acknowledged the necessity of copyright but they think it should only be temporary and not exist.

The problem is that it is too damn long nowadays.

You could make that same argument about patents in general, couldn't you? If you invent something, say, a new battery, and somebody else copies it, doesn't have your R&D-costs invested and prices it accordingly lower than you, the market will "reward them" by buying from them instead of you, they're getting the same thing after all.

We do want some stability though, if you invest money to create something and somebody immediately copies it, you're not going to invest money again. We want you to invest money to advance humanity with new technology and knowledge though.

Since there's no re-implementation without looking at the original, it feels sufficiently close to taking your buddy's homework and saying "no worries, I will change it a bit" and you'll have Math.add(a, b) and while they wrote return a + b;, you'll write return b + a;, you're not copying after all.

It would be more about copying the batteries terminal structure, such that you could build products compatible with the battery or a battery compatible with the products. It snot about copying the battery, its about supporting interoperability. That's what is at risk here. Sixty seven different kinds of outlets, or arbitrarily expensive ones where the "design" itself is licesned, instead of the code.

I think this is a very important point. I haven't read all of the briefs in this case, or looked at the arguments presented at the hearing, so I don't know if Google's lawyers stressed this point, but they sure ought to.

I like this framing and think it’s entirely correct, but I don’t agree that it necessarily dooms the interoperability argument.

Google wasn’t trying to achieve compatibility with existing code (for which, you’re right, they’d have needed to take the whole set) but rather compatibility with existing developers. Arguably, that is still interoperability.

You should distinguish the concepts of copyright and patent. A hardware design, like a battery, is not copyrightable in general. The technical drawings or a written description can be copyrighted, but the abstract technology and process cannot. Under copyright laws, it's illegal for me to duplicate your documents, but there is nothing to stop me from reverse-engineering or duplicating the same process or hardware [0], and I'm also allowed to write about this technology in my own words. Only patent laws can grant a period of exclusive control of an abstract technology to its inventors.

[0] If I obtained your documents illegally, it would be trade secret infringement, which is an independent issue from copyright nor patent.

Copyright protects authorship.

Patents protect against reinvention.

It's clear that Oracle needs a patent unless Google outright stole the standard library.

I think that's somewhat unlikely; I think its somewhat more likely that the court concludes that the Federal Circuit erred in using de novo review, but instead of remanding to the Federal Circuit for reasonableness review reconsiders the jury verdict on the bases of the trial record itself (especially if by doing so it can uphold the trial verdict and kick the copyrightability issue down the road to another case.)

While the Supreme Court will dodge hard issues where it can, it doesn't tend to do it in a way which leaves a good chance that the same issue will come to them again in the same case. When they dodge, they like to make sure the issue stays dodged, at least for the immediate case. There's way too much risk that the Federal Circuit would reach the same answer if told to use a reasonableness standard of review (I don't think it should, but absent reaching the answer itself, the Supreme Court can't be sure of that), which would leave the copyrightability issue to come before the Court again before this case would be finalized.

I think you are correct that it is more likely for that reason than it would otherwise be, though I still think its less likely than a more permanent punt on the case (that would still leave the issue live for a future case.)

But that's just my intuition.

While they really have to be substantially similar to allow interoperability, OpenJDK is open source (GPL) and Oracle's Java is not.

That brings up a couple questions which don't directly bear on the case just heard by the Supremes, but are (IMHO) relevant to potential second-order consequences of a ruling for Oracle:

1. Given that the OpenJDK API is substantially similar to the Oracle Java API, could Google avoid repercussions by switching to the former from their "adaptation" of the latter?

2. Should an API be considered eligible for copyright, wouldn't that enable opportunities for language and library developers to restrict others from developing competing (via performance or utility enhancements) languages/libraries by forcing anyone who wished to implement enhancements to either purchase a license or flat out deny them the ability to do so (assuming the product --including the API isn't open source)?

3. If (2) is the case, what does that mean for incremental improvements of languages and libraries?

I'm not a java dev or a copyright expert, so pardon me if I missed an important point.

It would be a software patent except not by name and it would last significantly longer. I can already see both software and hardware patents being abandoned if this court sets a precedent that APIs can be copyrighted. The next day people will want to add everything patents do simply because copyright has a longer duration and it is effective immediately.

I wonder if they win on that front if the Court will be able to dodge the question of API copyrightability in general.

The problem with this theory is that class and package declarations are still just recipes. There is a recipe for making chocolate chips. Then there is a recipe for making chocolate chip cookies where one of the ingredients is chocolate chips. It's recursive but it's not fundamentally different. Saying you can copyright a recipe for chocolate chip cookies because it's just organizing the recipes for chocolate chips and butter and brown sugar is pretty ridiculous.

Think of it like you put in the effort to curate a collection of recipes that work well together, and that curation is what’s copyrightable.

I don’t know what will happen with the law, and if APIs like this will be deemed a “curation”, but it makes a lot more sense to me from that perspective.

Ex.

Anyone can have a `Math.remainder` function, but the curation of an entire `Math` library might be copyrightable, since the effort was in collecting all of the correct things that work well together, even if they aren’t individually copyrightable.

A mega-recipe containing other recipes would be like making a `Math.AddAndThenMultiply`, which even if someone else had created the Add and Multiply methods, you aren’t stealing their API curation of methods, you’re just combining logic/algorithms (ingredients) from multiple methods (recipes) into a bigger method (mega-recipe).

Suppose I want to compile the big book of all known recipes. Then it will contain every recipe in your book, in its entirety, as well as every recipe in every other book. But if I can put the entire contents of your book in my book then what is it that you're really claiming to protect? The order the recipes appear in the book, i.e. the order the classes appear in the file? Which isn't generally regarded as part of the API.

A ToC cares what order it's in. You can't move Chapter 4 to before Chapter 2 or the implementation has to change. By contrast, the order of functions within a class, or classes within a package, isn't really part of the API -- they're most often in alphabetical order, which is totally mechanistic, and changing the order doesn't change the API.

A ToC is also not a rigid formal specification (like a recipe), but that's the core of what an API is.

> A ToC cares what order it's in. You can't move Chapter 4 to before Chapter 2 or the implementation has to change.

This isn't true.

  Table of Contents

  Foreword.................i
  Introduction............ii
  Preface................xvi
  Chapter 1................1
  Chapter 2...............17
  Chapter 3...............30
  Chapter 4...............51
  Chapter 5...............58
  Chapter 6...............76

  Table of Contents

  Foreword.................i
  Introduction............ii
  Preface................xvi
  Chapter 4...............51
  Chapter 1................1
  Chapter 2...............17
  Chapter 3...............30
  Chapter 5...............58
  Chapter 6...............76

> individual recipes are generally not copyrightable, but if you compile a set of recipes and publish them in a cookbook, the cookbook itself becomes copyrightable.

(emphasis mine)

The law understands that the whole is more than the sum of its parts. And Java adds up a lot of parts. It's also an interesting model case because it's inherently so very open, without (particularly pre-Jigsaw) a clearly demarcated dividing line between "API" and "implementation." Alito's not unreasonable to suggest that a Supreme Court ruling in Google's favor might raise difficult questions about how copyright law applies to software in general.

That's true, and while I have a very clear way I would like the Court to handle that personally, it's probably a good reason for the Court to look for an excuse to punt hard on copyrightability if it is open to them (and the procedural issue on fair use seems to offer that opportunity) and let the Circuit Courts (and I don't mean the Federal Circuit dubiously interpreting some regional circuit’s law) develop this issue more before resolving it at the Supreme Court level.

My point is that "the whole" is the implementation of the Java standard library and the API is really still just the recipe.

> It's also an interesting model case because it's inherently so very open, without (particularly pre-Jigsaw) a clearly demarcated dividing line between "API" and "implementation."

The line is clear even if the language puts them both in the same file.

  public class Foo {
    public static void Hello(String[] args) {
        System.out.println("Hello World");
    }
  }

"Whole" in the sense of "the whole is more than the sum of its parts" is not generally understood to imply the maximal possible scope in any given context. It's simply meant to meant to talk about how the identify an aggregation (of no particular scale) relates to the identities of its individual components.

Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private?

Moreover, there are certainly rational distinctions that could be drawn, but that does not mean that they are legally relevant. The issue at hand really doesn't have anything at all to do with how programmers understand things. The law is not what we think is right, the law is what is written in the books.

Which is how I'm using it. An API that consists of two functions and one that consists of a billion functions have completely different scales but each whole unit has an API portion and an implementation portion. And the API portion is the recipe. It's a purely factual description of what the implementation is expected to do.

> Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private?

That doesn't affect whether the API parts of it are API parts, only whether the API is regarded as internal or not, which shouldn't be relevant to copyright. Internal APIs shouldn't be copyrightable either.

> The issue at hand really doesn't have anything at all to do with how programmers understand things.

It better, or you're in real trouble, because then all you have are meaningless zeros and ones.

Compare it to x86. It's just an "API" as well. Someone can write a specification or reference listing all opcodes and even though that reference is licensed under MIT or GPL you are still not allowed to make your own x86 processor because there is an IP tool specifically designed for this case. It's called patents. Just because you are not violating Intel's copyright doesn't mean you aren't violating Intel's patents.

Google probably didn't violate copyright and probably didn't violate any patents. So it is pretty much clear cut. Oracle failed to patent its API and therefore Google is allowed to use it.

AMD, Cyrix, Transmeta

I'm 99% certain that, if Intel had legal grounds to keep them out of the market, they would have done so. I'm 100% uncertain what's different between that case and this one.

Which in of itself is a long avoided question that sorely needs to be addressed.

No it doesn't. If that was the case then you could just do piecewise reinvention and then later on recombine the result.

Grasp the difference. Copyright prevents 1:1 copies, not against reinvention, patents do that.

A lot can be interpreted into the law when it is beneficial for everybody to do so. But interpretation has its limits. Some laws must be made explicit by the legislature.

Not the algorithm. The algorithm is essentially the recipe. The algorithm is merge sort, or depth first search. It's the contract the API gives you, more or less. "This function does merge sort." But there are unlimited possible implementations of merge sort and each one is copyrightable. And one implementation doesn't infringe the copyright of the other ones, even when they're the same algorithm, but you have to write your own. Copyright doesn't protect function, it protects works of authorship.

Copyright protects how code is written not what it does. And the how applies just as much to interfaces as implementations.

Splitting hairs like that doesn't change anything because it's still not the algorithm which you get a copyright on. It's the work of authorship implementing it.

But you can certainly produce multiple implementations of source code that are not only functionally equivalent in practice but actually generate identical machine code.

> Copyright protects how code is written not what it does. And the how applies just as much to interfaces as implementations.

The issue is that the interface is strictly the what it does part. Given the implementation, or the need for compatibility with one, the API is purely a factual description of the call spec. You can't rewrite it or it changes the what, which means there is no room to change the how, and the code correspondingly required shouldn't be copyrightable because it's purely functional and leaves no room for alternative compatible implementations.

It doesn't protect against reinvention because it's easy to bypass copyright through clean room designs which is probably what Google did.

This is not the most common type of contract in APIs. More like "this function sorts", or perhaps "this function sorts in O(N*log N) time". Sorting can be done with many different algorithms.

Is there still a way to protect your cookies? Yes, it's called patent law. It's explicitly designed to prevent reinvention.

It's hard not to use it when it's the one from the case law.

> That's not quite the same thing as curating a set of recipes into a cookbook and thereby exercising creativity in the "selection, coordination, and arrangement" of those recipes.

Exercising creativity can't be the hook if recipes have that and aren't copyrightable. You exercise creativity in choosing whether to specify chocolate chips or peanut butter chips or licorice bits etc.

APIs have hierarchy, but recipes have that too. You make butter from milk. You make cookies from butter. You make cookie crumb topping from cookies.

It's all already there in a recipe without reaching the result you want. You choose chocolate chips over peanut butter chips. You combine them with cookie ingredients to make cookies and brownie ingredients to make brownies. Selection, coordination, and arrangement. But the end result is still just a list of facts about how to make those cookies/brownies.

So why look at those things sometimes but not others? Because sometimes it applies to a work of authorship, but sometimes it applies to function, and you can't copyright function. So the functional part shouldn't count.

And that's what an API is. It's a formal functional specification. It's a list of facts about how to call those function implementations. It's the exact piece you don't get credit for.

Anything required for interoperability, is functional.

Sure, creativity is a requirement but it isn't the only requirement. But think about why a cookbook of selected recipes is copyrightable even if the recipes individually aren't.

> And that's what an API is. It's a formal functional specification.

The problem for Google is the Java API is also code, which is generally copyrightable. You seem to be saying that since this particular code happens to form a specification it should be treated differently under copyright law, but I'm not sure the court would find that argument very convincing.

Or to state it more plainly: the problem is legislators not understanding tech, and not updating our laws to account for the way computers and the internet have transformed society over the last 40 years. This was a similar gripe in the Net Neutrality arguments on HN. It's truly insane that regulatory bodies are using public utility laws from 1934 - before even the mass adoption of television - to create the rules that govern the internet.

I have no issue with updating (or even replacing) the Communications Act of 1934, since much has changed in the last 24 years (the last time the act was updated).

But claiming that the Communications Act of 1934[0] originally enacted in 1934, is a public utility law that's over 80 years old isn't accurate.

In fact, has been repeatedly modified and updated, the last time in 1996.

You could certainly argue that 1996 was a long time ago too (almost 25 years), but arguing that the law applied was, in its entirety, 80+ years old is uninformed at best and disingenuous at worst.

[0] https://en.wikipedia.org/wiki/Federal_Communications_Commiss...

Edit: Fixed typos.

As an IP-minimalist, I'm surprised anyone can look at the mental gymnastics that people go through in order to draw some arbitrary line between acceptable and unacceptable copying, and come to any other conclusion than "this whole system is ludicrous".

APIs aren't cookbooks, they are toolboxes, and Oracle is claiming to own the idea of putting your Flathead next to your Phillips

Is binary API copyrightable? That's a cookbook too.

Is API as build target copyrightable? I just want this code to run.

Is processor ISA copyrightable?

I have to put gas in tank, oil in engine, water in cooling system for car to run. I have to press clutch, turn a key for engine to start. Is this copyrightable?

Every thing is creative. There are many ways to make same thing. Sometimes we care not about creativity but compatibility. Qemu runs x86, ARM. Open Office opens Microsoft Word files. Google Cloud Storage is interoperable with Amazon S3 [1]. I can construct my own client.

And yet we have PNG, OGG, AV1, RISC-V — there are some issues with MP3 (patent), GIF (patent), H.264 (patent), x86 (patent), ARM.

[1] https://cloud.google.com/storage/docs/interoperability

Evidently yes, to the extent that {X} includes subjective properties that go beyond the fundamental function of {X}.

To use file formats as an example, the fundamental function of an archive file format is to bundle a set of otherwise-independent files together. A basic archive file format that simply concatenates file contents together (and I guess the necessary header to identify the boundaries between them) wouldn’t be copyrightable. But a more advanced format that includes an index of included files might be, since the addition of the index is a product of some artistry by someone who thought it would be a helpful convenience for users. [1]

Extended to the car example, “putting gas in tank” wouldn’t be copyrightable because no tank can function without gas. But improvements to the method of transferring that gas might be. Engaging a clutch is fundamental to the operation of a transmission and not copyrightable, but a clutch that is specially-designed to require less force might be.

The key is an interesting case though... I suppose I’d have to say that mechanism would have been copyrightable, since one could start an engine in ways other than a key (maybe a crank or a push button), or perhaps because the idea to couple the unlocking mechanism to the engine start signal was a clever idea rather than a fundamental necessity.

[1]: To my understanding, this is exactly the situation with “tar” and “zip,” though fortunately for us the “zip” format was contributed to the public domain rather than copyrighted.

I thought copyrights protect literary and visual illustrations, but not any underlying processes, mechanisms, or artifacts they describe (patents protect those). My understanding of copyright law is surely flawed, and perhaps the “original work” standard means that only descriptions of systems are copyrightable and not the systems themselves.

In that case I agree that my examples fail. Keys and clutches are mechanisms and filling gas is a process, and those aren’t copyrightable (but they are patentable). The file format example fails too, because the concept of laying out data in a particular way is a mere idea, and ideas aren’t copyrightable either (they are also not patentable, though a description of the format is copyrightable and a specific process for reading or writing the file might be patentable if it were nontrivial).

> GIF images are compressed using the Lempel–Ziv–Welch (LZW) lossless data compression technique to reduce the file size without degrading the visual quality. This compression technique was patented in 1985. [1]

x86 protected by patents:

> Partly. For some advanced features, x86 may require license from Intel; x86-64 may require an additional license from AMD. The 80486 processor has been on the market for more than 20 years and so cannot be subject to patent claims. The pre-586 subset of the x86 architecture is therefore fully open. [2]

One can build/emulate 80486 but not x86-64, SSE, AVX, VT-x etc.

[1] https://en.wikipedia.org/wiki/GIF

[2] https://en.wikipedia.org/wiki/X86

Roberts: Let's say someone copies the headings in your brief and they copy the organization in your brief, which sections you put first and how you organize them. Would your argument say that's perfectly fine so long as they write their own text?

Google's lawyer didn't really have a great response to that. He said "no but computer programs are different" but really didn't provide a compelling argument for why.

Can designing an API be a different job from implementing a design? If so, then maybe the work product of the designer is copyrightable on its own.

Suppose then, than I publish the book explicitly as a replacement for the other book. Not as in "this is the same" but as in "if you find a reference to a chapter in the other book, you can also just look here". Would that be copyright infringement?

What happens if I do this to a technical document (think a 3gppp spec) where the TOC runs for 10 pages for a 300 page document, with headings nested 5 deep?

If this argument is valid, it means that APIs are not copyrightable, they are patentable, because copyright is only for expressions of ideas, not for machines; patents are what apply to machines. And Oracle has already lost on the question of patent infringement in this case (back in 2015, IIRC).

Processes, whether they're made up of abstract concepts or not are patentable[0]:

"Processes are patentable under the U.S. Patent Act if they meet certain criteria. A process patent is a form of utility patent that covers methods of changing the functionality or characteristics of a material during a particular use. The patent-holder is granted exclusive protections and rights to that process for 20 years.

When one patents a business method or, in some cases, a computer program, this is a form of patenting a process. It's now possible to patent subscription-based services, targeted advertising networks, online auction sites, portal sites, email systems, and even discussion forums.

As our society has evolved, intellectual property (IP) issues have evolved along with it. What constitutes IP these days is so much more than the newest machine or physical invention. Today we have genetically modified seeds, new strands of DNA, computer software, chemical formulae, and more. As these issues become more complex, patent law has to evolve to address new concerns. For example, one can now patent business models and software through the U.S. Patent and Trademark Office (USPTO)."

[0] https://www.upcounsel.com/can-you-patent-a-process

That is incorrect.

> . If I change the names of things in a table of contents to synonyms, I can still use it to find what I am looking for.

If I change the name to be something you cannot refer to, you cannot.

> If I change the names of things my implementation of an API, it no longer functions as an interface for the things that worked with it previously.

This is irrelevant to the API. The API does not make a guarantee about functionality. If I have an endpoint /foo and later /foo increments an internal counter by 1, the API remains unchanged. Documentation supplements and is not part of the API per se, which is an important distinction. The fact that Documentation and an API are being referred to in conjunction, was a failure that software will suffer for more than the lifetime of my children.

The only purpose of an API is providing mechanical access to functionality.

An API doesn't require an implementation and copyright is handed out automatically. Could I then write and run a generator that just starts spitting out endless variations of possible APIs (combinations of dictionary words?). Does that mean I would end up holding the copyright for most of the 'common sense' APIs people would want to use for software projects?

European judges got that right.

IIRC there is durable precedent that mechanical collections of information w/ no creative "touch" are ineligible for copyright. I wonder if that can be extended to the meta information definition you came up with.

Although it would be HILARIOUS if Amazon Sues Oracle on day one after the ruling for their copying of the S3 API.

That said there are ALL KINDS of interop code that is at risk with the ruling, only people with their heads in the sand and do not understand the industry at all believe that nothing negative will come about if this ruling stands

Yes, there are parties that stand to lose a lot in the short term from a decision for Oracle.

But would it be so bad in the long term if proprietary vendor-specific protocols were put at a disadvantage? Maybe back-to-basics open protocols (or at least protocols formally contributed to the public domain) would resurge, and interoperability would actually _increase._

Oracle is a case book study if it, that is their entire business model

This isn't how the courts work and it's sad that Google has pushed this nonsense for the past 6 years.

Recipes that contains more than just the basic list of ingredients and instructions can be copyrightable. Include a picture, illustration or a bit of creative text and copyright will apply on that. That's the true reason why cookbooks fall under copyright (while the actual list of ingredients and instructions do not, which people do lift out of cookbooks for example).

Even when applying copyright to an "arrangement" of items that are not copyrightable, as in a database, there needs to be creativity expressed, otherwise it will not qualify for copyright.

> Even when applying copyright to an "arrangement" of items that are not copyrightable, as in a database, there needs to be creativity expressed, otherwise it will not qualify for copyright.

As the Supreme Court said in Feist: "To be sure, the requisite level of creativity is extremely low; even a slight amount will suffice."

This is not a very difficult threshold to meet (and Google has already conceded it has been met.)

Not exactly; an API can be completely re-implemented from scratch and still be compatible. If it was just about the API code, there wouldn't even be a case.

The idea that an API could legally be an "original work of authorship" makes a lot of sense; but the technical implications could indeed harm the industry overall.

Essentially what this means is: I build a system, you're not allowed to build a compatible system. Yet another reason why open source is the only way forward.

It doesn't make sense because an API doesn't exist in the work. Copyrighting APIs is functionally useless because you can have multiple works with the same API without violating copyright through clean room designs. Therefore whatever protection you want should cover more than one work. Copyright only covers the works you create yourself. It doesn't cover works that other people create even when they are directly inspired by your works. We have patent law for this.

How is heat transferred to the pot? From the stove to the pot, this is the API, and how it's implemented doesn't matter. Oracle claims that this specific thing, that you turn on any button and make it heat up is copyrightable.

But we all know that a stove is useless without that API. We would have to buy a whole new kitchen equipment for all stoves that we are going to buy.

A further question is: When will it end with copyright claims? I mean, at somepoint somebody will claim that the effing powerplug is also copyrightable. But we all know that nobody (speaking of % of the population) even has the skills to connect a device without a power plug without potentially harming themselves.

All technology is useless without APIs. Nonetheless I think that copyright laws is essentially full of flaws here, because if we focus on speech alone (of which most copyright laws are based on), someone might even argue that specific words are copyrightable if they are "uncommon enough".

Heat transfer to a pot is not an API, not even remotely close. It's a physical fact that has been observed since the stone age. The Java API is huge. It's not a mere physical fact, nor even a collection of method prototypes. It's everything covered in the JavaDocs: what happens in error scenarios, thread safety rules, how objects are combined to get different effects, what you can subclass and what's not, what security permissions things need. It's enormous and every decision in that was a 'creative' decision, in some sense.

From a plain reading of copyright law it's obvious APIs far smaller and simpler than Java should fall under copyright. The idea APIs don't is a convenient consensus-quo for the software industry that benefits competition and should probably be preserved, although there is the counterbalancing factor that the non-protectability of APIs probably has invisible side effects we can't see (e.g. under-investment in API design). But the Supreme Court won't or shouldn't care about any of that because it's a political debate. The question before them is about what the current law says, and on that, Oracle probably have a point. Also, it's going to be even more fashionable to hate on Oracle if they do win, but the current situation has always been legally fragile. Sooner or later someone would have observed the apparent skew between the software industry's approach to copyright and what the law really says. We may be at least somewhat grateful that it's a fight between two well resourced firms and not e.g. a patent troll firm type of situation, where the defenders are threatened and have to pay up because they're too small to fight it.

The whole software industry would have to change, and the potential pitfalls of buying software without an open source license would be too great a risk for pretty much everyone that developed any software for any proprietary environment.

I mean, using a proprietary GPU could be enough to get sued because you are rendering things on the screen, right?

This case is not about using APIs to build apps. Standard software licenses clearly allow that. The case is about reimplementing them.

You do realize that copyrighting APIs is functionally useless? There are ways of copying APIs that do not violate copyright. Reinvention is still possible precisely because of things like javadoc or the fact that Oracle doesn't have copyright ownership of code that uses the Java API. There is an endless list of loopholes that this protection is useless.

>The idea APIs don't is a convenient consensus-quo for the software industry that benefits competition and should probably be preserved, although there is the counterbalancing factor that the non-protectability of APIs probably has invisible side effects we can't see (e.g. under-investment in API design).

It has more to do with the fact that we already have patent law that was explicitly created for cases like these. Two inventors build the exact same thing. The first inventor should have the rights to the invention.

>But the Supreme Court won't or shouldn't care about any of that because it's a political debate. The question before them is about what the current law says, and on that, Oracle probably have a point.

Can you point me to software patents that protect the Java API?

>Also, it's going to be even more fashionable to hate on Oracle if they do win, but the current situation has always been legally fragile.

Clean room designs are the status quo in the hardware world. There is zero fragility. It's done all the time.

>Sooner or later someone would have observed the apparent skew between the software industry's approach to copyright and what the law really says.

They already did so to the point that patents have existed before copyright.

Are there? That's exactly what's being litigated.

Two inventors build the exact same thing

Patents don't cover APIs, by the nature of their form as a patent typically must make a narrow list of claims. To patent the Java API would presumably require making the entire specification a set of claims, which the PTO wouldn't accept.

You could argue APIs should be patentable but not copyrightable. That'd be weird though. Copyright is clearly the better fit, if you want APIs to be protected works.

Clean room designs are the status quo in the hardware world. There is zero fragility. It's done all the time.

No. The hardware world is the exact opposite of what you claim. ARM sells ISA licenses exactly because in the hardware world the Oracle side won out a long time ago: if you want to implement the ARM instruction set you need to pay ARM for the privilege. And if you want to use ARM's implementation you need to pay them even more. AMD can only make Intel-compatible chips because they have an architecture license for complex historical reasons, and so on.

> To develop a legal BIOS, Phoenix used a clean room design [2].

I think there was some creative process in designing BIOS.

There is no difference between binary and text format, it is just a serialization. WASM text format and binary format. Java source and bytecode.

API documentation is certainly copyrightable, even text definition file. A lot of creative process goes to putting braces, spaces, commas, naming

    static double min(double a, double b)

    static double
    min (double x, double y)

Yes, problem is copyright law.

[1] https://en.wikipedia.org/wiki/Clean_room_design

[2] https://en.wikipedia.org/wiki/Phoenix_Technologies

Yes but it is useless. You can e.g. copyright an electronics schematic. People aren't allowed to copy it and sell it but they can build the device that is being described by the schematic and then they can create their own schematic based on the device they have created. That's why we have patents.

Yep I second this. I think there’s a parallel “legal news” community somewhere pointing at us here going “those nerds don’t understand how law works” :)

What we should _all_ be doing more actively, imo, is nudging our representatives to update the law to create legislation that answers definitively “whether APIs are copyrightable or not”. Albeit, that is a much more difficult and slower process.

Well, you know what they say about democracy as a form of government though: “something something yeah, it kinda sucks but it’s the best we’ve got something”

Imagine if you copyrighted the six sided bolt head? Or the TORX screw. Making screw drivers or wrenches that loosened or tightened them would be copyrightable. How about copyrighting which side of the street people drive on, or the width of driving lanes. Do we get to charge a "usage fee" for cars that adhere to the lanes available on freeways?

Congress would have made that exemption when they made the law in the first place.

>A “computer program” is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.

This is an important fact people keep forgetting. Asking the Court to bluntly create legislation is never ever going to happen.

That's another aspect. API isn't code, only implementation produces executable code, API only helps ensure that those chunks of code fit together, like book's spine holds pages together and in order.