2015-06-29

New submitter
Neil_Brown writes:
The Supreme Court of the United States has today denied Google's request to appeal against the Court of Appeals for the Federal Circuit's ruling (PDF) that the structure, sequence and organization of 37 of Oracle's APIs (application program interfaces) was capable of copyright protection. The case is not over, as Google can now seek to argue that, despite the APIs being restricted by copyright, its handling amounts to "fair use". Professor Pamela Samuelson has previously commented (PDF) on the implications if SCOTUS declined to hear the appeal. The Verge reports: "A district court ruled in Google's favor back in 2012, calling the API "a utilitarian and functional set of symbols" that couldn't be tied up by copyrights. Last May, a federal appeals court overturned that ruling by calling the Java API copyrightable. However, the court said that Google could still have lawfully used the APIs under fair use, sending the case back to a lower court to argue the issue. That's where Google will have to go next, now that the Supreme Court has declined to hear the issue over copyright itself.

Re: Oracle is GPLd now, then.

By gnasher719



2015-Jun-29 15:01

• Score: 3, Insightful
• Thread

Actually, he might have a valid point. If an api is subject to copyright, wouldn't that make a whole bunch of closed source things in violation of the gpl? For example, the closed source nvidia drivers include some of the kernel api, so are they now subject to gpl?

I suspect that (1) there is a license allowing the inclusion of header files, for example the GPL license terms might allow this, (2) NVidia is merely using, but not copying the header files (unlike Google), and (3) if someone insisted that NVidia can't include kernel header files to build its drivers, then instead of a GPL'd driver Linux users will end up with no driver. And if the same thing happens with ARM / AMD, then good night Linux.

Re:Fucking Lawyers

By HiThere



2015-Jun-29 15:02

• Score: 4, Interesting
• Thread

That would be sufficient to make the APIs stop working. Perhaps you should think again about what information is required and copyrightable.

I think that this decision may mean that Google will need to do something like alphabetize the API. (Customized organization can be copyrighted, but alphabetical order can't.)

Re:Fucking Lawyers

By gstoddart



2015-Jun-29 15:10

• Score: 5, Insightful
• Thread

And yet something written against the Java API can fairly trivially be made to work against the Google API -- well, in theory.

The interfaces for APIs have been borrowed and re-implemented for literally decades. If you retroactively go back and say all of them are licensed and you need to pay money ... you fuck up the entirety of computing history.

Like I said, the standard C library, most of POSIX, the C++ template libraries, Mono ... all sorts of stuff was basically a re-implementation of an API.

This ruling completely ignores several decades worth of precedent, and grants Oracle something nobody else has ever had.

Hell, even Microsoft's vaporware to provide Android support is covered by this. This has very far reaching implications, and makes no sense in the context of computers since the 70s.

Re:Fucking Lawyers

By Anonymous Coward



2015-Jun-29 15:36

• Score: 5, Interesting
• Thread

That would be sufficient to make the APIs stop working. Perhaps you should think again about what information is required and copyrightable.

I think that this decision may mean that Google will need to do something like alphabetize the API. (Customized organization can be copyrighted, but alphabetical order can't.)

Nah, I'm pretty sure Google will win the case against Oracle. There are at least two more defenses they can fall back on.

First, exactly what the summary mentioned: Fair Use. Fair Use is complicated and there are multiple factors to consider but courts generally come down strongest on the economic questions, and there the question is whether Google's action devalued Oracle's property. Speculatively, suppose that Google had had to create its own set of APIs. They could absolutely have been modeled on the Java APIs, but would need to use different names, etc. Google could well have taken the opportunity to clean up a lot of crufty corners of the Java APIs. This would have been a significant undertaking for Google, but wouldn't have been prohibitive by any means. Not doing it saved Google money, but the more interesting question is what was the impact on Java?

I think Google has a really compelling argument that using the Java APIs in what has become the world's dominant personal computing platform's primary development toolset has increased the value of the Java APIs. Although Java was originally built with embedded and mobile devices in mind, without Android it would likely be relegated to being a big systems application language only.

There are probably other Fair Use angles to attack, but that's the one that jumps out at me.

The second defense, and one that seems absolutely deadly to Oracle's claims, is promissory estoppel. Google very much had Sun's approval and cooperation when they decided to use the Java APIs for Android, so it's really nasty of Oracle to try to take that back now, and courts don't buy it.

It would have been better if Google could have established the general principle that APIs are not copyrightable. They shouldn't be, and establishing that would be good for the whole software industry. Barring that, the Fair Use defense could establish a precedent that is almost as good. The estoppel argument solves Google's problem but doesn't do anything to make the industry better.

Re:Fucking Lawyers

By reve_etrange



2015-Jun-29 16:06

• Score: 4, Insightful
• Thread

A Fair Use exception will allow them (if they choose) to effectively exclude APIs without threatening to upturn industry expectations generally.

Unfortunately, fair use claims are judged on a case-by-case basis. Even if Google prevails on this issue, API implementation will be too risky for individual programmers or small companies to undertake.

Show more