
Oracle v. Google - Judge Alsup Rules APIs Not Protected By Copyright - mbreese
http://www.groklaw.net/article.php?story=20120531172522459
======
grellas
A few thoughts:

1\. This is a meticulously researched, marvelously analyzed, and brilliantly
synthesized order done by a judge who has a keen grasp of not just the facts
of the case but of those that really matter. As the opinion notes, this was a
case of "first impression" - meaning that no published decision has ever dealt
specifically with the precise question raised of whether APIs in themselves
are protectable by copyright or not.

2\. The developer community needed a definitive ruling that was almost
impossible to arrive at in light of the controlling precedents of the Ninth
Circuit (which are binding on the judge). Why? Because (beginning with the
_Johnson Controls_ case in 1989) the precedents had held that the "structure,
sequence, and organization" (SSO) of any part of a software program _were_
potentially protectable by copyright and that the issues had to be determined
case-by-case to determine whether a particular component was or was not
protectable. Thus, the best a trial judge can do in such a case is to make a
fact-specific conclusion about the case immediately being tried, one which
would have limited impact in the next case, where the parties could argue the
same issue on different facts. Yet, while doing just that and limiting his
ruling to the particular facts before him, Judge Alsup has provided a
definitive and logically compelling _approach_ to how such issues are to be
decided where they concern APIs and copyright and such reasoning is, in my
view, destined to be widely applied throughout the court system going forward.
Lower court rulings _can_ have a powerful impact through the sheer force of
their reasoning. This is just such a ruling. It is rare to get this. It could
not have been better timed on a vital issue affecting interoperability in our
modern era.

3\. Fundamentally, Oracle had been arguing that the SSO of its 37 API packages
reflected creative expression of precisely the type that the Copyright Act was
intended to protect. And it is true that API design choices reflect all sorts
of creative forms of expression. To deal with this issue, the judge got down
to fundamentals, with the key language found at page 35 of the opinion: "Much
of Oracle’s evidence at trial went to show that the design of methods in an
API was a creative endeavor. Of course, that is true. Inventing a new method
to deliver a new output can be creative, even inventive, including the choices
of inputs needed and outputs returned. The same is true for classes. But such
inventions — at the concept and functionality level — are protectable only
under the Patent Act. The Patent and Trademark Office examines such inventions
for validity and if the patent is allowed, it lasts for twenty years. Based on
a single implementation, Oracle would bypass this entire patent scheme and
claim ownership over any and all ways to carry out methods for 95 years —
without any vetting by the Copyright Office of the type required for patents.
This order holds that, under the Copyright Act, _no matter how creative or
imaginative a Java method specification may be_ , the entire world is entitled
to use the same method specification (inputs, outputs, parameters) so long as
the line-by-line implementations are different" (my emphasis). Thus, even
though the judge was forced by Ninth Circuit precedents to assess the SSO
based on the particular facts before him only, he did so by finding, as a
matter of fact, that only a 3% layer of code dealt with the SSO of the API
packages, that this consisted entirely of names that had to be identical for
compatibility purposes and of tasks that could be performed in only one way in
order to work, and in this way - having established the factual setting as
consisting entirely of elements he concluded were unprotectable under
copyright - he could make a powerful and sweeping statement of law that will
undoubtedly have a huge impact on future cases.

4\. The judge finally had to deal with the claim that the SSO constituted a
sort of taxonomy that has been held protectable under copyright in other
circuit courts. Here, too, he addressed the issue based on fundamentals:
_assuming_ that the API design structure here constituted a taxonomy, he
nonetheless held that it was above all a command structure that was
unprotectable based on 17 U.S.C. section 102(b) (which categorically excludes
ideas, concepts, etc. from copyright protection). Thus (at page 39): "In our
circuit, the structure, sequence and organization of a computer program may
(or may not) qualify as a protectable element depending on the 'particular
facts of each case' and always subject to exclusion of unprotectable elements.
_Johnson Controls v. Phoenix Control Sys._ , 886 F.2d 1173, 1175 (9th Cir.
1989). Contrary to Oracle, Johnson Controls did not hold that all structure,
sequence and organization in all computer programs are within the protection
of a copyright." This is another way of saying that what might otherwise
constitute protecable expression (e.g., the creative design choices made in
developing the SSO of APIs) is nonetheless _not_ protectable if it
functionally operates within a computer program as a command structure. _This,
of course, is what APIs do_ and this means that his conclusion can be used as
a powerful guide in all future API copyright cases. As a trial court decision,
this ruling is not binding on other courts, yet it is compelling and
persuasive, which can amount to the same thing (including in its impact on the
Ninth Circuit when it considers this case on appeal).

