
Oracle wins appeal re Java API copyrightability [pdf] - dctoedt
http://www.cafc.uscourts.gov/images/stories/opinions-orders/13-1021.Opinion.5-7-2014.1.PDF
======
grellas
Disappointing as this result is for those who want IP law to adapt more
cleanly to developer realities, and much as I loved Judge Alsup's decision in
the lower court
([https://news.ycombinator.com/item?id=4051761](https://news.ycombinator.com/item?id=4051761)),
this is certainly not some badly reasoned decision by this particular 3-judge
panel of the Ninth Circuit.

What the panel essentially did was continue to apply Ninth Circuit law as it
has existed since the 1989 _Johnson Controls_ case holding that the sequence,
structure, and organization (so-called "SSO") of a computer program may be
entitled to copyright protection depending on the facts of a case. Judge Alsup
had not disregarded this precedent but had found what in my view were superb
ways of treating APIs in particular in a special way that rendered the copying
of their SSO non-infringing - to wit, acknowledging that developing an API was
even highly creative, a structure of this type, functioning as a method for
compatibility only, should not in itself be protected by copyright but should
be protected, if at all, only if it rose to the level of warranting patent
protection. How he got there was somewhat complex given that this is a complex
area of law. But that is where he had landed. The result, as a matter of
policy, was very clean for developers: it gave the courts a workable roadmap
for moving the copyright analysis into conformity with the modern digital age
on the critical area of APIs and inter-operability without the need of having
Congress address the issues.

This panel did the exact opposite. It held that, when it comes to the subject
matter of copyright, if a form of expression meets the threshold of being
"original," that is enough to make it copyrightable no matter what its
function. If the developer of an API had to make creative choices in deciding
how to set up the SSO of the API (and almost certainly he will), then the API
is protectible and any attempt to copy the same SSO is infringing on its face,
subject only to fair use and similar defenses. In so holding, this panel
vigorously reasserted the _Johnson Controls_ precedent that has hung over SSO
analysis in the Ninth Circuit for many years - meaning, in the case of APIs,
it is for a jury to determine case-by-case whether any particular SSO is
protectible by copyright. The panel here by no means disregarded the concerns
and issues raised by Google (and highlighted in Judge Alsup's decision) but it
relegated them to being a potential defense under fair use analysis for acts
that are otherwise presumptively infringing. The result: stronger IP
protection for APIs and a wealth of uncertainty created for developers in
trying to work with inter-operability issues in our modern age.

This case sparked intense interest and drew upon many top lawyers on both
sides to argue the issues. It is by no means some hack result. Indeed, it
could be argued to be far more in line with Ninth Circuit precedents than
Judge Alsup's decision. It can be appealed further, possibly to the full Ninth
Circuit complement of judges and possibly to the Supreme Court, and who knows
whether it will be upheld or not.

But the really sad thing is the missed opportunity. This was a chance to bring
clarity and order to an otherwise muddled area of law and this panel, rightly
or not, chose to go back to the muddle. Should it ultimately be upheld, the
only real solution in light of this is for Congress to amend the Copyright Act
to do a carve-out for APIs to enable them to get special handling under the
law to facilitate inter-operability.

~~~
scriptproof
The federal circuit ruled that an API is a "creative" work and thus is
copyrightable. But is it really creative? It is an interface and made
according some rules, not some sort of art... I must point out I have read the
28 pages ruling.

~~~
delackner
Im no lawyer, but an API is the most creative part of an entire developer
ecosystem to my mind. not the implementation. What made Cocoa so joyful to
work with while years of previous Java and MS coding were dissonant painful
experiences? All of them manage to get a button on the screen, respond to user
input, etc. The naming and organization of different features in a clear and
developer friendly way is entirely the API spec.

Whether you should be able to protect such a creation from copying is an issue
for society to choose. So far it has chosen poorly.

------
bcantrill
Ironically (and not surprisingly), Oracle themselves do not abide by this, and
freely copy the APIs under copyright of others where and when it suits them.

One recent, concrete and particularly brazen example is the llquantize()
DTrace aggregating action, which was added to illumos[1] after Oracle forked
OpenSolaris by closing it.[2] Oracle has copied this API verbatim in Oracle
Solaris 11.2[3], despite not holding copyright to it. One presumes that they
didn't copy the implementation (it's open source, but with a weak copyleft
that would prevent its inclusion in closed source software like Oracle
Solaris), but by Oracle's principles in the Google case, they would have
violated copyright. While I would love to pursue this on a purely personal
level, the reality is that the principle itself is wrong: Oracle actually
should be able to implement the llquantize() API, just as Dalvik should be
able to implement the Java APIs. But it would make my day if llquantize()
could somehow be used by Google's lawyers to show that Oracle themselves do
not abide by the perverted and depraved principle that they espouse...

[1]
[http://dtrace.org/blogs/bmc/2011/02/08/llquantize/](http://dtrace.org/blogs/bmc/2011/02/08/llquantize/)

[2]
[https://www.youtube.com/watch?v=-zRN7XLCRhc](https://www.youtube.com/watch?v=-zRN7XLCRhc)

[3] [http://www.oracle.com/technetwork/server-
storage/solaris11/d...](http://www.oracle.com/technetwork/server-
storage/solaris11/documentation/solaris11-2-whatsnew-2191087.pdf)

~~~
fpgeek
As I've noted below, Oracle's API copying goes all the way back to their
beginning. After all, Oracle doesn't own any of the original SQL copyrights
(and somehow I doubt they've ever licensed them from IBM).

~~~
pron
Except that the ruling differentiates between languages (which are not
copyrightable) and APIs, which are. Google claimed that all of the Java APIs
are part of the language, while the court ruled that only 3 (out of
fortysomething are).

~~~
windsurfer
May I ask why languages are different from APIs, since both are programming
interfaces?

~~~
tomsthumb
It mostly has to do with the way you squint and look at it. You're a smart
guy, give it a few goes and it'll make sense.

~~~
AnimalMuppet
To whoever downmodded the parent: I'm pretty sure it was sarcasm. That is, I'm
pretty sure when he says "it has to do with the way you squint and look at
it", he's saying that there really is not much difference.

~~~
jpadkins
sarcasm generally does not add signal to the conversation, so it is downvoted
here like humor and other noise.

~~~
tomsthumb
I felt that that particular piece of sarcasm added more to the conversation
than a simple statement of my agreement, which _is_ distinct from an upvote,
however, I was also unaware of this general policy/behavior of the forum as it
is mentioned in neither the FAQ nor the guidelines. Thanks for the heads up.

edit: just to be clear, this is _not_ sarcasm.

------
DannyBee
This is really bad for open source. A lot of people can now get sued for
making compatible API implementations, and their only argument will be whether
it is fair use (which is an affirmative defense).

IE Say FredCo has C++ and Java clients for their API. You decide to make and
publish a Ruby client. If you use the same Structure, Sequence, and
Organization of the API (IE you use the same API), congrats, the court thinks
you are infringing copyright.

This is the simple version. Think about compilers and ABI's and SQL extensions
and all sorts of things, and you can see this decision is truly terrible for
open source.

~~~
tosseraccount
I wouldn't say it's bad for open source. Java was always a proprietary
technology. Anybody who wasn't aware of this didn't do due diligence. It's bad
for java. Who wants to bet the company jewels on someting that Oracle
controls? It won't be happening in the future.

Apple's decision to stick with (objective) C is turning out to be a really
smart move. That it runs 2x faster than java is another bonus.

Bottom line: you can use java but don't get stuck so bad you can't refactor
out of it. And don't trust Oracle. Regardless.

~~~
cromwellian
Except that iOS is based on Unix, and the freedom to re-implement copyrighted
Unix APIs was litigated and won. What if SCO/Novell/USL/whoever owns the Unix
copyrights now, comes back and sues anyone reimplementing them? That includes
OSX and iOS which are dependent on Unix compatibility.

Also, what's being litigated here is not Java-the-language but Java-the-core-
API-interfaces.

You could refactor your way out of those, just provide alternate versions of
java.io, java.lang, etc, new redesigned core APIs.

It would break core Java compatibility, but Android is so big, most people
would port their Java libraries, and in the end, Oracle would be hurt more,
since they rely far more on server-side Java, but most of the world's Java
programmers would be migrating to writing mobile apps, probably with non-Java
backends, or Java + new Core APIs.

~~~
super_mario
Except UNIX

[http://en.wikipedia.org/wiki/Unix](http://en.wikipedia.org/wiki/Unix)

is owned by "The Open Group"

[http://en.wikipedia.org/wiki/The_Open_Group](http://en.wikipedia.org/wiki/The_Open_Group)

One of its purposes is to provide Single Unix Specification (SUS)
certification.

[http://en.wikipedia.org/wiki/Single_UNIX_Specification](http://en.wikipedia.org/wiki/Single_UNIX_Specification)

Mac OS X is SUS v3 certified (I don't think iOS is) and can call itself UNIX,
and there is 0 danger of anyone suing you for implementing POSIX API or SUS.
You just can not claim you are providing a UNIX without getting certified.
This is why Linux is UNIX-like OS and not a UNIX.

~~~
cromwellian
You're confusing Trademark with Copyright. The Open Group owns the Unix
trademark, it does not own the API. The fact that POSIX uses the API does not
mean any claims to "structure, sequence, organization" of the APIs or command
line utilities are invalid.

This has never been litigated before. Past UNIX copyright wars were fought
over copying actual code between Unix and clones. No one has ever tested
whether API reimplementation of Unix is copyrighted. Implementing as public
spec won't save you. Java has a public, open, specification and was clean-room
reimplemented in much the same way that Linux is not Unix, Android Java is not
Java.

Claiming there is 0 danger in being sued sounds like naively wishful thinking,
especially with Apple's deep pockets, there are plenty of lawyers out there
looking for ways to crack that nut.

~~~
maxlybbert
The Open Group own both the UNIX trademark and the POSIX spec. They used to
demand a lot of money for copies of the spec, but you can get it online for
free nowadays (
[https://www2.opengroup.org/ogsys/catalog/G101](https://www2.opengroup.org/ogsys/catalog/G101)
is a good place to start). They put copyright notices on the spec, but (at
least until this ruling) that was widely believed to only apply to the
description of what functions needed to do, and not to the function
declarations.

~~~
stormbrew
Is it clear that The Open Group or IEEE actually have a clear right to claim
copyright of the POSIX api given this ruling? Were they assigned or licensed
that copyright by AT&T or any of its successors? It seems likely enough that
in the 80s this was not seen as necessary, and the old guard of UNIX
implementers were still being quite belligerent towards each other at the
time, afaik.

~~~
maxlybbert
I believe the Open Group was assigned whatever copyright AT&T had when the
Open Group was created.

------
jahewson
Oracle haven't won yet, Google still have the opportunity to show that Android
is fair use:

 _we conclude that the declaring code and the structure, sequence, and
organization of the 37 Java API packages are entitled to copyright protection.
Because there is an insufficient record as to the relevant fair use factors,
we remand for further proceedings on Google’s fair use defense._

Some further detail found later on:

 _On balance, we find that due respect for the limit of our appellate function
requires that we remand the fair use question for a new trial. First, although
it is undisputed that Google’s use of the API packages is commercial, the
parties disagree on whether its use is “transformative.” Google argues that it
is, because it wrote its own implementing code, created its own virtual
machine, and incorporated the packages into a smartphone platform. For its
part, Oracle maintains that Google’s use is not transformative_

So it looks like there will be a new trial.

~~~
dragonwriter
> Oracle haven't won yet, Google still have the opportunity to show that
> Android is fair use

And the opportunity to appeal the CAFC decision on copyrightability to the
Supreme Court.

~~~
jahewson
I'd like to see that, a sensible copyrightability precedent would surely
reduce the number of future "is this specific API fair use?" cases which might
arise if Google wins on fair use only.

------
cromwellian
There's be no PC revolution if this ruling existed in the 80s.

[http://ckolderup.tumblr.com/post/48362660527/phoenix-
technol...](http://ckolderup.tumblr.com/post/48362660527/phoenix-technologies-
cloning-the-ibm-pc-bios)

The entrenched players benefited from an enormously more free era of software
development, we now live in an age where every line of code, every UI widget,
every pixel, is going to be patented and copyrighted.

If you develop any code and achieve any success at all, there will always be a
sword hanging over you.

The whole system is going to have to implode before it will be reformed. Last
year 92% of patent applications were approved. Every area of human thought is
being fenced off.

~~~
pron
No need to get hysterical. BIOS is not the same as a software API, and
copyright is not the same as patents. I think software patents are terrible,
but I definitely want software to be copyrighted. Regarding the
copyrightability of APIs, I don't think either ruling has much of an effect in
today's ecosystem.

~~~
georgemcbay
If not BIOS, consider the operating systems themselves.

If AT&T had strong copyright claims on the "APIs" that make up the system
calls of UNIX, for example there goes Linux (and essentially the entire GNU
and BSD projects as well), there goes modern MacOS, etc, and the
reverberations would be enormous even with fully closed sourced OSes like
Windows... With strong copyright on APIs there, essentially, goes the Internet
as we know it when there isn't a clear path of UNIX->BSD/POSIX->sockets for
everyone to copy (and thus be interoperable with each other).

And even if we shift the strong copyright event later into the 90s then
consider the modern web, if Netscape (which at one point was a very different
entity than today's Mozilla in terms of openness) had a strong copyright on
the definition of JavaScript's APIs? Or if nobody dared implement their own
XMLHttpRequest for fear of Microsoft's API copyright?

This is something developers (and anyone who cares about technology, really)
should _absolutely_ be hysterical about.

~~~
pron
Unless the reason those technologies spread is precisely because no one had
strong claims, or no one chose to pursue protection. If Netscape had chosen to
make JS proprietary, JS wouldn't have become a de-facto standard.

I am not aware of any significant proprietary API today that is in widespread
use, and is cloned by FOSS. But I could be wrong on that. If you know of such
APIs, I'd love to know which ones are in danger.

~~~
cromwellian
That's not really true, things can become de-facto standards even if they're
proprietary, especially if the actual status is in doubt. Many developers
don't think about the long term consequences of licenses when they start using
stuff, especially if it is useful and free of charge.

Linux is a perfect example of a proprietary API (Unix) which is in very
widespread use, which was cloned by FOSS. Most of the Unix command line
utilities were explicitly cloned by the FSF to be compatible with existing
shell scripts on Unix.

Adobe made Flash proprietary and it became incredibly widespread, so
widespread that if you turned if off, many websites would break, despite the
fact that it had numerous performance and security issues. Flash made it to
something like 97% penetration of all Web clients (prior to Apple iPhone)
People have cloned Flash (hAXE for example), but there was really no reason to
do it, because Adobe offered the player free of charge.

WINE is in widespread use. Samba is in widespread use. Lots of Website REST
APIs have been cloned.

Adobe PDF was proprietary and widespread cloned until in 2008 it became an
open standard.

Cloning APIs is a time honored tradition for "embrace and extend". Microsoft
even cloned proprietary APIs, and DOS itself started out as an unauthorized
clone of CP/M. Where would Bill Gates be today without Seattle Softworks?

I hate having to resort to the tired ole idea of rich people having gotten
rich by theft, but in many cases, it's quite true, that Gates and Jobs both
freely copied, cloned, and modified other people's stuff, got stupendously
wealthy off of it, but somehow, it's wrong for us to want to practice their
methods?

~~~
pron
What happened in the past is irrelevant, because after this ruling, it
probably won't happen again. The freedom to clone proprietary APIs is not
essential to FOSS any more, because the FOSS ecosystem has become powerful on
its own. Either proprietary vendors choose to license their APIs to FOSS, or
risk being replaced by an incompatible FOSS implementation.

My question was about how the current ecosystem will be disrupted. Now, with
WINE -- I agree, but I don't think it's in widespread use, and I don't think
Microsoft will go after them. AFAIK, Samba implements a networking protocol,
not an API (but I may be mistaken).

It really all comes down to Linux. If Linux is in danger, then obviously the
ecosystem can be disrupted by this ruling; if not -- then probably not. I must
say I don't know enough about the current legal status of Linux, and whether
or not it's in real danger.

~~~
cromwellian
>What happened in the past is irrelevant

In other words, "I got mine". People who profited and got stupendously rich,
get off scott free, and are free to deploy lawyers to interfere with the next
wave of participants. Not unlike immigrants who settle in, and then want to
slam the door on the next group of immigrants.

>Samba implements a networking protocol, not an API

Protocols and APIs are another distinction without a different. If the
sequence, structure, and organization of an API can be copyrighted, then
surely, the sequence, structure, and organization of a wire protocol or file
format can, after all, the only real different is the invocation mechanism.

~~~
rayiner
> If the sequence, structure, and organization of an API can be copyrighted,
> then surely, the sequence, structure, and organization of a wire protocol or
> file format can, after all, the only real different is the invocation
> mechanism.

While it might be easy to analogize between an API and a wire protocol in
terms of technology, that doesn't mean that analogy holds within the framework
of copyright law. The Fed. Cir. opinion was expressly couched in terms of the
"sequence, structure, and organization" of the names in the API. Indeed, the
opinion concedes that if Google had chosen different names, then things would
be fine. Putting the same bytes at the same offsets is not at all the same as
naming things the same way.

~~~
georgemcbay
Yeah but doesn't the distinction become way less clear when talking about
protocols that aren't traditional fixed-structure binary protocols?

We live in a world of protocols that are increasingly RPC/REST based which as
others have mentioned are really just APIs you happen to access over a network
connection.

~~~
rayiner
Good point.

------
ChuckMcM
Sigh. Allowing Copyright for API declarations is a poor choice, and analogous
in my mind of allowing patent protection on a thread radius and spacing. That
APIs and the constants they use are declared in words is an artifact of how
computer languages evolved and not the 'art' part of the work. We might just
as well copyright any story that involves a young man falling in love with a
young woman where the parents disagree that they should be together. Such
structural elements which are required for constructing a story are similar to
the structure of an API which is required for creating an interoperable
program.

Ideally this goes to the Supreme court and gets knocked flat. Doubly ideally
someone amends to the Copyright act to specifically disallow this sort of
argument for Copyright.

------
dctoedt
The appeals court looked to a decades-old "abstraction, filtration,
comparison" test. In essence, that test requires the judge and jury to play
the role of a patent examiner. See slip opinion at pages 23, 40. The expense
and uncertainty aren't much fun for either party (or for the judge, jury, and
law clerks for that matter). But yippee, say the IP litigators, because cases
like this require lots of billable hours.

EDIT in response to @crashandburn4: Oracle still hasn't won the case, because
the appeals court ordered a retrial of Google's fair-use defense, as to which
the jury deadlocked in the first trial. See the slip opinion at pages 60-62
(and preceding pages if you want the legal background).

------
npinguy
The only winners of the current software patent system are lawyers.

I sincerely hope we look back at this dark time and laugh at it like we do
with powdered wigs. Unfortunately I just don't see any change on the horizon,
so it's just as likely things will only get worse and worse, and innovation
will be stifled even more.

~~~
pron
This is about copyright, not patents. Even the biggest opponents of software
patents support copyright. If there's no copyright, anyone can take your
software and just make it their own.

~~~
rayiner
Not really. The modern generation of web developers don't sell software, they
sell eyeballs. So they don't really care about copyright. But trademark,
that's important! No advertising dollars without trademark! /cynic

------
zmmmmm
I see a lot of people downplaying the impact of this, saying that it just
means the defense falls back to "fair use" \- but isn't that the point? Every
single open source project that implements any kind of API now has an
individual legal threat that their work might not be "fair use" which can only
be decided on a case by case basis. It seems to me like the worst case is that
any large corporation, whether it be Microsoft, Google, Oracle or Apple can
exterminate just about any open source project with a simple cease and desist
letter that they are unable to afford to challenge. Without a crystal clear
ruling that APIs are not copyrightable a great portion of open source and non-
open source that is now out there seems to be essentially in an untenable
position.

I really wish Google had invested in the "nuclear" option and pursued a
parallel development strategy to move Android entirely away from dependency on
Java. If they had started 3 years ago and offered an alternative API (say, for
example, based on Go, but it could be anything relatively efficient, even a
brand new language), by now there would be a significant base of users and
Google would be able to threaten Oracle with a wholesale migration away from
Java. Even in their most delusional moments Oracle must know that losing
Android would be a huge loss in terms of the mindshare and userbase. I think
it's unlikely we'd be seeing Oracle pursuing this to the death if Google
hadn't left themselves in such a weak position. (I have a secret hope that
they _have_ been doing this and will astonish us all by taking the wraps off
it at Google I/O one day ...)

------
mey
I wonder how this will impact MariaDB's future development. In theory the
original APIs were forked under an open license, but new MySQL features
probably can't be legally replicated with application compatibility because of
the API.

Also, how does this impact things like Wine, as the MS API set has never been
open source (to my knowledge)

Actually in a wider perspective, I wonder how this will impact emulators in
general.

------
haberman
If you can copyright an API, I can't see anything that would prevent you from
copyrighting a protocol. This is a terrible decision for interoperability, and
for competition. It favors entrenched players at the expense of everyone else
(including users).

------
fidotron
It's quite ironic that Oracle, of all companies, would be making this
argument, when they got their start attempting to clone IBM's system and API.

~~~
briantakita
It's a common pattern. Disney got it's start by making derivative works. Now
Disney is the champion of draconian & perpetual copyright laws.

Give someone dominion and that person takes on the role of the overlord.

------
ChrisClark
Doesn't Oracle have many systems that depend on API compatibility with
competitors?

Are they shooting themselves in the foot? I sure hope so.

~~~
fpgeek
Oracle isn't shooting themselves in the foot (now). Today they have the money
required to pay lawyers to put on a vigorous fair use defense of any potential
API copyright infringements.

Of course, back in the late 1970s when Oracle was just starting out by
building a database based on a query language developed at IBM it would have
been another matter entirely...

------
josephlord
I think that this is absolutely right in principle. An API is tricky to get
right and good one is definitely creative (it is a work of design) and there
are many copyright able things that are less worthy.

The fair use/enforceability side of things is where the interesting questions
lie and that is the place for a messy compromise to allow some forms of
interoperability. I would be most in favour for attempts at drop in
compatibility and actually find Google's incompatible embrace and extend
commercial manoeuvre quite unsympathetic.

~~~
AnimalMuppet
Yes, an API is tricky to get right, and a lot of work, and can have creativity
in it.

But not everything that meets those criteria are, legally, things that can be
copyrighted. Until Oracle, nobody assumed that an API (as opposed to the text
describing it) could be copyrighted, since it is legally settled that a single
function declaration (that is, not implementation) cannot be copyrighted, and
an API is just a collection of function declarations.

------
sehugg
Probably too early to discuss, but what's the status of the VM + bytecode
spec? The preface of the SE 5.0 VM spec [1] says:

 _We intend that this specification should sufficiently document the Java
virtual machine to make possible compatible clean-room implementations._

IANAL, but isn't the "clean-room" giving permission or at least encouraging
others to reimplement the VM without Sun/Oracle's involvement? Or is this a
non-legally-binding statement and all bets are off with respect to the VM
specification? (Or something else?)

[1]
[http://docs.oracle.com/javase/specs/jvms/se5.0/html/Preface....](http://docs.oracle.com/javase/specs/jvms/se5.0/html/Preface.doc.html)

~~~
SAI_Peregrinus
IANAL, but I'd take that as a non-legally binding statement, as it merely
specifies that the documentation should be specific enough to make a clean-
room implementation possible, not that such implementations are allowed.

------
shmerl
Why did they decide that APIs are copyrightable? It's a complete lunacy. Can
Google appeal it again? Would it be Supreme Court in such case?

~~~
dragonwriter
> Can Google appeal it again?

Yes.

> Would it be Supreme Court in such case?

Probably. In theory, I think they could first ask for _en banc_ review by the
Federal Circuit.

------
seacious
It seems pretty likely that this will go to the SCOTUS. The court has been
taking a lot of IP related cases recently and this one is pretty huge.

------
sixbrx
If Oracle wins, is Linux the next target, as an api-compatible re-
implementation of Unix?

~~~
pmarin
Unix != POSIX

~~~
sixbrx
Sure it's not, but the existence of a spec to guide (arguably) _licensees_ of
Unix to have greater compatibility with each other will not necessarily
protect non-licensees. (That the spec doesn't address this case is neither
here nor there, if Oracle eventually wins this case.)

------
mmorearty
I wish Groklaw was still around to give a good analysis of this :(

~~~
cromwellian
Don't work, we still have Shillian Mueller to spike the ball, I mean, analyze
it.

------
curtis17
My only use of Java is for Android.

The Android VM - Dalvik - uses Dalvik not JVM byte code. Now ART - the new
Android runtime replacing Dalvik - is native - no more byte code.

There's not much Java left apart from the (poor) syntax. Why doesn't Google
bless one of the alt-Java's, like Kotlin, and cut out Java entirely.

~~~
bsdetector
Sun used to make a good portion of their revenue from Java licensees. Then
Google copied Sun's JVM, language, and APIs with a few very minor tweaks in
Android. Sun's Java revenue dried up because its licensees didn't renew
because they could just use Android.

Dalvik and JVM bytecode map 1:1 with one or two exceptions for initializing
arrays with data instead of a sequence of instructions. Even if you want to
pretend that Dalvik isn't a JVM then you must accept that it is a derivative
work, as even the names of the bytecode instructions are the same.

Google killed Sun and if they end up paying for it by APIs being copyrightable
that may be a disaster for the tech industry, but it's karma for Google.

~~~
tensor
Java is used in a great many places other than Android. Google most certainly
did not kill Sun.

~~~
bsdetector
An analyst came up with a $250 million annually for Java licenses. Andy Rubin
said (exhibit 13) that "Sun is prepared to walk away from a $100M annual J2ME
licensing business" into a deal with Google for some portion of Android
income, which obviously is not an exact but indicates the scale.

Java wasn't going to power a Sun-sized company by itself, but having this
income dry up while already trying to save the company from linux is a death
blow.

------
drawkbox
We've just harmed innovation in the US even more. Oracle, the same place you
made it you are destroying the future of, just stop. Ellison has forgotten his
engineering roots entirely. Java is also going to be limited due to this, one
of their own products now.

------
crashandburn4
Does anyone have any idea what the practical significance of this for android
and google is? IANL and find these documents hard to parse.

~~~
fpgeek
Other than a pile of legal fees, it's not clear that there will be any direct
impact on Android and Google. Even if you assume Google loses all their
appeals (a big if - the Federal Circuit and the Supreme Court often don't see
eye-to-eye on IP law), Google didn't lose on fair use - the jury deadlocked.

So the issue of fair use would need to be re-tried, and there's a good chance
they'd win - the deadlocked jury was 9-3 in favor of Google. That may even be
overstating Oracle's support. According to some reports, only one juror was a
holdout for Oracle on the fair use question [1].

The problem isn't Google's, it's everyone else's. If this decision holds up on
appeal, the legality of a compatible re-implementation of an existing API will
often be a question of fair use that needs to go to a jury. Practically
speaking, that means API re-implementation (a previously standard, commonly-
used part of the interoperability toolbox) is dead for anyone who doesn't have
the millions required to try this sort of case. I can't even begin to
comprehend how that will change software development.

[1] [http://www.reuters.com/article/2012/05/24/net-us-oracle-
goog...](http://www.reuters.com/article/2012/05/24/net-us-oracle-google-
idUSBRE84M18K20120524)

~~~
rayiner
Obviously, non-copyrightability is the best possible outcome, because then
such cases wouldn't even be worth bringing. But the opposite holding doesn't
necessarily mean every such case has to go to a jury trial. If the facts are
such that no possible jury could find in favor of one party, a fair use
question may be disposed of on summary judgment:
[https://www.eff.org/document/opinion-granting-summary-
judgme...](https://www.eff.org/document/opinion-granting-summary-judgment-
fair-use).

Getting a case to summary judgment isn't cheap, but the fair-use factors
aren't super fact intensive: [http://fairuse.stanford.edu/overview/fair-
use/four-factors](http://fairuse.stanford.edu/overview/fair-use/four-factors).
They center around the nature of the work itself, which can be described in
pleadings, rather than specific facts about the creative process that might
require extensive discovery.

------
runn1ng
Hm. I'm gonna check what Groklaw says to this....

....wait. Oh.

------
afarrell
Why is American government the best government? Because of our endless appeals
system.

~~~
adanto6840
Although not overly on topic, for those that don't know, this is a quote from
the movie "Thank You for Smoking" \-- I normally wouldn't upvote a comment
like this, and maybe shouldn't, but it really is a fantastic movie for those
that may not have seen or heard of it before!

[http://www.imdb.com/title/tt0427944/](http://www.imdb.com/title/tt0427944/)

------
namelezz
When can Go be used for android development?

~~~
AnimalMuppet
My guess: five minutes after the Supreme Court rules that Oracle is correct.

If Google doesn't have something like that started, they should. If they
didn't start it immediately after this ruling, they are far dumber than I
think they are.

------
spacemanmatt
This can cut both ways. Certainly parts of the Java API are essentially copied
(SSO) from APIs they did not license. Google should be able to argue their
rights are terminated under fruit-of-a-poisoned-tree doctrine.

But realistically, I can't see much except federal corruption in the decision
to hold the copyrightable SSO higher than the functional requirements. In this
digital age, that is a boot-licking verdict.

Alsup got it right.

------
xkarga00
_[...]The accused product is Android, a software platform that was designed
for mobile devices and competes with Java in that market.[...]_

How does Android compete with Java? Wasn't it supposed to be a good thing for
the whole language to have Android out there especially in times when many
other languages emerged that have been touted as "the new Java" or "the next
C++"?

------
fragmede
Let's rewrite the story some for a bit of perspective.

Instead of Google, let's use Microsoft, and say we're in the 90's and it's
Sun's Java, not Oracle.

Oh wait. That happened, and Sun and Microsoft settled out of court to the tune
of some $2 Billion.

~~~
frowaway001
Microsoft paid because they called it "Java", in blatant breach of their
contract with Sun. I don't like Google, but they never did anything remotely
like that.

~~~
tdurden
[https://developer.android.com/guide/index.html](https://developer.android.com/guide/index.html)

"Android provides a rich application framework that allows you to build
innovative apps and games for mobile devices in a Java language environment."

~~~
Oletros
> Java language environemnt

Java the language is not Java the platform

------
exabrial
I herby copyright:

    
    
        Object *(Object...);
    
    

I'll take a check Oracle. Thanks.

------
phkahler
If the API headers are copyrighted, wouldn't any program that uses them be a
derivative work? In that light, every Java program is infringing. Every
program on earth would be infringing something wouldn't it?

~~~
Pxtl
To be fair, the free software foundation takes the opinion that using a
library _is_ a derivative work of that library, which is why they provide both
the GPL and the LGPL. If using a library was not a derivative work of that
library, then there would be no need for an LGPL.

~~~
belorn
LGPL has nothing to do with API, but rather the definition of a derivative
work.

Using a library i akin to put a engine into a car. One could argue that the
engine would still be a separate piece and thus not "part of the car", but its
a tough sell to do in court. The line that separate "a thing" with "other
things" is determined by judges, juries (and in some cases, common sense). In
23 years, no one has dared yet to do so.

Using an API however is like putting your own engine into the car, but it
happens to use the same input/output of similar car engines. The GPL do not
have a dog in that fight, but FSF argues against such stretching of copyright.

------
DonGateley
As much as I dislike the impact this could have I must say that designing a
clean, orthogonal, complete API can take longer than actually implementing it.
A properly thought out API will dictate the implementation and strongly
optimize it. I've done API's and then the code to implement them and there is
no way I can see API creation as other than a highly creative endeavor.

The designer in me says, yes this is the right decision, but my pragmatist is
worried.

Processor instruction sets are no less API's than are the means of accessing a
software product. Can they be copyrighted?

------
Oletros
I ask a question, Sun changed the Java license to GPL, doesn't that means that
Google can now use it to reimplement Android API's?

~~~
jboy55
You can comply with the GPL or you can comply with the original license.
Neither of which allows you to BSD license the code, if in your use of the
code you violate copyright. GPL is very specific in that every copy of GPL'd
code must be in turn GPL'd. Re-Releasing code of BSD breaks that chain, and
thus isn't allowed.

If you don't like what licenses are available to you, then you negotiate a new
one or you don't use it. Every vendor knows that when they modify Linux and
embed it, their changes to Linux must be available. No vendor has done more
than pay lip service to challenging this aspect of the GPL, the reason being,
is the strength of copyright.

------
briantakita
The commercial legal system favors the entrenched players who have money to
prosecute and defend against prosecution.

The whole game is rigged to consolidate power & dominion. The only way to get
away from the game is to stop playing.

Software free of, or successfully loopholed from, this system are viable
alternatives that deserve more mindshare.

------
jijji
If this isn't the death nail in the coffin for Oracle Java, I don't know what
is. Why would anyone continue to use Java when they can potentially be sued
into oblivion by Oracle for trying to use their products? Run for the exits
while you can.

------
saurik
So, I have been going through the opinion (though I haven't finished reading
every single word of it, I do intend to do this, and I hope that many other
people do as well; certainly, I wanted to skim enough of it to have an
informed opinion, rather than operating only off of things I've heard in
popular news articles). I care a lot about this case (doing interoperable
development), and there is some nuance to what is going on that I don't think
many of the people commenting on this matter in the general developer public
appreciate.

To fail to summarize ;P, this nuance stems from separating the question of
whether Oracle's APIs are copyrightable from whether Google can claim "fair
use" in copying them for their purposes. Much like with trademarks (where
people get really uptight that someone "trademarked a word", ignoring context
restrictions), I think people lose these nuances while talking about
situations like this, and presume that if something is protected in some way
then it is an ironclad protection that applies even in ludicrous
circumstances.

Keeping this difference in mind, if the court said "APIs are copyrightable,
but what Google did was a clear example of fair use: creating interoperable
implementations is allowed", some people might still be angry, but I think
many fewer people would be bothered: it changes what the opinion means. And,
in fact, this is closer to what this opinion is saying than many people seem
to be reading from it: they talk a lot about whether what Google is doing
might be fair use, but they essentially punt that call back to the lower
court.

> Because the jury deadlocked on fair use, we remand for further consideration
> of Google’s fair use defense in light of this decision.

We then have to ask "what happened" with this fair use argument, as we would
_hope_ that in the situation that APIs are copyrightable that interoperating
with those APIs would be considered fair use: "something went wrong here". I
think we can actually see some disappointing mistakes in Google's argument
from reading this opinion: even though it wasn't trying to decide this matter
directly, it talks a lot about fair use and models of interoperability. It
frankly seems like Google just did a really really bad job of arguing the case
:(.

If we go back to the beginning of this, most of Sun's core arguments about
Java surround the idea that code written against Java should run on anything
claiming to support Java. Microsoft was really excited about Java, but because
they wanted to add a few extra features--some classes that would exist for UI
purposes on their implementation of Java but on no other--the Internet has
ever since considered them horribly evil people and were happy when Sun won in
court against them (which is why Microsoft decided to build C#, btw).

Google seriously did not want to build something interoperable with Java under
this definition: they have their own class libraries for handling large
regions of the platform, including basic things absolutely any application
would be using a lot of, such as UI and RPC. Given this, Google trying to
claim "we want to be interoperable with Java" is horribly confusing. You find
the opinion trying to understand Google's position on interoperability and
failing: it almost makes Google look like they are lying about
"interoperability".

> Indeed, given the record evidence that Google designed Android so that it
> would _not_ be compatible with the Java platform, or the JVM specifically,
> we find Google's interoperability argument confusing. While Google
> repeatedly cites to the district court's finding that Google had to copy the
> packages so that an app written in Java could run on Android, it cites to no
> evidence in the record that any such app exists and points to no Java apps
> that either pre-dated or post-dated Android that could run on the Android
> platform.

> During oral argument, Google's counsel stated that "a program written in the
> Java language can run on Android if it's only using packages within the 37.
> So if I'm a developer and I have written a program, I've written it in Java,
> I can stick an Android header on it and it will run in Android because it is
> using the identical names of the classes, methods, and packages." Counsel
> did not identify any programs that use only the 37 API packages at issue,
> however, and did not attest that any such program would be useful. Nor did
> Google cite to any record evidence to support this claim.

Now, I have certainly seen many Java libraries that manage to only use this
subset of features; and to me, being able to use those libraries is an
interesting aspect of "interoperability". Sadly, however, Google's lawyers
seem to have not bothered making that argument: they were probably doing the
important thing where they simplify the kinds of words and ideas they are
using for the jury to quickly understand, but the difference between
applications and libraries needs to not be understated and left to implicit
context :(.

The result is that rather than seeing what Google was doing as building an
interoperable implementation of an API, the panel sees Google as instead
building their own _non_ -interoperable platform that _happens to share
striking similarities to Oracle 's Java_. They feel like Google is just
copying a bunch of effort and work and even creative expression that Sun had
put into Java in the construction of Google's competing way of developing
applications for the seemingly-purposely unrelated platform that they are
using on Android.

> The compatibility Google sought to foster was not with Oracle's Java
> platform or with the JVM central to that platform. Instead, Google wanted to
> capitalize on the fact that software developers were already trained and
> experienced in using the Java API packages at issue. The district court
> agreed, finding that, as to the 37 Java API packages, "Google believed Java
> application programmers would want to find the same 37 sets of
> functionalities in the new Android system callable by the same names as used
> in Java."

Let's say that Microsoft's C# happened to have a programming library that had
large regions of API that were "directly copied" from the standard library of
Java, even if there were no way to even attempt to run a Java class/jar on the
.NET Virtual Machine. While many people would still say "that clearly should
be allowed", I think that changes the character of the discussion quite a bit:
I think many of the same people angry at Samsung about copying things off
Apple would find themselves angry at Microsoft for copying things off Sun.

Again, I want to stress that I am not saying this should sit well with
everyone: I can easily appreciate the arguments of people who feel that APIs
should simply fundamentally not be subject to copyright. (That said, I can
also appreciate the arguments of people who feel that software in general
should not be subject to copyright, and I appreciate the arguments of people
who believe that absolutely nothing should be subject to copyright as they
think the idea of copyright is flawed. These are all somewhat reasonable
positions to me.)

Instead, I point this stuff out as I think people are extrapolating too much
from this decision and are taking it to mean things that it doesn't: in
particular, it doesn't mean that you can't build systems that interoperate
with an API designed by another party. It is then unfortunate that people are
extrapolating this decision all the way up to hyperbole like "the PC
revolution wouldn't have happened under this ruling". It just doesn't help
when people make these kinds of grandiose statements: everything becomes
emotional :/.

Really, what we are looking at (and I think grellas is saying something
similar, though from a different direction) is an opinion that leaves an area
of law in a state where it is not entirely clear: that is a problem, as it
leads to individuals having to make horrible and oft-flawed decisions as to
whether specific actions they want to perform are or are not allowed. But this
uncertainty is not the same as saying "this is not allowed"; and even if
Google's usage was not allowed, maybe a intended-to-be-fully-interoperable
Java is.

~~~
cromwellian
A fully-interoperable Java on smartphones IMHO would be a market failure out
of the gate. The OpenJDK/JDK was designed for desktop environments, most of
the APIs left how have no applicability to mobile. To include them would
needlessly bloat an already slow Java platform on mobile. These devices are
extremely constrained by memory and battery.

So, you can either have Java on 800 million devices where the APIs are
subsetted and retargeted towards modern smartphones, or you can have a
hopelessly bloated, too-many-cooks-in-the-kitchen JDK on devices no one wants
to use, but they, they'd be capable of running Java apps from the 90s.

This is like saying, I won't let you subset the Win32 APIs unless you
guarantee that DOS 3.0 apps will still run.

~~~
saurik
Right: as I said, I think Google needs to make a point that compatibility with
libraries, even though "apps" are not compatible; apparently they didn't.

------
johnpmayer
Pretty simple solution - legislation that explicitly classifies as fair use
the copying of the SSO, the Structure, Sequence, and Organization, of an API
for the purposes of interoperability

~~~
AnimalMuppet
Your "simple" solution has a huge problem, which is named "Congress". Under
current circumstances, do you really think we can get an IP bill through
Congress that makes things better, rather than worse?

------
wil421
I havent grasped my head around the core issue Oracle is trying to sue them
for.

Are they saying you need a license to use the API? For example something like
java.util?

~~~
aidenn0
1) When you download a JDK you get a license to use the API.

2) They are saying that the java header files are copyrightable. It would be
challenging to create a compatible java implementation that didn't include
something awfully close to the java header files (and it appears that google
copied them verbatim). Depending on future rulings, it make make it hard or
impossible to create a java-compatible implementation without violating
Oracle's copyrights.

~~~
xienze
This isn't quite right. Google didn't copy the API classes verbatim -- they
made an implementation of the API. Big difference, and that's why the outcome
of this case is so huge.

There is nothing fundamentally copyright-able about an API. It's just a bunch
of methods and descriptions. The implementation is the secret sauce. By
finding for Oracle the courts have essentially said that you're not allowed to
reverse-engineer a library.

~~~
aidenn0
Google copied the _declarations_ verbatim. Doing so makes sense, if indeed
"There is nothing inherently copyrightable about an API" which is probably why
Google did this.

On the other hand, this ruling says that there is something inherently
copyrightable about the declarations.

~~~
rossjudson
Every JDK I'm aware of contains the following text in its license. It
specifically grants a license to the specification (API) for the purposes of
creating a clean room implementation. There is only ONE possible expression of
the specification, in Java.

"Sun hereby grants you a fully-paid, non-exclusive, non-transferable,
worldwide, limited license (without the right to sublicense), under Sun's
intellectual property rights that are essential to practice the Specification,
to internally practice the Specification for the purpose of designing and
developing your Java applets and applications intended to run on the Java
platform or creating a clean room implementation of the Specification that:
(i) includes a complete implementation of the current version of the
Specification, without subsetting or supersetting; (ii) implements all of the
interfaces and functionality of the Specification without subsetting or
supersetting; (iii) includes a complete implementation of any optional
components (as defined by the Specification) which you choose to implement,
without subsetting or supersetting; (iv) implements all of the interfaces and
functionality of such optional components, without subsetting or supersetting;
(v) does not add any additional packages, classes or interfaces to the "java.
_" or "javax._" packages or subpackages or other packages defined by the
Specification; (vi) satisfies all testing requirements available from Sun
relating to the most recently published version of the Specification six (6)
months prior to any release of the clean room implementation or upgrade
thereto; (vii) does not derive from any Sun source code or binary code
materials; and (viii) does not include any Sun source code or binary code
materials without an appropriate and separate license from Sun. The
Specification contains the proprietary information of Sun and may only be used
in accordance with the license terms set forth herein. This license will
terminate immediately without notice from Sun if you fail to comply with any
provision of this license. Upon termination or expiration of this license, you
must cease use of or destroy the Specification."

------
spacemanmatt
Normally I'd hope to see Google appeal it to the Supreme Court. But not this
Supreme Court.

------
Oletros
The irony is that was not Google the ones that copied Sun's Java, they used
Apache Harmony

------
ausjke
what does this mean to developers and users? what's the impact to android?

------
throwawaykf05
I will bring up my prediction again:
[https://news.ycombinator.com/item?id=7282162](https://news.ycombinator.com/item?id=7282162)

"My take is [APIs] would be found copyrightable, but Google may probably
prevail on fair use." [1]

Unlike most here, I think this is the right decision given the current
framework of copyright protection. This is because what copyright protects is
the _creative expression_ of a work. APIs, after all, are just another form of
code, and requires the same (if not more) amount of creativity to design
properly [2].

I see a lot of people here seemingly conflating this with patents (which
protect functionality) or patent-like scope of protection. Copyright does not
protect functionality, only the _exact_ expression thereof. There are an
unlimited number of ways to design an API for the same functionality. For
instance, the file system APIs for Posix, Java, C# and Python are all
completely distinct in their expression.

The arguments against API copyrightability, taken to their logical conclusion,
would remove copyright protection for _all_ code. I'd like to see cogent
arguments as to why copyright _as it currently exists_ should apply to all
other code but not API. ("Because we should be able to re-implement APIs" is
not a valid answer, as that is begging the question. Without justification,
you may well say that about any code.)

I suspect that any valid arguments would indicate that copyright is not an
appropriate means of protection for software. That would be unsurprising; code
was shoehorned into copyright because it was a close enough approximation and
didn't require formulating a whole new framework from the ground up [3]. Many
others [4, 5, 6, 7] have explored the weird interplay of copyright protection
and code, which at its heart, is functional (which copyright does not protect)
yet is also creative (which copyright does protect).

[1] Even if Google prevails on fair use, I still think that is unfair to Sun
(and by proxy, Oracle). People ignore the massive investment, not only in
engineering, but in _marketing_ that Sun undertook to make Java as prevalent
as it is today. I don't think it's fair to let another party hijack a hard-
earned ecosystem without permission from its creators.

[2] Some may argue the Java APIs are poorly designed. All I can say is, even
the Twilight series gets copyright protection.

[3] "The Uneasy Case for Software Copyright",
[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171451](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171451)

[4] "The Strange Odyssey of Software Interfaces and Intellectual Property
Law",
[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1323818](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1323818)

[5] "Sum Greater than its Parts?: Copyright Protection for Application Program
Interfaces",
[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1325104](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1325104)

[6] "Copyright Protection of Computer Program Structure",
[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1438164](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1438164)

[7] "IP's Problem Child: Shifting the Paradigms for Software Protection",
[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=901604](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=901604)

~~~
clavalle
> I'd like to see cogent arguments as to why copyright as it currently exists
> should apply to all other code but not API.

For the same reason a textbook publisher shouldn't be able to copyright the
table of contents of a calculus textbook:

1) It is merely a guidepost to the rest of the work and doesn't rise to the
level of creativity of the meat of the text.

2) over time the structure becomes standardized because of the nature of the
information it attempts to organize suggests that standard.

For example: imagine an API for accessing student information. You have
certain common characteristics for those students: Name, Address, Contacts,
Schedule, Grades, Absences etc. I'd be willing to bet that if you put 10
people in separate rooms and asked them to create an API, 80% or more would be
so close to one another that if someone studied one, they could find their way
in another. And if showed a person who had studied the different APIs some
specific part of a particular API they wouldn't be able to tell you which one
it came from. They would not differ enough in 'style' to be readily
distinguishable.

Now imagine Strings. Or authentication or routes or any number of other
aspects of computing that we have to deal with every day.

Now, can the same thing be said of ten different authors of say a writing
prompt that says "Write about a student who is having an altercation with a
gym coach"?

I'd argue that you'd get some very different and and easily distinguishable
stories and styles.

~~~
throwawaykf05
_> 1) It is merely a guidepost to the rest of the work and doesn't rise to the
level of creativity of the meat of the text._

As anyone who has designed enough APIs will tell you (including engineers
testifying on Google's behalf during the trial, and many commenters here who
disagree with the decision), an API often requires more creativity than the
implementation. Sure, the implementation is also difficult to do well, but
making that implementation _usable_ by others is no less a creative task. The
"table of contents" analogy is backwards: you don't write the code first and
then extract the functions into an API. That's how you get poor APIs. For a
well designed API it's always the other way around. With enough creativity and
forethought put into an API, the implementation flows naturally, and in
practice, it's exactly the opposite of the table of contents analogy.

(Not to mention that a ToC may also be copyrightable.)

 _> 2) over time the structure becomes standardized because of the nature of
the information it attempts to organize suggests that standard._

The "nature of information being organized" sounds like "functionality" to me.
As before, it is distinct from expression.

 _> I'd be willing to bet that if you put 10 people in separate rooms and
asked them to create an API, 80% or more would be so close to one another that
if someone studied one, they could find their way in another._

Consider the corollary of your argument. If you asked those same people to
write actual implementations for that same problem. I'd bet you get the same
"80% or more would be so close" results. Do you mean that their resulting code
would not be covered by copyright? Consider whatever arguments you apply to
defend copyrightability of the implementation, and try to differentiate them
from the API case.

Unless you provide a detailed spec and enforce some conventions, I'm willing
to bet nobody will have an exact duplicate of another, either for
implementation or for API. An API for the same functionality, say for getting
the number of absentees, may be labeled getAbsenteeCount() or nAbsentees() or
NumNotPresent(). Or even absenteeList().length(). Or a poorly defined API may
require something like classSize() - numPresent(). Or a really badly defined
API would require iterating over each member of the class and checking the
"present" flag. And that is the point: each expression of the same
functionality can be unique, and hence a candidate for copyright.

~~~
clavalle
>an API often requires more creativity than the implementation. Sure, the
implementation is also difficult to do well, but making that implementation
usable by others is no less a creative task.

"Difficult to do well" and "creativity" does not equal "copyrightable".
Mathematical proofs are hard to do well and require creativity but are not
copyrightable.

If the form is necessary for practical application, it belongs to the public.

>The "table of contents" analogy is backwards: you don't write the code first
and then extract the functions into an API. That's how you get poor APIs.

You generally don't start writing prose before you have the overall structure
fleshed out, either.

>Do you mean that their resulting code would not be covered by copyright?
Consider whatever arguments you apply to defend copyrightability of the
implementation, and try to differentiate them from the API case.

Perhaps you are right. Copyright may be the wrong tool for code. Patents may
be the wrong tool for code. It may be time to set aside these grossly
imperfect abstractions that were built for wildly different purposes hundreds
of years before programming was conceived and think through something that
fits this type of intellectual property better.

~~~
throwawaykf05
_> "Difficult to do well" and "creativity" does not equal "copyrightable". _

But how you express it _is_ covered by copyright. A mathematical proof is not,
but if you write it out so that it rhymes, that specific expression _is_. You
can now state the same proof a thousand different ways, even those that rhyme
differently. But all those original those of the same proof remain protected.

I would tend to agree that copyright and patents are probably not a good fit
for protecting software, and maybe a new framework is needed. But given the
current means at hand, this decision is internally consistent.

------
suyash
Congratulations to Oracle, it's about time justice needs to be served.

~~~
thebeardisred
"There's no justice. There's just us."

