Hacker News Reader

Comment by guelo | Hacker News Reader

It's weird how uncommon the knowledge that Google lost the lawsuit is. They lost it in appeal at the Federal Circuit. There is a remaining "fair use" decision from the lower courts but Google doesn't have much hope there.

Google's current approach using Harmony's clean-room API implementation has been basically deemed illegal. Google will likely have to pay millions if not billions to Oracle for copyright infringement. And they will continue to be infringing as long as they are distributing their current Android systems.

P.S. The law of the land is now that when you create an API it is copyrighted.

View on HN

> The law of the land is now that when you create an API it is copyrighted.

The US is the only strange land where such a law could be even comprehended. Asserting API copyright to someone on the basis of accusation of copying nine lines of code[1] indicates that a jury isn't in its right mind.

1. https://news.ycombinator.com/item?id=3940683

Nine lines of extremely trivial code; one would be hard pressed to write it any other way. The judge from the initial trial basically yelled at the Oracle attorneys saying that it was code that a highschooler could have written.

HN is a strange forum, where ostensibly intelligent people will post uninformed, sensationalistic comments despite the presence of multiple earlier comments in the same thread by better-informed people explaining things clearly. To wit: https://news.ycombinator.com/item?id=10848716

(While I am not sure it nails all the nuances exactly, especially around the distinction between web and language APIs, it is an infinitely better account of the situation than what I've seen in any tech media so far. Golly, I wonder why.)

Of course, it doesn't help that the better informed comment is also down-voted, making it harder to find.

No doubt, the link you have provided has some merit and explains a lot about the Oracle's side of coin. But after reading a lot about this story from all different angles, my final impression is that no organization is all too saintly or 100% honest, and neither are any altogether guilty. In fact, the thing about organizations is that they are multi-faced and do a lot of complex things and its just impossible to keep track of all those details.

Considering all this, I feel that the only important thing in technology is that concentration of power shouldn't be in the hands of one/few tech companies, be it Oracle or Google. Rather, there should be checks and balances everywhere. Ideally, all software should be produced by communities where all coders are chosen strictly on merit every commit passes through the scrutiny of all members.

>P.S. The law of the land is now that when you create an API it is copyrighted.

No, it's just the law of the Federal Circuit and only when interpreting 9th circuit law. Their decision is not binding precedent on any of the usual circuits, and their usual domain is patent law, not copyright law.

No. The Federal Circuit has subject matter jurisdiction, not geographic jurisdiction. Their decisions are binding precedent throughout the United States.

They don't have subject matter jurisdiction over copyright. Their decision on a copyright case isn't binding in other circuits.

I think that is correct. This case is a little misleading because there were both patent and copyright claims at the district court level. As a result of the patent claims, the Federal Circuit had jurisdiction over the entire case, even though the copyright claims were to be adjudicated under 9th Circuit precedent. If they had only brought copyright claims, this appeal would have been heard at the 9th Circuit Court of Appeals.

> P.S. The law of the land is now that when you create an API it is copyrighted.

I look forward to the extinction WINE and PostgreSQL, and the resurrection of the SCO corpse for another tilt at Linux vendors, he said sarcastically.

> PostgreSQL

why, which API does that infringe?

SQL. Time for IBM to earn some well-earned royalties from all the current implementers.

Starting with oracle hopefully. (Un)fortunately (and IANAL) I don't think copyrights are enforceable if you don't enforce them everytime you know of a violation.

Nope, that's trademarks.

That won't happen because IBM also uses a lot of Java stuff including the great eclipse infrastructure. They will end up suing each other for a lot of components if that happens. If rumors are to be believed, Oracle and IBM have some sort of "agreement" that they won't sue each other on these matters.

I would venture a guess that IBM is a paid up licensee of Java, they've been releasing their own proprietary JVM for quite a while and never been sued by Sun/Oracle for it AFAIK

That applies to trademarks, not copyrights IIRC.

SQL is an international standard. IBM has gave up their rights long time ago.

I don't see why. WINE is done for interoperability and is non-profit: two fair use defenses. SQL is a language and therefore not copyrightable (its spec isn't "fixed", which is a prerequisite for copyright). And as for SCO, AFAIK, it was ruled that they don't own the copyright to begin with.