5\. Oracle here is like the Black Knight in Monty Python: as each limb of this
case was lopped off, it dismissively would say "a mere flesh wound." Now that
its case has been reduced to a final stump, it can continue to declaim but who
will listen? Maybe a long shot on appeal but I wouldn't hold my breath. This
is an unbelievable outcome that illustrates that great good can come even from
lousy things that people do. The computing world owes a great vote of thanks
to Judge Alsup: the cause of interoperability has won a huge victory.

~~~
scott_s
Please seriously consider starting a blog. Even if you post just once every
two months, after major rulings, your analysis is always so illuminating. I
come into legal threads on HN specifically to read what I know will be your
top-rated comment.

~~~
gruseom
Couldn't agree more, except I like the fact that grellas posts his stuff
(which keeps getting better, by the way) as part of community discussions
here. It's like one of HN's superpowers. Even though both are completely
public, blogs feel more arm's length and isolated, where this is convivial.

~~~
scott_s
I know, and I love that such in-depth and approachable analysis is a part of
our community, but I feel compelled to tell him that it would benefit himself
so much.

------
krschultz
Reading the ruling is fantastic.

The judge basically puts a CS 101 chapter in to explain some of the basics of
Java. I laughed when he used the variable name 'Foo' as an example.

This was one argument that I haven't seen before:

"This brings us to the application programming interface. When Java was first
introduced in 1996, the API included eight packages of pre-written programs.
At least three of these packages were “core” packages, according to Sun,
fundamental to being able to use the Java language at all. These packages were
java.lang, java.io, and java.util. As a practical matter, anyone free to use
the language itself (as Oracle concedes all are), must also use the three core
packages in order to make any worthwhile use of the language. Contrary to
Oracle, there is no bright line between the language and the API."

~~~
gruseom
_there is no bright line between the language and the API_

This is actually a deep observation about the relationship between languages
and libraries: the line between them is fluid and to some extent just a
convention.

How astonishing that the judge of a lawsuit would show this level of technical
understanding. Let's hope he has succeeded in appeal-proofing the ruling.

~~~
Natsu
> How astonishing that the judge of a lawsuit would show this level of
> technical understanding.

It's been reported that he's done programming before. I had very high hopes
based on that and the extensive research he did in preparing for this ruling.
He asked for several rounds of briefings and spent a considerable amount of
time reaching this decision.

So in a sense it's not that astonishing: he worked really hard to arrive at
the correct answer. I'm just glad they got such a capable judge.

~~~
gruseom
_It's been reported that he's done programming before._

Of course; that's the astonishing part. This was more than a capable judge -
this was a capable judge with deep intuition for the domain. You don't get
that by cramming from scratch.

For once, we software people got a lucky break in the courts. If only this guy
could be set on a patent troll case.

------
mmastrac
"So long as the specific code used to implement a method is different, anyone
is free under the Copyright Act to write his or her own code to carry out
exactly the same function or specification of any methods used in the Java
API. It does not matter that the declaration or method header lines are
identical. Under the rules of Java, they must be identical to declare a method
specifying the same functionality — even when the implementation is different.
When there is only one way to express an idea or function, then everyone is
free to do so and no one can monopolize that expression. And, while the
Android method and class names could have been different from the names of
their counterparts in Java and still have worked, copyright protection never
extends to names or short phrases as a matter of law."

