Google’s Supreme Court faceoff with Oracle was a disaster for Google

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.

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.

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

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.

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.

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.

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

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.

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

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

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

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.

They have had 6 years to do so and yet they can not state a single instance.

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

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.

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

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

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.

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.

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.

Then you thought wrong[0]. While the poems themselves may be copyrighted by others, the editor (presumably getting license/permission from copyright holders of said poems) organizes the poems in the anthology. The resulting work is copyrightable in its own right.

Check out the link below and the copyrights on each anthology.

[0] https://www.theguardian.com/books/2018/oct/03/top-10-poetry-...

what does writability has to do with anything?

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.

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.

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

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

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.

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.

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.

How is software, something of which there is an infinite supply that doesn’t exist until someone creates it, more of a “collective resource” than my back yard, which was here before I was born and will remain here after I die?

""" In another example from the 1990s, an open-source developer created a program called WINE, which al- lowed developers to enable Windows applications to run on computers that used the Linux open-source system, without explicit authorization from Microsoft. Gratz & Lemley, supra, at 611. To create WINE, the developer “use[d] the same hierarchy of function names” of various Windows APIs. Id. at 612. Years later, Microsoft created “the inverse of WINE,” reimplementing the structure of certain Linux APIs to create the Windows Subsystem for Linux, a program that allowed Linux programs to run on Windows. Ibid. The Windows-Linux experience shows that reuse of functional code is a “two- way street” that benefits both the original creator and the follow-on developer—and ultimately the consumer. """

Not to mention there's no monetary chest at the end of that fight (and the creation of WSL wouldn't bode well for them if they were to make a case at all).

Also, I forget if openjdk or this infringement happened first, but if the latter was first than it wasn't open source at the time.

This reasoning would also make valid those silly "I hereby declare that my photos on Facebook are my property, with all rights reserved etc etc" posts.

who knows, maybe strong APIs will prevent embrace/extend/extinguish?

That seems incompatible with the text of Section 107, which includes the amount copied as a factor for determining fair use. The more compatible your implementation is, the more you have to copy, so the logical end of this reasoning is that Android's implementation of Java would be fair use if it had copied all of the API, not just a subset.

Why it should? It would mean that implementing commercial Java runtime without Oracle license is not possible?

That is not at all clear.