Neither of those are fair use defences.

This says they are[1]: Interoperability has been succesfully used as a fair-use defense in the past, and commercial use decreases the chances of a fair-use ruling. Both points (interoperability and commercial use) are central to the Oracle v. Google case, and have been brought up by both sides. See here[2]:

I reached out to Collard, a partner at Dorsey & Whitney, who specializes in intellectual property... "In my opinion, the biggest problem for Google is the commercial nature of its use [of the APIs]," he said. "That is generally a strike against finding fair use. Its best argument is probably interoperability -- in other words, it should be fair use because Google must use the APIs in order to make its products interoperable."

[1]: https://www.cs.duke.edu/courses/cps182s/fall02/cscopyright/C...

[2]: https://adtmag.com/blogs/watersworks/2015/07/google-java-api...

WINE is designed to be compatible with Win32. It is built to be interoperable with that existing product. They strive to be complete, and when issues are found with compatibility, they fix those issues. None of this is true of Android, which explicitly went out of its way to build an incompatible ecosystem of software and libraries using the core work of defining the Java API somewhere in the middle. When the case was first being talked about here, I did a writeup on some of this, extracting quotes from the court's decision that I think make the idea clear. I recommend reading that post.

https://news.ycombinator.com/item?id=7723853

Thanks for the analysis.

That point on Microsoft is just their revisionism, though; the documents and emails gathered by discovery at the time show they weren't excited about Java, but actually trying to "kill cross-platform Java by growing the polluted Java market" (direct quote from their internal strategy docs).

But WINE isn't designed to be interoperable with Windows. I'm not even sure what that means. Outside of some special cases, it's not like you can get something useful (or even functional) by arbitrarily mixing and matching Windows and WINE components.

Instead, for the APIs it supports, WINE was designed to interoperate with Windows programs (binary and source) in same kind of way the Android Java environment interoperates with Java programs (again both binary and source) for the APIs it supports. There are some minor differences (e.g. WINE works with binary applications directly, Android requires that Java bytecode be compiled to Dex bytecode, etc.) but the overall structure is the same.

Sure, Android only supports few Java APIs and WINE supports tons of Windows APIs, but that's the distinction fair use hangs on, how does any re-implementation of a proprietary API ever get off the ground (legally anyway)?

There's a difference between "not compatible yet" and "rips out Swing and implements its own UI library."

Legally is there?

So I'm wondering who Microsoft would sue under US jurisdiction for Wine implementing Windows APIs.

Its not like there is some central corporate entity behind Wine - Codeweavers sells its own proprietary fork and could be sued, but upstream free software Wine was founded by a guy from Switzerland (outside the jurisdiction of the incredibly barbaric IP around software in the US, at least until the TPP passes and spreads that plague through the Pacific rim, but even then Europe remains safe and sane for now). They could sue any individual contributor to Wine who lives in the US, but there is no way to extract royalties from the Wine project itself.

They don't need to sell the developers, just anyone who ships it. Which would pretty much shut down Steam for Linux, as far as I can tell.

> I look forward to the extinction WINE and PostgreSQL, and the resurrection of the SCO corpse for another tilt at Linux vendors, he said sarcastically.

Wasn't one of the central issues that Google copied Java headers verbatim? Wine doesn't copy windows.h [1]; it seems to be a clean room reimplementation.

[1]: https://github.com/wine-mirror/wine/blob/367b30d8278684aaff3...

But this article seems to be saying that Oracle's version is GPLed. If that's the case, then how can Oracle sue Google for copyright infringement? Is it for violating the GPL?

The lawsuit has (mostly) nothing to do with the license the implementation is under.

Oracle's argument is that an API is copyrightable, and cloning an API is illegal.

The only known way to obtain a license to use those APIs is to use the GPLed Java implementation of those APIs.

>use the GPLed Java implementation of those APIs

Google did a clean-room implementation. But what about derivatives? Obviously you have to redistribute your source. Does using your patched version magically become legal iff your changes are merged into the upstream? This seems to defeat the GPL entirely, since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs.

This seems to defeat the GPL entirely, since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs.