~~~
Cyranix
Yep, that's the juicy excerpt. Other bits that I found salient from the
ruling, on patent vs. copyright:

    
    
        Much of Oracle’s evidence at trial went to show that the 
        design of methods in an API was a creative endeavor. Of 
        course, that is true. Inventing a new method to deliver a
        new output can be creative, even inventive, including the
        choices of inputs needed and outputs returned. The same is
        true for classes. But such inventions — at the concept and
        functionality level — are protectable only under the 
        Patent Act.
    
        ...
    
        That a system or method of operation has thousands of 
        commands arranged in a creative taxonomy does not change 
        its character as a method of operation. Yes, it is 
        creative. Yes, it is original. Yes, it resembles a 
        taxonomy. But it is nevertheless a command structure, a 
        system or method of operation — a long hierarchy of over 
        six thousand commands to carry out pre-assigned functions. 
        For that reason, it cannot receive copyright protection — 
        patent protection perhaps — but not copyright protection.
    

The entirety of p. 38, on interoperability and fragmentation, is also a good
read.

~~~
newhouseb
Does this mean that companies will start to patent their APIs? I wonder if
this means we should expect virtually the same case s/copyright/patents/g a
few years in the future.

~~~
wmf
Patenting of APIs/protocols/file formats has been going on for a while. The
bar for patenting an API will be much higher[1] because it has to be a novel
concept.

[1] In theory. In reality, the USPTO will issue anything.

~~~
Tuna-Fish
USPTO will issue anything, but the patents rarely survive. In this litigation,
all the patents brought out by Oracle were struct down.

~~~
notatoad
whether patents survive litigation or not is irrelevant unless both parties
have equivalent resources to spend on litigation. large companies can use
their patents to bully small companies into paying licensing fees without
having any fear of needing to defend their patents.

~~~
chii
which seems to be a problem with the patent invalidation process - it
shouldn't cost anyone money to invalidate a patent. If a patent holder's
patent is found to be invalidated, the costs for the entire process should be
be beared by the patent holder!

~~~
nitrogen
That would only work if patent holders were required to post a bond or
something at time of filing for the costs of invalidating their own patents.
Otherwise, costs will be incurred by the victim in the process of invalidating
the bogus patent that will not be recovered until the invalidation is
finished. If they run out of money in the mean time, they die, and the patent
stands.

It would be very bad to require such a bond to be placed for new patents, as
that would be the final blow that kills the idea that patents protect the
"little guy."

------
fpp
This is definitively a relief for our whole industry.

Thanks to Judge Alsup for taking an impartial stand on the whole matter and
for the commitment to enable himself to an understanding of the matter and an
informed decision going as far as to even learn himself how to program in
Java.

I hope this does not remain one of the few cases when knowledge, ethics and
the law is applied in its true sense while billions are brought to the
battlefield.

Maybe all those that think that "rounded corners", sending email
messages/calendar entries from mobile devices or different shades of gray are
true inventions will one day soon rethink their monopoly strategies and start
again with what they were once great at - actually create and invent things
that people want to use.

~~~
jasomill
While I agree with the gist of what you're saying, the "rounded corners" claim
was that the specific corner shape was an ornamental _as opposed to_ useful
part of the iPad's design. Design patents and utility patents aren't even
close to the same thing.

~~~
ZeroGravitas
The key element of both (all) types of patents is that, rather than
"protecting" your property, they actually allow you to prevent others from
independently inventing or designing the same thing by giving you a legal
monopoly. In that regard using the law to prevent someone having rounded
corners on a handheld device isn't too different from preventing them having a
touchscreen device that you unlock by swiping.

~~~
jasomill
Sure. I'd even go on to say that the latter isn't much different, _in
principle_ , than granting Eli Lilly a monopoly on pills that, by a certain
chemical action, boost serotonin levels in the brain.

Which is _not_ to say that there might not be sensible reasons for society to
favor protection of one over the other. In the words[1] of Oliver Wendell
Holmes, "the life of the law has not been logic: it has been experience."

Fortunately for the industry, today's ruling was clearly written by a judge
well-versed in both.

