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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: api, copyright, fair use, java, scotus
Companies: google, oracle
Reader Comments
The First Word
“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.Subscribe: RSS
View by: Time | Thread
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.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Good News!
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.
[ link to this | view in chronology ]
( 3 + 4 ) ^ 3 = 343
Shall we use an API to describe that?
How about raise(term1, term2, power).
[ link to this | view in chronology ]
Re: ( 3 + 4 ) ^ 3 = 343
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?
[ link to this | view in chronology ]
For the technically illiterate
[ link to this | view in chronology ]
Re: For the technically illiterate
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.
[ link to this | view in chronology ]
Re: Re: For the technically illiterate
Yes indeed:
https://www.nytimes.com/2017/03/16/us/oxford-comma-lawsuit.html
[ link to this | view in chronology ]
Re: Re: Re: For the technically illiterate
[ link to this | view in chronology ]
Re: For the technically illiterate
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.
[ link to this | view in chronology ]
Re: Re: For the technically illiterate
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
It's not just technologically illiterate judges that whine about Google, 230, or Mike.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
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.)
[ link to this | view in chronology ]
Re: API didn't just pop out of the blue: was creative work.
[ link to this | view in chronology ]
Re: Re: API didn't just pop out of the blue: was creative work.
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.
[ link to this | view in chronology ]
Simpler 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.
[ link to this | view in chronology ]
You're making the same mistake they are
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.
[ link to this | view in chronology ]
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-requ irement/
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.
[ link to this | view in chronology ]
For the technically illiterate
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*.
[ link to this | view in chronology ]