Google Asks Supreme Court To Overturn Crazy Ruling About Copyright In APIs

from the don't-mess-this-up-please dept

This is, of course, no surprise at all, but Google has officially asked the Supreme Court to fix the Federal Circuit’s ridiculously bad ruling concerning copyright of APIs. Remember, this was the Federal Circuit’s second awful ruling in this same case, both regarding the copyright status of APIs. The first bad ruling is still a travesty, in that a technically illiterate court couldn’t comprehend that an API is like a recipe or instruction set that is not subject to copyright under Section 102(b) of the Copyright Act that explicitly states:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

However, when you get a bunch of technically illiterate judges together, and show them snippets of an API, which makes no sense to them, they assume it’s the same thing as software code — which clearly is covered by copyright. On the second trip through the courts, the Federal Circuit messed things up again, insisting that Google’s reuse of certain Java APIs could not be fair use.

Google is asking the Supreme Court to hear this issue and overturn the Federal Circuit — something that the Supreme Court has done with some regularity over the past dozen years or so (though, mainly on patent issues, where the Supreme Court has been quite good, and not on copyright issues, where the Supreme Court has been mostly bad). While Google’s cert petition officially clocks in at 343 pages, much of that is just the appendices, which include the various lower court rulings. What’s key is that Google is asking the Supreme Court to review both of the Federal Circuit’s awful rulings in this case:

The questions presented are:

  1. Whether copyright protection extends to a software interface.
  2. Whether, as the jury found, petitioner?s use of a software interface in the context of creating a new computer program constitutes fair use.

I’d still argue that the first question is the more important one here, though if that goes sideways, a good ruling on the second question (as the jury in the district court found) would at least be some level of relief from insanity.

The opening to the cert petition sums everything up nicely:

If allowed to stand, the Federal Circuit?s approach will upend the longstanding expectation of software developers that they are free to use existing software interfaces to build new computer programs. Developers who have invested in learning free and open programming languages such as Java will be unable to use those skills to create programs for new platforms?a result that will undermine both competition and innovation. Because this case is an optimal vehicle for addressing the exceptionally important questions presented, the petition for a writ of certiorari should be granted.

There is, of course, no guarantee the Supreme Court will hear the case (indeed, as everyone likes to point out, the Supreme Court denies most such petitions). However, allowing this ruling to stand would do serious harm to software development, and would be a real shame.

Filed Under: , , , ,
Companies: google, oracle

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Google Asks Supreme Court To Overturn Crazy Ruling About Copyright In APIs”

Subscribe: RSS Leave a comment
25 Comments
Mason Wheeler (profile) says:

I seem to recall that after the first FC ruling, they sent it back to the lower court to decide, among other things, if this was a fair use, because (they explicitly said) it was plausible that it may have been fair use. And then on the second ruling, those very same people said “there’s no way this could have possibly been fair use.”

Is there any way to use contradictions like this to prove that the judges were dishonest and need to be removed? The Federal Circuit has been operating as a rogue court for decades now, and it would be nice to see something like this used to rein them in.

Paul Brinker (profile) says:

Re: ( 3 + 4 ) ^ 3 = 343

This is the basis of the problem. There is a cadence to most APIs, this leads to LOTS of architects building the same APIs for drastically different systems.

Almost any enterprise application today will have the same set of commands:

/Get/Customer
/Get/Account
/Get/”Stuff that’s fairly standard”

You could easily find that 90% of it is duplicated and while “Independent creation” appears to be allowed, how does one prove it when 90% of one API is the same as some other API?

DV Henkel-Wallace (profile) says:

For the technically illiterate

Google should use the example of a dictionary: it can indeed be copyrighted, including the definitions, but two different dictionaries can have the same words (e.g. both can include the words “obscure”, “judicial”, and “frog”). Each has to write its own definition but it is hardly infringement if a user could consult either dictionary and end up with pretty much the same impression of what a frog is.

Bobvious says:

Re: For the technically illiterate

Even the courts expect you to use a specific format on any documentation and submissions. See how far you would get if you didn’t use the specific and EXACT title required. Hmmmm, has anyone ever litigated over the exact placement of a comma???