[1]
[http://books.google.com/books?id=xXouAAAAIAAJ&pg=PA1](http://books.google.com/books?id=xXouAAAAIAAJ&pg=PA1)
(well worth reading in context)

------
modeless
Favorite part: "Oracle has made much of nine lines of code that crept into
both Android and Java. This circumstance is so innocuous and overblown by
Oracle that the actual facts, as found herein by the judge, will be set forth
below for the benefit of the court of appeals."

------
ajross
So, now that the recrimination phase of the trial has begun: where did Oracle
go wrong? I mean, at this point they've lost everything and it's abundantly
clear that Sun would have been better off just blessing whatever Google wanted
to do as "Java". At the very least, they'd have gotten some branding karma and
been able to sell an "Official Android Pro SDK" product or whatever.

But at what point was that clear? Who missed that call?

~~~
marshray
I think Oracle bought Sun, at least in part, thinking they could do a better
job monetizing Java than Sun had done.

That's where they went wrong.

~~~
sounds
I have to agree.

Oracle's only possible course in purchasing Sun was litigation. (And I think
most expected nothing less from Larry Ellison.)

Google seemed like a vulnerable target.

Alsup was a spanner in Ellison's plan. It could be argued that Google's legal
defense was another.

~~~
marshray
> Oracle's only possible course in purchasing Sun was litigation.

To be fair to Oracle (OMG I can't believe I just typed that) it's not clear to
me that they realized that at the time.

Oracle has a relatively large, locked-in, and well-monetized customer base.
They have tools and languages and interefaces too. I imagine that _most_ of
the time they don't end up litigating against their customers.

Sun had a good customer base and a lot of them were fairly deeply committed to
Sun hardware, Solaris, and yes, Java. Often they were running Oracle on Sun
hardware and developing database data entry apps in Java.

It's possible that they were thinking "There's a good synergy here with the
market footprint, opportunity for vertical integration, we both have some
server tools, developer tools used by committed/locked-in corporate users. Sun
isn't getting any revenue from Java because they're just too much "Mr. Nice
Guy". We can fix that, we know how to monetize an app platform in the
corporate market.

It may also be that I am hopelessly naive and they bought Sun solely as a
ticket to sue Google.

Edit: See example "Mr. Nice Guy" blog post at
<http://groklaw.net/article.php?story=20110723095928839> How would an Ellison
interpret that?

~~~
flomo
No, I think you're correct.

Oracle on Sun hardware was like peanut butter & jelly for a long time. It
would have been _very bad_ for Oracle's business if IBM had purchased Sun and
used the hardware as a wedge to sell middleware. So while I'm sure Oracle
wanted to monetize Java as much as possible, buying Sun was largely a
defensive move.

~~~
tytso
Actually, I wouldn't have been surprised if IBM (if it had purchased Sun) had
dumped Sun's hardware division. It was losing money hand over first, and IBM
was doing a pretty good beating Sun with its hardware offerings. Between IBM's
x86, Power, and Mainframe hardware product lines, it really wouldn't need
sparc. So the only question is how quickly IBM would have been able to
transition what was left of Sun's hardware business to IBM's x, p, or z series
machines.

As a result, that's probably why Oracle was willing to pay more than IBM. Both
IBM and Sun wanted to be able to make sure they could continue to use Java ---
and preserving the freedom of action against lawsuits was I'm sure high on
both company's minds. But Oracle could also find a good use for its hardware
division, where IBM probably would have tried to sell it off.

~~~
flomo
Well, platforms like Solaris/Sparc are never just dumped. No matter who ended
up with it would be milking it all the way down, making it that much more
expensive & obscure every year, until the users finally say uncle. Generally
that's when the customer wants a new CRM or something and gets two birds with
one stone.

That's why it would have been disastrous for Oracle if IBM got them. Everytime
a Sun customer ordered a new stick of RAM, the IBM software sales team would
have been circling around.

(Note: I'm sure there's some niches where Sun hardware is very strong, but
those are only going to get narrower over time.)

------
luminaobscura
"For example, Java-based code using the replicated parts of the 37 API
packages will run on Android but will not if a 38th package is needed. Such
imperfect interoperability leads to a “fragmentation” — a Balkanization — of
platforms, a circumstance which Sun and Oracle have tried to curb via their
licensing programs. In this litigation, Oracle has made much of this problem,
at times almost leaving the impression that if only Google had replicated all
166 Java API packages, Oracle would not have sued."

LOL

~~~
esrauch
Why is that an LOL?

That is _exactly_ why Sun sued Microsoft _and won_. Microsofts JVM was
slightly incompatible with the official one. If Microsoft had replicated all
Java API packages, and not added Windows-specific ones then they wouldn't have
sued.

One of the big sells of Java has always been "write once, run anywhere", Sun
sued Microsoft because their incompatible JVM made that not true anymore. Now
it's effectively true of Android; no program written in Java not specifically
for Android can possibly be expected to work. Not that I think that is a
particularly bad thing, since J2ME is a big pile of crap, but it's kind of
interesting to see the difference between the perception in favor of Sun then
and against Oracle here when the core issue is the same.

~~~
orangecat
Microsoft entered into an contract with Sun specifically agreeing that any
Java implementation they shipped would be fully compatible with Sun's version.

 _Now it's effectively true of Android; no program written in Java not
specifically for Android can possibly be expected to work._

The large majority of existing Java code and libraries will work on Android
without modification.

~~~
flomo
The relevant point being that Google didn't want to license Java under the
standard terms because they wanted control over the platform, and certainly
partially because they saw what happened to Microsoft.

It certainly wasn't just the technical matter of reproducing "166 APIs", there
was the whole political angle of putting Android under control of Sun/Oracle's
committees.

(And just on a trivial note, Microsoft eventually created their own 'clean-
room' Java called "J#". It died in obscurity, but Google wasn't the first.)

------
DigitalSea
A judge making a rational and fair decision? Seems to be happening a lot
lately, maybe the world is ending. Needless to say as a programmer this makes
me incredibly happy, if the judge ruled API's are copyrightable, then there
would have been a lot of sore bums as a result. I have a feeling if the judge
didn't know how to code, the result could have been marginally different.

~~~
krschultz
We as a community live and breath computers all day. When SOPA is put in front
of us, we immediately know it is wrong. When you talk about the idea of
copyrighting an API, we pretty much instantly were against it. And most of us
are against the indiscriminate sueing of file sharers (not to open that can of
worms here, but just as a point).

Whethers its judges, politicians, companies, or public opinion overall, it can
take _years_ for the viewpoint of the 'experts' to become mainstream. We look
at this stuff 24/7, most other people are thinking about it with 1% of their
time.

I don't think its just us either, if you dive into a community of people
focused on medicine or energy, they are 5 years ahead of you and I as well. It
just takes a long time to percolate outwards from the experts to the laymen.

~~~
ghshephard
" And most of us are against the indiscriminate sueing of file sharers"

I was with you up to that point. I think you would find that the majority of
HN doesn't have a lot of sympathy for those who would distribute other
people's creative works in violation of said creator's copyrights.

After all, the same thing that protects authors rights in the GPL underly the
rights belonging to the creators of "Game of Thrones".

Let's not stretch something that 95%+ of us agree on (You should't be able to
copyright an API) into a place where there isn't consensus.

~~~
koglerjs
I don't know about a majority.

This poll, while hardly conclusive, suggests at least a sympathy for the "IP
is imaginary!" crowd.

<http://news.ycombinator.com/item?id=2555088>

~~~
fpgeek
No, it really doesn't.

There are 3/28 votes for abolishing copyright, 1/28 for the current system as-
is and the bulk, 24/28, for retaining copyright with some reforms.

Supporting copyright reform is solidly opposed to the "IP is imaginary!"
crowd. Supporting reform means valuing the concept of copyright and wanting to
see it work better. The "IP is imaginary!" crowd would much rather see the
current system collapse under its own weight as a path towards getting
copyright abolished.

------
zmmmmm
I think the implications of this case are huge.

Apart from having the non-copyrightability of APIs reaffirmed (hugely
important in itself), we're now seeing the whole general broadside of the
intellectual property armageddon largely fizzing out. We have huge tech giants
throwing whole rafts of patents at each other and seeing time and time again
95% of them dismissed and the remainder get trivially worked around.

Hopefully this starts to change the mentality into one where these companies
realize that patents are fairly worthless protection for trivial ideas in the
first place and the only way to truly protect yourself is to actually out-
innovate and be one step ahead of where the competition is.

~~~
roguecoder
The problem is that threatening to throw those patents at small companies has
proven, and will probably continue, to be effective. It doesn't matter whether
or not they effectively protect ideas when their true value lies in raising
barriers to competition.

