18 ms·

Oracle wins appeal re Java API copyrightability [pdf]

285 points by dctoedt 13y ago

exabrial 13y ago
I herby copyright: Object *(Object...); I'll take a check Oracle. Thanks.
dctoedt 13y ago
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).
crashandburn4 13y ago
Does anyone have any idea what the practical significance of this for android and google is? IANL and find these documents hard to parse.
- tssva 13y ago
  For now the case has been sent back to the district court for it to determine fair use questions. The API is now considered copyrightable but Google's use of it may fall under fair use. The district court needs to decide this. Whatever the outcome expect either side to appeal which means any practical significance may be years away.
  - msandford 13y ago
    The idea of an API being copyrightable is ridiculous. An API describes and interface between application code and system code. It describes the "shape" of the interface. So now Oracle has an (effectively) infinite length patent (it's technically a copyright which at this point is eternal as long as Disney keeps lobbying) on the shape of the Java API. Perfect.
- fpgeek 13y ago
  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-google-idUSBRE84M18K20120524 http://www.reuters.com/article/2012/05/24/net-us-oracle-goog...
  - rayiner 13y ago
    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-judgment-fair-use https://www.eff.org/document/opinion-granting-summary-judgme.... 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.
afarrell 13y ago
Why is American government the best government? Because of our endless appeals system.
- adanto6840 13y ago
  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/
- cidico 13y ago
  Bitch please... Come to meet Brazil :)
jahewson 13y ago
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 13y ago
  > 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 13y ago
    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.
npinguy 13y ago
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.
- xntrk 13y ago
  It's not even just software patents though. Amazon just got some crazy patent on taking pictures on a totally white background which has been around forever..
  - sergiotapia 13y ago
    They have a copyright on that? That's ridiculous. Everybody does that.
- rayiner 13y ago
  This is a copyright case. It's in front of the federal circuit because there were originally some patent claims, which invoked federal circuit jurisdiction, but none of those remain any longer. See Groklaw's Update #2: http://www.groklaw.net/articlebasic.php?story=20130213000119924 http://www.groklaw.net/articlebasic.php?story=20130213000119....
  - smrtinsert 13y ago
    > Here's Atari Games v. Nintendo, so you can see what you think for yourself. But here's what I notice is not protected by copyright: > "Under the Act, society is free to exploit facts, ideas, processes, or methods of operation in a copyrighted work. To protect processes or methods of operation, a creator must look to patent laws." > It's there in black and white that methods of operation are not protected by copyright. So what is Oracle thinking? Seems pretty clear to me!
- raverbashing 13y ago
  Of course Software Patents are a great sell for developers with an inflated sense of self-importance (and their bosses) thinking that everything they created is wonderful and unique. Lawyers just played on that, and of course, they get their share of it
ChrisClark 13y ago
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 13y ago
  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...