Every computer program, environment and architecture in existence today relies on the principles of those that went before them, including when they were enacted in things as simple as weaving looms.

TripMN (profile) says:

Re: For the technically illiterate

I will go one step further. Your example of a dictionary is close but could go further.

The dictionaries can be copyrighted for the explanatory and sample text, but what they cannot copyright is the interface, which for a dictionary is more than just the word.

The interface in every modern dictionary is the word, the type of speech, and the pronunciation. That way everyone who runs across a new word knows how it is supposed to be used and pronounced, not just what the meaning given to it by that specific dictionary.

comnothingmon says:

API didn't just pop out of the blue: was creative work.

Again, Google could have just paid the pittance and been done with it, expensed off, just routine. But that’s not Google’s way. TAKE AND DEFY is Google’s way. So lawyered this for years, doubtless cost more than licensing, and won’t give up.

Still hope to have last laugh here, but there’s no predicting Supreme Court when NSA-protected corporations are involved. (Huh, you say? — Google, you should always recall, gives NSA "direct access" according to Snowden.)

Bobvious says:

Re: Re: API didn't just pop out of the blue: was creative work.

Will we ever tire of stating the obvious:

The actual code used to IMPLEMENT the API is already protected by existing copyright laws. The METHOD of engaging with that implementation is the use of the API, with its DESCRIPTIVE form, which describes only the form and/or type(s) of inputs and outputs, and is not patentable, copyrightable, or trademarkable.

Even the NAME of the API function does not have to describe HOW it works, or what it does, in order for it to work.

The raise(term1, term2, power) function described above could easily be replaced with divide_by_zero(you, freaking, moron) and it would STILL work with the correct inputs. Anyone other than the programmer responsible might have trouble understanding what it’s supposed to do or how it works, but code obfuscation is nothing new.

Ever used FIND and REPLACE in an editor? It will happily let you substitute new words and allow you to change the APPEARANCE of PARTS of that API, but not the implementation. Changing all the necessary words to profanities might get you held in contempt of court, but the humble silicon processor doesn’t care.

Any API is based on the things that went before it, or the fundamental principles of operation upon which it is executed.

The compiler/interpreter/translator/assembler will expect specific words in specific places. Good luck with trying something else.

polistra says:

Simpler examples

Simpler non-software examples:

The mechanism of a deadbolt is patented. If this decision stands, you can’t make a key for a lock without acquiring a license for the lock’s patent.

The mechanism of a printer is patented. If this decision stands, you can’t make paper of a standard size, because the standard size fits into patented printers.

Most printed material is copyrighted. If this decision stands, you’ll need to wear separate licensed eyeglasses for each text you want to read, because each text has its own copyright.

pegr (profile) says:

You're making the same mistake they are

“they assume it’s the same thing as software code — which clearly is covered by copyright.”

No, not all software code is copyrightable. Software code must be sufficiently “creative” to be eligible for copyright protection. That is the essence of this very issue.

Put it to you this way. If you give a programming problem to ten programmers and they come up with identical code, the code is not creative enough for protection.

nasch (profile) says:

Re: You're making the same mistake they are

There is a creativity requirement, but the bar may be lower than you describe.

https://copyright.uslegal.com/enumerated-categories-of-copyrightable-works/creativity-requirement/

That is the essence of this very issue.

I don’t think that’s right. The argument is not that the API definition is not a creative work. It’s that it is a "process, system, or method of operation" and thus not eligible for copyright protection. That’s my understanding of the case anyway.

Dyspeptic Curmudgeon (profile) says:

For the technically illiterate

For the technically illiterate judges, the best possible example of an API would be RULE 33 of the Rules of the Supreme Court of the United States.

That Rule is all about how documents are to be sized, printed, colored and bound. How many words may be contained in any particular class of document, and how many copies are to be filed.

The Rule says NOTHING about the actual contents of the documents beyond specifying the general type of content. The Rule is an API for the production of the paper-based aspects of an application for, and the hearing of an appeal to the Supreme Court.

Similarly the API at issue in Google v Oracle has nothing to say about the contents of or even the names of the variables being used in the code ‘behind’ the API, only the structural manner in which that code is called, and the intended results of a call *of that type*.

Add Your Comment

Your email address will not be published.

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...