~~~
zmmmmm
True, but I think the effect will even trickle down to smaller cases. That is
the benefit of having a clear precedent set. For example when Big Co. now
tries to sue Small Co. for implementing their API Small Co. will be able to
stand up with much more confidence and tell them to go away. Even if that
could have been interpreted from previous legal doctrine, having such a clear
and and recent statement on it will bolster anybody in that situation to
defend themselves instead of caving.

~~~
nitrogen
It's not a lack of courage that keeps small companies from defending
themselves, it's a lack of money.

~~~
zmmmmm
Well, I would argue a clear precedent dramatically lowers the cost of
defending yourself as well. Instead of a team of lawyers to finesse obscure
complicated points and amassing huge quantities of research and evidence it
just comes down to a simple well established point of law: the stuff is not
copyrightable (I'd agree doesn't help so much with patents, which aren't
affected by precedent in this case).

------
Nogwater
_Update_ : Grocklaw now links directly to the PDF:
<http://www.groklaw.net/pdf3/OraGoogle-1202.pdf>

Someone linked to this in the groklaw comments:
[http://www.scribd.com/zdnetrachel/d/95477548-Oracle-v-
Google...](http://www.scribd.com/zdnetrachel/d/95477548-Oracle-v-Google-Order-
Regarding-Copyrightability-of-APIs)

I assume this is legit.

------
Steko
This is really a huge win for Google not just against Oracle but for Larry
Page and Schmidt who made the ballsy call here and in general to remake many
standards instead of licensing.

------
dctoedt
Judge Alsup is an outstanding judge, but I would also bet a nickel that one or
more of his clerks [1] had experience as a developer before going to law
school.

[1] A judicial clerk is a young lawyer, normally just out of law school and
generally with a first-rate academic record, hired by a judge to serve for one
or two years as a researcher and (often) as an opinion-drafter. ('grellas, for
example clerked for Judge Ingraham.) Clerk positions are highly coveted among
law students, because they can open doors to jobs in large law firms, the
Justice Department, etc. As just one example, Chief Justice John Roberts
clerked for then-Associate Justice, later Chief Justice William Rehnquist. See
<http://en.wikipedia.org/wiki/Law_clerk#United_States>

------
mbreese
Sanity prevails when you have a judge who can also code...

------
thoughtsimple
Don't celebrate too much yet. This is likely to be appealed.

I think the judge did a good job in trying to make sure this decision stands
on appeal but until the appeal process is over, this could still turn ugly.

~~~
chimeracoder
IANAL, but I'm not sure that this is too likely, because of the way that Alsup
separated the jury's decision from his own.

Prosecution can't appeal a jury's acquittal; in this case, Alsup's ruling is
separated from the jury's decision (remember when he told them to 'assume APIs
are copyrightable'), so I'm not sure what the possible courses of legal action
are here. This is a subtle point, so I imagine one would have to be a lawyer
to answer this one, though I have a suspicion that there may not be a
precedent here (or, if there is, it's a weak enough precedent that it could
still reasonably go either way).

~~~
DannyBee
I can't speak very much or about this particular case (because i'm involved),
but i can tell you you are confusing civil and criminal law. You are correct
that in a criminal case, the government cannot generally appeal a jury
acquittal . In a civil case, you can appeal a jury verdict (in practice, I'm
being deliberately loose with terminology to make this understandable), the
usual method is to file a post-judgement motion for judgement as a matter of
law, and then appeal its denial, or appeal the jury instructions, or ...

~~~
chimeracoder
I know civil and criminal are different; however, I thought that was the whole
point of the special jury instructions (making it impossible/more difficult
for his ruling to be overturned on appeal).

In any case, I guess we'll see soon....

~~~
DannyBee
Sadly, I can't comment on the jury instructions except to encourage you to
look around at other patent and copyright cases and see if you think they are
really all that special or different.

I can say it is statistically more difficult to overturn jury verdicts than it
is to overturn judge verdicts. On the patent side, you can find interesting
but slightly out of date data here:

[http://www.patentlyo.com/patent/2010/04/are-appeals-at-
the-f...](http://www.patentlyo.com/patent/2010/04/are-appeals-at-the-federal-
circuit-a-coin-flip.html)

You should be able to figure out which issues are eliminated by having mainly
a jury decision on patents instead of a judge decision.