DannyBee 13y ago
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.
- fpgeek 13y ago
  And not just open source. Compatible re-implementations are a standard staple of proprietary software as well (arguably including, ironically, Oracle itself as a compatible implementation of IBM's SQL).
- tosseraccount 13y ago
  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 13y ago
    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.
cromwellian 13y ago
There's be no PC revolution if this ruling existed in the 80s. http://ckolderup.tumblr.com/post/48362660527/phoenix-technologies-cloning-the-ibm-pc-bios http://ckolderup.tumblr.com/post/48362660527/phoenix-technol... 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.
- syntern 13y ago
  Or, you can just move to a more reasonable region. I'm expecting more startups coming from the EU and Asia because of the difference in regulations. (And while they will be sued in the US and other places, they will have plenty of business opportunities elsewhere).
  - cromwellian 13y ago
    That will work so long as no world-wide treaty synchronizes the shitty copyright/patent laws across nations.
    - undersuit 13y ago
      You'd have to do that in secret if you didn't want massive backlash.
    - cromwellian 13y ago
      You mean do it in secret like this? http://www.theverge.com/2013/11/13/5099236/wikileaks-publishes-leaked-draft-of-tpp http://www.theverge.com/2013/11/13/5099236/wikileaks-publish...
    - lern_too_spel 13y ago
      According to the Berne Convention, signatory countries must recognize the copyright of a work in its country of origin. I think that means US copyright law on Oracle's works apply in all 167 signatory countries, but maybe an IP lawyer will chime in to correct me.
mmorearty 13y ago
I wish Groklaw was still around to give a good analysis of this :(
- cromwellian 13y ago
  Don't work, we still have Shillian Mueller to spike the ball, I mean, analyze it.
seacious 13y ago
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 13y ago
If Oracle wins, is Linux the next target, as an api-compatible re-implementation of Unix?
- pmarin 13y ago
  Unix != POSIX
  - sixbrx 13y ago
    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.)
fidotron 13y ago
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 13y ago
  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.
phkahler 13y ago
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 13y ago
  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 13y ago
    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.
  - phkahler 12y ago
    The existence of the LGPL has always seemed liked a solution to what would otherwise be a grey area to me, and I thought FSF thought that too. Not sure they come down clearly on the one side. I know some of the Linux kernel people think that way too. Interesting.
- jboy55 13y ago
  The API headers are copyrighted, and any program that uses them is a derivative work. However, the license you accept in using the copyrighted work allows you to do so, with some conditions. Google chose to ignore those conditions. API headers being copyrightable protects a lot of GPL'd code too, this ruling protects FOSS as much as it hurts Java.
wil421 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        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."
johnpmayer 13y ago
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 13y ago
  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?
shmerl 13y ago
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 13y ago
  > 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.
namelezz 13y ago
When can Go be used for android development?
- AnimalMuppet 13y ago
  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.
- camus2 13y ago
  IMHO not going to happen. Google will probably pay royalties to Oracle at worst.But it just cant throw out of the window an entire ecosystem like that.It would be a terrible blow at android. Go is definetly not Java,dont have all the tools and ecosystem and libraries and i'm not sure how good Go is at GUI development.
suyash 13y ago
Congratulations to Oracle, it's about time justice needs to be served.
- thebeardisred 13y ago
  "There's no justice. There's just us."
bcantrill 13y ago
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/documentation/solaris11-2-whatsnew-2191087.pdf http://www.oracle.com/technetwork/server-storage/solaris11/d...
- fpgeek 13y ago
  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 13y ago
    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 13y ago
      May I ask why languages are different from APIs, since both are programming interfaces?
ausjke 13y ago
what does this mean to developers and users? what's the impact to android?
ChuckMcM 13y ago
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.
briantakita 13y ago
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.
Oletros 13y ago
The irony is that was not Google the ones that copied Sun's Java, they used Apache Harmony
mey 13y ago
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 13y ago
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).
curtis17 13y ago
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 13y ago
  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 13y ago
    Java is used in a great many places other than Android. Google most certainly did not kill Sun.
    - Shebanator 13y ago
      Cheap and good Linux servers did far more to kill Sun than anything anyone did w.r.t. Java.
    - bsdetector 13y ago
      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.
runn1ng 13y ago
Hm. I'm gonna check what Groklaw says to this.... ....wait. Oh.
Oletros 13y ago
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?
- as_someone 13y ago
  Sure, if Google were happy to comply with the GPL. But they're not.
- jboy55 13y ago
  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.
sehugg 13y ago
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.doc.html http://docs.oracle.com/javase/specs/jvms/se5.0/html/Preface....
- wmf 13y ago
  Snoracle said compatible clean-room implementations. Dalvik isn't fully compatible with the bloated parts of Java.
- SAI_Peregrinus 13y ago
  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.
josephlord 13y ago
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 13y ago
  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.
