Hacker News new | past | comments | ask | show | jobs | submit login

> This is a widespread practice in the software industry. Oracle, for example, re-implemented Amazon's S3 API so that customers who built software for Amazon's cloud platform could easily switch to Oracle's rival cloud platform.

Talk about cutting off your nose to spite your face.




Hope Amazon sues Oracle over this and uses Oracle's arguments against them, claiming judicial estoppel.


1. That would probably be considered fair use.

2. The amount of money Oracle would get back (and going forwards) in licensing fees for Android would probably dwarf most financial prospects from any API reimplementations that might be at risk.


> That would probably be considered fair use.

Because APIs have never before been considered copyrightable, unless Google wins on fair use in this case, we will have exactly zero on-point case law as to when an API reimplementation is fair use.

Speculating on what would be considered fair use in API re-implementations in that case would be extremely speculative.

> The amount of money Oracle would get back (and going forwards) in licensing fees for Android would probably dwarf most financial prospects from any API reimplementations that might be at risk.

Maybe more than existing ones, but is it worth more than the entire strategy of using API reimplementation to stay in the game against Amazon, who is far and away ahead in cloud? Is losing that worth a parasitic claim on Android until Google replaces it with something not subject to that claim?


Google already switched Android over to OpenJDK in 2016, which they have an absolutely ironclad right to use without paying for. If Oracle does end up winning the payout will be for the period of 2008-2016 when Google was using their own home brewed Java implementation.


Unless this ruling becomes applicable to the Java bytecode format, in which case they can go after Dalvik and ART (the latter of which is still in use).


> That would probably be considered fair use.

Why would that be considered fair use, and Google's not be? As far as I can tell it's exactly the same situation.


Google wasn't interested in interoperability. A big part of why they allegedly walked away from Java licensing was Oracle wanted Android to actually run Java apps, and Google wanted to basically fork off, but just benefit from the developer community around the Java language.


Can't you use many Java libraries on Android? Interoperable doesn't mean "exactly the same".


There were a number of Java standard library incompatibilities that various libraries have had to adapt to, until they switched the library implementation to OpenJDK.


Interoperability is not limited to executable-interop: it includes developer knowledge, libraries and tooling - which are exactly the reasons Google chose to use Java (the language). Dalvik checked all those boxes, without being bytecode-compatible with the JVM


Because Oracle implemented the S3 API in order to be compatible with Amazon, while Google didn't implement the Java API in order for Android apps to be compatible with server-side Java code.


Both reimplement for compatibility at some level in the toolchain, why fair use analysis would privilege one level of interoperability over another is purely speculative; arguably, the kind of user-interoperability Oracle does is more of an assault on the market for what is reimplemented (that's the whole purpose of Oracle doing it) than what Google is doing, and that's a factor that weighs against fair use.

It is important to realize that since APIs have never been viewed as copyrightable previously, we also, if Google loses on both copyrightability and fair use, will have zero case law that is directly on point for any API reimplementation being fair use. Speculating on the law that will develop in that area is fun, but almost by definition not strongly grounded.


How do you figure that it would be considered fair use in one case but not the other?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: