
Google/Oracle’s $9B Copyright Case Could Be Headed for the Supreme Court - lawrenceyan
https://www.newsweek.com/2019/06/07/google-oracle-copyright-case-supreme-court-1433037.html
======
grellas
No tears will be shed, I am sure, if Google has to pay some billions to fatten
the already fat pockets of Oracle but the decision by the Federal Circuit
being appealed here made a hash out of key legal foundational items that
facilitate the very idea of interoperability in the computing world and
therefore cries out to be corrected.

My comment at the time the decision was rendered: "This ruling will do what
its [the Federal Circuit's] prior expansive reading of patent law did: it will
set up a legal standard that invites lawyers and litigants to engage in
endless second-guessing over copyright and fair use in areas of connectivity
and inter-operability in the computing world and this in turn, as a standing
invitation to litigate, cannot be good for future development." (See
[https://news.ycombinator.com/item?id=16691774](https://news.ycombinator.com/item?id=16691774)
for fuller analysis)

The Supreme Court quite often fails to take up discretionary appeals even if
the issues loom large for a particular industry or even if an important case
was wrongly decided. Sometimes it does so to resolve conflicting rulings among
lower federal courts on an important issue; other times, because a case raises
important issues of public policy. Don't know if this case will fit the
criteria (it didn't on its first cycle of appeal - see my comment here:
[https://news.ycombinator.com/item?id=9801251#9802457;](https://news.ycombinator.com/item?id=9801251#9802457;)
also,
[https://news.ycombinator.com/item?id=4050490#4051761](https://news.ycombinator.com/item?id=4050490#4051761)).

I have long been an advocate for solid protection of IP rights but the Federal
Circuit here has almost fetishized the idea of copyright protection to the
point where it has, in the API and fair use areas, become a caricature of
itself. Strong correction _is_ needed on the legal merits of the case.

Let us hope that the high level of interest in the tech community, as revealed
by the number and quality of amicus briefs filed, will prompt the Supreme
Court to intervene and bring soundness and clarity to an important area of law
that affects the tech world in profound ways.

~~~
monocasa
> Sometimes it does so to resolve conflicting rulings among lower federal
> courts on an important issue; other times, because a case raises important
> issues of public policy. Don't know if this case will fit the criteria

It will. The CAFC's rulings are in open conflict with the normal court that
would handle this, the ninth circuit.

------
liara_k
The aspect of this case that I don't understand is why, even if APIs are
copyrightable, why Google would need a special license for the Android. If
Java is available under the GPL, and Android is a derivative work but is also
licensed under the GPL, then where's the problem?

Conversely, by Oracle's logic, any application that uses the Java API would be
a derivative work (the method signatures are perfect copies), and thus the app
would need to be either GPL itself or pay for a commercial license for Java.
This, too, seems incompatible with existing practice (e.g., Apache's Java
applications are licensed under its own open-source license which is more
permissive and thus can't be a derivative work under the GPL.

What am I missing here?

~~~
geofft
Wikipedia says:

" _At this point in time, the OpenJDK implementation offered by Sun was not as
mature or complete as the Java Standard Edition. Instead of licensing Java,
Google chose to develop a cleanroom version of the Java Standard Edition
libraries, developing the libraries from a completely fresh start without any
access to Sun 's code._"

OpenJDK was released in 2007. Android was founded in 2003 and acquired by
Google in 2005. It's entirely possible that if the schedules had been shifted
a few years, Android would have gone with OpenJDK.

Note that OpenJDK is available under the GPL with the "classpath exception,"
allowing you to link non-GPL software against it (sorta like the LGPL).
Android avoids the GPL in userspace, to the extent of writing their own libc
(apparently glibc being under LGPL was not enough).

~~~
stefan_
When Android was started, no embedded system of any kind used glibc. It's now
2019 and still _none_ do. It's not GPL avoidance, it's just glibc being (a)
huge (pain) for all the wrong reasons.

~~~
andrekandre
what parts of glibc make it trouble for embedded systems? is it the way it
uses memory? or just “too large”?

~~~
kllrnohj
glibc has a reputation for being bloated. Here's a post from 2002 of Linus
complaining about it, for example: [http://ecos.sourceware.org/ml/libc-
alpha/2002-01/msg00079.ht...](http://ecos.sourceware.org/ml/libc-
alpha/2002-01/msg00079.html)

Independently of that glibc also has organizational issues. You see this in
some major projects flipping back and forth on it, like Debian switching to
EGLIBC in 2009 and then back to glibc in 2015. You continue to see this with
the very slow (or outright rejection) adoption of new syscalls:
[https://lwn.net/Articles/655028/](https://lwn.net/Articles/655028/)

It's important to remember glibc is _not_ libc for Linux, and distinctly does
not behave as such. If your platform is unapologetically Linux to the core,
wouldn't you want something else that tracks the kernel API better?

And it's not like Android was unique in not using glibc, either. The *BSD's
don't, either.

~~~
geofft
The job of a libc involves a lot more than just tracking the kernel APIs: it's
got a malloc implementation, string handling, userspace buffered I/O and
formatting, locales (quite a bit _more_ important on a phone targeted at
consumers around the world than on servers whose sysadmins generally prefer
messages in English to their native tongue anyway), user and group names and
not just numeric IDs, DNS resolution, thread handling, math functions, etc.
All of that is quite independent of your kernel and hewing closer to Linux
doesn't help you with any of it - except _maybe_ the thread stuff, and for
that glibc is the standard pthread implementation for Linux so you're probably
better off using it anyway since that's what the kernel developers expect. (In
other words, libc is the C standard library, not the kernel's client library
for its APIs.)

Bloat in terms of amount of _code_ is a confusing argument: you map libraries
from disk, so you only use memory for the pages of code that have actually
been read from disk and you only use one copy regardless of how many programs
are running. You could add a function to glibc to print _War and Peace_ to the
screen and the only thing it would do is add a few megabytes of disk usage if
nobody called it. Even on Android, disk is cheap.

EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was
intended for embedded use.

The BSDs don't use glibc because of licensing concerns, not because they
dislike glibc's bloat. (Their own libcs implement just as much, because
programs use those features.) My claim upthread was that Android avoided glibc
for licensing concerns, not for technical unsuitability; giving the BSDs as an
example seems to agree with that argument.

~~~
kllrnohj
> locales (quite a bit more important on a phone targeted at consumers around
> the world than on servers whose sysadmins generally prefer messages in
> English to their native tongue anyway)

This is part of where glibc's bloat comes from. Locales are important, yes,
but when your libc's versions are bad and you have to ship an alternative
anyway (icu4c), then the one in glibc is just pure, wasted bloat.

But ignoring that aspect since not every program needs internationalization,
this just becomes bloat in the libc.

This is really not something a libc (or any standard library) should be
handling. Even if it's just because it's an area that moves too fast for a
standard library to typically keep up with, and needs a faster deployment
cycle.

> Bloat in terms of amount of code is a confusing argument: you map libraries
> from disk, so you only use memory for the pages of code that have actually
> been read from disk and you only use one copy regardless of how many
> programs are running. You could add a function to glibc to print War and
> Peace to the screen and the only thing it would do is add a few megabytes of
> disk usage if nobody called it.

Not entirely true. You're assuming everyone is using a single shared version,
which isn't universally true. Some need static for reasons, and there's
multiple shared versions not one for 32bit vs. 64bit or strict versioning
requirements.

Also not all functions are free to add. __attribute__((constructor)) exists,
after all, and is hugely not free of course. Similarly pages are not purely
loaded on-demand, they are prefetched. Depending on where you've added those
functions and how the resulting layout happened, you may now be getting fewer
prefetch hits than you did before.

> Even on Android, disk is cheap.

No, not really. Today is the size of glibc less important? Maybe, sure. Was
that true back in the Android 1.0 days? No. There are some numbers here:
[http://www.etalabs.net/compare_libcs.html](http://www.etalabs.net/compare_libcs.html)
glibc is stonking _massive_ compared to what a C library really needs to do
and, critically, has the largest minimum dirty page sizes. That's a shared
library creating not-shared memory usage.

> EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was
> intended for embedded use.

Someone forked GLIBC and ripped a bunch of stuff out and you're taking that as
a good sign GLIBC was intended for embedded use? What?

~~~
geofft
> _Someone forked GLIBC and ripped a bunch of stuff out and you 're taking
> that as a good sign GLIBC was intended for embedded use? What?_

If that were what happened, then you'd have an argument, but eglibc contained
_more_ than glibc did (the primary motivator was that glibc refused to support
architectures that the maintainer didn't like; they also had patches to
support compiling things out, but that's _more_ source code and certainly
isn't ripping anything out). If you don't know this history I have trouble
taking the rest of your argument seriously.

~~~
kllrnohj
> but eglibc contained more than glibc did

That "more" being "you can remove things." Straight from the project:

> EGLIBC's goals included reduced footprint

> A primary feature of EGLIBC is support for configurability. You can build
> EGLIBC without support for NIS, locales, or other things that you may not
> need in your embedded system.

So sure a full-fat EGLIBC was as big as GLIBC, but that was clearly not the
point of making all the big stuff removable, and binary compatibility was not
guaranteed as a result.

> the primary motivator was that glibc refused to support architectures that
> the maintainer didn't like

Given that reducing size is the first listed goal in both the opening
description _and_ the mission statements it seems like your claim is more
about what you wish was true than anything else.

Furthermore the "why not contribute to GLIBC?" FAQ states "The GLIBC
maintainers have stated that they wish to focus on server and workstation
systems." Given servers with non-x86 architectures definitely exist (PowerPC
says hello), along with GLIBC supporting an exhaustive list of architectures
anyway, it seems this is really just about size after all. Unless your
argument is GLIBC maintainers held a grudge against ARM specifically?

------
binthere
I must admit I have not been following this case too close. But I get the
general sense that most people in the CS community is in favor or Google and
against Oracle. I'd like to understand it better.

Can someone please explain _in technical terms_ exactly what Google copied and
what is Oracle complaining about? Is it just the Java API declarations? Most
of the articles I find try to explain the issue in layman's terms which makes
it harder for me to understand exactly what was copied.

~~~
dmitrygr
Google REIMPLEMENTED base classes to match what a normal Java app would
expect. They complied with the public API as you'd find in javadocs. Oracle
claims that is infringement because to make that work, their method signatures
look identical to oracle's (and thus Oracle claims they were copied, in
violation of copyright law). Google claims that API cannot be copyrightable by
definition (an argument that most programmers agree with I feel)

There was also a bit of similar code for obvious reasons. For example, how
many ways are there to implement "bool rangeCheck(int idxRequested, int
maxValidIdx, int minValidIdx)"?

~~~
krn
Is it similar to how Preact just implements React's API? So the problem here
is, that Java's API is not under MIT? And what about all those competing
companies that implement AWS S3's API?

~~~
wuliwong
I'm trying to understand the same thing. I think the idea is something like
the render method basically behaves the same whether it is React or Preact but
the actual code inside of Preact's render method is written from scratch.
Although, in the case of Preact, it's probably not necessary because of the
license for React?

~~~
dmitrygr
Yes. All actual implementation code was not oracle's

~~~
zucker42
Actually, there were 8 lines (of out however many million) that all parties
agree was copied, but that's been ruled de minimis. All the implementation
code they're ruling on now is not orcale's.

------
mjw1007
As far as I'm concerned, it's a huge failure that, over thirty years after
computer programs were explicitly added to copyright law, it isn't clear to
what extent APIs are copyrightable, and we have to watch lawyers argue over
strained analogies to chapter titles in Harry Potter books.

I think the process where the legislature writes a vague law and leaves it for
the courts to decide what it actually means over a series of cases has fallen
down badly here.

~~~
dmitrygr
Do you really want our senators, who usually old enough to remember hunting
dinosaurs, writing these laws though? At least in court informed experts can
be called. Congress only hears from experts if they so choose (surprise: they
usually don't so choose)

~~~
mjw1007
I think there are other options.

We could do a better job of getting test cases through the courts that clarify
the law.

Or we could invent new mechanisms for turning rulings from specific cases into
general principles that people can rely on.

Or we could allow somewhat more hypothetical cases in certain circumstances.

As I understand it, in the US, after a few cases like the Phoenix BIOS one
people came to believe that a clean-room reimplementation of an exisiting
interface was generally permitted, and so people stopped suing and we didn't
get a flow of cases exploring the limits of that principle.

So now when Oracle comes along and points out that the Java API is a lot
bigger, and arguably more creative, than the PC BIOS call interface, there
isn't an existing case that settles the question.

I can see why there's reluctance to allow people to get courts to decide
hypothetical questions, but this case seems to be a decent example of when it
would be helpful: if Google had had the option of getting a ruling ahead of
time on whether its Java library clone was permitted, it might have saved an
awful lot of time and money.

~~~
jacques_chester
Courts don't decide hypothetical questions. They decide on the case before
them, constrained by the precedents of previous cases.

A judge can use examples and hypotheticals (called "obiter dictum"), but that
doesn't create a binding precedent and later judges may ignore it, refute it
or alternatively convert it into precedent by adopting the reasoning in a
decision.

------
optymizer
I've discussed this topic once with a developer who sided with Oracle, which
was a fun exercise for me, because I side with Google.

The insight I got from that exercise was that, to him, APIs represent a
product (e.g. I put a lot of effort into making this API, it's nice and clean,
why should someone else be allowed to copy it?) and the implementation is
typically straightforward grunt work, with intrinsically less value (e.g. we
all know how to square a number).

As a developer, it was easy for me to sympathize with that thinking, because
who hasn't been amazed by how elegant some of the APIs are and how difficult
it is to create a simple, yet powerful API?

However, I believe that in the general case, it is the implementation that's
the difficult part, which is why I'm against copyrighting APIs. Anyone can
come up with an API for a Map, not everyone can create an efficient
implementation of HashMap.

Doesn't this sound vaguely familiar? I think it's the same argument as "ideas
vs execution", it's just that, as a community, we've discussed the pitfalls of
ideas, NDAs and execution an order of magnitude more than copyrighting APIs vs
implementation, and so there's less of a divide.

If you side with Oracle and you agree that execution > idea, then you should
consider that implementation > API, and, similarly to how you can't copyright
an idea, you shouldn't be able to copyright APIs.

In the case of Oracle vs Google, both the API and the implementation are
trivial, which is a special case of the more general "API vs implementation",
and it is unfortunate that a precedent will be set for the general case, based
on a special case. That sounds like a recipe for future trouble.

~~~
wtallis
> I put a lot of effort into making this API, it's nice and clean, why should
> someone else be allowed to copy it?

The problem is that copyright protection has requirements beyond the above
sentiment, which can just as easily apply to something that needs to be
patented rather than copyrighted. You can't get copyright protection just
because you feel you deserve it.

------
nradov
I hope Google wins the legal case for the sake of maintaining an innovative
software industry. But at the same time I still think that they acted like
jerks by creating their own proprietary pseudo Java for Android rather than
negotiating a formal agreement with Sun. Now the Java ecosystem is fragmented
so many Java tools and libraries can't be used for Android development. That's
bad for everyone.

------
exabrial
Is there anything we can do as developers? Obviously I don't want to DDOS/DOX
the supreme court, but can we write letters or do anything else to show _how
massively important_ this is?

EDIT: For those unable to read between the lines, HN is a large forum read by
thousands of people of different backgrounds. Often when someone suggests
something, small actions can add up to create a large problem. DDOSing/Doxing
is never acceptable for any situation. I want to "do something" but without
accidentally creating a problem.

~~~
JudgeWapner
How does it impact us as developers either way? Both are titans that have
contributed vital pieces of tech infrastructure as well as committed evil acts
in their space. Oracle is arguably more evil here, but is it that big of a
tragedy if Google loses? They have obscene amounts of cash; what difference
does it make if a pile of cash goes from one evil pocket to another? Please if
you downvote give an explanation. I honestly want to know what's at stake here
for us.

~~~
lloydde
> How does it impact us as developers either way?

“Treating APIs as copyrightable has a profound negative impact on
interoperability and innovation. And it goes against decades of tradition and
common practice in the software world.”

[https://www.eff.org/deeplinks/2017/05/eff-asks-federal-
circu...](https://www.eff.org/deeplinks/2017/05/eff-asks-federal-circuit-fix-
its-terrible-api-copyright-decision)

~~~
id7f8gmh
Controlling how the issue is framed has a larger impact than who wins. Whether
APIs are copyrightable is beside the point and no matter who wins, we all
lose:

If Google/Oracle can copyright APIs, then they are free to use their market
positions to block competition because the very ability to inter-operate with
other programs would be infringement, and their monopoly forces everyone to
acknowledge their presence.

If Google/Oracle cannot copyright APIS, then they're free to use their market
positions to snuff out upstarts by copying / re-implementing their programs.

Whether some method signatures are the same is just evidence suggesting
copyright infringement, not infringement itself. I can write a song with some
of the same words as another song. That doesn't answer the question of whether
that's copyright infringement.

~~~
lloydde
> If Google/Oracle cannot copyright APIS, then they're free to use their
> market positions to snuff out upstarts by copying / re-implementing their
> programs.

Do you have examples of this? I’m having a hard time thinking of types of
programs that are susceptible.

I’d argue that the small businesses have much more to lose by APIS being
copyrightable as you then are locked out of ecosystems. You’d have to pay to
play to build compatible or replacement products. If this was the rule of the
land in the 70s+ would we have had GNU tools or BSDs?

------
sarcasmic
This whole case is contrived, and both actors acted in bad faith, so the
outcome will be troubling no matter what.

If Oracle wins, others can claim that their API is copyrighted and weaponize
copyright law to sue anyone they don't want to interoperate with them --
despite the whole point of APIs being that interoperability.

If Google wins, it means anyone will be able to hijack the syntax, semantics,
and interfaces of an ecosystem verbatim for commercial ends to promote an
incompatible implementation, like they've done with Android. To protect
against this, patents and NDAs will proliferate, and black-box organization
and SaaS business models will solidify as the only (commericially) sensible
way of distributing software.

~~~
XCabbage
How did Google "hijacking" the Java API harm Oracle? If it didn't, why should
anyone need to "protect" against such a thing happening in future?

Maybe I'm missing something, but your comment seems to boil down to "If Oracle
wins, people won't be able to copy APIs, which is awful! If Google wins,
people will be able to copy APIs, which is awful!" Surely you have to be on
one side or the other?

~~~
jryan49
It segmented the Java ecosystem into two parts. Android doesn't keep up-to-
date with current Java version changes and creates friction. It seems similar
to what Microsoft did to Java in the late 90's [0] (without the malicious
intent).

0:
[https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine](https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine)

~~~
mullingitover
> It segmented the Java ecosystem into two parts.

I'd argue it vastly expanded the Java ecosystem, and the original part is
unharmed. It's not necessarily getting unearned growth from the success of
Android, but at the same time it's a _huge_ stretch to say it was harmed.

------
wuliwong
I'm trying to understand what was copied by Google.

Did they copy the core class names and the different method and attribute
names for these objects but rewrote everything else from scratch?

I dont know java but but lets say it was ruby and then i made xruby and copied
the same type of things. So, Random.rand (in xruby) still produced a similar
random Float like in ruby. But the code that was called by Random.rand was
entirely written by me from scratch? Is that the idea?

~~~
orthoxerox
Imagine Ruby was closed source, but you were allowed to make open source
implementations that ran Ruby programs.

Then you implement a language called Crystal that uses Ruby syntax and its
stdlib looks a lot like Ruby's, but it can't run Rails because it's designed
for car navigators, not webapps.

The Ruby Company comes after you and says that if you wanted to reuse their
APIs you should've bought a license.

~~~
wuliwong
Interesting. I was thinking it was like google copy and pasted oracle's code,
kept the function definitions and then re-wrote the innards. To me if code is
truly treated as a literary work then it doesn't really matter how the end
product behaves. It matters whether the text was copied.

In the case of ruby vs crystal, I think the courts will rule on the side of
crystal!

------
kodablah
> "Before Android," Oracle’s lawyers write in their brief to the Supreme
> Court, "every company that wanted to use the Java platform took a commercial
> license...including smartphone manufacturers BlackBerry, Nokia and Danger."

Either that's word twisting (e.g. "platform" means something different or the
commercial license was implicit) or just false.

~~~
stefan_
What they licensed to BlackBerry, Nokia and Danger was of course the Java ME
runtime.

------
TheFlyingFish
I really only have two questions about this case:

1) The US legal code explicitly excludes "methods of operation" from being
copyrightable. Does an API count as "methods of operation"? And if so, what
ground does Oracle have left to stand on?

2) If this case goes Oracle's way, does this set the precedent that ANY re-
implementations of an existing API are in violation of copyright? I don't know
who now owns the original rights to Unix, but if they decide to come after
Linux where does that leave us?

~~~
beefhash
> 2) If this case goes Oracle's way, does this set the precedent that ANY re-
> implementations of an existing API are in violation of copyright? I don't
> know who now owns the original rights to Unix, but if they decide to come
> after Linux where does that leave us?

We can't know until a decision is made, but this could likely start a
precedent for _any_ re-implementations.

The curent copyright holders of UNIX are Micro Focus, who acquired it via
buying Attachmade, who had bought Novell, who had bought UNIX System
Laboratories from AT&T. Micro Focus mainly sells COBOL and is apparently
hellbent on ignoring UNIX as much as possible (multiple people have tried to
reach out to them about Ancient UNIX and possibly licensing some missing parts
like PWB/UNIX and System III, but the best they've had is a salesperson being
confused and trying to sell SUSE Linux). If they ever regain their
institutional knowledge that they hold copyrights to UNIX and this decision
happens, well, it's open season for Micro Focus v. Red Hat.

------
paganel
Oracle now has a market cap of about $170 billion, give or take a few billion,
I'm pretty sure that if a company like Google put its mind to it it could
purchase Oracle outright.

It would also allow Google a very good entry on the enterprise market where it
could push GCP down its clients' throats, imho there's no other way for them
to catch up with AWS and Azure.

~~~
burtonator
Buying oracle might kill them. Like a tiger eating a poisonous snake and
getting bitten

------
pier25
IANAL... but it seems to me copyrighting an API instead of the actual
implementation would be like trying to copyright the idea of "chair" or
"wheel" which is not possible AFAIK.

~~~
sovande
A better metaphor is probably to look at an API as a design blueprint. For
instance a blueprint of a house. Describing in detail all the components that
goes into creating the house, plumbing, electricity, rooms etc. Clearly it is
a lot of work to come up with such a design.

~~~
count
It's a literary work. It's copying the table of contents, but writing your own
chapter text.

I fail to see how it's not copyrightable as such. It appears to be a
collection of facts (the interface of the implementation). These are not
copyrightable, _unless_ it meets the following:

"the work must be a collection and assembly of pre-existing material, facts,
or data; the work must contain the selection, coordination, or arrangement of
those materials; and the work is created by virtue of the particular
selection, coordination, or arrangement of an original work of authorship."

I can't see how "arrangement of those materials" and "virtue of the particular
selection or arrangement" isn't obvious here?

Oracle is pursuing the path where this case is literally about the contents of
text files with words, which are supposedly well defined and understood under
copyright law.

~~~
monocasa
A table of contents, stripped of editing, is generally not copyrightable as
is. It falls under mere listings of ingredients or contents exemptions.

------
javagram
IMO copyright protection is way too strong and long lasting for this type of
thing.

The creation of something like Java should be protected by the patent system
which at least has an expiration time of a couple decades rather than a
century like copyright.

Google taking Java and reimplementing it without paying a penny to Sun (who
was requiring a license to other manufacturers at the time) does seem unfair.
But I think the law should provide something like the “FRAND” standard for
patents, or the mandatory mechanical license for copyright, to prevent a
company from blocking interoperability.

As far as who’s actually right on the law today.... the SCOTUS decisions will
be interesting to read :-)

------
shmerl
Supreme Court should bust the bad decision about copyrightability of APIs.

------
panpanna
I'm surprised the board at Oracle has let things go this far.

Google could probably do a lot of damage to Oracle if they wanted.

~~~
AsusFan
How so?

Google has already been found guilty of Copyright Infringement (and then
admitted it by invoking the "fair use" defense).

They are in the hole already. This is just ironing out the details of how much
Google is in the hole.

~~~
panpanna
Buddy, EVERYTHING in this trial is about fair use.

Oracle using a technicality to ask 9B for something they used to give away for
free can backfire.

~~~
javagram
Sun didn’t give it away for free. They charged manufacturers for licenses for
J2ME - Until google came along and blew up their business with android.

------
alfalfasprout
It's mindblowing how so many developers are quick to build on the Java
ecosystem... an ecosystem backed by a company so hell-bent on stifling
innovation.

~~~
panpanna
Java was created by Sun. Oracle bought them mainly to sue Google.

Kotlin from jetbrains is where developer mindshare is today ;)

~~~
pier25
But Kotlin does run on Oracle's JVM, no?

~~~
jryan49
Runs on OpenJDK as well...

~~~
icebraining
That's Oracle's too.

~~~
lma21
Really? In what way does it differ from Oracle Java SE ?

~~~
__HYde
In that it is GPL+Link Exception licensed. The copyright still belongs to
Oracle. See this[0] example:

> Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.

> This code is free software; you can redistribute it and/or modify it under
> the terms of the GNU General Public License version 2 only

[0]
[http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/tip/src/share/...](http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/tip/src/share/classes/java/util/List.java)

------
pubkraal
If anyone knows, how much would this affect non-US technology processes and
legislature? What would an outcome of this mean for Asia and Europe?

~~~
orra
What Google did is very clearly lawful under European Union law.

The Software Directive explicitly permits reverse engineering for
interoperability.

Interoperability is not explicitly defined, but is widely understood to relate
to interfaces. API, or Application Programming Interfaces, are of course
interfaces. Hence you can reverse engineer APIs to create something
interoperable, without infringing copyright.

This topic has even gone to the CJEU, the top European court. World
Programming implemented a language and library compatible with SAS. SAS sued.
Ultimately, the court found in favour of World Programming.

Of course, despite reimplementation of APIs clearly being legal in Europe, a
ban in the US could still have a chilling effect, due to the international and
cross border nature of software development.

~~~
orthoxerox
Except Google didn't provide interoperability, you can't run Java applications
on Android. A lens company can study how a camera company mount works and sell
compatible lenses. A camera company cannot study another camera company's
mount to make an incompatible mount that uses similar circuitry and protocols
to help lens companies support it faster.

~~~
wtallis
> Except Google didn't provide interoperability, you can't run Java
> applications on Android.

You don't get to pick your own narrow definition of "interoperability" and
claim that it's the only one that applies. Requiring 100% compatibility with
compiled code quite obviously makes it trivial for the creator of the original
work to completely subvert that right to reverse engineer. European courts
would almost certainly choose to interpret that right in a way that allows it
to have real power.

------
christkv
If Oracle wins this lawsuits does that mean it’s the death kneel for AWS
cloning open source wire protocols like MongoDB ?

------
smadurange
Is this copyability issue for software APIs or more general? I feel like if I
copied the full user interface of an iPhone (the way it looks and interacts
with the user) and provided my own imementation I'm still liable?

------
bitwize
The Supreme Court should, and probably will, deny cert.

Read the CAFC's opinion. Pretty cut and dry in favor of Oracle. APIs are not
an abstract idea, but a concrete expression of an idea, thus protected by
copyright. Google could have chosen its own expression, but decided to copy
Oracle, which is against the law.

