And thus, it ends. Despite a never-ending stream of doom and gloom from Oracle/Microsoft-funded ‘pundits’ regarding Google and Android (six hundred billion trillion gazillion eurodollars in damages!!1!), judge Alsup has just squashed all of Oracle’s chances with a ruling that is good news for those of us who truly care about this wonderful industry: APIs are not copyrightable. Alsup: “To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands. No holding has ever endorsed such a sweeping proposition.” Supreme Court, Ellison?
That’s great! For now. Oracle probably will still file an appeal. I doubt Oracle would learn from all of this. Here is a good description of Oracle management corporate thinking from Bryan Cantrill:
http://www.youtube.com/watch?v=-zRN7XLCRhc#t=33m40s
Edited 2012-05-31 21:54 UTC
And here is Linus’ prediction on Google+:
“Prediction: instead of Oracle coming out and admitting they were morons about their idiotic suit against Android, they’ll come out posturing and talk about how they’ll be vindicated, and pay lawyers to take it to the next level of idiocy.
Sometimes I really wish I wasn’t always right. It’s a curse, I tell you.”
From the updated article:
Update: Oracle has forwarded us a statement with its response as well:
Oracle is committed to the protection of Java as both a valuable development platform and a valuable intellectual property asset. It will vigorously pursue an appeal of this decision in order to maintain that protection and to continue to support the broader Java community of over 9 million developers and countless law abiding enterprises. Google’s implementation of the accused APIs is not a free pass, since a license has always been required for an implementation of the Java Specification. And the court’s reliance on “interoperability” ignores the undisputed fact that Google deliberately eliminated interoperability between Android and all other Java platforms. Google’s implementation intentionally fragmented Java and broke the “write once, run anywhere” promise. This ruling, if permitted to stand, would undermine the protection for innovation and invention in the United States and make it far more difficult to defend intellectual property rights against companies anywhere in the world that simply takes them as their own.
——————————————
Dear Mr Ellison. Stop being a cunt.
The fragmentation of Java and issue of incompatible implementation are valid critiques of Android. But what does it have to do with the idea that APIs shouldn’t be copyrightable? Both are right.
Oracle is doing a very blatant bait-and-switch.
Fortunately fragmentation is actually an essential element in the concept of free market competition, thus isn’t illegal under any law.
“Right to fork” is good as a right, but in practice forking (or in general creating incompatible implementations) is not always a positive thing.
Depending on your point of view. From the point of view of someone/organization that wants to avoid adapting to change, or wants to maintain complete control, forking is not a good thing.
To those people, I say tough cookies.
What I mean is, that if forking can be avoided by collaboration on one project – it’s better than spreading efforts on incompatible implementations. (Well, in this case it isn’t even forking, just incompatible implementation).
Edited 2012-06-01 03:11 UTC
Aside from what I already posted about Dalvik converting bytecode, thereby not making it an incompatible implementation…
If forking can be avoided, probably yes. But in this case, can forking be avoided? I don’t think so. Not if you want to have a register-based VM over a stack-based VM (as explained in the Wikipedia Dalvik article).
I think Oracle are absolutely right in claiming that android’s API fork has caused java platform fragmentation. However I think this fragmentation argument shows just how desperate Oracle are here. API’s are not copyrightable, and yet a clone of the APIs are in violation of copyright law because they fragment the market? Seriously?
I’d like to try that one myself: Your honour, the defended have not violated our copyrights per say, but their clone has fragmented our market you see? Here we have some charts to prove it too. Here we have a laptop running defrag to demonstrate just how bad fragmentation is…
Except that Java *itself* is fragmented, and is not interoperable with itself. Afterall, the APIs available to a J2ME developer are not the same APIs available to a J2SE developer, which are not the same APIs available to a J2EE developer. And that is all Oracle’s (originally Sun’s) doing!
The problem with Oracle’s entire case against Google/Android is that they keep changing their demands/arguments. They don’t actually have a case, which is why they keep changing their demands/arguments.
Reading through the Groklaw coverage of the case, it’s amazing it even made it to court, let alone made it through the complete trial. There was never any possibility of Oracle winning. Their lawyers and arguments were specious at best, and downright wrong most of the time.
You forgot JavaRT. Java Card and a whole lot of other API sets that are very much incompatible with Java SE.
I think Oracle is not right on that. If people write an Android application they write an Android application using the Android API’s which are not available in Oracle JVM nor outside of Android. As such such applications are 100% Android and 0% Oracle Java.
The language is irrelevant. It could have been C++, Javascript or C#. It’s irrelevant cause both languages are *NOT* compatible cause of the different API’s and packages. You just cannot run an Android application with Oracle Java.
cdude,
“As such such applications are 100% Android and 0% Oracle Java.”
“The language is irrelevant. It could have been C++, Javascript or C#. It’s irrelevant cause both languages are *NOT* compatible cause of the different API’s and packages.”
The thing is, android does use the Java language plus it’s APIs, even though they reimplemented everything in the back end. Oracle’s case was about how android derives from Java’s APIs, which is true, but the court ruled that it doesn’t matter.
Edit: You raised the issue that google’s Java implementation bytecode isn’t compatible with Java’s official bytecode. That may be true (although the existence of a bytecode translator makes it somewhat less true), but I don’t think it’s relevant. Consider a C++ program that uses the STL APIs, this program can be compiled for Linux (PPC/ARM/x86/x86-64), windows, SunOS, etc. Now would you admit that these all share the same API even though they’re not binary compatible?
This was the right ruling, in my opinion. If we’re not permitted to re-implement APIs, then 3rd party software implementations could be prohibited from being compatible with defacto proprietary standards (Mono, Wine, ReactOS, Samba, etc). The ruling in this case was very narrow, but it did set the right precedent.
Edited 2012-06-02 01:25 UTC
removed cause double-post
Edited 2012-06-02 00:19 UTC
XBMC which was forked from XBMP sucked at first and then got considerably better.
Not sure about the MATE fork of Gnome… haven’t used it yet… only time will tell.
According to Oracle’s own engineers, Android is not derived from Java. Therefore there can be no fragmentation.
Looking at that from usability perspective – isn’t it ridiculous that on supposedly Java (as in Dalvik) based Android you can’t run Java (as in JVM) programs? Compatibility is not a bad thing. There were probably technical reasons why Google went with Dalvik (supposedly performance advantage). But in practice it did cause a rift.
Edited 2012-06-01 03:08 UTC
According to this: http://en.wikipedia.org/wiki/Dalvik_(software)
“Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device.”
The bottom line – runtimes are incompatible. You can’t run Dalvik bytecode on JVM and vice versa.
Edited 2012-06-01 15:02 UTC
And … the problem is?
Android is not Java.
Dalvik is not Java.
Can you use Java syntax to write Android programs? Sure. But it’s not Java.
Can you use Java libraries in Android programs? Sure. But it’s still not Java.
Nowhere has Google ever claimed that Dalvik is Java. So how is it fragmenting Java?
Did you not read the description? You can run JVM bytecode on Dalvik by converting it to Dalvik bytecode before installation.
So you’re at least half wrong by saying “and vice versa”.
You can’t run Dalvik bytecode on a proper JVM, but due to the ability to convert Java bytecode to Dalvik, a developer can write and compile Java into JVM bytecode and be able to distribute just the JVM version and end up with something that runs in a JVM and can be made to run on Dalvik.
Converting it during installation is not a good method, more interesting solution would be to convert it at runtime (what different emulators do). But it adds overhead. The whole point of compatibility is to avoid such things. But well, in this case they diverged.
Java programs wouldn’t have been compatible anyway. The “write once, run everywhere” motto is a fat joke, far bigger than “don’t be evil“.
Yeah. Had to install Windows on the office PC because the Java app we needed to file our taxes wouldn’t work under Linux. It’s like they never tested it on anything but Windows.
A license to call your implementation Java, which is not the case here.
One of the critical sleight of hands Oracle tries to put into people minds in their statement is: “a license has always been required for an implementation of the Java Specification”. To be a certified implementation of the Java Specification this is true. Dalvik, however, neither purports nor seeks certification. Dalvik simply provides an API that is similar or the same (in some areas) as that of a popular system.
So Google borrowed from Java’s API, big deal. So long as Google doesn’t claim that they are a certified Java (R) implementation with the cutesy little logo they should be in the clear.
Based solely on the words in this news blurb, I’m not certain I agree with Judge Alsup’s analysis. The quote almost sounds like Alsup is mixing some patent analysis into copyright analysis. Judge Alsup is too smart to make that kind of mistake, so the whole opinion must explain it better. Just from what I read in the blurb, the decision could easily be overturned on appeal.
Either way Oracle wins from this. Either they get their copyright, for whatever that is worth, or they get a clear statement of law that says others cannot impose copyright restrictions on their APIs against Oracle. If I was Oracle, I would push this all the way. They have already paid for the expensive part of the litigation, may as well get the strongest legal statement possible.
This sounds like our “friend” at “FOSS”Patents would say. You sure, you aren’t him?
How? Oracle downed a lot of money against a company that fought an incredible battle. Invalidating patents(ridiculously hard thing to do) and dodging the other claims.
Can’t wait for muellers response!
Seems EVERYTHING he predicts is wrong.
Looks like: In it for the money like a camwhore.
ps Was thinking about deliberately misspelling his name – to avoid publicity for him – but prefer search engines to see his name associated with bad connotations
Nothing in this decision contradicts anything Mueller has said. You can dislike the guys overall opinions and direction, but he does do an excellent job at separating what is facts and what is opinion, and does present all the facts.
I also think it is important to note, as Mueller does, that while this is the end of the line for Oracle (pending appeal), that Alsup very clearly did not rule APIs uncopyrightable in general:
“This order does not hold that Java API packages are free for all to use without license. It does not hold that the structure, sequence and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act.”
Which makes sense; of course a sufficiently large, complex and creative API would be copyrightable, but it has to make that bar just like all other works under copyright. For most APIs this would be difficult, but in rich data modelling languages for example it would most likely be a fairly common occurence.
You’re kidding? His report on Oracle loss is merely FUD stressing that it can be overturned on appeal.
That’s *always* the case, so he is just restating the obvious to hide that the judgement is a loss for Oracle, even if the issue isn’t settled yet.
Of course?? In Europe, they explicit banned copyrighting APIs.
IMHO the judge is just making sure that his judgment won’t be overturned in appeal by stressing that his judgement only apply to this case..
True. Remember also that, regardless of the judge stressing that his judgement only applies to this case, the way that the legal system works is that this decision will set a precedent for all future alleged copyright cases involving use of APIs.
Yes, of course. If I write poetry in the form of Java interfaces it remains perfectly copyrightable. There is no magic about programming languages that make creative works impossible to copyright. It just happens to be hard to meet the requirements of copyrightability when it comes to common APIs, but it is perfectly certain that there are copyrightable material that can be expressed as APIs.
Funny that, I’m quite sure of the opposite: http://www.osnews.com/story/25904/EU_s_top_court_APIs_can_t_be_copy…
I don’t know about the USA, but in Europe you’re wrong..
The actual EU statement is still weaker than what the Ars article makes it out to be. One notable example is that there is such a thing as compilation copyright, a cookbook can be copyrighted even though recipes cannot. In much the same way the EU is saying that you cannot copyright small APIs, for much the same reasons why you can’t copyright recipes, but a greater integrated work fall into a different category. The Oracle suit fits this shape nicely, being about 37 (relatively few) disparate classes, and got appropriately shut down.
I would suspect that for example you cannot implement the entire interface of Emacs without respecting the GPL, since the public API is actually the entirety of the editor (it exports largely all its internals, and you can figure them all out by introspection from within the editor). It would simply be an obvious rip-off of a lot of work from GNU contributors, and would not really serve the purposes of simply making something Emacs-compatible. Implementing an editor that exports the same user-facing functions (the subset of Emacs functions that are prepared for being bound to the keyboard), and a compatible elisp environment (the documented parts of the interface that is expected to be used by package developers) would be fine, but ripping off the rest of the structure of Emacs would not be. It might be tempting at that point to define “API” to not cover the rest of the functions, but these functions are just as accessible as anything else, and the GPL would allow anyone to make a fork of Emacs that exported even the remaining inaccessible structure as APIs.
This is to some part speculation, but it is more or less how I would expect the line to be drawn. At the very least it is important to remember that there are no special rules for programming in copyright law, it all falls under the usual idea/expression and fair use rules as everything else.
You cant write a poetry in an interface.
The interface is the poetry-category. Your concrete poetry is an *implementation* of that interface.
Others may write poetry’s too that implement that interface, means match into the same category your poetry does. In no case can you prevent others to do that by claiming the poetry-category for yourself only. There are very good reasons this is not possible and the same applies to Software.
With C++ template libraries, the API and source code are one and the same. If the API can’t be copyrighted, then C++ template libs can’t be copyrighted. (Which means that all GPL template libraries are now public domain, and can be used without honoring GPL rules.)
Actually you should have an implementation substantially different, as it is not because they are templates that they lack the internal functionality, It is just that it is constructed on generic format.
you do realize there is a difference between developing and using right?
That’s not how it works.
You’re confusing various things here. First of all source code does not equal API. Secondly, the source code is still copyrightable even if the API isn’t.
See above.
Edited 2012-06-01 00:19 UTC
Easy:
template<class _T_> bool rangeCheck(const _T_& obj, int fromIndex, int toIndex);
is not copyrightable. But the body of:
template<class _T_> bool rangeCheck(const _T_& obj, int fromIndex, int toIndex)
{
if(fromIndex > toIndex) {
std::cerr << “fromIndex(” << fromIndex
<< “) > toIndex(” << toIndex
<< “)” << std::endl;
}
if(fromIndex < 0)
{
std::cerr << “Index out of bound.” << std::endl;
}
if(toIndex > obj.size())
{
std::cerr << “Index out of bound.” << std::endl;
}
}
is copyrightable.
same rule apply if you have an inline variant of the templated function in your header:
inline bool rangeCheck(const std::list<int>& obj, int fromIndex, int toIndex) { … }
In other word, do not confuse headers with APIs. APIs is only the functions name and its parameters. And code in a header does not magically become an API, it remains code.
(My appologies to OSNews for exposing them to Oracle copyright trolling by inserting very valuable Oracle copyrighted material in my comment)
Problem, Ellison?
Going out to have beers, even if they are not free!!
And here my favorite excerpt of the ruling (taken from a comment on arstechnica):
Hope it extends far beyond java.
Indeed let us hope that the sanity of this ruling extends further. Some of the stupid short phrases that are being granted trade mark protection (Paris Hilton suing Hallmark cards over “that’s hot”) makes it hard to imagine how any media gets out the door to the public without paying for dozens of short, trite trademarked utterances.
Reference:
http://news.lalate.com/2010/09/27/paris-hilton-settles-thats-hot-la…
What was utterly stupid is that she won!
I hope so, SCOTUS would bury him and probably make things even worse for him and others like Microsoft.
Another a bit overblown headline, Oracles case is indeed over, but APIs remain perfectly copyrightable if they are a sufficiently complex and creative work, all Alsup has decided is:
“This order does not hold that Java API packages are free for all to use without license. It does not hold that the structure, sequence and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act.”
To link to another comment where I summarized my complaint about this recurring misunderstanding about API copyrightability: http://www.osnews.com/permalink?518336
It is like with all copyight: Big, complex and creative works are copyrightable, and that is a high bar to reach for APIs, but it is clearly possible.
Au contraire, this decision is quite important. It means that as long as a project writes its own actual implementation then using someone else’s API (for reasons of compatibility and interoperability) is perfectly OK under copyright law.
This means that FOSS projects which re-implement functionality to a common API are perfectly fine. FOSS projects such as Samba, Wine, gnash, VBA for LibreOffice and Linux hardware drivers etc can’t be attacked for copyright violations.
Edited 2012-06-01 07:37 UTC
Not really the case though, despite the quote that Thom picked for the blurb here. Alsup is very clear that Google is in the clear due to their use of the APIs being limited (37 classes out of hundreds) and the relatively low complexity of the classes concerned. Implicit (though not in a legal sense of course) in the decision is that very broad copying of APIs, or copying of APIs that are more complex and specific to a task, is not really allowed.
It is an interesting question for the future where the line is drawn. I find Alsups conclusions here to be very reasonable (this case was pretty limited), but I also agree that there are limits. Hugely complex software that is mostly concerned with defining complex interfaces does need a bit of protection, and this includes GPL software needing it to control commercial rip-offs. For example it seems reasonable that no one should be able to write a non-GPL gcc back-end, since the interface in question, GIMPLE, is monstrously complex and very tied to the functionality of gcc (that is, a lot of gcc cleverness is embodied in the interface itself).
No, that’s not reasonable at all.
The only reason why no-one should be able to write a non-GPL gcc back-end is due to the fact that GCC is under GPL. That’s the only reason.
There should be no sane reason why I, writing a compiler toolkit, could not have the same API as the GCC compiler, provided I didn’t copy the actual files from a GCC source tree.
Something being complex and difficult is not a good reason for it to be legally protected.
It would be a clear rip-off of very hard work in gcc to rip off GIMPLE. I think you are underestimating how much is involved in that stage of gcc, and would possibly argue that it doesn’t fit your idea of what an “API” is, but it is still just interface code. Making a legal distinction of what is interface and what is implementation is hopeless.
I think we might have to agree to disagree when it comes to what we want here, but personally I am very much on the side where sufficient innovation expressed in an interface should get protection.
Yes, and that is more reason to err on the side of freedom than to go immediately to the protection route.
There are no benefits from protecting an interface, but a lot of drawbacks.
No, I’m afraid not. The grandparent poster has it correct, further Judge Alsop has stated:
His ruling was very narrow, specific to the Java API. I think for a judge this is a safer path, less chance for it to be overturned later I suppose.
Nevertheless, the ruling can be, and no doubt will be, used as precedent for similar cases in the future.
Yes, I think we can all as technology enthusiasts be happy about this decision. It is important to be accurate about what is actually said, but certainly it is nice to see it reaffirmed that simple or small APIs can’t be copyrighted. I still have no trouble imagining APIs that believe are (or should be) copyrightable, but those are not on the level of a collection of disparate Java utility classes.
I don’t want to sound over dramatic but this is probably one of the most important court cases ever and probably thee court case of the century in terms of it’s implications.
Yeah, that was a little bit overly dramatic. 😀
So does that mean that Mono was safe all of this time?
The concern with Mono was patents, not copyright. Some claim that we can’t trust Microsoft with their legally binding promise* not to sue Mono users. Some claim that we can trust Microsoft. Whatever the actual case may be, they are different concerns from Java.
* I personally don’t feel comfortable with their supposedly legally binding promises. If they revoke their promise unilaterally, who actually could challenge Microsoft for breaking the promise?
You are right to feel uncomfortable. Any normal person would. But Microsoft don’t have to break their promise. Their promise covered only the ECMA part of Mono. Microsoft never promised anything regarding the non-ECMA part of Mono. And that broke Miguel’s heart because he had hoped that a complete promise would help him further infect Linux with Microsoft’s crap. Subsequently Miguel promised he would split Mono in two parts (ECMA and non-ECMA) for legal reasons. But he never delivered. Mono is dying slowly now. Moonlight is already dead. Novell is dead, Finally Attachmate threw Mono in the dump where it belongs.
As much as I distrust MS, I find .net (as a technology) to be vastly superior to java so that extends to mono as well.
One does not have to own a piece of art to be able to appreciate it.
Edited 2012-06-01 23:08 UTC
I am not a Mono fanboy, but this is just plain wrong.
Thanks to Unity, PS Vita SDK and AOT compilation for Android and iPhone, Mono is being used a lot in the games industry.
Isn’t there a similar concept in British law, the idea of a “poll” (e.g., “name poll”)? I believe it’s a form of legal obligation where the obligation is unilateral and self-imposed, or something like that. When the obligation is between two or more people, then it becomes a contract (I think).
I really don’t know anything about the whole Mono situation, but perhaps the reason why Microsoft called it a “promise” is because the “poll” concept doesn’t exist in U.S. law, AFAIK. Yet there may be some serious legal ramifications, just like how registering your copyright is not necessary to enforce it as long as it meets certain criteria (in theory). I always got the feeling that people were skeptical/prejudiced about/against the promise simply because of its name, as if it would sound naive to accept it because it would be like “believing” in a personal guarantee. But really, I haven’t informed myself sufficiently to know the grounds for skepticism.
The thing is Microsoft only promised that *Microsoft* does not sue. They did not promise the same applies for patent-“exploiter” or Microsoft-partners who have/got rights to do so using the Microsoft .NET patent-pool.
Does any of that really matter? Let’s suppose one day, Microsoft decides to unilaterally go back on their legally binding promise. Who has the money to sue them and can they guarantee the court won’t just invalidate the promise?
People were/are skeptical/prejudice of the promise, not because of the name, but because of who made it and their history. If Google were to make a promise of any sort, people would tend to believe it. In this case, it’s Microsoft and can we really trust any of their promises?
The legal doctrine is called “equitable estoppel”. If you unilaterally promise something, you cannot then unilaterally withdraw that promise if, in doing so, you would cause harm to anyone who had relied upon that promise.
The classic case is this: you own a property in London. It is war-time, and you are finding it difficult to let the building. So you promise a potential lessee that you’ll charge much-reduced rent for the duration of the war. The potential lessee agrees, and takes a lease. The war ends; you now say “you owe me the normal rent for the war years, which is much higher than the rent I actually charged you. And the war is over so you can afford to pay”.
The English High Court, in 1947, basically said, “Bugger Off: you promise something, you can’t go back on that promise if it causes detriment to someone who relied on your promise”.
Microsoft promises not to sue in various circumstances; they cannot subsequently unilaterally withdraw that promise and hope to have their “rights” enforced.
And it’s irrelevant if it’s Microsoft or someone who has subsequently bought their patents or their patent right: Microsoft have renounced their patent rights in these specific circumstances. No-one may subsequently seek to enforce those rights, to the detriment of others, without bumping into the equitble estoppel brick wall.
What a funny little world you live in.
If you’ve kept up with the “developments” of the legal system in recent decades, you know that a big company does not ever need to win in order to wield their power. All they need is a large sack of cash and lawyers and either intimidate or appeal endlessly until the other guy runs out of money. The threat of that alone has already forced many small players into undisclosed out of court settlements.
So again, while we all would like to live in a world where the side who is right is the side who wins, the real world favours the side with the money.
The legal system does not work like a computer.
Not so funny. Just the way it is. Promissory or equitable estoppel (or ‘detrimental reliance’) is so well established as a legal doctrine, both in the UK and the USA to name but two, that I don’t care how big the company is or how many lawyers they hire: they’re not going to win.
There are no legal developments in recent decades that make it a grey area. Quite the opposite: the doctrine is much more firmly developed now than it was, say, 60 years ago.
Whether it takes a 25-pound postal order, self-representation and a district court magistrate or two years and a large team of highly-paid barristers is really irrelevant to the issue at hand: you said “it’s Microsoft and can we really trust any of their promises”… and my point simply is, trust doesn’t come into it. The matter is justiciable, and that’s all that really counts.
You appear to believe that the law is abused by big business merely to intimidate the little guys. I happen to believe, with good reason, that it’s actually the law that *stops* big business trampling all over the little guys.
I personally don’t think that’s particularly naiive, but even if you do, it doesn’t alter the fact that promises not to sue can’t be withdrawn on a mere whim or without legal consequences.
And you quite missed my earlier point that a company like Microsoft can absorb the legal consquences and still leave everyone they “promised” in the gutter.
Have you seriously not understood that a large company can/has intimidate and just appeal until the smaller one gives up?
I want to scream on the top of my lungs today, I’m SOOO happy for Google! Who’s your daddy now, Oracle?!? Another one of your useless lawsuits (and millions of dollars) have gone down the drain because you, Oracle, are far too greedy and want to either buy out your competition or sue them bankrupt. Well, this time your f*cking lawsuits backfired. Good for you. I hope you keep losing lawsuits left and right until you become a different corporation altogether.