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:
- Whether copyright protection extends to a software interface.
- 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: api, copyright, fair use, java, scotus
Companies: google, oracle
Comments on “Google Asks Supreme Court To Overturn Crazy Ruling About Copyright In APIs”
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.
Re: Re:
Federal judges can be impeached, but it basically never happens.
Good News!
I hope the supremes fix this. Not holding my breath, they refused to address it the first time around.
Seems like too many judges have bought into the idea that “Somebody” must own it and it’s their decision to sort it out rather than pointing out that everything can’t be owned.
( 3 + 4 ) ^ 3 = 343
Nice to see elgooG using the magic numbers again.
Shall we use an API to describe that?
How about raise(term1, term2, power).
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?
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.
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.
Re: Re: For the technically illiterate
Yes indeed:
https://www.nytimes.com/2017/03/16/us/oxford-comma-lawsuit.html
Re: Re: Re: For the technically illiterate
That’s the one I meant 🙂
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.
Re: Re: For the technically illiterate
I hold copyright upon the word arrangement in a dictionary – and alphabetic ordering requires a license
Technically illiterate judges would also have problems with Section 230 and the impact of online defamation, or maybe they just don’t agree with Mike, who just happens to agree with Google.
Re: Re:
It’s not just technologically illiterate judges that whine about Google, 230, or Mike.
Re: Re:
And snake oil selling is difficult is the outrage of previous customers precedes them to the next selling opportunity.
Re: Re:
Damn boy. Did you apply a soothing cream for that burn you just got.
Re: Re:
Maybe you’re not making the point you think you’re making.
Re: Re:
It’s telling that your plans have to hinge on ruling and judicial authorities to have weaker amounts of intelligence.
Fortunately, CDA 230 has no impact whatsoever on the prosecution of defamation, online or off.
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.)
Re: API didn't just pop out of the blue: was creative work.
Even if it is creative, which is arguable, mere creativity is not enough to merit copyrightability under US law.
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.
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.
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.
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/
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.
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*.