~~~
e1ven
Under that interpretation, I'm curious what you view as different than IBM vs
Compaq about the original PC bios?

~~~
bitwize
The law is the law. Wishing it were different doesn't make it so. Which means
that yes, Compaq and other PC clone makers may have broken the law by
reimplementing the PC BIOS. The BIOS API does not depend on named functions
but rather on specific values appearing in CPU registers, so I'm not sure how
copyright applies to that. Maybe a "structure, sequence, and organization"
argument à la _Whelan v. Jaslow_.

~~~
wtallis
> The BIOS API does not depend on named functions but rather on specific
> values appearing in CPU registers, so I'm not sure how copyright applies to
> that

Do you have any reasoning for treating magic numbers different from English-
like names for the purpose of determining copyright eligibility?

~~~
bitwize
No, I don't. Which only supports the copyrightability of the BIOS API, and the
illegality of BIOS clones (and hence, early PC clones).

------
RcouF1uZ4gsC
One thing I hope everyone agrees with is that API design is an art. Often
coming up with a good API is as significant a task as actually implementing
it. An API that is intuitive yet flexible and extensible is tricky to design.

If APIs are copyrightable, this actually might be good for open source
projects such as Redis and MongoDb where cloud providers are just taking their
API and creating implementations. This has been a huge issue for
sustainability of these kinds of open source initiatives when a multi-billion
dollar corporation can just come through, take the API and write their own
implementation.