grellas 13y ago
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.
throwawaykf05 13y ago
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
drawkbox 13y ago
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.
fragmede 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      > Java language environemnt Java the language is not Java the platform
spacemanmatt 13y ago
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.
spacemanmatt 13y ago
Normally I'd hope to see Google appeal it to the Supreme Court. But not this Supreme Court.
saurik 13y ago
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.
xkarga00 13y ago
[...]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++"?
zmmmmm 13y ago
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 ...)
jijji 13y ago
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.
DonGateley 13y ago
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?

285 points by dctoedt 13y ago

I herby copyright: Object *(Object...); I'll take a check Oracle. Thanks.

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).

crashandburn4 13y ago

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

tssva 13y ago
For now the case has been sent back to the district court for it to determine fair use questions. The API is now considered copyrightable but Google's use of it may fall under fair use. The district court needs to decide this. Whatever the outcome expect either side to appeal which means any practical significance may be years away.
- msandford 13y ago
  The idea of an API being copyrightable is ridiculous. An API describes and interface between application code and system code. It describes the "shape" of the interface. So now Oracle has an (effectively) infinite length patent (it's technically a copyright which at this point is eternal as long as Disney keeps lobbying) on the shape of the Java API. Perfect.
fpgeek 13y ago
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-google-idUSBRE84M18K20120524 http://www.reuters.com/article/2012/05/24/net-us-oracle-goog...
- rayiner 13y ago
  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-judgment-fair-use https://www.eff.org/document/opinion-granting-summary-judgme.... 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.

afarrell 13y ago

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

adanto6840 13y ago
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/
cidico 13y ago
Bitch please... Come to meet Brazil :)

jahewson 13y ago

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 13y ago
> 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 13y ago
  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.

npinguy 13y ago

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.

xntrk 13y ago
It's not even just software patents though. Amazon just got some crazy patent on taking pictures on a totally white background which has been around forever..
- sergiotapia 13y ago
  They have a copyright on that? That's ridiculous. Everybody does that.
rayiner 13y ago
This is a copyright case. It's in front of the federal circuit because there were originally some patent claims, which invoked federal circuit jurisdiction, but none of those remain any longer. See Groklaw's Update #2: http://www.groklaw.net/articlebasic.php?story=20130213000119924 http://www.groklaw.net/articlebasic.php?story=20130213000119....
- smrtinsert 13y ago
  > Here's Atari Games v. Nintendo, so you can see what you think for yourself. But here's what I notice is not protected by copyright: > "Under the Act, society is free to exploit facts, ideas, processes, or methods of operation in a copyrighted work. To protect processes or methods of operation, a creator must look to patent laws." > It's there in black and white that methods of operation are not protected by copyright. So what is Oracle thinking? Seems pretty clear to me!
raverbashing 13y ago
Of course Software Patents are a great sell for developers with an inflated sense of self-importance (and their bosses) thinking that everything they created is wonderful and unique. Lawyers just played on that, and of course, they get their share of it

ChrisClark 13y ago

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 13y ago
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...

DannyBee 13y ago

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.

fpgeek 13y ago
And not just open source. Compatible re-implementations are a standard staple of proprietary software as well (arguably including, ironically, Oracle itself as a compatible implementation of IBM's SQL).
tosseraccount 13y ago
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 13y ago
  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.

cromwellian 13y ago

There's be no PC revolution if this ruling existed in the 80s. http://ckolderup.tumblr.com/post/48362660527/phoenix-technologies-cloning-the-ibm-pc-bios http://ckolderup.tumblr.com/post/48362660527/phoenix-technol... 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.

syntern 13y ago
Or, you can just move to a more reasonable region. I'm expecting more startups coming from the EU and Asia because of the difference in regulations. (And while they will be sued in the US and other places, they will have plenty of business opportunities elsewhere).
- cromwellian 13y ago
  That will work so long as no world-wide treaty synchronizes the shitty copyright/patent laws across nations.
  - undersuit 13y ago
    You'd have to do that in secret if you didn't want massive backlash.
  - cromwellian 13y ago
    You mean do it in secret like this? http://www.theverge.com/2013/11/13/5099236/wikileaks-publishes-leaked-draft-of-tpp http://www.theverge.com/2013/11/13/5099236/wikileaks-publish...
  - lern_too_spel 13y ago
    According to the Berne Convention, signatory countries must recognize the copyright of a work in its country of origin. I think that means US copyright law on Oracle's works apply in all 167 signatory countries, but maybe an IP lawyer will chime in to correct me.

mmorearty 13y ago

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

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

seacious 13y ago

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 13y ago

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

pmarin 13y ago
Unix != POSIX
- sixbrx 13y ago
  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.)

fidotron 13y ago

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 13y ago
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.

phkahler 13y ago

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 13y ago
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 13y ago
  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.
- phkahler 12y ago
  The existence of the LGPL has always seemed liked a solution to what would otherwise be a grey area to me, and I thought FSF thought that too. Not sure they come down clearly on the one side. I know some of the Linux kernel people think that way too. Interesting.
jboy55 13y ago
The API headers are copyrighted, and any program that uses them is a derivative work. However, the license you accept in using the copyrighted work allows you to do so, with some conditions. Google chose to ignore those conditions. API headers being copyrightable protects a lot of GPL'd code too, this ruling protects FOSS as much as it hurts Java.

wil421 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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."

johnpmayer 13y ago

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 13y ago
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?

shmerl 13y ago

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 13y ago
> 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.

namelezz 13y ago

When can Go be used for android development?

AnimalMuppet 13y ago
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.
camus2 13y ago
IMHO not going to happen. Google will probably pay royalties to Oracle at worst.But it just cant throw out of the window an entire ecosystem like that.It would be a terrible blow at android. Go is definetly not Java,dont have all the tools and ecosystem and libraries and i'm not sure how good Go is at GUI development.

suyash 13y ago

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

thebeardisred 13y ago
"There's no justice. There's just us."

bcantrill 13y ago

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/documentation/solaris11-2-whatsnew-2191087.pdf http://www.oracle.com/technetwork/server-storage/solaris11/d...

fpgeek 13y ago
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 13y ago
  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 13y ago
    May I ask why languages are different from APIs, since both are programming interfaces?

ausjke 13y ago

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

ChuckMcM 13y ago

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.

briantakita 13y ago

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.

Oletros 13y ago

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

mey 13y ago

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 13y ago

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).

curtis17 13y ago

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 13y ago
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 13y ago
  Java is used in a great many places other than Android. Google most certainly did not kill Sun.
  - Shebanator 13y ago
    Cheap and good Linux servers did far more to kill Sun than anything anyone did w.r.t. Java.
  - bsdetector 13y ago
    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.

runn1ng 13y ago

Hm. I'm gonna check what Groklaw says to this.... ....wait. Oh.

Oletros 13y ago

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?

as_someone 13y ago
Sure, if Google were happy to comply with the GPL. But they're not.
jboy55 13y ago
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.

sehugg 13y ago

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.doc.html http://docs.oracle.com/javase/specs/jvms/se5.0/html/Preface....

wmf 13y ago
Snoracle said compatible clean-room implementations. Dalvik isn't fully compatible with the bloated parts of Java.
SAI_Peregrinus 13y ago
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.

josephlord 13y ago

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 13y ago
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.

grellas 13y ago

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.

throwawaykf05 13y ago

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

drawkbox 13y ago

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.

fragmede 13y ago

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 13y ago
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 13y ago
  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 13y ago
    > Java language environemnt Java the language is not Java the platform

spacemanmatt 13y ago

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.

spacemanmatt 13y ago

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

saurik 13y ago

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.

xkarga00 13y ago

[...]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++"?

zmmmmm 13y ago

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 ...)

jijji 13y ago

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.

DonGateley 13y ago

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?