Indeed.

IANAL, but that is one (of many) problems with this legal outcome.

Although it's possible that the explicit permission to change the code in the GPL would be interpreted as a license the the API as well.

Although it's possible that the explicit permission to change the code in the GPL would be interpreted as a license the the API as well.

I don't see how it can be any other way; since the infringement was based on the copyright of the API, by having a legal license to the copyright of the code that implements the API, I don't see how can one lack a license to the API. It'd be different if the API was somehow patented, but copyright explicitly covers the actual implementation.

OpenJDK being licensed under the GPL means that the APIs are under the GPL as well. You can legally create your own implementation of the APIs, as long as you don't violate the GPL. Your project would be considered a "derived work" of the APIs, meaning you need to keep the same GPL license.

So why didn't Google do that? Is their Java implementation closed-source?

Apache Harmony is Apache Licensed, and that license is only comaptible with GPL3+. OpenJDK is GPL2 + classpath exception, so no, Harmony is not a valid derivative work of OpenJDK.

Since the only free software Oracle still maintains is the stuff they couldn't relicense from Sun, and the acquisition was before the GPL3 was finalized and even then Sun would not have been able to relicense all their stuff before being bought out, there is no chance of any Oracle products being Apache compatible in the future.

OpenJDk's initial release was May 8th, 2007. Android was already far along in development by that point.

> since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs

I don't understand your argument, wouldn't using the license (GPL) imply a license to use and modify the API's? And that would mean you can create your own modified API, provided it is also under GPL.

This doesn't apply to Google's clean-room implementation since that wasn't using the GPL license.

So, can they take OpenJDK, through a series of commits revert it back to what they have now, release that under the GPL, and be legally in the clear, as long as they don't call it OpenJDK or something that might be confused with it (the license for the name is stricter)?

I don't see why not; as long as it's derived from GPL licensed code, and they respect the license, they have the right to change it to whatever they want.

They don't even have to go through those motions, they could just release what they have under the same license as OpenJDK and grab some of the interface definitions they need from OpenJDK

And they wouldn't necessarily be "legally in the clear"... when this is all said and done they may be found to have infringed copyright illegally and will have to pay a price for breaking the law. Complying with the OpenJDK license would only protect them going forward, not for past transgressions.

Interesting move on Oracle's part would be to try to prove that Google infringed on OpenJDK's copyright (i.e., violated the GPL)... then under GPLv2 Google could lose their rights to redistribute OpenJDK

https://www.softwarefreedom.org/resources/2008/compliance-gu...

Google did a clean-room implementation of copied APIs. Those APIs are licensed under two licenses, and Google chose neither. All you need to do is choose one and comply with it.