~~~
orthoxerox
Did Redis and MongoDB copyright their APIs?

~~~
icebraining
Copyright is automatic, so if APIs are copyrightable, the answer is
necessarily "yes".

------
vxNsr
This is the first time I've read anything in depth about this and I gotta say
Oracle's case feels stronger and google is tilting at windmills. Oracle wrote
something, google copied it.

Oracle isn't arguing that you can't use java api's in general without a
license. Its arguing that if you wanna create a new platform you can't copy
copyrighted code. Doesn't matter how small it is, google has demonstrated that
it was intentional and instrumental in helping android grow.

~~~
ocdtrekkie
Yeah, that's the thing: Google knew it should've paid, it looked into a
license, and then decided to claim it didn't need one and go without. It's
certainly not fair use, it was specifically to build a competing
product/commercial ecosystem to Oracle's and they state it was fundamental to
their strategy to do so.

This case has been going on since 2010. It's time Google let it go. They lost.

~~~
mjw1007
What Google looked into licensing was considerably broader than the APIs, and
included material that everyone agrees is copyrightable.

We don't learn anything from the fact that Google negotiated for a broad
licence, decided not to take one, and used a clone which copies only the API
definitions.

If API definitions aren't copyrightable then Google didn't do anything wrong.
If they are then it did.

The idea that API definitions may not be copyrightable certainly isn't a wild
theory that Google made up for this instance.

