A reminder that what the law says, and what is a good idea, is not necessarily the same thing. The courts rule on the first point. Given that Oracle has prevailed in court on this before, one has to at least entertain the possibility that our law really allows for API to be copyrighted.
But if so, that law desperately needs to be amended - the nature of APIs, at least public ones, is such that interoperability concerns override everything else, IMO. If companies can copyright an API and block competitors from implementing it, that would be very detrimental to the industry as a whole, for the sake of a few rent seekers profiting.
>If companies can copyright an API and block competitors from implementing it, that would be very detrimental to the industry as a whole, for the sake of a few rent seekers profiting.
The practice of writing drop-in replacements for software products is as old as the software industry, even those replacements that diminish the original product's commercial value. E.g gnu/linux vs proprietary unix.
Writing drop-in replacements may very well fall under fair use and be allowed, but this is not what happened in this particular case the court ruled on:
> It was not ... intended to permit third party interoperability, since Google had made no substantial efforts to use them for the purpose of third party interoperability. (In fact it found that Google had tried to prevent interoperability with other Java and had previously been refused a license by Sun for that reason.) It was not transformative in the sense of a new platform either, since other Java smartphones predated Android.
The crux of re-implementing an API is that the name and structure of the replacement has to be the same otherwise it won't work as a drop in replacement. If I reverse engineer a file format I don't have to name any of my code the same as the original or structure it in the same way.
True, but there's many parts that you do have to copy into your source code:
* magic numbers at the start of the file format
* all sorts of enums that you just have to know, names and numbers and the correspondence between them
* names of data types and classes are often needed
* there are often many "standard" things that will be in both the original source and the duplicate because it's the industry standard (things like bold text in any word format or parallel constraints in cad files). They will mostly match in all programs of the same time
And that's just the beginning. You could make an argument that all of those fall under copyright. And they shouldn't. So it really isn't that far from an API.
If you copyright all those things then you aren't copyrighting the file format. You're copyrighting a bunch of code you wrote to read/write the format. Which (virtually) everyone agrees is something subject to copyright.
The point is that file formats are qualitatively different than APIs. If I have a doc file that is:
<doc>
<author>
.....
Then in my code I have a parse method:
Def parse_doc(xml)
self.Owner = Person.new(xml[:author])
....
End
And a corresponding write method.
My code is original and contains nothing written by whoever created the file format beyond short and simple tag names. It's much different than copying a class structure and method signatures.
Other than the tags, the Harmony code was completely original too, with the exception of the nine line range check code that was the only literal copying Oracle could find.
Here is the only piece of code Oracle accuses Google of copying, out of slightly under one million lines of code:
private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
if (fromIndex > toIndex)
throw new IllegalArgumentException("fromIndex(" + fromIndex +
") > toIndex(" + toIndex+")");
if (fromIndex < 0)
throw new ArrayIndexOutOfBoundsException(fromIndex);
if (toIndex > arrayLen)
throw new ArrayIndexOutOfBoundsException(toIndex);
}
Note that of course "rangeCheck", "arrayLen", "fromIndex" and "toIndex" are part of the function signature, as is "ArrayIndexOutOfBoundsException" and "IllegalArgumentException".
I think that assessment would be stretching the definition of "file format". Neither the file nor the thing producing/consuming the file "have a copy of [the] format", since a file format is an abstract thing to which the file itself and producer/consumer adhere.
The format of the file is not (last I checked) the thing that's copyrightable; rather, it's the specific producers and consumers which are. Same deal for an API; the API itself is not (supposed) to be copyrightable, while the producers and consumers are indeed copyrightable (as is the documentation).
> Except that you don't have a copy of a file format in your code.
Except you do in many cases - there are many serialization systems out there where you describe your structures as types, and they generate the serializers for you. Just look at protobuf as one example. Is a protobuf declaration an API? If not, how is it different from any other API that declares a bunch of structs?
I haven't used protobuf so I might be mistaken here, but it's not necessary to use the same variable name. In other words, I can use date_of_birth and you can use birthdate so long as we both agree that the first item in the message is the date a person was born. So you can reverse engineer a protobuf message without creating a direct copy.
Google didn't do this to be interoperable. There is no set of software interoperable with Android's Java runtime. Not even the court bought this argument, because not only is it ridiculous on its face, but it's technically not true.
Why do people involved in tech keep repeating this?
This is a bold claim - but I suspect your definition of "interoperable" is stricter than common usage (i.e. executable)
> There is no set of software interoperable with Android's Java runtime.
Countless 3rd party libraries are interoperable with Android - the few that aren't probably rely on sun.* - I suspect google did do this to be interoperable with 3rd party libraries as well as Java developers' mental model of where to find things.
Regardless of why Google did this, it does offer some interoperability - you can write Java libraries that compile and work on both J2SE and Android. That is valuable.
IANAL but wouldn’t a win for Google achieve the result of amending the law? Everyone will reference Google vs Oracle when challenged. Of course if Google looses then the longer process of amending the law could ensue but that sounds like an uphill battle.
What I'm saying is that all the people who are trying to make the "but it's bad!" argument are missing the point of the courts. Courts are not there to determine whether it's good or bad, only whether it's legal or illegal. If SCOTUS rules that APIs are copyrightable, it's not because they hate the software industry, it's because our law is stupid.
This multi-year legal battle seem like insanity to me.
What does Oracle, who practically prints money, expect to get out of this other than exercising a fleet of expensive lawyers? At best the case was always iffy and even if they "win" it's unclear what that really means for them given the inevitable subsequent legal maneuvers. Even more puzzling is how are they making the argument that Google has, in any way, harmed their business?
It's just mind boggling. A slip-and-fall insurance scam makes more rational sense to me.
It's business admin 101, really. The unfair advantage IBM/Oracle/SAP et al have, is that they are entrenched.
It is infinitely cheaper to develop things in-house or with smaller software shops, But then you won't be able to interface with your factory's material providers' system, or other Banks, etc because they only talk some protocol that is copyrighted/trade secret of those firms.
They are not fighting google. Google just happened to enter in the cross fire and have deep pockets to fire back! What oracle (and others like IBM behind the scenes, via DC Federal Circuit "lobbying") are fighting back, is the freedom of smaller software shops to provide their clients with fully compatible offerings to their money cows.
This is the only time someone conscious of freedom and privacy should be rooting for Google.
" is the freedom of smaller software shops to provide their clients with fully compatible offerings to their money cows."
Thanks for this summary! I had no idea this was the underlying reason. I feel silly now because I thought it was just some weird obsession of someone in Oracle's C-suite.
Oracle doesn’t actually print money. They are cash-rich but are struggling to convert long-suffering customers from on-prem products to their cloud equivalents. Nobody trusts them; you can sort-of deal with a crocodile that shows up once a year to collect, but when you go SaaS you are basically walking by the crocodile all the time, hoping it won’t bite you with higher prices at a day’s notice. And their support is not very good either, which again is more critical in saas scenarios than on-prem.
In this situation, a significant new revenue stream ( an Android tax) is definitely worth fighting for. And Ellison loves lawyers; he even sued to compete in the America’s Cup...
Wasn't that in reaction to the previous America's cup challenge where the Australians introduced a winged keel that had previously been disallowed from 3-meter boat competitions? IIRC, both were allowed because the charter gave the challenger the power to set constraints.
> In this situation, a significant new revenue stream ( an Android tax) is definitely worth fighting for.
Except that there is no hope of that ever happening. Even if Oracle won in a big way, then Google would eat the one-time cost of deprecating the Java API on Android, similar to what Apple did between Objective C and Swift. There is no sustainable revenue stream there.
They have already done that, in practice - Google keeps coming up with other ways of writing Android apps and alternative runtimes, and encouraging developers to adopt them. It would have been silly not to, the minute Oracle sued, as insurance. But it’s a mammoth task and nowhere near completion. Moving such a humongous ecosystem is always hard; if you cut too abruptly you risk opening the market to competing platforms. This goes even more for a platform that has customers both above (developers) and below (manufacturers) the stack. Apple didn’t even change anything of substance internally, and still a lot of (most?) apps are not built with Swift. It will take years to replace Dalvik; and in those years, the crocodile would be happy to collect.
You can't do it overnight, but you can do it over an abbreviated time frame. Especially once you're sure you need to.
Then it could be announced that the Java API will be removed in a specific future version (so update your applications now), the Google Play cut of applications using it will now be 50% instead of 30% for those without it, some of the OEMs will immediately start selling phones that don't have it and those phones are less expensive so people will buy them and developers will have to use the new replacement to reach those app customers, etc.
Forcing a transition to happen faster is not fun, but that isn't the same as not possible.
Still the same stdlib API, at least the way Google has introduced Kotlin to Android. If they had any ambition to use Kotlin as their vehicle for abandoning the Java API I would expect at least some visible efforts of opening Flutter to languages other than Dart. But in typical Google fashion they seem to deliberately avoid forcing their teams down in the trenches into some unified grand strategy, giving them the freedom to build the best version of their product that they can. Given Google's deep pockets and how badly coordination overhead would scale to their project dimensions, this hands-off approach seems reasonable enough.
Not defending Oracle here, but the fact that the decision in Google's favor has been overturned twice suggests Oracle's not 100% crazy to pursue this. And the upside is mandatory licensing fees for every Android device.
Or that Oracle is politically connected to the court of appeals for the federal circuit, hence why a patent appeals court is claiming jusdiction over a copyright matter, and making it's own copyright case law in contradiction with the normal copyright appeals court case law to begin with.
The supreme court can send it back to a lower court with instructions, they can also decide on the case but note that their decision would not cover particular arguments if they were made.
It is zero-sum iff the benefit to Oracle is exactly equal to the deadweight loss imposed by the tax.
I tried to calculate this in the simplest econ 101 way, and got a surprising result. I would appreciate someone else commenting...
Assume that the schedule of supply and the schedule of demand are straight lines. We have three groups: (1) purchasers of phones; (2) vendors of phones; (3) Oracle.
In the absence of a tax imposed by Oracle, an equilibrium quantity Q_e of phones trade at an equilibrium price P_e. [1] This generates gains from trade, producer and consumer surplus, equal to the area circumscribed by the schedule of supply, the schedule of demand, and the line Q = 0.
When Oracle imposes a fee on phone sales of value F, the price and quantity-traded of phones adjust. The new quantity traded Q_f is lower than Q_e, and the new price P_f is higher than P_e. The gains from trade are now the trapezoid circumscribed by the line Q = 0, the line Q = Q_f, the supply schedule, and the demand schedule. The missing gains, the deadweight loss, are equal to the triangle circumscribed by the line Q = Q_f, the supply schedule, and the demand schedule.
Oracle receives F×Q_f in fees, a benefit equal to F×Q_f.
The deadweight loss is a triangle with base F and height (Q_e - Q_f). It is therefore equal to (F×Q_e - F×Q_f)/2.
Balancing the gains to Oracle against the deadweight loss, we see that they are equal when Q_f is one third of Q_e, or in other words when the fee is so massive that it cuts the quantity traded by 66%. If Q_f is larger than that, the benefits to Oracle exceed the loss imposed on purchasers and vendors.
This result would seem to imply that we could improve the efficiency of the marketplace by allowing random third parties to impose large taxes on pretty much any good. This is hard to believe. Where did I go wrong?
[1] In reality, there are a variety of models available at a variety of price points. This doesn't affect the problem I have with my result, though it is probably relevant to the phone market in specific.
You inverted the sign. The zero sum thing is the prospective transfer to Oracle. If you pay $100 and Oracle receives $100, net across everyone is zero.
Then whatever lack of commerce caused by the higher prices occurs is a deadweight loss with negative sum. You start from zero and go down.
To get a positive sum you need to be creating something with value greater than its creation cost.
So, before the fee, there's a certain amount of producer surplus, a certain amount of consumer surplus, and zero Oracle surplus.
After the fee, there's less producer surplus, less consumer surplus, and more Oracle surplus. As a consumer, I don't see which part of the price of the phone goes to the producer (generating metaphysical good) and which part goes to Oracle (generating metaphysical evil). I just see that the phone is worth more than its price by an amount equal to my consumer surplus. My surplus is measured in dollars just like Oracle's surplus.
But it seems that after Oracle imposes the fee, it generates so much Oracle surplus that it could cover the deadweight loss out of its own pocket and leave everyone better off. This is surprising.
I think your comment is mostly correct, but I'm going to try to put it in terms that make more sense to me.
The answer is that the loss of producer/consumer surplus is being calculated incorrectly. Deadweight loss is the triangle described, but the loss of consumer surplus is more than just the consumer-surplus part of the deadweight loss. It also includes the rectangle separating the price the consumer would pay in the absence of the fee, P_e, from the price the consumer does pay, P_f. My mistake isn't that I inverted a sign, it's that I compared the wrong quantities -- I included a benefit to Oracle without accounting for the cost to consumers and producers who are still willing to trade under the new regime. (Where the deadweight loss only includes consumers and producers who were willing to trade under the old regime, but not under the new one.)
(bananamulch and 34624523 both said the same thing I'm saying here.)
If the fee is per phone it adjusts the supply schedule by moving it towards a lower quantity as a higher consumer price is required to compensate the producers at the same amount.
The schedule doesn't change. The quantity traded does, but I mentioned that:
> When Oracle imposes a fee on phone sales of value F, the price and quantity-traded of phones adjust. The new quantity traded Q_f is lower than Q_e, and the new price P_f is higher than P_e.
The deadweight loss is the net loss to the combined system (producers, consumers, and oracle leech). So if the total surplus of the system was X, and the deadweight loss was (F×Q_e - F×Q_f)/2, the total surplus of the system with oracle is (X - ((F×Q_e - F×Q_f)/2)). This is less than X.
The producers/consumers combined would lose both the oracle tax and the deadweight loss (lack of opportunities that otherwise would have occured).
The loss to consumers and producers combined is both the oracle tax and the deadweight loss. So the lack of efficiency is measured by the deadweight loss, and the optimal amount of deadweight loss is 0.
But then again, what if phones have a negative externality from a society where no one talks to eachother? The oracle tax might be good for society.
It's certainly a downside for society, because there are people who otherwise would have purchased android phones that can't afford them because of the oracle tax.
The only ones winning this are the lawyers, salivating at the idea of this blob of mess, playing on words beyond recognition and way above any common sense.
I saw a lawyer's office earlier. Big logo said "We fight for fair". Sure, per minute.
I have used lawyers to defend my contract rights against people that try to weasel out of paying up for some services. How about we don't go black and white on lawyers (go case by case instead), to appreciate the complexity of human interactions and the corresponding complexity of determining who's right?
My lawyer is fantastic. On the few occasions I’ve used his services, he’s advocated passionately for me, and given me great advice. He cares personally about his clients and I don’t regret a single dollar I’ve spent on his invoices.
It’s strange how law and finance are both heavily demonized. Why is that? Both professions are productive, yet for some reason, it appears that most will only focus on the negative aspects of these two professions.
It’s the speculative part of finance that is loathed. The one that don’t care about fundamentals, product quality, humanity and the earth.
The law is in general a good thing, but you have this whole business going that is from a fundamental point of view just meaningless. This business is about patent claims, and often all it manages to do is stifle innovation.
You could argue the productivity of both these specialities.
I used to work in finance. People don't like finance because 99% of the time if there's a relationship involved we wouldn't have to compete on price.
It would be obvious if someone's shopping around a loan, to the extent that it was very easy to get a broker to send over a competitor's offer sheet so you could compare.
People hate finance because at the core it's sales and you make your keep by being predatory since everyone does it. If you don't, you sink.
One negative example for lawyers would be dragging a case about pensions out for over a decade so that over time people would die and reduce the cost to the company.
There are advantages to controlling a dominant platform. Even if Oracle doesn't get much direct revenue from Java they can use it to block strategic moves by competitors.
While I think this lawsuit is terrible and I hope Google wins the legal case, from a moral standpoint they kind of acted like assholes back in 2005 when they decided to fragment the Java ecosystem rather than negotiating a licensing deal with Sun. So now we have real Java in multiple JDK / JRE implementations plus this weird pseudo-Java offshoot in Android. The language used by Android looks a lot like Java but it hasn't kept up with improvements in the core language and standard library, so now developers can't reliably reuse code across those platforms. That harms the software industry as a whole.
There are plenty of commercial 3rd party companies selling alternative JVM implementations, none of them has ever had any issues with either Sun or Oracle.
They were foresighted enough to see mobile as a key platform, and critical for long-term advertising... but not foresighted enough to try to work with Sun, to make a subset of java giving reasonable performance/efficiency on mobile back then.
Probably because Sun went along with it, so why bother?
In Italian there is an expression “putting a good face over a bad game”. Sun was in shambles and had no muscle to force Google to do the right thing. The CEO was already so embattled that he couldn’t admit he had mismanaged the relationship. So they just smiled and tried to spin it as a great thing for the Java ecosystem at large; which, at the time, it kinda was. After all, it basically gave Java programmers a mobile story that wasn’t the dying J2ME, and even a new client-side story that could replace the quickly-disappearing desktop toolkits.
Other companies at least have some notion that they should be helping society or something like that, and occasionally they do. Oracle has a long track record of being evil.
There was a Freakonomics episode about just that. Studies show that most companies show of altruism is just social signaling and that people are willing to work for less if they think their company is doing good.
It's just a way to say "hey, see what happens if we get angry ?" so that smaller players will always try to comply to their ludricrous future claims. You can see that even if they will spend millions, knowing to loose, against a giant like google, for a reason that ridicoulous, a tiny business won't stand a chance.
Because you can't just take other software and change the license on it.
The industry's, justified, hate for Oracle is blinding them to the larger underlying concern.
Many people forget that Oracle technically won the legality of the last case, hence why we're here. They just weren't awarded damages. Even the judge didn't buy Google's arguments about open source or compatibility concerns.
They only got that ruling by appealing a copyright question to the patent appeals court, who for some reason decided to just go off into the weeds and set their own precedent in open conflict with the appeals court these questions would normally go to.
That's why all the rulings keep getting overruled. The lower court judge is sane (he's actually awesome, you should check out Alsup) and keeps ruling in accordance with established case law, and the appeals court (who shouldn't even be answering copyright questions) keeps going 'nah, all that case law is stupid'.
Hence why this should go to the supreme court who'll most likely tell the court of appeals for the federal circuit that they can't just go make their own law.
It's not true that they won the legality of the case through an appeal. The original ruling sided with oracle on technical and legal matters. They just weren't awarded damages.
By "the original ruling" are you referring to https://www.eff.org/files/alsup_api_ruling.pdf , which says, "on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act. Therefore, Oracle’s claim based on Google’s copying of the 37 API packages, including their structure, sequence and organization is DISMISSED. To the extent stated herein, Google’s Rule 50 motions regarding copyrightability are GRANTED"?
Can you point to what part of this ruling sided with Oracle on either technical or legal matters? (With the exception of rangeCheck.) Or can you link to what ruling you mean by "the original ruling"?
Google did not take software (other than rangeCheck), they took interfaces.
That said, it is common wisdom around F/OSS folks that you can't take other people's interfaces and change the license on it, e.g., I can't write and distribute a proprietary Linux kernel module using EXPORT_SYMBOL_GPL functions. I haven't seen a good analysis of whether this case is relevant to that—would a Google victory mean that VMware's use of vmklinux is legal (well, at least in the US), that ZFSonLinux is in the clear, that Nvidia can write proprietary drivers using dma-buf, and that CLISP should have been able to use readline without relicensing itself under the GPL?
> I can't write and distribute a proprietary Linux kernel module using EXPORT_SYMBOL_GPL functions.
That is because by using EXPORT_SYMBOL_GPL functions you are invoking code that is GPL'ed. If you made a clean room implmentation of a kernel that exposed the same interfaces as Linux, you could licence it anyway you want.
By calling any kernel API you are invoking code that is GPL'd. It is not like EXPORT_SYMBOL functions are BSD-licensed (and even if they were, they themselves call GPL-licensed code). In fact even making a normal system call from userspace invokes GPL'd code.
So I think there are only two interpretations. One is that EXPORT_SYMBOL_GPL attempts to claim a copyright on the interface, and not the code. The other is that redistributing a GPL-incompatible object that invokes GPL'd code is always infringement, and (possibly) the special exception for userspace in Linux's copyright statement, https://github.com/torvalds/linux/blob/master/LICENSES/excep... , is the only thing that makes normal userspace processes non-infringing, and that regular EXPORT_SYMBOL is basically also an explicit exception (which may or may not even be legally meaningful - during the dma-buf discussion, various copyright holders expressed that they did not interpret EXPORT_SYMBOL as an exception).
>By calling any kernel API you are invoking code that is GPL'd.
What does this have to do with anything? If you think this is a relevant statement you are severely confused about the current subject matter and what is being argued in court.
Please explain how the above statement is relevant to the current case.
That sentence is a reply to the comment above it, which states, "That is because by using EXPORT_SYMBOL_GPL functions you are invoking code that is GPL'ed."
My claim is precisely that this is not a relevant statement.
On a legal level, no, that's not a mistaken belief. Prior to this case, that was in fact the legal consensus. Given this case, it's only a mistaken belief if the Supreme Court decides for Oracle (or declines to take the case).
Yes, that is exactly my contention. An interface is no more software than a recipe is food, than a credit card statement is money.
From a technical perspective, interfaces in, say, C are mostly compiled out. There is no place in a (stripped) binary where you can point to a structure definition. There is a place you can point to names of functions that are yet to be dynamically linked, but only their names, that place is different from the program code (text section) itself.
None of this is to say interfaces are not an important part of software engineering. Interfaces, APIs, internal zero-cost abstractions, tests, comments, design documents, threat models, bug triage, commit messages, code reviews, operational techniques, runbooks, monitoring and alerting systems, end-user documentation, etc. are all important work products in the discipline of software engineering. They're also all (IMO) something different from the software itself.
> Please explain to me the fundamental difference between an interface and what you consider software.
"Software" is code. An interface is the expectations of code.
In particular, if software X implements interface A, it is possible to write a compatible drop-in replacement of X using software Y, which does not incorporate any portion of software X, is it not?
GNU libc and Apple libc both implement the UNIX libc interface. If you claim that an interface is indistinguishable from software, is there a portion of the GNU libc software that also present in Apple libc? Where is it? Can you point to it? (The source code of both is public, so this should be easy for you to do.)
Google gave another example in the blog post: the interface of keyboard shortcuts. If I implement a text editor that uses Ctrl-X for cut, Ctrl-C for copy, and Ctrl-V for paste, have I copied the software of another text editor that uses that interface?
> An interface in all its various forums as we understand interfaces are placed in binary. From object implementations to ABI's and API's.
An API, an "application programming interface," is distinguished from an ABI, an "application binary interface," precisely because it does not mandate what appears in the binary.
If you think that there is in fact a way where you can point to a structure definition in a compiled C object file, please identify where it is in this object: https://godbolt.org/z/SVhsJk
I agree with you: the interface is represented in actual binary format. But Google didn't copy that either. Dalvik doesn't even use the same binary format as Oracle's JDK.
I've read all the Oracle v. Google decisions, with a strong command of software and IP, and I side 100% with Oracle. It is not a question of whether the world would be better if API's were open-sourced (in re: EFF amicus brief), or whether Mr. Ellison needs a new yacht (in re: comments on HN), or whether copyrights are a good thing (also re: HN). The question is whether the copyright of the Java API is enforceable.
Here's the bottom line: Google didn't have to call it's resizable array java.util.ArrayList<E> -- it could have made android.data.ResizableArray<E>. But they didn't. Google copied the method signatures, and more importantly their organization into packages, to avoid the "drudgery" of defining their own original API. While a function that finds the minimum of two numbers -- int min(int a, int b) -- can arguably only be written one way and may not be enforcable, the issue isn't any one method's signature. The issue is that the Java API is an original, curated taxonomy of classes, methods, and interfaces, organized by authors. And taxonomies are protected under copyright. In the case of the Java API, the whole API taxonomy is greater than the sum of its method signature parts. Oracle owns that taxonomy.
Google didn't reimplement Java from scratch for Android. They adopted Apache Harmony which was the first open source Java implementation - so blame IBM for copying method signatures. Sun refused to bless Harmony as an official Java (or rather, refused to provide the TCK required to certify Harmony) - so you can understand why signatures and packages were identical: because Harmony was always meant to be fully compatible with Java.
Don't let any animus towards Google blind you to the real harm this will ruling will cause if it stands: say goodbye to any S3-compatible APIs, and good luck to WINE and Proton and say hello to lock-in and higher switching costs.
That's not the all story. Sun/Oracle refused to provide the TCK with a license that would allow it to be used in mobile. They did agree to allow it to be a desktop/server only solution.
However the knowledge that Java isn't open-source compatible in mobile environments was known before Google started building their own.
> Here's the bottom line: Google didn't have to call it's resizable array java.util.ArrayList<E> -- it could have made android.data.ResizableArray<E>. But they didn't. Google copied the method signatures, and more importantly their organization into packages, to avoid the "drudgery" of defining their own original API.
That's one explanation of their motive, but it's not the only one and it's not the one they claim. The one they claim is that they wanted their platform to be compatible with existing software written for the Java platform. And along with it, with existing software developers writing on the Java platform. From that perspective it's not a choice: you can't use a different standard library API and have Java software run on your platform, just like you can't have a different instruction set and have a compiled executable work on your CPU, just like you can't sell an appliance with a different plug and have it work in a standard household outlet.
If I take a book and change the names of all the characters, I will still get sued. Renaming APIs and making a derived work is not in any way certain to prevent lawsuits like this one.
All SQL derives from IBM. Can they sue everyone on the planet? What about the guys who made B or C, can they sue everyone? Where does the insanity stop?
> If I take a book and change the names of all the characters, I will still get sued. Renaming APIs and making a derived work is not in any way certain to prevent lawsuits like this one.
This is not an apt analogy, because this isn't what happened. Google wrote all of the implementations from scratch: the only thing they copied was the character names (and potentially one tiny function used for sorting). This is more akin to taking the Wikipedia summary of the plot of a book and writing a new book based on that summary.
APIs aren't functions, they are interfaces. No matter how original they are or how much you pile them together, they aren't supposed to be copyrightable because they are too abstract.
Not trying to be confrontational here - but through your other posts, are you suggesting by changing class names the whole situation could’ve been avoided?
If you're saying the creative value is in the original curation of classes, methods, and interfaces, and that Google could've permissibly rewritten everything with alternative names, that still seems to copy the "soul" of the creative work.
Personally I'm with the perspective that API which has informally become an industry standard should weaken copyright protection.
If that holds. Intel will sue AMD into the ground. "The 8086 API and instruction set, is an original, curated taxonomy of classes, methods, and interfaces, organized by authors"
AMD would have rights to sue back saying that "The x64 API and instruction set, is an original, curated taxonomy of classes, methods, and interfaces, organized by authors", as they extended x86 to 64 bits, and then had similar with x86 cross licensing agreements with Intel.
And yet there's fx!32 (WinNT for Alpha), x86emu (of XFree86), Bochs, VMware, parallels, Plex86, QEMU plus numerous other implementations of i386+ in software (one of them shipping in Windows 7 and newer to run PCI Option ROMs) where nobody seems to care too much.
OTOH, ARM was rather adamant about not wanting to see ARM instruction set implementations in software for a long time.
Either they saw the value in these emulators existing so that changed their minds - or somebody didn't let themselves be bullied into compliance: just because a company threatens you with lawyers doesn't mean they actually have a case.
Your answer surprised me and I went to do a bit of reading. Found this quote:
> Since this article was first published, Sun (now part of Oracle) has relicensed most of its Java platform reference implementation under the GNU General Public License, and there is now a free development environment for Java. Thus, the Java language as such is no longer a trap.
So it looks like at least older versions of Java were under the GPL. Apparently you can't use the name "Java" without passing a conformation testing suite, but you should be okay as long as you didn't call it Java, (say calling it Android).
Open source licenses are enforced by copyright; without owning the copyright of a work there's not much you are able to license with respect to copying. There's a reason most license files out there start with "(c) 2019 <Authors>".
The opposite of a copyrighted work is not an open sourced work: it's a work in the public domain.
> So that would mean that Android would have to be under GPL, right?
That kind of depends on whether you can apply a different license to an API and its implementation. There's not really any precedent for that kind of question, because it presupposes the validity of a kind of copyright that the industry has grown up assuming is not valid.
AFAIK Android originally didn't use OpenJDK, but rather Apache Harmony, which is an IBM reimplementation of the Java JDK. So in that sense maybe Oracle does have a point (if API's are deemed to be copyrightable).
I think Android has since switched to OpenJDK, so it seems to me what Oracle and Google are arguing about is whether Google owes Oracle some damages for their previous use of Harmony. And of course, the lawsuit could have larger repercussions as well, if API's are deemed to be copyrightable.
Honest question - where does one draw the line between what is protected under copyright and what isn't? You mentioned "taxonomies" - what does that mean exactly? Does a single package with one class and one method count? What about two?
The place the line ought to be is where there is only one way to do a particular thing. If the function signature has to be a specific one to achieve compatibility then it isn't a creative act to choose it, it's chosen for you as a functional requirement. You may not even want the interface to look like that, but it's the only way to achieve compatibility.
The implementations are something else entirely, specifically because there are a thousand ways to implement the same function that are all functionally equivalent but nonetheless have different code. It's not a matter of how long it is, it's a matter of whether there is another way to do it.
Google should just copy the iOS APIs! This will make app development much much easier for all developers and will instantly get all the high quality iOS apps onto Android. Apple will only thank them for it.
Well said. There is a lot of hard-work that goes in defining the right API.
Question for you since you sound knowledgeable: If Oracle wins- can Linux in some way enforce this on Microsoft given Microsoft's work on WSL? Or is that applicable only where there is a taxonomy as you pointed out? My understanding from fosspatents is that it doesn't specifically have to be a taxonomy and even a flat API can be copyrighted (which I agree with since there is work that goes in it...)
Answering it from cwyer's comment on this page- doesn't apply to fair use so WSL is fine.
I would urge people who are looking to get the other side of this argument (pro-Oracle) to also read fosspatents.com. That is a sensationalist blog but the facts presented are very true.
Telephone directories may take quite a bit of work to compile, but perhaps more labor than creativity. I can't off hand think of too many ways to organize such a directory.
I can immediately think of many ways to do dates, and so can many java programmers (think the Date api, the Calendar Api, JodaTime, JSR310).
And having "new Date(1,1,1)" mean "the first day of the second month of the year onethousandninehundredandone" surely requires a bit of creative thinking.
Interestingly Microsoft also had it's own set of problems with Java when Sun was at the helm. Windows used to ship with Java and Visual studio had java as a first class citizen. Microsoft being microsoft, added extensions to Java which only worked on Windows which Sun didn't like. Microsoft ditched java, stopped shipping it with windows and created C#. Thanks to Microsoft , C# is a far better language than what Java is today and developing on windows is a breeze.
Google on the other hand, has not focussed on developers much. I've been building on android for a few years now and the IDE is derived from IntelliJ ( Earlier you had to use eclipse which was even worse ). They could have easily gone the MS way and used another language or one of their own. Major language features are delayed, the code is incredibly verbose(kotlin tries to solve that to a small extent) and they are fighting a lawsuit which if they lose would be pretty expensive.
Guava is great, thats why its used often. And if you combine projects with each other (hadoop, spark, etc..), they bring in their own guava API level dependency. Normally that is not a problem, if you stick to non @Beta methods, the highest version is used.
I did not find it on the spot, but i remember, there was once a written promise made by the Guava people to remain compatible to a certain API version. And then they broke that promise by changing public signatures or removing methods. Vividly i have the Stopwatch example in my head.
How many projects would be affected if the Supreme Court sides with Oracle and rules that APIs can't be reimplemented?
Java is open source, but copyright is retained by Oracle. Would this affect say, Amazon's ability to rip off the MongoDB API? What about open source x86 emulators? (Intel IP) Hercules IBM emulator? Any of the Nintendo, SNES etc game emulators?
If Oracle succeeds and Amazon proceeds to sue Oracle for that, that would be some sweet schadenfreude. Granted, I’d still be pissed at the decision, but to have Oracle’s tactics used back at them would feel really nice.
They'd lose for the very same reason that Android is within the confines of the law via the Android Runtime. Dalvik violated the Java license, Android Runtime isn't. Aurora's compatibility layer isn't violating the MySQL license either.
> Dalvik violated the Java license, Android Runtime isn't.
Can you elaborate on this point? What license for what copyrightable work did Dalvik violate, and why does Android Runtime not violate that same copyright license?
The issue at hand was licensing. In the Android Runtime, Google is linking to the OpenJDK libraries rather than using it's "reverse engineered" runtime. OpenJDK is GPL with a classpath exception, which Google is utilizing.
The caveat for Google is any changes to the OpenJDK itself has to be upstreamed. But the Android Runtime itself doesn't have to be GPL due to the classpath exception.
In all honesty, this is how they should have done it in the first place.
It was violating the open source license, thus required a commercial license, which it didn't have, which in turn makes this copyright infringement. At least that's the position of the courts so far.
Linux and OS X implement the same APIs as Unix. Windows implements the same (or very similar) APIs as PM in OS/2.
Most modern PCs reimplement the IBM PC "API", hence "PC compatible".
> In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
(—Copyright Law of the United States[2])
APIs are the idea that binds components together. Even if you come to understand the interface by reading a programmatic description of it (e.g., a function signature), and reimplement it, and your language forces you to use the same exact wording to match the signature (b/c it's an API), there's nothing different here than the same exception given to the way that a the raw listing of ingredients in a recipe is not copyrightable (and this is called out as an example of such by copyright.gov[1]).
The appellate court erred in its application of the law.
Additionally, this was said on one of the amicus briefs,
> reversing the District Court would dangerously undermine the settled expectations of computer scientists and the entire computer industry that rely upon the open nature of APIs
(—Martin Fowler, Bruce Schneier, Bjarne Stroustrup, et al. were signatories to this amicus brief.)
The decision, were the industry to actually pay attention to it, would wreak havoc on the state of software engineering.
That just means that Apple's implementation is allowed to use the Unix trademark. It really doesn't add much of anything to the copyright discussion, especially since The Open Group doesn't own Unix copyrights, just the trademark.
Yes, if this decision doesn't go Googles way, all hell is going to break lose: WINE, Samba, S3 compatability, Amazon DocumentDB. The list is enormous and frankly, everyone loses somewhere. It's a complete nightmare.
Remember, if Oracle wins, they are not pursuing a ruling that obviates the doctrine of fair use; all of those cover the case of implementing an API for compatibility. Oracle's argument about Android and its use of Java is that Android did not run Java apps; it ran Java code, but it did not implement enough of the Java API surface to let you run Java apps unmodified. You could use existing Java code in new, Android-only apps that couldn't run on Sun/Oracle's JVM.
Therefore, Oracle's argument is that the fair use doctrine does not apply here; that Android is a derivative work of Java, which is not fair use. WINE, for example, is not ruled impermissible by the sort of ruling Oracle seeks.
I agree that Oracle isn't trying to create a ruling that obviates fair use; but assume you believe that the appellate court's ruling is correct, and APIs are copyrightable, how does fair use cover implementing an API for compatibility?
> Oracle's argument about Android and its use of Java is that Android did not run Java apps; it ran Java code, but it did not implement enough of the Java API surface to let you run Java apps unmodified.
So what? Partial compatibility is still meaningful in software engineering, and should allow libraries to run on both. Are you saying that if Google had fully implemented all of the Java APIs, it would have been fair use?
Further, can you ground the above reasoning (that fair use covers API copying, and that Google's partial implementation is material here) in the actual rulings for the case? I don't remember any of this from when I read them, though I do admit that was some time ago.
> WINE, for example, is not ruled impermissible by the sort of ruling Oracle seeks.
Why not? Simply because you cannot write a .exe that would run in WINE, but not in Windows?
Further, what if the example was instead Linux? Linux implements Unix's APIs, but also adds other APIs. You can use existing "Unix" code in new, Linux-only apps that won't run on other *nix OSs.
I'll appreciate links to previous discussions about the subject but let's say I create the next big thing in the JVM world(the next Kotlin compiler or something like that), it targets the JVM and I happen to replace the implementation of `String.getBytes` at linking time while keeping the same method signature. How big do I have to be for Oracle come after me and ask for royalties of any Enterprise services I could be selling on top of my product?
There was a story on the fp 2 months ago by someone who went to an interview at Google to present her work (didn't work out) only to find out that a patent was later filed by Google covering much of the presented material.
Reminds me of the McGreggor vs Khabib fight - "it's only business"
It was slimy moves on Oracle's part through and through. It's like the only reason they chose to have acquired Sun Microsystems was so they could go and patent troll with it. Some seriously sad future that Oracle is heading towards if this is their definition of continuing innovation and growth.
Also, don't forget that Ellison was a former Apple board member, and probably not entirely unbiased on giving Google a rough time, and thus rallied behind Jobs when he vowed: "I'm going to destroy Android, because it's a stolen product. I'm willing to go thermonuclear war on this." [0]
Of course, it was maybe just Ellison shrewdly leaping on a opportunity to profit off an undervalued ecosystem (Java) at the time. Going on almost a decade now, things certainly proved to be not so clear cut in Google favor, and might still pay off.
I'd be cool with that story, if Oracle didn't go and sue Google like pretty much immediately after they finished acquiring Sun. They were 100% eyeing Android right from the start in my opinion.
Well, Google had the opportunity to bid for Sun. The price was peanuts for Google. But they didn't pursue it, despite the risk. They brought this to temselves. And yes, Oracle behaves as a sleazy bag, but that was also common knowledge at the time...
That's like saying that you could have gone to the gun store and bought the gun that I am pointing at your head before I did. It wasn't very expensive and you could easily afford it. You really brought this robbery on yourself.
The analogy works if there's only one gun and I was offered it in an auction. I turned it down despite knowing you're very keen on robberies and in my neighbourhood. And I heard you're keen on buying it.
I kept the money and now you're using the gun to get the money I saved.
If we had a second round, this time with a machine gun... What would you do?
I'm still cross with Google. At the time it seemed like the natural home for Java.
Except that Google is not a friendly grandma, but a global thug that has its own gun arsenal, including the knock-off copy of a gun that was offered at the auction with a hefty discount.
This blog post is laundering history. The choice quote: "With smartphone apps now common, we sometimes forget how hard it once was for developers to build apps across a wide range of different platforms. Our 2008 release of the open-source Android platform changed the game." This could be equally said of Java itself, a good eight to ten years prior, which brought a serviceable userland onto desktops of all kinds, mobile phones of the day, and embedded devices too. They lifted that API to bootstrap the developer ecosystem for Android after their efforts to license Java from Sun failed, and did a different cleanroom implementation underneath.
In the gold rush to develop Android apps, their frozen-in-time copy of the Java ecosystem rose to prominence and sought-after Java libraries were held back for years to lag behind official Java's versions. Differences between Android's facsimile of Java and real Java (from plenty of other vendors) caused confusion and divergence to the Java ecosystem, as Oracle's own efforts to leverage Java faltered too. Android's popularity de facto forked Java for years and did so without the permission of the rightsholder. If the copyrightability of APIs isn't the answer we want in the field, what instrument do we need to prevent the same from happening to other products too?
> what instrument do we need to prevent the same from happening to other products too?
...We don't need such an instrument, because the outcome you mentioned is desirable.
If we had such an instrument, Linux would not have been possible, because it's compatible with the Unix APIs. OSX would not have been possible, for the same reasons.
> If we had such an instrument, Linux would not have been possible, because it's compatible with the Unix APIs. OSX would not have been possible, for the same reasons.
Technically, OS X would be possible, because it is not merely Unix compatible. It is a Unix [1].
They only own Unix the trademark. Unix the copyright is a much more muddy concept that'd probably lead to another trial between Novell and SCO. If SCO won they'd totally go after all the Linux and BSD variants too.
The difference between a blob storage system that implements an "S3-compatible" API, and AWS S3, is that no one is mistaking the other offering for S3. Dozens of libraries that implement the S3 API as a client, and offerings that implement it in the server aren't under pressure to diverge between fake S3 and real S3, because the API is feature-complete, and doesn't change in meaningful ways. There may be monetary harm to S3 from the competitor cloning their API and competing with them on price, but there is no reputational harm to S3.
It would be revisionist to claim that there was no reputational harm done to official Java by Android's lookalike Java -- irrespective of any mismanagement by Oracle of the Java platform. How does one prevent that?
> we sometimes forget how hard it once was for developers to build apps across a wide range of different platforms.
I take it you never had the misfortune of developing for J2ME? The blog is laundering history - by severely understating the horror of how it was before: CLDC/MIDP combined with model-specific vendor extensions (E250 would have different packages from other models by the same manufacturer), add non-standardized screen resolution resulted in your apps compatibility matrix having to be in 4-dimensions, at the very least.
There is a view that WordPress plugins are open source because they inherit the WordPress GPL by using the WP plugin API. This case seems to apply in that the question is whether APIs are copyrightable. In other words, is one able to apply a license to an API that affects code and devs that use that API.
So if Oracle loses, I wonder if that will have the unintended consequence of making WP plugins not inherit the GPL, which currently forces them to be open source. It could have similar effects on other projects.
No, the issue being discussed is on the other side of the interface: if I reimplement a known API created by a developer, am I infringing the developer’s copyright?
It doesn’t touch the question of “if I work with a certain software, do I have to follow the licensing terms of such software?”, which is what WP plugin developers must abide by.
The wordpress argument is about the question if a court would see a plugin as an independent work, or as an modification of wordpress. Copyright law allows for independent works to interface with each other without permission from both authors, but do not allow modification of a work without permission.
The distinction between a modification and a interface is an interesting legally gray area, but it is not relevant to the claim that Oracle is making. They say that the interface itself in Java was artistically made and thus made the header files copyright-able. If the courts agree with Oracle then it makes it impossible to write software that have compatible interface, since it is (almost) impossible to do so without creating copies the interface.
Is there anything in the Federal Circuit's ruling that restricts the consequences of API copyright to independent implementations of APIs, and ensures that consumers/users of the same APIs are not treated as derivative works of the API?
Not that I know of, but in general the idea of independent implementations of a compatible API is practically impossible. In order to be compatible it need to match, and while you can make a independent implementation of the libraries you will still need to copy the API definitions in order to be compatible. That is the part that Oracle sued for.
If anyone hasn’t seen oyez[1], I highly recommend it. It’s a simple web app that plays back Supreme Court proceedings, showing the current speaker etc. It’s somewhat intoxicating to listen to history in the making. If you click on the oral argument link, you get the dialogue experience[2].
Oracle bought Sun, the company that created Java. Android was designed in such a way that code written for the Java Virtual Machine could run on it without modification, though the implementation itself is totally original. Oracle is claiming that even the set of vocabulary used by Java programs to talk to the JVM - not just the JVM itself - is copyrighted. This vocabulary is otherwise known as an API. APIs live between every piece of software and every other piece of software it talks to. If the precedent was set that you could copyright an API, it would be a catastrophe for people's ability to build software on other software.
If Oracle wins what would that mean for a project such as WINE? My understanding is that Microsoft could cite precedent and request WINE pay royalties as a standard install of windows.
So Oracle is saying that google violates copyright by implementing certain java interfaces for android? I’m not sure how java and android work together. Does google provide a java wrapper and then go under the hood and implement those APIs for the android device?
They use the same signatures in the header files, e.g.
int add(int, int); //adds two numbers
Oracle is claiming copyright on a similar bit of text. If Oracle wins, any developer writing a method with that signature is violating Oracle's copyright. It's insanity.
It's a bit different from that. Any developer who writes a big chunk of the Java API violates their copyright. It's the API as a whole, not one method in it.
That's still super grey, the higher courts in this case haven't really been looking at de minimis interpretations in a positive light (overturning a lower court de mininis ruling over the range check code). It just hasn't been a real sticking point yet on the API questions.
But there's the rub: they are claiming the API is copyrightable, not just the code that implements it. Independently coming up with the code is irrelevant if the API being (re)implemented is copyrightable.
Yes, I understand that. My point is that simply defining add(int, int) isn't infringement. You have to actually copy something for it to be infringement. Independently coming up with a small portion of an API is not copying and not infringement.
There's not much of a difference, practically speaking.
If you can copyright the structure and organization of an API, then interoperability becomes impossible. If every API has to be unique enough that it doesn't violate the copyright of anyone else in the same problem space, you can no longer create compatible reimplementations.
>There's not much of a difference, practically speaking.
It means you can come up with your own API design without infringing on someone else's copyright.
>If you can copyright the structure and organization of an API, then interoperability becomes impossible.
It doesn't become impossible. It simply means that people need to follow the license that the API has. If the Java API was valuable to Google then they can pay the creators a license fee to use it. If the license fee is too expensive or comes with unacceptable terms then don't use it. Write your own or use some other API with a more permissive license.
Contrast that with musicians who get sued over copyright for using one or two bars of music from another composition. Unfortunately I'm concerned that this isn't even about a single method being OK and a large API not.
Appealed to the Supreme Court? That's good news. They've shown more sanity than many other courts on intellectual property issues. Maybe we can get the idea of copyrighting APIs finally shot down...
Google's petition describes it pretty understandably; see section "A. This Court Should Grant Review To Decide Whether Copyright Protection Extends To A Software Interface" beginning on page 11 of the PDF (http://services.google.com/fh/files/blogs/googlepetition.pdf).
Do you understand copyright? Copyright protects the specific expression of an idea, it doesn't protect immutable facts. An interface is an immutable fact. That's the essence of the argument.
It's a shit argument, because software interfaces are no more and no less "immutable facts" than software implementations. Oracle is correct here; fair use and copyright law need legislative intervention to fix the problem.
> software interfaces are no more and no less "immutable facts" than software implementations
The crucial litmus test is whether there is creative expression involved or not.
So you have to ask yourself this question: are there multiple choices about how to make the interface or not? And the clear answer is, the very definition of an interface is to fix a single way to transmit some information. No other way works to interface to all the existing systems out there. Given there is no other way that works, there is no creative choice involved and copyright has no application.
Now where the argument sets in is that making a binary compatible interface actually doesn't require (in Java) all the variable names to be the same, nor the order of the methods to some extent. Hence all the argument in court about the "sequence and structure" being Oracle's creative expression. And the fact is, Google did copy many of the argument names etc. So you come down to things like, was it creative expression to call the x and y of a Point class 'x' and 'y' or is that part of the interface?
Which is all to say, yes you can argue about this. The OP however said there is no argument. I disagree: there's an argument here with valid perspectives from both sides. If you think there's no argument, you don't understand the nature of copyright law (after all, there's a reason this has made it to the supreme court).
You must be joking. Of course there are multiple ways one could design an application programming interface. People make subjective and aesthetic judgements about API design all the time.
As far as I know a single judge has ruled in favor of Google. Appeals courts have ruled in favor of Oracle on matters of the law and applicability of fair use. (It doesn’t apply.)
Yes, you're right. The original act of designing the interface is creative expression.
But that isn't actually the point. The question is whether the the person creating something compatible with it has scope to exercise creative expression.
It's like the difference between reproducing Van Gogh's chair and stating the fact it that it is yellow. The fact that it is yellow isn't copyrightable, even though the original painting is.
It's a Table of Contents at best. There's nothing "original" about System.out or StringBuilder.append. The only reason this case has seen success is because the appeals court ruled that an API is akin to a taxonomy and that a taxonomy is copyrightable. The problem I have with that is that facts aren't copyrightable.
You can append to a string. You can prepend to a string. You can reverse a string. And that's all API's are. There definitions of things you can do to a given structure. If the API was "Shazam.PowerBuilder.AwesomeThing()" I'd understand this position. But it wasn't. It was obvious lists of "facts" about given structures.
>You can append to a string. You can prepend to a string. You can reverse a string. And that's all API's are. There definitions of things you can do to a given structure. If the API was "Shazam.PowerBuilder.AwesomeThing()" I'd understand this position. But it wasn't. It was obvious lists of "facts" about given structures.
But in Java I can't add to a string. I can't prefix a string. Nor can I invert a string. So the things you mention aren't mere definitions or facts about things you can do to a string. They're methods specifically chosen by the language designer to be useful and those choices are a big part of what makes Java different from Ruby, for example.
But structured compilations of facts (taxonomies) are copyrightable. You can’t just expect cases to go as if the black letter law and case law were written as you wish they were. The courts apply the law as it has been written and interpreted previously.
I'm a bit confused about why Congress made appellate jurisdiction with CAFC work they way it does with patent cases.
The usual justification for giving courts supplemental or pendant jurisdiction over subjects for which they normally lack subject matter jurisdiction when a case involves both something they do have subject matter jurisdiction over and something they do not is that there they will usually be arising out of the same facts and involve the same witnesses.
If they were heard in separate courts, many witnesses would have to appear to both and that could be a hardship on them.
For appellate cases there aren't witnesses. It's just the lawyers arguing from the record from the trial court.
If the original case involved both patent infringement and something else, the patent aspects of the appeal are going to be handled by patent specialists, and the other aspects are likely to be handled by different lawyers.
Thus, I don't see why the appeals should be bundled together and all sent to CAFC. Why not send the patent appeals to CAFC, and the appeals for other aspects to the ordinary appellate court they would have went to if there weren't also patent appeals?
Furthermore, in the Google vs. Oracle case the second trial was just on the issue of copyright fair use, wasn't it? Apparently even though the trial court there was just dealing with copyright, because the original action why back at the beginning had a patent claim, it goes to CAFC even though there is now nothing involved that they normally handle.
If we are going to have this screwy appeals path, how about allowing CAFC decisions on matters that are normally out of their jurisdiction, such as copyright, to be appealed to the regular Circuit Court of Appeals they would have normally gone to? CAFC is supposed to follow the regular Circuit Court of Appeals for precedent on such matters, so it seems crazy that the appeals path does not go through that court. As a general principle, if court X is supposed to follow court Y's precedent for something, court Y should be in the appeals path of court X.
> I'm a bit confused about why Congress made appellate jurisdiction with CAFC work they way it does with patent cases.
Economy of justice; otherwise, an appeal of a mixed case would often actually be two separate appeals to separate circuits, each of which would often make some legal decision and remand to the trial court, which would potentially have to wait for both appellate decisions before proceeding, especially if either required a new trial, since those new trials would have overlapping witnesses, etc.
Exactly. Kent Walker's post oozes unearned righteousness. Does anyone believe Google will not be doing the exact same thing with its (moribund) technologies in, say, 5-10 years?
> Does anyone believe Google will not be doing the exact same thing with its (moribund) technologies in, say, 5-10 years?
I believe it, what about Google has shown otherwise? In many situations where they could have been offensively litigious they have not and I value them for that. Much more than many other tech companies that do use their legal department as an offensive weapon.
This is a super important point. Just look at the direction backend software is moving. Think about how many Postgres compatible databases there are. For virtually every major open source project that exists today, there are companies reimplementing pieces of backend to sell performance upgrades to their customers. If Google was able to copyright Tensorflow's or Kubernetes API, it could make it so GCP would be the only ones able to offer an improved runtime for that system, and would absolutely be something that they would very quickly take advantage of.
All the examples listed to the parent comment here are talking about the Google of today (2019). But all businesses come to an end, and some of these later stages look highly litigious (see: Oracle). So in the year 20xx when Google ends up in that phase (owned mainly by activist investors, etc.) how will it act in that circumstance?
I know for a fact that Oracle has weird rules targetting doing business with specific companies because someone from these companies did something bad to them at some point. It usually involves suing them as well. The culture is really weird there as management is some sort of monarchy. I wouldn't be surprised if this one has similar roots.
So if I write a small API that for all intents and purposes is identical to one that Oracle owns, but I write it in a different language, is that still infringing on their copyright? It seems that would have to be the case in order for a pro-Oracle ruling to make sense. If not, then everyone has a good reason to stop using Java.
Companies must be actively reconsidering their involvement with Java - I know a handful.
Google, on their part, is pushing Kotlin to avoid the Java branding. Next is Flutter to entirely get off Java. There seems to be some evidence that they're also beginning to avoid the Android brand in places.
I’m not a legal person or a supporter of Oracle but intuitively I’ve always felt their side of the story. The Java APIs are interfaces, but they’re the result of tons of work which Oracle bought, and it doesn’t make sense to me why those interfaces aren’t their intellectual property.
Because copyright isn't a right earned by effort its an unearned gift designed to motivate increased creativity and output.
Copyrighting api would be so unambiguously bad for tech as a whole that it would be better for society to repeal all copyright rather than accept this interpretation.
The entire industry rests on people making compatible parts. Pretty much all of software and most/all hardware currently used would become illegal in a fashion that would require negotiation with people many of whom are unknown or dead.
Want to reboot the entire tech industry while we shut down pretty much the entire developed world economy that can't operate without it?
We can also effect a global recession in which thousands in the poorer sectors of the world starve.
Or we can pretend this isn't real while the court fixes this.
> The Java APIs are interfaces, but they’re the result of tons of work which Oracle bought, and it doesn’t make sense to me why those interfaces aren’t their intellectual property
Just because something takes work doesn't mean you get a government monopoly on it. Sewing patterns and recipies aren't granted copyright for instance.
The trouble with this line of thinking is there's no viable way to make a legal distinction between interface and implementation. So either interfaces are copyrightable, or code isn't copyrightable.
>So either interfaces are copyrightable, or code isn't copyrightable.
Needs citation?
I don't know where to start, but no, this case ruling in Google's favor would not make code uncopyrightable. The general idea is that there is only one way to copy a method's signature. There are many ways to implement the actual logic. It's hard to find a direct source since no one else is jumping to this extreme conclusion. So the test is, could you have done it another way? And since you can not have a function with the signature System.out without having a function with the signature System.out, it would be considered fair game.
>The trouble with this line of thinking is there's no viable way to make a legal distinction between interface and implementation.
Why not?
Abstractly, interfaces are the ways you interact with a piece of software. Implementation is how the software works. That seems like a clear distinction.
You don't need to say "the interface is in the header files, the impl in the .cc or .cxx ones", specific facts of specific cases can be left to future courts. But it is absolutely possible to tell, in a generic sense, the difference between code and interface.
Doesn't really matter from an IP perspective, if you buy the idea that the work was significant in the first place. (I don't buy that; everybody comes up with basically the same sorts of standard API for their hobby programming language as every other programming language.) But if you accept the premise that the work is copyrightable, then it clearly transfers to Oracle via acquisition.
Google would only be able to sell new versions of Android, mainly starting with 10. They can't revoke the Apache license on Android through version 9.
On top of that, Android 7 already switched to OpenJDK. It no longer uses Harmony as a result in addition to their custom rewrites. So even if Oracle wins, Android hasn't been in violation of any API copyright they have for about two years now.
There was an article on a blog which I can't find now where the author explained this situation in depth. Do any of you have a link to it? I think it would be useful here.
Even with their switch to OpenJDK, they keep cherry picking standard Java APIs, forcing Java library developers to write two versions of their libraries or make do with minimal common denominator.
> they keep cherry picking standard Java APIs, forcing Java library developers to write two versions of their libraries
Can you give some examples of what Android is missing? I know it doesn't implement various packages like awt, swing, javafx, etc., and of course sun.misc.Unsafe. But I wouldn't consider any of that "core Java", and a lot of it doesn't exist in Java ME either.
Are there any disparities in "core Java" libraries, like java.util?
> - Locale.Builder, Java 7, introduced in Android 21
> - java.lang.invoke package, Java 7, introduced in Android 26
> - java.nio.file package, Java 7, introduced in Android 26
Should the legal status of Android really depend in any way on whether or not it is done? Is there any practical way to define public policy that allows a work-in-progress reimplementation for competitive purposes but prohibits an incomplete reimplementation that you don't intend to flesh out to 100% compatibility?
Can you please try to address the distinction between work in progress vs. not even trying for 100% compatibility? Are you saying that neither should be legal, but a complete and 100% compatible reimplementation should? Or are you saying that reimplementations should not be legal regardless of how complete and compatible they are?
I am saying that Google has done exactly the same to the Java community as Microsoft did with J++ and should suffer the same outcome in court as Microsoft did.
It was wrong for Microsoft, it is just as wrong for Google.
Implement whatever Android specific APIs they feel like, but just like ISO C or ISO C++, don't fork the Java standard library.
> I am saying that Google has done exactly the same to the Java community as Microsoft did with J++ and should suffer the same outcome in court as Microsoft did.
As far as I can tell, Sun sued Microsoft for trademark infringement, and Microsoft settled. Which part of that applies to Google?
It really seems that you've decided you want Google to lose regardless of the legal basis used by Oracle. Whereas I think Google should win because of the legal basis Oracle is attempting to use. I don't actually care whether Google ends up having to pay Oracle some money; I just don't want the entire legal foundations of the software industry to be retconned by this case.
Sun sued Microsoft for changes to the Java platform, making it not compliant with the trademark.
I want Google to loose because they succeed where Microsoft failed, forking Java eco-system, and having a bunch of people that call Microsoft the evil empire, actually supportive of Google's actions.
A de facto standard is something that a community iterates on together. S-100, early iSCSI, etc. One company publishing specs and suing competing implementations is not a "de facto standard".
That is your definition, because otherwise the Google PR message is a failure.
de facto - "existing in fact, although perhaps not intended, legal, or accepted:", Cambridge dictionary
"A de facto standard is a custom or convention that has achieved a dominant position by public acceptance or market forces (for example, by early entrance to the market). De facto is a Latin phrase that means in fact (literally by or from fact) in the sense of "in practice but not necessarily ordained by law" or "in practice or actuality, but not officially established", as opposed to de jure."
"Microsoft Word DOC (over all other old PC word processors): one of the best known de facto standards. Due to the market dominance of Word, it is supported by all office applications that intend to compete with it, typically by reverse engineering the undocumented file format. Microsoft has repeatedly internally changed the file specification between versions of Word to suit their own needs, while continuing to reuse the same file extension identifier for different versions."
So much for Google's definition of what a de-facto standard is supposed to be.
But even if it was the full J2SE, better don't let people understand that implementations get improved, that there are commercial Java vendors with better implementations than Android.
Google's PR message would suffer from everyone understanding that improving a platform does not require forking, after all.
Wait a minute. Oracle acquired Sun. And Google acquired Android. Oracle trys to lock down API of Java. Google locked down their services and PlayStore by Google account. Oracle sued Google for Java API usage. Am I missing something? :)
This is a really good case for the supreme court. As much as we may wish to side with Google because it benefits the typical developer, it is a nuanced case that requires some serious legal study. I can see the argument for these API's being in the public domain due to their widespread use, but at the same time, that sets a precedent for making success anti-competitive. I'm reminded of the cases where brands lose their trademark because their brand becomes the generic name. Can that be seen as a precedent in favor of Google's case? I.e. that once something becomes so widely used it becomes generic and free game for others to use freely?
Lots of FUD here. Please see cwyers's answer on this page to see that a ruling in favor of Oracle will change little in terms of where software stands today. Almost all the use cases we see are fair use- except Google's where they deliberately harmed the Java ecosystem, the way Microsoft tried in 1998 (PS: Their JIT actually beat Sun's so in that particular case better technology lost because it was illegal)
I wish you, and cwyers, would provide better reasoning as to why this is all FUD before decrying it as such.
I'm not seeing how "doesn't harm the ecosystem" is a fair-use defense. What logic are you using to arrive at a fair use argument for Linux's copying of Unix APIs that doesn't apply to Google's case?
I'll pose the same examples to you as I did in another thread: IIRC (it was a long time ago) Window's APIs closely resemble or are exactly like OS/2's PM APIs. Windows, one might argue, definitely harmed OS/2's "ecosystem", since the latter is virtually extinct in the mind of the public. Is that a violation of copyright?
Especially since nobody thought APIs were copyrightable right up until Oracle decided to declare them as such, nobody has put anything regarding them in licenses. Nobody has thought that they even needed a license, much less obtained one, and a lot of effort has been built on top of products that are backwards compatible with things from many decades ago.
You know the great thing about copyright? Nobody has to say anything. If it's creative work then you automatically have a copyright. You don't need a (c) 1988-2019 for that.
On the one hand I feel bad for Google. On the other hand, if this is what ultimately ends the twin blights of Java and Oracle on our industry... so worth it.
Oracle is right. Google & Android hinder and split Java with their outdated Java version support. If you write code in Java - now you have to decide whether you want it to be Android-compatible, then you need to limit your code to the outdated API available on Android. Or you can write sterling Java code which can use modern Java API. I hope Oracle wins and Android dies or switches to some other programming language, like Dart or whatever Google is capable of.
I don't think Sun should have protected the code for Java. But I think it should be possible to protect it. Most people here may hate the Jaa language but it took a ton of work and expertise to invent it. And it took something to make the ecosystem as large as it is today. This seems to contain as much intellectual property as something like a book. And when it come down to it, the intellectual property is in the method signatures anyway. There is no big trick to the code inside them. An intern could write that.
As the lesser of two evils, I prefer Google to Oracle. And I hate patent trolls, especially this instance of it. But at the same time I don't want to reduce the legal value of software. If java is not protectable, is a program like Micrsoft Word or Autocad?
Are there any jurisdictions that don't have any distinctions between types of intellectual property (eg. copyright, trademark, patent)? Because in one sense, what makes Oracle's claims so objectionable is that they're trying to assert copyright powers and duration over relatively patent-like subject matter (if you make a fairly simple analogy between software interfaces and mechanical interfaces).
Given that Oracle is claiming copyright on the public API, they can't do that without also removing support for literally the entire app store. It doesn't matter if it's in Go or Java.
While I don't endorse the sneaky way Oracle purchased the rights only to sue Google it does highlight what happens when you become complacent and lose focus on what's important.
If you're serious about an industry, you work to reinvent it like apple has done with their operating system and hardware. If you take shortcuts then you need to face the music and in this instance Google has been out smarted by another industry competitor.
If we support open competition and we believe in Darwin's theory of evolution then Google is the inferior because they took shortcuts & didn't make serious investments in owning the mobile landscape.
> If we support open competition and we believe in Darwin's theory of evolution then Google is the inferior
Evolution theory has no bearing whatsoever on critical moral and philosophical concepts like whether you should be allowed to prevent others from conforming to an API.
Hmm, I agree building everything entirely on your own may have less legal risk. However shouldn't we encourage the use of public standard and compatible technologies, instead of going into the antique UNIX world where everything's proprietary and fragmented?
In my impression that when Google chose Java for the purpose, SUN really wanted Java to be a public interface like thing. Things happened afterwards may be unfortunate.
I don't see why they shouldn't. They're definitely creative works that take skill to produce.
I think using an API for the purposes of interoperability should be allowed under fair use.
However! My controversial opinion is that Google's use of the Java API wasn't for interoperability. They didn't use the Java API so that Java programs could run on Android, they used it so that Java developers could transfer their skills to a new platform which is precisely the value of a cleanly designed API -- value that Oracle doesn't want to provide for free.
I don't see why they shouldn't. They're definitely creative works that take skill to produce.
You're missing an argument in there that joins your two assertions.
The fact that something is creative or requires skill to produce doesn't mean that it should be copyrighted.
Copyright is a government enforced monopoly. In order for society to enforce that monopoly on behalf of private enterprise, there has to be a quid pro quo. The usual one is to promote creation and distribution of new works.
The question then is: would no APIs exist if they weren't copyrightable?
> I don't see why they shouldn't. They're definitely creative works that take skill to produce.
A creative work that takes skill isn't the definition of what should get copyright. For instance sewing patterns and recipies aren't granted copyright.
> My controversial opinion is that Google's use of the Java API wasn't for interoperability.
Following that logic, then any even slightly incompatible implementation wouldn't be legal. For instance WINE isn't a perfect recreation of Win32 by any means.
There isn't really a definition at all of what makes something eligible for copyright protection. What is and isn't covered is fairly arbitrary and informed more by history than logical derivation. Source code is typically viewed as a literary work and I see no reason API documentation would be viewed any differently.
> Following that logic...
I never said it had to be perfect, just that the reason for using the API is for interoperability -- WINE is exactly that. It allows software that was designed for Windows to run on Linux.
> I see no reason API documentation would be viewed any differently
It's not the API documentation that's at dispute here. It's literally the abstract "structure, sequence, and organization" of the API. And there's tons of ninth circuit case law that sso isn't copyrightable.
> I never said it had to be perfect, just that the reason for using the API is for interoperability -- WINE is exactly that. It allows software that was designed for Windows to run on Linux.
What's the test here that a court can use to make that distinction? And just letting you know at one of my former jobs, we modified our codebase to better run on Wine a few times.
> However! My controversial opinion is that Google's use of the Java API wasn't for interoperability.
This brings to mind something I heard from my legal friends in the early days of this case. Their position was that this wasn't a dispute about APIs, copyright, etc. It was a licensing dispute -- Sun/Oracle wanted to charge for Java on Mobile, and Google didn't want to pay. Google then executed an engineering 'hack' whereby Java JVM bytecode (.class files) was converted to Google's Dalvik VM format (.dex) via a tool (dx), thus avoiding Sun's licensing fees and still being able to take advantage of the Java ecosystem.
Their argument would have been this was a fairly mechanical effort to avoid licensing fees, analogous to reprinting a copyrighted book in Piglatin, and therefore Google was liable to pay licensing fees to Oracle.
This was from ages back though; the case has of course evolved since then. I do wonder however if Google's effort to paint this as a case of straightforward re-implementation of an API may not backfire upon them.
It can be API for Oracle or it can be how electronic components are assembled on a ford windscreen wiper https://en.wikipedia.org/wiki/Robert_Kearns The reality is that one person did the hard work (trail and error) while another party commercially benefited with minimal effort.
We need a system that rewards those who experiment & innovate, if anything by Oracle winning this case it further highlights the value in Oracle's IP (promoting innovation and competition).
But if so, that law desperately needs to be amended - the nature of APIs, at least public ones, is such that interoperability concerns override everything else, IMO. If companies can copyright an API and block competitors from implementing it, that would be very detrimental to the industry as a whole, for the sake of a few rent seekers profiting.