------
hannibalhorn
Kudos to the judge for making the effort to really understand the issues. I'm
curious, did WINE ever come up as an example of an alternative API
implementation?

I'd actually find that a more interesting case, as it's an alternative
implementation of APIs where the creator never even envisioned there being an
alternative implementation.

Java, despite what Oracle may say, was always spec'd to a point where
alternative implementations were probable, and many JVM improvements started
off as proprietary forks/implementations.

~~~
fpgeek
So far as I could tell, WINE was never part of the trial record (i.e. no
testimony, exhibits, etc.) so it wouldn't (shouldn't) be referred to in the
legal arguments in the trial.

That being said, it would be good to see the WINE project submit an amicus
brief (possibly with the help of, for example, the EFF) during the appeals
process.

------
spullara
How does this effect the GPL? Is this no longer something that the GPL can
restrict?

<http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL>

~~~
chc
The GPL never forbade creating a nonfree library with the same interface as a
free one.

~~~
jrockway
That's my reading too, though I remember someone who wrote a MySQL API layer
that was not libmysql was accused of violating the GPL. Amusingly, MySQL is
now an Oracle product (though I'm not sure it was at the time).

~~~
Sanddancer
It had been MySQL's standard MO for a while. Their point of view was you
either had to completely open source your product, or you had to pay them lots
of money. Using it in an in-house webapp, or as you mentioned, reverse
engineering the API, would get them knocking on your door threatening to sue
you.

------
rwmj
I like how Florian Mueller manages to spin this[1] as a two year respite for
Google who will eventually lose on appeal!

[1] [http://www.fosspatents.com/2012/05/judge-says-google-only-
us...](http://www.fosspatents.com/2012/05/judge-says-google-only-used.html)

------
kodeninja
With this ruling, Judge William "Haskell" Alsup has become a personal hero of
mine - a real caped crusader!

Way to go, judge! The wider developer community salutes you.

------
12bit
I imagine this has implications for the Cappuccino framework, which uses the
Cocoa API with some minor changes (replacing NS with CP).

------
barrynolan
Who is he referring to here? " For those who have depended on the self-
described patent expert for your understanding of this case . . . well, maybe
now you will know better than to trust a paid spokesman." FOSS Patents?

~~~
parfe
Mueller's likely cooking up another article of baked shit right now. He will
write about how Oracle actually won this case (even with all the verdicts and
judgements going against them), so it was actually bad for Google.

I guarantee he posts an article tomorrow lamenting how Google will only face
more lawsuits like this and they won't luck out with an "incompetent" judge
and google-loving jury next time. He has been so off the mark with every
article he's written on this case he's got to have zero personal pride in his
work.

It's a shame people go to him for information. He's a poison in the software
community.

~~~
kierank
He makes valid points about abuse of the FRAND patent system.

------
SquareWheel
What a great judge. If only the politicians passing tech laws would put in
this kind of effort.

~~~
chii
a judge goes thru some very different education and indoctrinations than a
politician would have.

A judge is more difficult to corrupt, and/or bribe with circumstances, because
there is no incentive for the judge to favour one or the other. Thus, this is
fair.

A politician has plenty of incentive to favour one party over another when
creating legislation - after all, who pays for their campaign contributions?
He/she/it who pays controls.

~~~
zopa
As it happens, most trial court judges in the US are elected. See here:
[http://www.brennancenter.org/content/section/category/state_...](http://www.brennancenter.org/content/section/category/state_judicial_elections)

Judge Alsup is a federal judge, so he's an appointee, not an elected official.
But most judges do need campaign donors. It's a problem.

------
robomartin
I can't remember ever having read a legal document that pulled me in as this
one most-definitely did. I found it fascinating and educational. Every time I
had a question Judge Alsup answered it. In detail. It clarified many points
and questions I had about some of my work and upcoming projects where the
question of interface vs. expression was surely going to come-up. The other
thing it did for me is further clarify the demarcation line between copyright
and patent. I had a very good idea, but this document explored edges I didn't
know existed.

------
EternalFury
Does this set a precedent for all kinds of APIs or just the Java API?

Can I go and implement any commercial API and sell my own implementation
without having to pay any fee to the original author of the API?

That would be awesome.

~~~
mbreese
If you can be sure that the implementation wouldn't be encumbered by a patent,
then yes. But, you can't be sure that you still wouldn't get sued. Although,
if the API isn't publicly available, I'm not sure it is so clear.

You've always needed to be able to implement APIs in order to have
compatibility, so in essence, this decision puts into case-law what what
already assumed to be the case.

~~~
EternalFury
OK, let me clarify.

Let's say a software vendor out there is making a ton of money with a product
that exposes a certain API.

Let's say I know a way to implement that API in such a manner that its
performance will be improved by an order of magnitude. (without using any
patented method in my implementation)

Can I put together that implementation and market it as a competitive product?

In my experience, APIs of commercial products are disclosed under the terms of
their licensing agreement. So, one could argue that I cannot market a
competitive implementation, if the license terms I agreed to (to gain
knowledge of the API itself) prevent me to do so.

~~~
harshreality
If you agreed to a license or NDA prohibiting you from competing, that might
be enforceable under contract law, but that is neither related to copyright
nor patents.

Assuming a case where there's no contract involved, patents are typically what
would cause trouble. The original implementor will typically have a patent on
some silly thing their software does, and you have to do that thing to make a
compatible implementation, so they sue you for violating their patents.

~~~
EternalFury
A lot of things out there are very dumbly implemented and you can implement
them better easily. Patent-heavy code is fairly rare (maybe 10% of all
enterprise applications) in my experience.

To go back to my question, there are a lot of entrenched players out there who
rely on an age-old user base to keep afloat. If you can provide a better
implementation without asking them to rebuild their client applications, their
customers will have an easy road to migrate towards your implementation.

------
dminor
Great! Now just a few years of appeals and it will all be over...

------
duckduckgouser
I'm so glad to hear this. This is more than a win for developers (almost)
everywhere, this is deterrence for large companies that want to bully others
with their legal team when almost everyone is saying what their legal team is
doing is at best suspect and at worst a travesty.

------
CUR10US
So here's the question: Can you protect a computer language with copyright,
e.g. a high level language like a scripting language?

~~~
saraid216
I'm fairly sure that languages cannot ever be copyrighted, programming or
otherwise.

~~~
CUR10US
Can the interpreter be protected by copyright? Technically that is a program,
not the language.

~~~
caf
Of course. But that doesn't stop anyone from writing their own interpreter
that interprets the same language, as long as they don't copy any
copyrightable parts of your interpreter to do so.

(Such an interpreter would likely contain a table of function names. The
effect of this ruling is to clarify that that set of function names can't be
copyrighted, so the alternative implementation of your interpreter can copy
it. We already knew that the names themselves couldn't be copyrighted, but
this ruling clarifies that also the "structure, sequence and organsiation" of
those function names can't be copyrighted either.)

~~~
CUR10US
This still seems like pretty good protection for someone who has written an
interpreter that performs "the best" vis-a-vis any clones. From the end
user/customer's perspective, who cares how the function's interface/arguments
are structured? What matters is how well the functions are written and thus
how well the interpreter, and the programs it runs, perform. Of course,
programmers might care about how well interfaces are designed, but
unfortunately we can't sue people for crappy interfaces.

~~~
caf
Well, from the end-user's perspective they care very much that the clone can
provide the same functions organised in the same way as the original, because
otherwise their scripts that run on the original interpreter won't run on the
clone.

But yes, the underlying implementation is still subject to copyright (and
potentially, patent). You can't copyright the fact that your scripting
language has an operator spelled >< that concatenates strings, but you can
copyright your particular code that performs string concatenation.

~~~
CUR10US
Yes, same functionality. I only meant the implementation, the code. Let's take
an example: The APL and APL-related languages. IBM and some other old
companies have been licensing these "languages" for many years. But what are
people really licensing? Not the language. If we agree that languages are not
protectatble, then no one needs permission to use a language. (What the
licensee is really paying for is the use of an interpreter and perhaps
support/consulting.) But how many programmers understand this distinction?

------
rhizome
Ralph Yarro is bummed.

------
DannoHung
Anyone else hearing the Ewok victory song in their head?

~~~
heretohelp
Yeeeep

------
indiecore
A sudden outbreak of sanity!

~~~
ajuc
Let's hope it's addictive.