But given that Android is not fair use (it's not interoperable

How is it not? Lots of code written for the JVM will build and run unmodified on Android. Not 100%, but WINE isn't 100% compatibile either.

What about improving the API? E.g. some languages may be mostly but not 100% compatible with existing languages and provide more or less the same API but not be 100% the same - both the in the runtime library (API) and the language itself.

For example Free Pascal is mostly compatible with Delphi but not the same and its runtime library is mostly the same as Delphi but also not the same.

BUT in this case we are talking not of using part of an API (say the Math library to implement a physics engine is assembly and link it) but of reimplementing a whole language which has, as of today an when the events discussed took place (even if we agree to hate it) an owner.

For example, glibc is owned by GNU, and it is licensed under the LGPL, so you are allowed to dynamically link it without having to release your own code under the GPL (or compatible). This is all happening today.

The only projects that will be more seriously affected by this decision are WINE and similar - projects that are copying the API but not the implementation. Even here, it is very likely that WINE could win on Fair Use, since their copying is obviously done for interoperability.

Also, APIs are obviously creative human works, and their purpose is first and foremost usability for the end-user.

Require copyright assignment or a guarantee for royalty free use by any implementation. Standards committees already have to deal with hidden patent dependencies someone might sneak in so this would just be another bullet point on paperwork that should already exist.

As another HN commenter put it to me when I made the same mistake: "The GPL is not viral." If one party breaks the terms of the license, then normal copyright goes into effect.

No, not at all.

OTOH, it does mean if they implement a GPL interface in proprietary software it does mean that they are in violation of copyright (barring a fair use defense) and the GPL, potentially triggering the loss-of-license provisions of the GPL and other legal consequences.

Just look at the commentary around overturning Chevron deference and non-delegation. Absolutely apocalyptic.

Yes, it is.

> There is no legal definition of "interface" or "implementation".

There is a legal definition of what is included, and what is excluded, from copyrightability, and (though its quite fuzzy, in large part because it was trying to incorporate a fuzzy judicial doctrine grounded in the First Amendment into the statute) what is included, and excluded, from "fair use" even if it otherwise violated copyright.

The courts job is very much to test existing concrete things against those definitions.

"Close your honor, but let me expand on this further. Imagine instead that your opponent publishes their calls and they are regularly available to all individuals of the general public. However, while they may describe a call for going long, they do not give any specifics if the receiver starts from the left, center, right side of the field, how fast he should go, who should block for him, etc. They essentially are just assigning a call to a general concept of 'go long'. Now as a competitor team, I look through their publicly available calls and say "Hey, thats a good idea, we should have a call for 'go long' as well". However, in practice my team does start from the left, and then cut in the center of the field to receive the ball. This may, or may not be totally different then what my opponents choose to do when they call "go long" The additional benefit is if I transfer a new coach onto my team, he can use the call "go long" and even though the team accomplishes the goal, possibly by a different route, he can make the call to accomplish essentially the same thing."

Note: Not a huge sports guys, so perhaps my football analogy broke down a bit there, but hopefully you get the idea.

It’s more likely the arstechniva writer failed to understand the point of the analogy.

Having just listen to the audio, it really annoyed me that Google’s lawyer kept saying “If we can’t copy this it would be impossible to write software.” And always left of the “in Java” part. Really fucking misleading.

First, as colejohnson66 pointed out, that may be a derivative work. This will depend on how your transformer actually works.

I can't think of any way to do it that does not involve having access at run time to a copy of the copyrighted API. If that copy is part of the transformer, there is a good chance the transform is a derivative work.

If the transformer does not include the copyrighted API, instead getting information about it from some external source that the user must supply at run time such as via an input file describing the API using some sort of API description language then it is much less likely to be a derivative work. Well, at least if it somewhat general, working with several APIs described in that language rather than just working with the one particular copyrighted API.

Second, even if it is not a derivative work, the people who use it to make the shim might be infringing. Usually that would not be your problem (unless you do something like indemnify your users, which I'll assume you would not be insane enough to do).

However, you have to at least consider contributory infringement. If I infringe someone's copyright using tools I got from you, and those tools have no substantial use other than infringing copyright, you can be held liable along with me for the infringement.

As with the derivative work case, if you can make the transformer general purpose so that it can be used for transforming APIs that are not copyrighted too, you should be able to avoid contributory infringement.

You mean something that implements all the APIs that the Bell Labs never licensed to anybody?

I agree 100% with those sentiments.

No more so than statutory or any other cases; just as regulation can be changed by the executive and statute can be changed by the Congress, the Constitution can be amended by the process set out in the document itself.

The Supreme Court is the ultimate arbiter of the current state of the law, but no law that it applies, including the Constitution, is immutable.

https://en.wikipedia.org/wiki/List_of_screw_drives#Robertson

How? For that to be true, there would have to be binding precedent applicable outside this case. But Federal Circuit decisions on legal questions—for instance copyright—outside their special subjects (patent claims is what got this case before them) do not create binding precedent for any lower court.

Had this not gone through the Federal Circuit, and had it been the Ninth Circuit (which otherwise would have been the court to hear the appeal) that had ruled, sure, you could then say “Hey, look, there's not some apocalypse due to this ruling happening in the Ninth Circuit, so it must not be a real problem”. But the Federal Circuit decision, notionally applying Ninth Circuit law, has no binding effect on any other court in any other case, so of course it hasn't caused an apocalypse. Precisely because no other court, trial or appellate, has ever held APIs to be copyrightable.

Because APIs have never before been considered copyrightable, unless Google wins on fair use in this case, we will have exactly zero on-point case law as to when an API reimplementation is fair use.

Speculating on what would be considered fair use in API re-implementations in that case would be extremely speculative.

> The amount of money Oracle would get back (and going forwards) in licensing fees for Android would probably dwarf most financial prospects from any API reimplementations that might be at risk.

Maybe more than existing ones, but is it worth more than the entire strategy of using API reimplementation to stay in the game against Amazon, who is far and away ahead in cloud? Is losing that worth a parasitic claim on Android until Google replaces it with something not subject to that claim?

Why would that be considered fair use, and Google's not be? As far as I can tell it's exactly the same situation.

> arguing that there is less innovation in programming because you don't own the rights to function names is ridiculous

I applaud the rhetorical flourish, but I think it misses the point. It's not the cause of the fragmentation, but the fragmentation caused by the lost rights that improves the innovation.

Which was a fairly stupid question from a Supreme Court Justice, because you'd think that they know that decisions of the Court of Appeals for the Federal Circuit on issues not within their special subject matter jurisdiction (which copyright is not) are not binding authority on any lower court, as the lower courts (and, in fact, the CAFC itself) are bound by the actual precedent of the regional circuit court (even trial courts in, in this case, the Ninth Circuit, whose law the CAFC notionally was applying in its Oracle v. Google decision, are not bound by the CAFC ruling, only by decisions actually issued by the Ninth Circuit or the Supreme Court.)

So there is currently no binding precedent applicable to any federal trial court that APIs are copyrightable, which is why the sky hasn't fallen.

You would think that, however much they might not understand APIs, Supreme Court Justices would be intimitately familiar with the appellate structure of the US federal courts.

You're probably thinking about the reproduction of the design document, not adherence to the specifications that document describes.

People make a big deal about beautiful apis. Almost all apis are simply functional. The complexity lies in the implementation not the specification.

An API spec will not (necessarily) provide you with any internal implementation detail. Architectural diagrams/design specifications very likely will do.

If API is copyrightable, I'd love to be the first person to copyright the following API (and variations thereof):

  class Processor {
    void init();
    void process(...);
    void cleanup();
  };

Something like coding is so alien to a 70-80 year old it's basically incomprehensible. That won't be the case with us in 50 years when were that age because we understand it, but there will probably be other things at that point that are equally incomprehensible.

Good APIs embody the key architectural and conceptual decisions. They define the key concepts and how they interact. But at the level of a programming language, this is of immense scope and power. Java defines an imperative language with built in garbage collection with abstraction from physical hardware.

Furthermore, the real distinction between API and implementation is that API are that which needs to be exposed to the world.

Programming languages are more akin to defining the fundamental laws of a universe. Physics to chemistry.

It is true that other APIs are of much smaller scope but the point is that the range is so wide.

[1] https://retrocomputing.stackexchange.com/questions/12018/why...

They reimplement MySQL for Aurora Serverless, but losing Aurora Serverless MySQL probably hurts Amazon less than losing their S3 clone hurts Oracle, and in any case MySQL is GPL and Amazon doesn't redistribute their implementation, so they are probably within the license anyway.

to use the client (boto) with a server you need to CLONE the api. even the headers which are named: "x-amz-server-side-encryption-customer-algorithm" I doubt that oracle would need to call that "x-amz-server-side-encryption-customer-algorithm"