All the ruling means is that if you copy an API you should either comply with the license (Google didn't comply with either possible licenses) or don't, but have a good fair-use defense, such as non-profit use and/or interoperability (neither applies to Android, but that hasn't been ruled yet).

Now let me say this again: It has been in Google's best interest to keep people's confused about the ramifications of this court case, because Oracle's legal's department is fierce, and if you believe that they might come after you, too, you'll support Google's position. The reality is that whichever side you're on and regardless of the outcome, the ruling in this court case will not apply to the rest of the industry (because Google's use of Java's API was very unusual).

Google's use of Java's API was very unusual

How is it different from any other reimplementation of an existing API?

Because usually reimplementations are done in a way that would allow programs/libraries written for the original platform run on your platform, i.e. reimplementations are usually done in a way that makes them drop-in replacements to the original as much as possible. That is not the case with Android. Running existing Java programs is a non-goal, and reusing libraries is only a goal as long as it helps Android's separate ecosystem (Java libraries -- for any Java standard -- work on Android only if they happen to use the subset of APIs implemented by Android; this is not due to any real limitations or lack of developer resources, but simply because being a drop-in or near-drop-in replacement for Java is not a goal for Android).

I will note again that Google is free to use OpenJDK however they like -- they don't need to be compatible or anything -- as long as they comply with the GPL license.

Google's use of Java APIs pre-dates OpenJDK.

Google's implementation is a clean-room one, based on the former Apache Harmony and isn't a derivate of OpenJDK. If it would have been a derivate work of OpenJDK, then the GPLv2 license would have protected them.

And no, they didn't violate the GPL. When a copyright owner releases code under an open-source license, that doesn't mean that they are waiving their copyrights. Open-source is not the public domain.

Google was found to be infringing on Oracle's copyright when Google implemented APIs that mirrored the organization of the APIs exposed by Java libraries of the Java platform (as well as other portions of code).

From what I infer, Google borrowed the implementation of classes from Apache Harmony's project, which had nothing to do with OpenJDK. That is, it is an independent implementation of the J2SE, etc.. If that is the case, Google can be found to be infringing on Oracle's copyright when it distributes binaries derived from Apache Harmony code that infringes on Oracle's copyright over Java APIs.

The version the article is talking about is OpenJDK; Oracle holds the copyright of the OpenJDK implementation, and licenses it under the GPL. By using OpenJDK, Google is allowed to distribute programs and code derivative of OpenJDK code as long as it complies with the terms of the licenses.

A word of caution: IANAL.

It won most counts and lost on the API's aren't copyrightable stance. The thing is that even if API's are copyrightable what is the damage if someone does a clean room implementation...

Since Oracle/Sun is effectively giving OpenJDK for free I'd argue the damages are effectively 0 USD so Oracle would win a 0 USD compensation. Since the lower court justice mostly sided with Google I'm guessing compensation won't be much for Oracle.

> P.S. The law of the land is now that when you create an API it is copyrighted.

Oracle has stolen an "r" from the API specification of my full name. How/where can I sue them?

You can sue anyone for anything. That doesn't mean you will be successful.

Then how come Oracle did it successfully?

Because Google was playing dirty after not wanting to pay Sun what they were asking for.

Why should they pay for using something that is free and open source?

Because back then it was only free when targeting desktop and servers, not embedded devices.

Also the license requires that all of Java is taken, not cutting down pieces as they feel like.

To make a few more things clear: that APIs are not copyrighted has never been settled law either, so the chances of getting sued over copyright violation has always existed. The only difference is that before (as Google did) you could make two arguments: 1) that APIs aren't copyrightable to begin with, and 2) if they are, then you're making fair use of them. Now only option 2 exists (with the caveat of the ruling serving as a precedent, as other commenters say).

Also, copyrighted APIs are only "language-level" APIs (or just APIs as we've always called them) -- not web APIs (or protocols, as we used to call them), simply because web APIs lack other prerequisites to be copyrightable.

To the question of fair use. There are several fair use defenses, but two apply to the industry in cases like this: 1/ non-profit use, 2/ use for the sake of compatibility (to prevent vendor lock-in). AFAIK, all third-party implementations of APIs happen to be one or the other (or both). Android is neither -- it is for profit and it is not compatible with Java programs. More than that: it wasn't even done to prevent vendor lock-in. So even if Google loses on the fair-use case, chances are that the defense still holds for all other cases of third-party implementation. Unlike the claims made by Google's PR, this ruling's effect on the industry are at worst tiny, and most likely nil.

> with the caveat of the ruling serving as a precedent, as other commenters say

No, this is incorrect. Because it was a copyright case decided by the Federal Circuit, it is precedent nowhere. Literally no court will need to treat it as precedent. Please educate yourself further before making these lengthy posts in threads like this; you're spreading misinformation.

> Also, copyrighted APIs are only "language-level" APIs... not web APIs (or protocols, as we used to call them)

From this and your post below, this appears to be a distinction you have made up (to appeal to the audience here? I have no clue). "Structure, sequence and organization" are certainly aspects of web APIs that could be copyrightable under the Federal Circuit's ruling.

Also, no one called web APIs "protocols" anymore than they called system calls "protocols". Unless you're talking about actual protocols, in which case I'd just stick to calling them "protocols" because that's what we still call them.

> There are several fair use defenses, but two apply to the industry in cases like this: 1/ non-profit use, 2/ use for the sake of compatibility (to prevent vendor lock-in).

Non-profit use is neither necessary or sufficient for fair use (see Google's recent book scanning ruling, for instance), and the compatibility argument is not with existing JVMs but with existing Java source code.

As for the rest of you post on fair use, I would suggest other readers to take a look at the actual four factors of fair use in the US, as your summary is a poor one. One good source:

http://fairuse.stanford.edu/overview/fair-use/four-factors/

> you're spreading misinformation.

I am most certainly not. I concede that I am not clear on how much this serves as a precedent if at all, but that has little or no bearing on what I've said on the case.

> From this and your post below, this appears to be a distinction you have made up (to appeal to the audience here? I have no clue). "Structure, sequence and organization" are certainly aspects of web APIs that could be copyrightable under the Federal Circuit's ruling.

You can apply "structure, sequence and organization" to anything you like, but if you want it to be copyrighted, your work must be fixed. If it is not fixed -- as in the case of web "APIs" -- it cannot be copyrighted no matter what other properties it may have. If there is a piece of text long enough to be considered "a work" that must be replicated verbatim (or through some copyright-preserving transformation) for you to implement my web API, then that could be copyrighted.

The problem is that even if you have a fixed media form you may not be eligible to copyright (which is where structure, sequence etc. applies).

> and the compatibility argument is not with existing JVMs but with existing Java source code.

Android is not compatible with Java sources.

> I would suggest other readers to take a look at the actual four factors of fair use in the US, as your summary is a poor one. One good source

That is indeed a much better summary of fair use than my poor attempt. Nevertheless, it has no bearing on my point, which is that the result of this lawsuit has little to no effect on any other players.

>> you're spreading misinformation.

> I am most certainly not. I concede that I am not clear on how much this serves as a precedent if at all, but my comments are not predicated on that issue in the least (it is a minor point at best).

This:

> The only difference is that before (as Google did) you could make two arguments: 1) that APIs aren't copyrightable to begin with, and 2) if they are, then you're making fair use of them. Now only option 2 exists (with the caveat of the ruling serving as a precedent, as other commenters say).

is incorrect. Whether or not your comments are predicated on, you know, your comments themselves, I don't care.

> Android is not compatible with Java sources.

There is a whole lot of code that works on Android because those 37 Java packages are API-compatible, which was pretty important back in 2008. You can argue that's creating an incompatible Java ecosystem in order to allow Google to bootstrap an Android ecosystem, but that is compatibility.

As for your web APIs/protocol thing you're on about, I'd suggest defining what exactly you're talking about for anyone to discuss it with you. As it is you seem to be vaguely waving at something you've already defined to not be subject to copyright in order to give an example of something not subject to copyright...but now with a name that appeals to a broad audience (speaking of PR...)

> is incorrect.

Even if it is, calling that "spreading misinformation" is a stretch, as the words "at worst" would make the statement completely true.

Also, if the case serves as no precedent whatsoever how could it have an effect? If it does have some, then what I said holds, and if it doesn't, then there was no cause for panic to begin with, and my point doubly holds.

> There is a whole lot of code that works on Android because those 37 Java packages are API-compatible.

In general, no Java library works on Android except by happy coincidence, as Android conforms with none of the several Java standards. Some libraries (that happen to only use the particular subset Google has chosen to implement) may just so happen to work, true, but it is not true that Android is interoperable with Java for any well-accepted definition of "interoperable" or "Java". Whether or not that's enough to make Google's implementation fall under fair-use is a separate question, but my point is that even if Google's use isn't fair use, that has little bearing on other cases where much stronger "drop-in" compatibility was sought.

> I'd suggest defining what exactly you're talking about for anyone to discuss it with you.

Certainly. I am referring to this: "Copyright protection subsists .. in original works of authorship fixed in any tangible medium of expression"[1]. Explanation here[2]. A specific description of a web API is certainly copyrighted (like any text), but the API it describes is not because it is not fixed. There can be many wildly different texts all describing the same web API. This is not true for library APIs, that are fixed text, just like any other code (that is not sufficient to make them copyrightable, but it is necessary).

Programming languages are -- similarly to web APIs but not library APIs -- not fixed.

[1]: https://www.law.cornell.edu/uscode/text/17/102

[2]: http://www.mateoaboy.com/f6/blog_files/804f4c5940fe299168ea6...

> In general, no Java library works on Android except by happy coincidence

Well that's just not true now is it.

It is true. No Java standard is supported by Android: not SE (maybe some of the new SE compact profiles, but those don't apply to Android's version of Java), not any ME profile, and not any other more obscure Java standards. If a Java library happens to only use the "Android subset" then it will work, but as that subset is not specified by any Java edition or profile, such compatibility can only be coincidental (of course, Google made sure that the libraries they thought may help their ecosystem will work, so it's not a coincidence from that perspective, but it certainly does not make their case for interoperability).

You are technically right on all these points and yet, wrong overall. See my response above [1]

[1] https://news.ycombinator.com/item?id=10850585

> In general, no Java library works on Android except by happy coincidence

This is not true at all.

Every single library I have ever added in my build.gradle has always worked. Every. Single. Time.

Even libraries that were compiled with Java 8, which is the most baffling thing, if you think about it (since Android doesn't support Java 8).

Most of these libraries were compiled and deployed to the Maven repo by Java developers who had no idea whether their library was going to be used on Android. And yet, it does.

This is no happy coincidence.

Have you tried Apache Lucene? Java libraries that declare manifest service declarations won't work.

From Android's perspective, of course it isn't coincidence. Google implemented those APIs that they thought would be useful to Android developers. But from Java's perspective it is coincidence. If I have a Java application or a library (designed for SE or ME -- doesn't matter), it will only work on Android if I'm lucky (I'm not saying there's a 10% chance of it working, but it isn't 90% either). As a maintainer of several Java libraries -- none work on Android -- I feel this pain when people ask us to support Android, and there's a lot of work involved in making that happen.

While I think your understanding of the business situation is accurate, I don't think your distinction about language vs. web APIs stands. My (non-lawyer) take on the situation is this: The interoperability exception for copyright applies only at the system level, for things like binary protocols, byte code and machine instructions. This, I think, is because at that level there is only purely functionality and little expression. Copyright law explicitly covers creative expression and not functionality.

APIs, on the other hand, are required for humans to create systems that interact with other systems. As such they are meant for human consumption and communication and can have significant creative expression. Note that to be interoperable with other Java code, Google did not have to re-use the existing API. They could have used their own APIs, or heck their own language, that compiled down to the same byte-code. This is why I think the interoperability exception does not apply to this case.

As such, I think this ruling does mean that most web APIs, being text-based and intended for human consumption, could be copyright-eligible.

> most web APIs, being text-based and intended for human consumption, could be copyright-eligible.

But the very first condition of copyright eligibility is that the work have some fixed media representation. What fixed representation does a web-API have, a representation that must be replicated for the API to be implemented?

You should abstain from speculating and posting your personal analysis in threads like these. When I say "you", I don't mean the indefinite second person form that stands in for saying "people in general"; I mean you in particular. Your understanding of the relevant statutory and case law is bad, and your comments are, at best, unhelpful. Realistically though, we can call them harmful. Better to just hold it in.

If you're posting to satisfy an earnest effort to be productive and helpful, instead use the time that you would have otherwise spent writing these comments to go somewhere and ask questions in an attempt to better understand the area of discussion here. But don't do this.

While I am not a lawyer and I admit that my previous comment was too legal in nature for my own comfort, it is not any more harmful than Google's agitprop shrieks over a software apocalypse. I am familiar enough with the software industry to conclude that the ruling, for non-legal reasons, is likely to have little or no impact on the industry, which, aside from a few notable cases (each with their own very special circumstances) has not been in the habit of replicating proprietary library APIs wholesale for any purpose (let alone for purposes other than freedom from vendor lock-in) for quite some time. Others, of course, may have other opinions.

While I myself have simplified some of the points regarding fair use defense, I also linked (in this comment: https://news.ycombinator.com/item?id=10851052) to a more nuanced discussion. The bottom line is that both interoperability and commercial use will play a central role in the debate over Google's fair-use claim (and any debate over API implementation).

I also know that Google was encouraged to use OpenJDK for Android precisely in order to prevent the very predictable lawsuit (as well as for other reasons) long before it happened, but Google refused to use GPL software for that part of the Android runtime.

Reply on news.ycombinator.com