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), 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.
The decision (like some other Federal Circuit opinions) seems to reflect almost a natural-rights view of intellectual property, as opposed to Jefferson's utilitarian view.
Please indulge the following hyperbolic exaggeration to make a point: In the natural-rights view, the most important people to recognize and compensate are (supposedly) those who think up good ideas; other folks who deal with "mere" execution details are less deserving (again, supposedly) of status and financial reward.
One might call this the "think and grow rich" school of intellectual property. Or, from The Music Man, Professor Harold Hill's "Think System" of learning to play a musical instrument without actually practicing.
> natural-rights view of intellectual property [vs] Jefferson's utilitarian view.
I'm going to steal that one, though I may have a slightly different understanding of the dichotomy: the natural-rights view would focus on rewarding creative people, and the utilitarian view would focus on benefiting everyone.
The utilitarian view is obviously the correct one, but up until now, I didn't have the words to express it.
Just wanted to add that most modern believers in 'natural rights' that I've met, i.e libertarians and market anarchists, don't recognise intellectual property as real property. See for instance http://mises.org/journals/jls/15_2/15_2_1.pdf, a libertarian patent attorney writing on IP law.
> the utilitarian view would focus on benefiting everyone
That's the precisely the general tenor of the Jeffersonian view, according to a canonical Supreme Court opinion, Graham v. John Deere Co. of Kansas City, 383 U.S. 1 (1966), starting at page 7 of the opinion [1].
Here's an excerpt (with the Court's citations omitted and emphasis and extra paragraphing added):
<QUOTE>
Thomas Jefferson, who as Secretary of State was a member of the group [three Cabinet officials who served as what might be thought of as the first U.S. patent office], was its moving spirit and might well be called the "first administrator of our patent system." He was not only an administrator of the patent system under the 1790 Act, but was also the author of the 1793 Patent Act. In addition, Jefferson was himself an inventor of great note. His unpatented improvements on plows, to mention but one line of his inventions, won acclaim and recognition on both sides of the Atlantic.
Because of his active interest and influence in the early development of the patent system, Jefferson's views on the general nature of the limited patent monopoly under the Constitution, as well as his conclusions as to conditions for patentability under the statutory scheme, are worthy of note.
Jefferson, like other Americans, had an instinctive aversion to monopolies. ...
Jefferson's philosophy on the nature and purpose of the patent monopoly is expressed in a letter to Isaac McPherson ... He rejected a natural-rights theory in intellectual property rights and clearly recognized the social and economic rationale of the patent system.
The patent monopoly was not designed to secure to the inventor his natural right in his discoveries. Rather, it was a reward, an inducement, to bring forth new knowledge. The grant of an exclusive right to an invention was the creation of society—at odds with the inherent free nature of disclosed ideas—and was not to be freely given.
Only inventions and discoveries which furthered human knowledge, and were new and useful, justified the special inducement of a limited private monopoly.
Jefferson did not believe in granting patents for small details, obvious improvements, or frivolous devices. His writings evidence his insistence upon a high level of patentability.
As a member of the patent board for several years, Jefferson saw clearly the difficulty in "drawing a line between the things which are worth to the public the embarrassment of an exclusive patent, and those which are not." ...
I would argue that designing a good API is harder than making a good implementation of the API. The idea vs. execution juxtaposiion seems more apt to software patents that tend to express obvious ideas of low utility as ambiguously as possible.
Just because you create an elegant "search the Web" API, the hard work of actually crawling, indexing, and searching the Web still needs to occur. Your statement is only true for very simple applications.
Your example seems to prove just the opposite, i.e. only in trivial applications such as web search client API is the API design trivial compared to the implementation. In complex systems, such as programming languages, IDEs, operating systems and scalable search engines, good API design is paramount to managing complexity.
Just to note: This was not a ninth circuit decision, but a federal circuit one (you mention it being a ninth circuit panel, and appealable to the full ninth circuit).
Even though no patent issues were appealed, fed cir still has jurisdiction, and oracle used it to appeal to fed cir.
I don't think it ruled that just being original was enough to make an API copyrightable. It was more whether at the time the work was created, was there some element of reality (for example an existing standard) that dictated that a particular expression had to be used. It also focussed that this type analysis was to be focussed on the choices available to the author of the original work, not the choices available to the accused plagiarist.
This is in keeping with our existing notions of IP. It would preclude someone who wants to make a toy related to Mickey Mouse claiming that the only way to make such a toy would be to use the trademarked and copyrighted material of Disney.
Google probably based part of its decision on the huge existing body of code and tools developed by the Java community that depended on the existing API and VM, aided and encouraged by Sun (which included clean-room VM implementations).
Fair use exists so that fans of Mickey Mouse can put up websites about Mickey Mouse, write reviews of cartoons, etc. Disney benefits from this activity, just as Sun has benefited from all of its pre-2010 goodwill toward Java.
Right, but the problem for Google is that Judge Alsop ruled as a matter of Law that API is not copyrightable. So that mooted the defense for Google's actions under fair use. This seems like a major ruling. Now Google is going to have to go back to trial with a fair use defense as the outcome of that portion of the original trial did not provide enough factual basis for the appellate court to rule.
Hopefully this isn't precedential especially because some of the things that came out during trial that hurt Google had nothing to do with the copyrightability of API but had to do with intent.
For example, this was an internal email by Google's Android boss Andy Rubin in 2005:
"If Sun doesn't want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language - or - 2) Do Java anyway and defend our decision, perhaps making enemies along the way"
Intent and knowledge matters a lot in court decisions, so the above makes it seem that Google had full knowledge of the risk it was taking and still went along with it kicking the can down the road rather than officially license .NET or Java by paying Microsoft or Sun.
I reaslly wish they had gone with C#. That whould have been amazing. I wonder if MS would have even tried to start their own mobile platform if Android was already running .Net?
I wish they would have used C, which has much better support for being called from other languages, and then let different people write code in C# or Haskell or Brainfuck or whatever they want.
Can you elaborate a bit more on what parts of Alsup's decision the panel found issue with?
I remember Alsup used Sega v Accolade/Sony v Connectix from the Ninth circuit and Lotus v Borland from the First to justify his ruling. Did this panel decide that his line of reasoning was flawed/misapplied with regards to the previous fair use decisions (aka this isn't a case of fair use) or was this issue just out of his jurisdiction (which is what "it is for a jury to determine case-by-case" sounds like)? Or did they over turn the precedent that Alsup used?
Also, how does this ruling change the rest of the case? Does Oracle have a chance to restart the battle from square one or will they only be able to go to court for infringement on IP that Alsup had previously claimed uncopywritable?
The federal circuit found Alsup was confusing a ruling about fair use and copyright. It made clear the copyright must be established at the act of creating, not at the act of using. But some think it is a misinterpretation of the district court ruling.
> It made clear the copyright must be established at the act of creating, not at the act of using.
I don't see how that should change the result. An API is an API from the time it's created. It's inherently functional. You can't change a single argument or function name without changing the functional behavior of the API, which is as true the day it's created as the day someone wants to create a compatible reimplementation.
It seems to me like trying to claim a copyright over e.g. the shape of a toner cartridge for a printer because some creative process was used to generate the shape, even though it's the only shape that will fit in that printer, with the intent of using that to prevent anyone from making compatible toner cartridges for 95 years. That's clearly not what Congress had in mind when passing the Copyright Act.
How does this kind of thing jive with the law on recipes, which can't be copyrighted? Or do I have a layman's misunderstanding of what constitutes a recipe? I would have expected code to be treated much the same way recipes are. Can you generally copyright directions except for recipes? (Maybe on a related note, do/did libraries have to pay license fees for things like shelving according to the Dewey decimal system?)
A written description of a recipe (that you'd find in a cookbook, for example) can most certainly be copyrighted.
As I understand it, what can't be copyrighted is the proportions/ingredients/cooking methods. So if someone writes a new recipe that happens to describe the same dish that someone else's cookbook's recipe would have you make, that is not infringement. But if you copy the recipe from the cookbook, it is.
I am not a lawyer, but I believe you cannot even copyright the name of a dish in most cases (trademark is a separate matter). So if you consider the names of dishes to be analogous to function names, function names should not fall under copyright in most cases.
That was essentially one of the points made by the District Court. The Appellate Court's response is in the "short phrases" part of the opinion. It basically says: while you can't copyright short phrases, you can copyright a larger corpus made up of short phrases (i.e. the whole API).
The federal circuit ruled that an API is a "creative" work and thus is copyrightable. But is it really creative? It is an interface and made according some rules, not some sort of art... I must point out I have read the 28 pages ruling.
Im no lawyer, but an API is the most creative part of an entire developer ecosystem to my mind. not the implementation. What made Cocoa so joyful to work with while years of previous Java and MS coding were dissonant painful experiences? All of them manage to get a button on the screen, respond to user input, etc. The naming and organization of different features in a clear and developer friendly way is entirely the API spec.
Whether you should be able to protect such a creation from copying is an issue for society to choose. So far it has chosen poorly.
> The federal circuit ruled that an API is a "creative" work and thus is copyrightable. But is it really creative?
I don't think that argument is a winner. Take any man-made thing, you can find some creativity that went into designing it. And that's the point -- creativity is not the sole determinant of copyrightability. What would be the purpose of the Patent Act if you could get 95 years of copyright protection just by describing invention as a creative process? Drug companies use creativity when creating cures for diseases. Should the formula or process of manufacturing for the Polio vaccine have to be licensed to this day under copyright?
Just read any given thread here about a language or a library. People argue the aesthetics of them, therefore they're a work with some creative/artistic element.
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...
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).
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).
To whoever downmodded the parent: I'm pretty sure it was sarcasm. That is, I'm pretty sure when he says "it has to do with the way you squint and look at it", he's saying that there really is not much difference.
I felt that that particular piece of sarcasm added more to the conversation than a simple statement of my agreement, which is distinct from an upvote, however, I was also unaware of this general policy/behavior of the forum as it is mentioned in neither the FAQ nor the guidelines. Thanks for the heads up.
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.
I think there are at least a couple of rays of hope:
1) This isn't binding precedent nationwide, like a patent ruling would be, and most copyright cases aren't going to end up in the Federal Circuit. The other Courts of Appeal will have their say in deciding the issue, and with any luck a circuit split could result in Supreme Court review. In particular, I'm not sure they're going to buy the Federal Circuit's merger doctrine analysis.
2) The court repeatedly mentioned that Google copied 7,000 lines of declarations verbatim. I wonder how many gaps are in the reasoning of this case to stick a knife through in cases where there wasn't such literal copying.
I think you misread it (so i updated the original comment).
I meant that open source projects that reuse API declarations or parts aren't typing them themselves, they are copying those API declarations verbatim from somewhere.
Ray's point what if they didn't copy, it may not be an issue, but they all do copy.
Here's a related but not exact example of what typically happens that i actually happened to have open in another window:
Person A reads the declarations and writes down what they do, without mentioning any function names or argument names.
"This function returns the index of a character in a string."
Person B takes person A's work and writes
int findIndexOf(String s, char c);
A team then writes all the functions to do what Person B wrote up.
Now, at this point, what you have is something functionally the same as Java's String object. Do this for all classes. Call this bundle something like AlterJava. (Or YerksDiddy if you really worry about the name.)
Then someone writes a tool that translates Java into AlterJava. It's an easy thing to put into the compiler chain.
I'm skeptical of these "just hop through this hoop and you aren't breaking the law" ideas when other people make them, so feel free to tell me I'm missing something.
I was thinking of exactly this, and I'd love to hear an explanation of why it wouldn't work. I think Oracle's win here is pretty "thin" in that regard. You could attack the translation tool, but it's just a directory mapping Java names to AlterJava names. What those Java names happen to be called are, under Feist Publications v. Rural Telephone Service Co., uncopyrightable facts.
> I wonder if you could clean-room most of this. ...
This was much discussed in the early days of the PC; if memory serves, it's basically the approach that was taken by the first successful cloner of the IBM PC BIOS [1].
Leaving aside that GQL is a language, and thus not copyrightable according to this decision, this is licensed use! (AFAICT, GQL is Apache licensed). Google intentionally chose not to comply with the OpenJDK license, and claimed that the APIs aren't copyrightable, and therefore not covered by the license anyway.
Do you have examples of FOSS projects copying code while not abiding by the license?
Again, I really think you're taking this out of proportion. This decision does not affect you if your implementing an API in accordance with the license.
Some people keep saying that this decision is bad for FOSS, but they can't come up with examples of FOSS that will be affected (there are probably a few projects, but nothing that will shake up the industry).
It's "Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License,"
Given they haven't complied with the license (no citation, no attribution), calling this a "licensed use" is quite a stretch. It's actually pretty clearly not a licensed use.
"This decision does not affect you if your implementing an API in accordance with the license."
Which open source projects rarely do ...
Really, do you think the TOS of most of these websites or software allow you to make your own implementations?
Are most of them who do get "licenses" being careful about actually following license requirements?
Every major open-source project complies, or tries to comply with licenses. Tiny projects don't matter because no one will sue them (and no one uses them anyway). Even if a completely imaginary scenario takes place, all they'll need to do to comply is add attribution, or something in the same vein. There's no earthquake coming.
As to copyrighting a language:
The appeals court makes a clear distinction between the Java programming language (i.e., the commands/keywords that are free for everyone to use) and the APIs, and finds that only three of the Java APIs in question are basically part of the Java language, but "Google could have written its own API packages using the Java languages", which, as the opinion notes, "Google chose not to do".
We'll strongly disagree as to where this decision will lead. Thankfully, I know i'm not the only one worried.
Also, fosspatents is not a legal decision, nor did you actually cite anything that backs up your claim:
Your claim was the decision says the language was not copyrightable. It says no such thing.
What it says is "It is undisputed that the Java programming language is open and free for anyone to use."
This is because it was licensed, not because it is uncopyrightable.
fosspatents is run by a (paid) Microsoft shill. He calls himself an IP pundit or something. Groklaw basically outed him before he owned up to being on Microsoft's payroll publicly.
He is loyal to his employer but his analysis and projections are often contradicted by facts.
That project doesn't clone an API. It uses one. It might be violating TOS, but not copyright.
I didn't know about the Katzer case, but I still see no danger to the FOSS community and ecosystem by the new ruling. All it would do is require developers to clearly specify the license for their APIs. Cloning of proprietary APIs is most certainly not a cornerstone of FOSS today (unless, that is, Linux is in actual danger, in which case I'll change my position).
"Cloning of proprietary APIs is most certainly not a cornerstone of FOSS today (unless, that is, Linux is in actual danger, in which case I'll change my position)."
> Open source projects that reuse API declarations or parts aren't typing them themselves.
And even if they were, if the originals were copyrightable, there's no copyright-relevant difference between "typing them themselves" and "copy and pasting", both are verbatim copying (and, even not doing a verbatim copy and merely doing a "derivative work" based on the existing API would be -- barring fair use or other explicit exception -- a violation of copyright if the API, as such, was copyrightable.)
The reason I bring up the difference between verbatim copying and "typing things in themselves" is because I think the Federal Circuit was myopic in how it applied the merger doctrine, and I think the District Court got it right. The merger doctrine basically says that an expression is not copyrightable if the expression is inextricably merged with the idea.
So I'm imagining a bunch of Java classes loaded into memory. They're objects, and they have methods, and those methods refer to methods in other objects. Creating this state of memory is functional, and definitely not protect-able. Now, the interface declarations, then, are just a description of this state of memory. A method has a particular name or a particular set of parameters but those are just a description of the functionality, and there is no other way to precisely describe that state of affairs. The closest analogue I can think of to an API is a phone book, and the names and addresses in a phone book are not copyrightable, although higher-level structure might be.
I think the court got stuck on the verbatim copying and that prevented them from seeing things this way.
Depending on the languages involved in both the original declaration and the implementation, its quite possible for an API reimplementation to include a derived work rather than a verbatim copy of the original API declaration (and obviously, it wouldn't be a reimplementation if it was just a verbatim copy of the original API implementation.)
Though both making verbatim copies and making derived works are exclusive rights of copyright owners so that doesn't really reduce the impact of API copyrightability on API reimplementations,
> And what is copied verbatim are just the headers
If you are using different languages that compile to a compatible target, or if you are using the same language that admits different literal declarations expressions that produce the same interface, it is possible to have an API reimplementation -- for the same target platform even -- that does not involve verbatim copying of even the headers/declarations.
It's possible in some languages, but it often involves serious messing around.
For example, in C, this would involve function name aliasing which is usually a compiler specific extension.
This might give you name compatibility, but to get struct-level compatibility, you'd have to copy the exact layouts due to padding issues.
In C++ it's even harder, due to when vtables are emitted, etc.
My java knowledge is old (java 5), so i don't know if they made it possible.
Objective-C, I believe it would only be possible if you used the runtime reflection methods directly. I don't think you can easily do it with just headers (corrections welcome!)
etc
If you're implementing an API, you don't need a license... (or at least you shouldn't). You are implementing something based upon given facts, which can't be copyrighted. Google thought that didn't need a license in the first place.
And that's the crux of this case... is an API copyrightable?
Samba and Mono, just to name a few, are pretty big-name open source projects that implement APIs without consent of the creator of those APIs. And even the Linux kernel uses the same system call API as AT&T Unix...
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.
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.
Mac OS X is SUS v3 certified (I don't think iOS is) and can call itself UNIX, and there is 0 danger of anyone suing you for implementing POSIX API or SUS. You just can not claim you are providing a UNIX without getting certified. This is why Linux is UNIX-like OS and not a UNIX.
You're confusing Trademark with Copyright. The Open Group owns the Unix trademark, it does not own the API. The fact that POSIX uses the API does not mean any claims to "structure, sequence, organization" of the APIs or command line utilities are invalid.
This has never been litigated before. Past UNIX copyright wars were fought over copying actual code between Unix and clones. No one has ever tested whether API reimplementation of Unix is copyrighted. Implementing as public spec won't save you. Java has a public, open, specification and was clean-room reimplemented in much the same way that Linux is not Unix, Android Java is not Java.
Claiming there is 0 danger in being sued sounds like naively wishful thinking, especially with Apple's deep pockets, there are plenty of lawyers out there looking for ways to crack that nut.
The Open Group own both the UNIX trademark and the POSIX spec. They used to demand a lot of money for copies of the spec, but you can get it online for free nowadays ( https://www2.opengroup.org/ogsys/catalog/G101 is a good place to start). They put copyright notices on the spec, but (at least until this ruling) that was widely believed to only apply to the description of what functions needed to do, and not to the function declarations.
Is it clear that The Open Group or IEEE actually have a clear right to claim copyright of the POSIX api given this ruling? Were they assigned or licensed that copyright by AT&T or any of its successors? It seems likely enough that in the 80s this was not seen as necessary, and the old guard of UNIX implementers were still being quite belligerent towards each other at the time, afaik.
IIRC, one of Oracle's points of contention is that Google is intentionally not being compatible with Java; they picked certain parts of the API they wanted to support, but it's not a full implementation of the Java APIs, and so conforming Java apps are not necessarily able to run.
The full Java spec includes tons of Desktop code for Desktop Widgets, CORBA APIs, and all kinds of insane stuff that makes no sense on a smart phone and isn't used by 90% of Java developers who mostly work on the server side.
Oracle's claims here are rather ridiculous, and even Oracle doesn't believe Swing or J2ME apps are appropriate for today's smartphones. It's a red herring of compatibility that no one cares about or wants to be compatible with.
A lot of the discussion in this thread is about what this sort of ruling means for people making compatible implementations of other people's APIs -- Unix, the PC BIOS, etc. But that's not what Google was intending to do here, they were using part of Oracle's Java tech to build their own, incompatible application format.
They're using Java "The Good Parts", the subset of Java that is platform neutral that most people use. By the time Android was launched, Java on the Desktop was already dead. Practically zero people write Java desktop apps not care about compatibility with them, the vast majority of Java code prior to Android lived in the cloud.
What makes Java valuable to most developers is byte-code portability, the widespread use of the language, the core APIs (not the GUI), and the developer tool chain.
The Sun licenses for Java go back to a time when they had a dream to displace Windows on the Desktop with all native desktop apps written in Java. That reality was delusional, but Java succeeded brilliantly on the server.
I don't know why you think this is relevant to the sort of precedent this sets legally. Oracle claims it is suing Google for making a deliberately incompatible set of libraries using their copyrighted material. The fact that Google's use of the APIs is deliberately incompatible is means that a ruling against Google is not necessarily a precedent that can be used against others who attempt to build compatible clean-room implementations of other systems, and that's just as true if you think that Google's lack of compatibility with Java SE was a good technical decision.
Most clones are incompatible in some way. WINE is not100% compatible with Windows, Linux is not compatible with AT&T Unix (ever looked at "cross platform" Unix source?)
My personal opinion is not about what is legal, but what I think is ethical and justified. The current system is broken and needs to be reformed.
You seem to want to defend the status quo. That's your prerogative, I think you're advocating for a world that makes everyone worse off, but we can agree to disagree.
Well, let's talk about WINE for a second. What I said wasn't "incompatible," it was "deliberately incompatible." WINE attempts to duplicate the Win32 APIs as they are implemented in various versions of Microsoft Windows. The entire point of WINE is to be interoperable, in order to allow programs that run on Windows to also run elsewhere. WINE may sometimes fail at this (man's reach must ever exceed his grasp, else what's a heaven for?), but it is certainly TRYING to be compatible. By the same token, the reason that Linux implements various APIs present in UNIX is so that it is compatible with software written for UNIX (or more accurately, to make software more portable between various types of UNIX and various types of Linux).
Google's use of the Java APIs is different; Google intentionally makes it so that Java applications do not run on Android and Android applications do not run on Sun's JVM. Google is not trying to implement those APIs for the purpose of interoperability. A finding that Google's appropriation of those APIs for their own runtime environment is not fair use is not a finding that WINE's use of Windows APIs in order to enable interoperability is not fair use. What's at stake here is more narrow than what several posters have surmised. You can argue that what's at stake here is still important, which is a discussion worth having, but posts in this thread about (for instance) how the PC compatible market wouldn't be allowed to exist under this ruling are mistaken.
Does the law make a distinction between copyright infringement based on unintentional incompatibility vs intentional incompatibility? I don't see it.
And why would it not be copyright infringement to implement a full API, but is copyright infringement to implement a subset of one?
When Phoenix cloned the PC bios, they did it on the assumption that if they reverse engineered the complete API specification, and then had a separate group of engineers perform the implementation, there would be no infringement, because no one in the history of computer science thought API interfaces could be copyrightable.
IBM was powerless to stop them, and clones flourished. With this precedent, would Phoenix have attempted the clone? Would IBM have not sued over copyright infringement of their interface?
Pretty much all clean room implementations since then have proceeded on the basis that implementing someone else's API, even against their wishes, is not an infringement. It's been the default assumption for decades.
To act like this Court decision has not flipped over decades of practice is putting way too much trust in the companies out there to show restraint and not unleash a tidal wave of copyright suits.
I don't think the deliberate making of Android incompatible with Java had much bearing in this case. Oracle might not have liked it, but it wasn't part of their claims, I don't think. It was discussed as part of the context for Google's choices.
> Except that iOS is based on Unix, and the freedom to re-implement copyrighted Unix APIs was litigated and won.
Not quite. The freedom to re-implement Unix APIs was litigated. If I recall correctly, it was settled rather than won (that is, there was not a court decision but rather a settlement agreement).
Thousands of companies "bet the jewels" on Java and will be making the same bet for the foreseeable future, for better or worse.
Blanket statements like "ObjC is 2x faster than Java" is... well, a blanket statement, and in general, wrong. It depends so much on what, precisely, you're doing, how you're doing it, the compiler and JIT implementation, etc.
The reason for using Java is the corporate penetration and being the de-facto language for thousands of developers. I seriously think that Java as a language is old and hard to use (hello Clojure & Scala) and on the top of that owned Oracle is the biggest patent troll in the history of humanity, so even implementing the APIs can lead to lawsuits just like the example above.
Now the only question is, why the hell do we still implement new things in Java in 2014? Time to wake up, get a language that is free by every meaning free has and bury Java for good. Is this hard? Definitely is, but if we don't start it today when can we stop Oracle from suing your startups because you implemented an API. Changing US law seems harder. :)
Go has about 0.0001% of the third party library base that Java does. Many of which are essential for large scale enterprise development. It's why languages like Clojure and Scala have become a lot more popular because they leverage the ecosystem.
No one will move just because of some insignificant lawsuit.
You are talking about a stall picture, a moment in time, thinking this will last forever. I am talking about how fast that 0.0001% becomes 50%. If Oracle is patent trolling the Java developer communities the developers and other enterprises are not going to take it easy. We are talking about Google not some random 3 people startup that pays whatever the patent owner is asking for just to save a lawsuit. Java is the the most resourceful ecosystem today, there is no doubt about that. It is ~20 years old Go is 5, and please have a look to this chart:
Well yes there is obviously some clean up work on that side, naming Go as go is a bit unfortunate. I guess my original idea still stands, it is not very smart to judge programming languages using their current popularity. This picture can and will change. You can dig up better evidence than that indeed url.
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).
On the other hand, there are at least a few instances of BSD licensed alternatives to GPL licensed software; can GNU sue people who use those for copyright infringement?
If someone made a BSD clone of your GPL software, then a bunch of companies took that BSD clone and built products off of it, keeping their modifications private. You'd bet the GNU people would help you sue.
I wonder how this affects the Microsoft Open Specifications Promise (which covers the specs pertaining to Office Document file formats) -- it would be unfortunate if Microsoft decided to reverse course and break their promise
The issue at hand was that Oracle specified that any implementation using their Specifications license be compatible, and the Dalvik implementation is not compatible.
So it isn't that Oracle is going back on their word, it is that Google did not follow the rules of the license.
What determines that approach? The way judge decides to do it in each case?
In this case however the biggest damage is that they reversed the ruling that APIs aren't copyrightable. Is there any way that Google can reappeal it in a higher court, or it's a final decision? In Europe APIs were ruled uncopyrightable some time ago, but somehow this didn't help in this case.
Google could request rehearing en-banc (IE in front of the whole federal circuit).
If that succeeded, the decision would be vacated until the en-banc rehearing.
Whether that happens or not, they can also appeal it to the supreme court.
Suffice to say, my completely personal view is that it was appealed to this very court for a reason. Normally, this is the court that hears all patent appeals. Because the original lawsuit involved patent claims, they have jurisdiction, even though there are no patent claims being appealed.
Otherwise, it would have gone to the 9th circuit, who, i suspect, would have been more favorable.
> What determines that approach? The way judge decides to do it in each case?
A fair use defense means that something happened that would otherwise create liability, but doesn't because of some (often policy) reason. Making something an affirmative defense has procedural implications. But "rights" can be implemented as affirmative defenses. For example, truth is an affirmative defense to defamation in the U.S., even though it's closely connected with free speech rights.
EDIT: But see dragonwriter's very pertinent comment about defamation cases involving matters of public concern, where falsity is an element of the claim rather than an affirmative defense.
The practical distinction is that it's easier to dispose of cases on a motion to dismiss when something is a required element of the claim versus when it is an affirmative defense.
> For example, truth is an affirmative defense to defamation in the U.S., even though it's closely connected with free speech rights.
This is wrong, at least on matters of public concern, specifically because it is connected to free speech rights, both for public figures and private figures as plaintiffs, who bear the burden of showing falsity rather than the defendant having the burden of showing truth.
See Philadelphia Newspapers v. Hepps, 475 U.S. 767 (1986); New York Times v. Sullivan, 376 U. S. 254 (1964).
First, I don't think the court ruled infringement -- only copyrightability.
Second, not too many open source projects implement proprietary APIs. FOSS today does not get its value from producing fully compatible clones of proprietary software.
Third, proprietary software vendors will face the choice of limiting the use of their APIs (i.e. copying) by OSS and risk reduced adoption, or allow it to get wide adoption and offer a superior implementation. I'm not sure most would choose the former.
So with the state of FOSS today, I don't see how such a decision changes much. I would very much like to hear if people have counterexamples (other than WINE).
Am I reading this wrong or what's missing?
"Because we conclude that the declaring code and the
structure, sequence, and organization of the API packages
are entitled to copyright protection, we reverse the district
court’s copyrightability determination with instructions to
reinstate the jury’s infringement finding as to the 37 Java
packages. Because the jury deadlocked on fair use, we
remand for further consideration of Google’s fair use
defense in light of this decision. With respect to Google’s
cross-appeal, we affirm the district court’s decisions:
(1) granting Oracle’s motion for JMOL as to the eight
decompiled Java files that Google copied into Android;
and (2) denying Google’s motion for JMOL with respect to
the rangeCheck function. Accordingly, we affirm-in-part,
reverse-in-part, and remand for further proceedings."
Good for the gpl does not mean good for open source. This decision immediately and directly harms software development as an industry, because it means that api interoperability now puts you on the hook for infringement.
The gpl exists to promote the creation of open source software, not to keep people from using open source. Just because this makes it more enforceable in no way makes this good for open source.
This is really great for open source. When I write some code and license it as open source, I want to be given attribution, including by closed source companies that 'copy' the open source.
People are having trouble groking that not good for Google doesn't mean not good for Open Source. Strong Copyright is the backbone of the GPL, without it, the GPL's perpetual open concept is meaningless.
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
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.
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.
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).
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.
No need to get hysterical. BIOS is not the same as a software API, and copyright is not the same as patents. I think software patents are terrible, but I definitely want software to be copyrighted. Regarding the copyrightability of APIs, I don't think either ruling has much of an effect in today's ecosystem.
If not BIOS, consider the operating systems themselves.
If AT&T had strong copyright claims on the "APIs" that make up the system calls of UNIX, for example there goes Linux (and essentially the entire GNU and BSD projects as well), there goes modern MacOS, etc, and the reverberations would be enormous even with fully closed sourced OSes like Windows... With strong copyright on APIs there, essentially, goes the Internet as we know it when there isn't a clear path of UNIX->BSD/POSIX->sockets for everyone to copy (and thus be interoperable with each other).
And even if we shift the strong copyright event later into the 90s then consider the modern web, if Netscape (which at one point was a very different entity than today's Mozilla in terms of openness) had a strong copyright on the definition of JavaScript's APIs? Or if nobody dared implement their own XMLHttpRequest for fear of Microsoft's API copyright?
This is something developers (and anyone who cares about technology, really) should absolutely be hysterical about.
Unless the reason those technologies spread is precisely because no one had strong claims, or no one chose to pursue protection. If Netscape had chosen to make JS proprietary, JS wouldn't have become a de-facto standard.
I am not aware of any significant proprietary API today that is in widespread use, and is cloned by FOSS. But I could be wrong on that. If you know of such APIs, I'd love to know which ones are in danger.
That's not really true, things can become de-facto standards even if they're proprietary, especially if the actual status is in doubt. Many developers don't think about the long term consequences of licenses when they start using stuff, especially if it is useful and free of charge.
Linux is a perfect example of a proprietary API (Unix) which is in very widespread use, which was cloned by FOSS. Most of the Unix command line utilities were explicitly cloned by the FSF to be compatible with existing shell scripts on Unix.
Adobe made Flash proprietary and it became incredibly widespread, so widespread that if you turned if off, many websites would break, despite the fact that it had numerous performance and security issues. Flash made it to something like 97% penetration of all Web clients (prior to Apple iPhone) People have cloned Flash (hAXE for example), but there was really no reason to do it, because Adobe offered the player free of charge.
WINE is in widespread use. Samba is in widespread use. Lots of Website REST APIs have been cloned.
Adobe PDF was proprietary and widespread cloned until in 2008 it became an open standard.
Cloning APIs is a time honored tradition for "embrace and extend". Microsoft even cloned proprietary APIs, and DOS itself started out as an unauthorized clone of CP/M. Where would Bill Gates be today without Seattle Softworks?
I hate having to resort to the tired ole idea of rich people having gotten rich by theft, but in many cases, it's quite true, that Gates and Jobs both freely copied, cloned, and modified other people's stuff, got stupendously wealthy off of it, but somehow, it's wrong for us to want to practice their methods?
What happened in the past is irrelevant, because after this ruling, it probably won't happen again. The freedom to clone proprietary APIs is not essential to FOSS any more, because the FOSS ecosystem has become powerful on its own. Either proprietary vendors choose to license their APIs to FOSS, or risk being replaced by an incompatible FOSS implementation.
My question was about how the current ecosystem will be disrupted. Now, with WINE -- I agree, but I don't think it's in widespread use, and I don't think Microsoft will go after them. AFAIK, Samba implements a networking protocol, not an API (but I may be mistaken).
It really all comes down to Linux. If Linux is in danger, then obviously the ecosystem can be disrupted by this ruling; if not -- then probably not. I must say I don't know enough about the current legal status of Linux, and whether or not it's in real danger.
In other words, "I got mine". People who profited and got stupendously rich, get off scott free, and are free to deploy lawyers to interfere with the next wave of participants. Not unlike immigrants who settle in, and then want to slam the door on the next group of immigrants.
>Samba implements a networking protocol, not an API
Protocols and APIs are another distinction without a different. If the sequence, structure, and organization of an API can be copyrighted, then surely, the sequence, structure, and organization of a wire protocol or file format can, after all, the only real different is the invocation mechanism.
> If the sequence, structure, and organization of an API can be copyrighted, then surely, the sequence, structure, and organization of a wire protocol or file format can, after all, the only real different is the invocation mechanism.
While it might be easy to analogize between an API and a wire protocol in terms of technology, that doesn't mean that analogy holds within the framework of copyright law. The Fed. Cir. opinion was expressly couched in terms of the "sequence, structure, and organization" of the names in the API. Indeed, the opinion concedes that if Google had chosen different names, then things would be fine. Putting the same bytes at the same offsets is not at all the same as naming things the same way.
Yeah but doesn't the distinction become way less clear when talking about protocols that aren't traditional fixed-structure binary protocols?
We live in a world of protocols that are increasingly RPC/REST based which as others have mentioned are really just APIs you happen to access over a network connection.
Amazon releases the client side of their API as open source. And none of their server-side code is available at all, so Eucalyptus is obviously not based on that. Seems different.
Again I direct you towards all of the APIs that make up a UNIX-compatible system, which by the logic of this ruling is an API definition whose copyright is currently mostly owned by Novell (since they own the old AT&T rights) and yet is largely cloned in Linux, all the various BSDs, MacOS/Darwin, Android, etc, etc, etc.
In a lot of ways the situation being defined by this ruling is way worse than patents given that copyright is essentially infinite these days (pseudo-time-limited, but constantly being extended due to the lobbying efforts of Disney, et al) whereas at least patents, as harmful as they are to overall software industry progress, run out after a couple of decades.
Since "proprietary API" is a concept invented somewhen about today, by this court decision, of course you know none.
NFS is a corporative API developed by SUN, LDAP and Kerberos were also created by a corportaion (IBM), UNIX is a set of APIs created by Bell Labs, just like C.
I'm talking about patent or copyright of abstractions, ideas, not implementations. I'm not wholly opposed to protections for copying someone's binary or source, although I can see arguments to made even for not having that (non-rivalry).
Don't get me wrong, I don't really like this decision either, because I think it doesn't serve the economic purpose of copyright (preventing free-riding). But I wouldn't like a world where I couldn't sell software, and frankly I'm not a huge fan of what the software world has become now, where in order to make any money off software you have to give it away and then figure out how to "monetize your users," or hide the real software behind a web server and sell it as a service.
>... because I think it doesn't serve the economic purpose of copyright (preventing free-riding).
Au contraire, I think it clearly solves the economic problem of free-riding in this particular case. Consider:
1) Sun (and now by proxy, Oracle) made a huge investment in engineering to make Java, and a big part of its success was a API for the standard lib that maintained a coherence across disparate domains ranging from file systems to networking to databases to cryptography to UIs.
2) Sun made an even more massive investment in marketing to make Java as prevalent as it is today. Without marketing a language goes nowhere, and yet Java is ubiquitous. Along with 1), this represents a massive economic investment.
3) Google had no inclination of investing its own time, money and resources to build its own ecosystem and build developer mindshare for it, not when it was trying to compete with the iPhone and wanted warm bodies to build apps for their platform. To make it worse, Google's engineers and executives knew that a) they had no better alternatives and would require a license (google "Lindholm email"), and b) that they were not going to be complying with Sun's terms (Ctrl-F "Rubin" on this page). Yet they went ahead and re-used Java for their purposes without permission or recompense to Sun.
I don't see how that's not "economic free-riding" in the most literal sense.
The BIOS is definitely a software API, as it is an item of software which has a carefully defined set of interfaces for the OS to call: http://www.ctyme.com/intr/cat-003.
In fact the only thing the clean room reimplementations of the IBM PC BIOS had in common with the original was exposing the same API.
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.
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).
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.
This is about copyright, not patents. Even the biggest opponents of software patents support copyright. If there's no copyright, anyone can take your software and just make it their own.
Not really. The modern generation of web developers don't sell software, they sell eyeballs. So they don't really care about copyright. But trademark, that's important! No advertising dollars without trademark! /cynic
Not that they aren't laughable and shouldn't go away. Likewise the black robes IMHOP.
The point is... we likely are going to be stuck with bad cultural remnants for a long long time which is why it is so important to get it right the first time. This ruling is a bad deal but Google certainly has the resources to fight further and I bet they do. Hopefully they scrap Java in the end.
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
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=20130213000119....
> 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?
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..
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 ...)
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.
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).
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...
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.
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.
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?)
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.
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.)
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.
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.
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.
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.
Obviously, non-copyrightability is the best possible outcome, because then such cases wouldn't even be worth bringing. But the opposite holding doesn't necessarily mean every such case has to go to a jury trial. If the facts are such that no possible jury could find in favor of one party, a fair use question may be disposed of on summary judgment: https://www.eff.org/document/opinion-granting-summary-judgme....
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. 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.
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.
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.
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!
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.
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.
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.
[...]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++"?
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.
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?
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.
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.
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.
1. Those programs aren't distributing the material in question. You, the user, will have independently acquired the JRE. This will have most likely been through non-infringing means, given that Sun/Oracle lets you have it for free, and even if it were infringing, you'd be the one at fault, not the program author.
2. Even if that weren't true, there would still be a couple of options to create a non-infringing program. Only programs that are neither non-GPL, nor those from authors who have some other valid commercial license would be infringing. Not "every Java program".
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.
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?
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.
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.
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.
A fully-interoperable Java on smartphones IMHO would be a market failure out of the gate. The OpenJDK/JDK was designed for desktop environments, most of the APIs left how have no applicability to mobile. To include them would needlessly bloat an already slow Java platform on mobile. These devices are extremely constrained by memory and battery.
So, you can either have Java on 800 million devices where the APIs are subsetted and retargeted towards modern smartphones, or you can have a hopelessly bloated, too-many-cooks-in-the-kitchen JDK on devices no one wants to use, but they, they'd be capable of running Java apps from the 90s.
This is like saying, I won't let you subset the Win32 APIs unless you guarantee that DOS 3.0 apps will still run.
Right: as I said, I think Google needs to make a point that compatibility with libraries, even though "apps" are not compatible; apparently they didn't.
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
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?
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.
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.
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.
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."
"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.
> I'd like to see cogent arguments as to why copyright as it currently exists should apply to all other code but not API.
For the same reason a textbook publisher shouldn't be able to copyright the table of contents of a calculus textbook:
1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text.
2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard.
For example: imagine an API for accessing student information. You have certain common characteristics for those students: Name, Address, Contacts, Schedule, Grades, Absences etc. I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another. And if showed a person who had studied the different APIs some specific part of a particular API they wouldn't be able to tell you which one it came from. They would not differ enough in 'style' to be readily distinguishable.
Now imagine Strings. Or authentication or routes or any number of other aspects of computing that we have to deal with every day.
Now, can the same thing be said of ten different authors of say a writing prompt that says "Write about a student who is having an altercation with a gym coach"?
I'd argue that you'd get some very different and and easily distinguishable stories and styles.
> 1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text.
As anyone who has designed enough APIs will tell you (including engineers testifying on Google's behalf during the trial, and many commenters here who disagree with the decision), an API often requires more creativity than the implementation. Sure, the implementation is also difficult to do well, but making that implementation usable by others is no less a creative task. The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs. For a well designed API it's always the other way around. With enough creativity and forethought put into an API, the implementation flows naturally, and in practice, it's exactly the opposite of the table of contents analogy.
(Not to mention that a ToC may also be copyrightable.)
> 2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard.
The "nature of information being organized" sounds like "functionality" to me. As before, it is distinct from expression.
> I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another.
Consider the corollary of your argument. If you asked those same people to write actual implementations for that same problem. I'd bet you get the same "80% or more would be so close" results. Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case.
Unless you provide a detailed spec and enforce some conventions, I'm willing to bet nobody will have an exact duplicate of another, either for implementation or for API. An API for the same functionality, say for getting the number of absentees, may be labeled getAbsenteeCount() or nAbsentees() or NumNotPresent(). Or even absenteeList().length(). Or a poorly defined API may require something like classSize() - numPresent(). Or a really badly defined API would require iterating over each member of the class and checking the "present" flag. And that is the point: each expression of the same functionality can be unique, and hence a candidate for copyright.
>an API often requires more creativity than the implementation. Sure, the implementation is also difficult to do well, but making that implementation usable by others is no less a creative task.
"Difficult to do well" and "creativity" does not equal "copyrightable". Mathematical proofs are hard to do well and require creativity but are not copyrightable.
If the form is necessary for practical application, it belongs to the public.
>The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs.
You generally don't start writing prose before you have the overall structure fleshed out, either.
>Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case.
Perhaps you are right. Copyright may be the wrong tool for code. Patents may be the wrong tool for code. It may be time to set aside these grossly imperfect abstractions that were built for wildly different purposes hundreds of years before programming was conceived and think through something that fits this type of intellectual property better.
> "Difficult to do well" and "creativity" does not equal "copyrightable".
But how you express it is covered by copyright. A mathematical proof is not, but if you write it out so that it rhymes, that specific expression is. You can now state the same proof a thousand different ways, even those that rhyme differently. But all those original those of the same proof remain protected.
I would tend to agree that copyright and patents are probably not a good fit for protecting software, and maybe a new framework is needed. But given the current means at hand, this decision is internally consistent.
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.