One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use:
> To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”
That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory:
> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.
I'll count that as a win, on balance.
It is even less decisive than you're saying.
The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are. And for fair use, one of the statutory factors is the "effect" of the copying on the "market for or value of the copyrighted work."
That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory:
The fact that one statutory factor points one way doesn't stop another from pointing the other. And part of their decision is the conclusion that Google's copying increased the value of Java. That will generally not be true when APIs get copied.
In particular if I am trying to create a product that competes with yours, and I copy your API for the purpose of interoperability, I'm going to have an uphill battle claiming fair use. Because my product directly reduces the market for your product.
To name some historically important examples, Microsoft copied the APIs for JavaScript from Netscape, Microsoft copied APIs from Lotus 1-2-3 for Excel, and Wine copied APIs from Windows for Linux. The outcomes famously were that Netscape went out of business, Lotus 1-2-3 was discontinued, and Linux became somewhat more viable.
>> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.
It's even weaker than you think. It was important that Google's use of Java's API was on a non-competing product. It's still quite up in the air what happens if you provide a generic library using your competitor's API without licensing it from them.
One of the big open questions is "are APIs copyrightable?"
IMHO they got the Huffman table wrong, although arguably it was the result compelled by an overprotective approach.
Also what people fails to realize with fair use is that it is up to the defendant raise a fair use defense and then a judge has to approve of that defense as a valid one (Viva Frei explains this https://youtu.be/AzQz1LrjCWk?t=253 ).Meaning Oracle can still go on with its lawfare campaign against those who made the mistake of basing their tech on theirs.
Well, if you can an API for any primary purpose that not making software compatible with the one you are copying, then it's not really an API. It's perfectly fine if you can't frame it and sell around as a painting.
I'm intrigued by how judgements are passed in such intricate technical matters.
I'm waiting for an ambitious attorney to figure out how to frame this as poaching talent from an ecosystem to bring to another.
Translated into developers speech: this is some sort of early return. ;)
Copyright in a private, internal API seems reasonable in principle.
RIP kotlin-first on android?
Doesn't deciding that it's fair use specifically mean that they think it is copyrightable? The fair use doctrine specifically refers to the use of copyrighted material.
Because the federal courts already ruled that APIs are eligible for copyright [0].
Google wanted to overturn the ruling that they were in violation of copyright and argued they used Java's APIs fairly under copyright law.
The court will not answer questions not put to it, and Google (I presume) felt they had a better shot at getting the court to agree it was fair usage, rather than arguing copyright should not apply here.
0: https://www.paleudislaw.com/federal-circuit-rules-that-apis-...
Is the difference that there's no SCOTUS precedent on the issue because it wasn't addressed in this case? Because (IANAL but) I'd assume the bench direction is itself precedent... In that if another circuit court tried to run a case as if the question was in the open, the Court would again ruler-slap them and say "No, assume APIs are copyrightable, plain language of the law."
Sanity prevailed! This judgment could have had devastating consequences and turned software development into a copyright nightmare.
I also appreciate this fair use argument, especially when you point out the code in question was 0.4% of the entire API.
Still, I'll always struggle with the idea that "the amount and substantiality of the portion used" when copying an interface is comparable to copying an implementation. The interface is, intellectually, the substantially heavier, "bigger picture" component of the API than the implementation. In my view they are apples and oranges.
So, I'm glad this was the outcome. But I'll always feel like there was something wrong with Googe taking the Java SE interfaces and using them like they did, gratis.
It’d sure have made the practice of taking someone else’s API and re-implementing the innards a lot more interesting:
https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3co...
[1] https://en.wikipedia.org/wiki/Eldred_v._Ashcroft
[2] https://www.legalaffairs.org/issues/March-April-2004/story_l...
Also known as compatibility and interoperability. I'm so happy to see that judges understand their importance.
I'm ok with either decision, but, depending on how this precedent going to be interpreted, it could have far reaching consequences, maybe unintentional/undesired ones too.
Based on this court decision, it's apparently fair use to lift someone else's API and use it to jumpstart programmer familiarity with your product, if the author of the API previously tried to achieve success in that narrowly-construed, retroactively-interpreted exact same market segment and wasn't very successful.
I see a few things coming out of this. IP holder companies will become even more common: they will be used to hold copyright to one API and license it out to customers -- including independent companies that you would currently recognize as part of the same platform.
But because the IP holder does not provide an implementation and therefore does not 'compete' in a market segment, any unlicensed use of it is necessarily infringing: there's no innate functionality with which one can interoperate under the doctrine of fair use.
It seems to me the judge is saying, “the house was full of 10 tons of jewelry but the robbers only took 10 pounds so that isn’t really stealing lol “
> Sanity prevailed! This judgment could have had devastating consequences and turned software development into a copyright nightmare.
This judgment is the equivalent of someone taking a movie script, shooting a new movie out of it without changing a word, and the court declaring this "fair use" of the script.
Software development wouldn't have turned into a nightmare unless you decide to steal a platform. Which most people don't need to do in order to do their work.
From 2018 (Oracle revives matter via appeal): https://news.ycombinator.com/item?id=16688521
Edit: Fixed, had written "Jury finds for Oracle", which was NOT what happened in 2016. Argh.
They were then overruled by the Federal Court, which has now in turn been overruled by the Supremes.
What happens after this, more appeals or is this like a proper static const readonly final?
It's worth noting that the higher court can reject your appeal. You're not entitled to be seen by the higher court, and if you can't come up with good grounds for why the lower court was wrong, the appeal will be rejected. The Supreme Court rejects a fair number of appeals (I think the majority of cases).
This is final though. There is no higher court than the Supreme Court to appeal to. At this point, the only reason it would change is if the laws change, or the Supreme Court reverses their decision later. It's extremely rare that they whole-hog reverse a precedent that they set, though.
"The fair use question is a mixed question of fact and law. Reviewing courts should appropriately defer to the jury’s findings of underlying facts, but the ultimate question whether those facts amount to a fair use is a legal question for judges to decide de novo. This approach does not violate the Seventh Amendment’s prohibition on courts reexamining facts tried by a jury, because the ultimate question here is one of law, not fact. The “right of trial by jury” does not include the right to have a jury resolve a fair use defense."
> Re- viewing courts should appropriately defer to the jury’s findings of un- derlying facts, but the ultimate question whether those facts amount to a fair use is a legal question for judges to decide de novo. This approach does not violate the Seventh Amendment’s prohibition on courts reexamining facts tried by a jury, because the ultimate question here is one of law, not fact. The “right of trial by jury” does not include the right to have a jury resolve a fair use defense.
I'm not a lawyer so I don't know exactly what this means, other than the SCOTUS saying that it can override the jury decision.
The point in this case was, can Oracle overturn the "phone books cannot be Copyrighted" concept baked into tech law by the IBM v Compaq BIOS case. Seems the Supreme Court finally told Oracle the collection of method signatures from the Java base API are, indeed, a phone book.
The idea in that case was that when you try to implement something identical to the Java language and standard library, it doesn't matter if you call it Java or "Visual J++"; you are still implementing Java and thus in order to be able to do that you need to agree to Sun's terms (in that time, it was that your implementation needed to pass a testsuite and among other things needed to be "write once run everywhere", something the MS one definitely didn't as it was offering lots of non-portable extensions).
Now to my understanding the opinion here is that literally Sun was trying to do the same to Google (forcing them to ensure their implementation was compatible with Sun's, including being able to run Android software under Sun's JVM), which would have quite put a setback to Android at least as it was at that point (could you imagine Android forced to go with Swing?).
If I try to be fair, I find that in fact Android did succesfully pull the embrace-extend-extinguish strategy that MS was prevented to by legal reasons, and as a consequence basically killed Java on the mobile space (though Oracle has a lot of blame to share here). Perhaps the tides turned and now Google is seen as the lesser evil when compared to Oracle, while in the past Sun was seen as the lesser evil compared to MS. But is there any objective reason why the two rulings should have gone differently?
I am actually completely undecided about how I would have liked this ruling to go. I can see some of the repercussions of being able to copyright "header files" way too dangerous to ignore, but on the other side I have already seen the consequences of not being able to, and they are also bad.
Alien vs predator...
Google however made sure to always be clear about "the Java Programming Language" or such safe phrase that makes clear that they're not the official thing.
On the flip side, if Microsoft had been judged by the same standard, they might determine that Microsoft's reimplementation of an incompatible Java would have too much of an economic impact on the original to be fair use.
Microsoft lost because Microsoft had signed a contract with Sun, and was found to have broken the terms of the contract.
Google never signed a contract with Sun, so was free to act in ways that Microsoft was not.
It's worth pointing out that the list of examples of "Embrace, Extend, Extinguish" on the wikipedia page of that name [1] contains zero actual successful examples of it working. Perhaps you have noticed that you aren't reading this page in an ActiveX control.
This is a boogeyman. Don't be afraid of it.
[1]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
The real answer is that copyright is the wrong tool to go after what Microsoft did and the correct tool for that is antitrust. EEE is anti-competitive even if copying an API is fair use.
I wonder if Microsoft's actions could have been ruled at the time as violating antitrust laws instead, if the copyright interpretation had fallen flat? Perhaps upcoming antitrust investigations into Google will look at their re-implementation of Java interfaces in the same light?
But Google (at least with respect to phone OS) was in the position of the startup, and Sun was the big market player. Now, Google had with ridiculous resources at its disposal, of course, but at the time not using a monopoly position to twist arms of carriers, for example. It's not anti-competitive to spend a lot of money to win.
Of course, things change....
I'm sorry, but this smells like a bad faith argument.
> The Copyright Act expressly protects computer code. It recognizes that a “computer program” is protected by copyright... And it defines “‘computer program’” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” §101. That definition clearly covers declaring code—sets of statements that indirectly perform computer functions by triggering prewritten implementing code.
Thomas seems confused here. An API (declaring code) is not a computer program. A computer cannot execute declaring code - by definition - because it is missing the implementation.
Declaring code does not "indirectly perform computer functions". Declaring code does not perform anything. It provides a reference, nothing more, for a compiler to match one computer program (the API client) to another (the API implementation).
> declaring code would satisfy the general test for copyrightability.. they are expressed in “words, numbers, or other verbal or numerical symbols
It is common knowledge that mathematical formulae & equations, which are also expressed in words, numbers, and symbols, do not have copyright protection.
> Copyright protection is therefore not available for... mathematical principles; formulas or algorithms
https://www.copyright.gov/circs/circ31.pdf
> public static int MaxNum (int x, int y, int z)
This is literally a mathematical formula, hence does not have copyright protection.
Declaring code in statement based languages is (1) a set of statements, is (2) used directly or indirectly in a computer, and it is used (3) to bring about a certain result. That hits all the points listed in 17 USC 101.
This is trivial to prove. Take a program that works and remove the declaring code. The program no longer works. That shows that the declaring code is indeed being used by the computer, and it is being used to bring about a certain result.
That the declaring code is not directly used in actually calling the API is irrelevant. The "certain result" the declaring code is used to bring about is the compiler producing output that works with the API.
public int max(int x, int y);
Is a program that tells a compiler or VM to add an entry to its public symbol table that allows it to compile or execute third-party code utilizing this function, and that the declaration, by itself, then qualified as a computer program and could be copyrighted, where would you draw a limit? Would two different programs that produce identical assembly instructions infringe on each other's copyright?
What about system calls for an OS? For example, Linux system calls have names, but they also have numeric identifiers. If someone copied Linux system call names in a new BSD-licensed OS, would they violate the GPL? What if they only copied the numbers?
It's interesting to think about. I'm glad this was the minority opinion.
This standard doesn't really make sense, and the legal standard says nothing about executability. What about programs with external dependencies, or a code snippet? Those won't necessarily be executable in a self-contained sandbox, but I'd certainly consider them computer programs.
Also, per Thomas's dissent:
> The majority also belittles declaring code by suggesting it is simply away to organize implementing code. Not so. Declaring code defines subprograms of implementing code, including by controlling what inputs they can process. Similarly, the majority is wrong to suggest that the purpose of declaring code is to connect pre-existing method calls to implementing code. Declaring code creates the method calls.
He clearly has a much better understanding of APIs than some software engineers I've worked with.
But a program that only declares functions never brings about a result.
Declaring code is just the recipe for how to invoke implementing code.
Yup, for all intents and purposes an API is just a data exchange contract between different software.
If you allow null pointer references to a declared variable, then it certainly can.
>Declaring code does not "indirectly perform computer functions". Declaring code does not perform anything. It provides a reference, nothing more, for a compiler to match one computer program (the API client) to another (the API implementation).
I strongly disagree. We understand the obvious difference between declaration and instantiation, as declaration brings a variable into existence while instantiation specifies the variable's value. Declaring a variable is ultimately based upon available language primitives.
Whether or not he realized it, Thomas draws out a deep philosophical element of computing. Consider the creation of a self-hosting compiler. Once created, this compiler has an identity. However, creating this compiler required the usage of other software tools, each of which have distinct identities. Once the compiler operates, its creating tools become unnecessary to it, as the compiler operates independently (though the broader system may not). His phrase "triggering prewritten implementing code" has full-stack implications, whereas the majority opinion considers scope.
To connect to hierarchical processing model of programming, the majority opinion says a top-level processing block is special, whereas Thomas says no processing block differs from one another.
From a business perspective, I agree with the majority. From a philosophical perspective, I agree with Thomas.
Hackers and programmers tend to try and read the law like computer code to be "hacked" and exploited based on the letter of the law. So you'd expect us to be more sympathetic to Thomas' view. So this is a great example to smack hackers with when they try and "hack" the law, treating it like code rather than something more human. It's a great example because this is a case where the majority is obviously the "right" decision to any true code hacker.
Textualists are trying to ignore the fact that there's a difference between intent and implementation.
The Legislature should do a far better job making their intent clear. But to the degree they make mistakes, leaving the intent unclear in some situation, it's good to have Case Law to inform us.
I am not a lawyer. I don't know much about the law. But I do know metaphors, and when someone talks about exploiting the law, this is what comes to my mind.
Speak for yourself. There are plenty of us that understand you can't take the human element out of this.
1. An important fair use test is market effects. 2. Amazon and others used to give Oracle huge gobs of money because they feared that APIs might be copyrightable and not covered by fair use. 3. After Google called Oracle on this, Amazon and others also started believing it was likely fair use and stopped paying Oracle tens of billions per year. 4. Therefore, Google copying the API was a major adverse market effect. 5. Therefore, copying wasn't fair use.
That's a shit argument. Watch me do a similar analysis in a more obvious way.
1. An important fair use test is market effects. 2. People used to pay gobs of money to watch the movie Transformers 2. 3. In a widely watched review of the film, I showed a 4 second clip of the movie where someone said "I am standing directly beneath the robot's testicles." 4. After this, nobody wanted to pay any money at all to watch Transformers 2. 5. Therefore, there was a major adverse market effect from my copying. 6. Therefore, copying wasn't fair use.
https://en.wikipedia.org/wiki/No_true_Scotsman
Have you spoken to any professional language or API designers about this case? Would all "true code hackers" agree that copyright shouldn't apply to software at all?
So in effect, "following the letter of the law" enlarges a judge's discretion. The opposite of what you would expect.
"Google’s limited copying of the API is a transformative use. Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. "
...
"Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE."
...
"Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment. "
...
"the Court concludes that Google’s copying of the API to reimplement a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, constituted a fair use of that material as a matter of law. "
If the un-italicized is the new test, that's probably the most reasonable thing I'm going to read this month. And it's only the 5th.
Does this mean that companies copying the S3 API as a substitute for S3 are still untested territory?
Well that nukes it. The courts took how long to identify this precedented principle? It seems like the rest of the opinion is just there to ward off more of this tomfoolery for people that don't get it.
Breyer also has a brother who was a District Court judge in the SF Bay Area who's undoubtedly had to deal with various tech cases. Not saying there's any kind of shared knowledge of tech within the Breyer family but just kind of interesting.
Emily Barnet, 2020, Yale (2015)
Diana Li Kim, 2020, Yale (2017)
Arjun Ramamurti, 2020, Yale (2018)
Daniel Richardson, 2020, Virginia (2018)
Brittany Jones-Record, 2020, Stanford (2016)
David Scott Louk, 2020, Yale (2015)
Elizabeth B. Deutsch, 2021, Yale (2016)
Joel F. Wacks, 2021, Chicago (2018)
[1] https://en.wikipedia.org/wiki/List_of_law_clerks_of_the_Supr...
This case involved copyright, not patents. Copyrights are separate from patents.
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
The first phase of the case lasted from 2010 to 2015. Oracle successfully established that APIs are copyrightable, but their claims of patent infringement were rejected. Google petitioned the Supreme Court in October 2014 to review the case, but this was denied. A second petition by Google in January 2019 included the judgement that APIs are copyrightable. The Supreme Court agreed to review this part of the judgment in November 2019.
To the degree that SCOTUS has found that an API can be copyrighted, there is still room for copyright trolls to operate.
In particular, social-media aggregators (one app to display your Twitter, FB, Instagram, etc.) may have new protections.
Open source code is still usually copyrighted. Nobody would trust closed languages and APIs unless they paid a fortune for them while open source with a grant would be safe to use.
Or prevent them from eradicating competing or even original projects by doing hostile rewrites or forks?
"The Google platform just got bigger and market power greater — the barriers to entry higher and the ability to compete lower. They stole Java and spent a decade litigating as only a monopolist can. This behavior is exactly why regulatory authorities around the world and in the United States are examining Google's business practices."
- Dorian Daley, Executive Vice President and General Counsel, Oracle
[1]https://www.prnewswire.com/news-releases/oracle-statement-re...
Now if we only could get the SC to invalidate software patents in general.
If you're big enough and have enough lawyers, there's no reason to license software you want to build on.
Can you elaborate on that? What does this have to do with those thing?
> The argument centered on a function called rangeCheck. ... It was in Oracle’s interest to play up the significance of rangeCheck as much as possible, and David Boies, Oracle’s lawyer, began to argue that Google had copied rangeCheck so that it could take Android to market more quickly. Judge Alsup was not buying it.
> “I couldn't have told you the first thing about Java before this trial,” said the judge. “But, I have done and still do a lot of programming myself in other languages. I have written blocks of code like rangeCheck a hundred times or more. I could do it. You could do it. It is so simple.”
https://www.theverge.com/2017/10/19/16503076/oracle-vs-googl...
He learned Java for the case, but he was already an accomplished developer: https://www.theverge.com/2017/10/19/16503076/oracle-vs-googl...
https://majadhondt.wordpress.com/2012/05/16/googles-9-lines/
Is this example correct? Can someone explain to me how this: if (toIndex > arrayLen)
is correct?
If the array length is say 5, and toIndex is 5, that should still throw an index out of bounds exception, right? But it would be acceptable here.
That David Boies? I guess law firms will represent whoever will pay, but it seems somewhat funny that he also represented The SCO Group in their litigation against IBM...
Sun Microsystems was acquired in 2010... I guess I should give Thomas the benefit of the doubt that he intended the statement to apply to Oracle's owned IP & not be a historical account of the language's creation and creators, but this rubbed me the wrong way.
What really happened here is that the Supreme Court did an end-run around the law to paper over a major fuckup by Congress. On the one hand, I'm glad that they fixed the problem. But the way that they did it fills me with dread for the future because it undermines the rule of law.
For the record, I absolutely despise Clarence Thomas and everything that he stands for. But in this case I think he has a valid point.
You seem to have misunderstood the idea of fair use. Fair use is a specific doctrine covering the acceptable ("fair") use of copyrighted works. Fair use of a non-copyrightable work would be, technically speaking, a contradiction in terms.
See, for example, the US copyright office's explanation: https://www.copyright.gov/fair-use/more-info.html The first sentence is "Fair use is a legal doctrine that promotes freedom of expression by permitting the unlicensed use of copyright-protected works in certain circumstances."
Furthermore, there is no requirement that fair use be non-commercial. It is more likely that the courts will find that non-commercial use is fair, but that is not a hard and fast rule. An easy example here is book reviews quoting passages from the text.
This is addressed in the decision on page 27. The Court wrote:
The text of §107 includes various noncommercial uses, such as teaching and scholarship, as paradigmatic examples of privileged copying. There is no doubt that a finding that copying was not commercial in nature tips the scales in favor of fair use. But the inverse is not necessarily true, as many common fair uses are indisputably commercial. For instance, the text of §107 includes examples like “news reporting,” which is often done for commercial profit. So even though Google’s use was a commercial endeavor—a fact no party disputed, see 886 F. 3d, at 1197—that is not dispositive of the first factor, particularly in light of the inherently transformative role that the reimplementation played in the new Android system.
I think reasonable people can agree with Justice Thomas on this (sidebar: this is why I love reading SCOTUS rulings - they're generally wise people and both the majority and dissent sides are usually reasonable takes). The tests of "is it transformative" and "how much was taken" are probably the most subjective tests in the copyright precedent.
The precedential parts are unambiguous: Google's actions were fair use, as a matter of law (this is code to lower courts to not fuck around). The majority opinion did not answer whether APIs are copyrightable in the first place because it was unnecessary to settle the dispute.
The rest of it is obiter dicta. Thomas's objection, as is usually the case, is irrelevant.
IANAL, TINLA.
But the dissent raises an interesting point. I think it shows how the crafting of legislation by people who are wholly ignorant of technology can create problems. While programmers recognize the difference between an API and it's implementation, Thomas makes the interesting point that the relevant legislation does not (page 4 of the dissent):
> Copyright law generally protects works of authorship. Patent law generally protects inventions or discoveries. A library of code straddles these two categories. It is highly functional like an invention; yet as a writing, it is also a work of authorship. Faced with something that could fit in either space, Congress chose copyright, and it included declaring code in that protection.
> The Copyright Act expressly protects computer code. It recognizes that a “computer program” is protected by copyright. See 17 U. S. C. §§109(b), 117, 506(a). And it defines “‘computer program’” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” §101. That definition clearly covers declaring code—sets of statements that indirectly perform computer functions by triggering prewritten implementing code.
While it clearly is in the Court's prerogative to interpret law, there seems to be a pretty good case that the court didn't provide an interpretation for a gap in the law, it instead fixed a law that didn't make sense.
Since it's API's all the way down, this is needed to protect any application on top of the BIOS/OS/HAL.
Otherwise, very little would be protected by copyright.
However, it's entirely possible that "indirect" is a word with a definition that is different to our understanding in legal documents.
"We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copy-righted. "
When the API definition is a small portion of a work, it is fair use to reimplement the api
https://www.independent.co.uk/life-style/gadgets-and-tech/ne...
In the case of the music project, it was for the protection of the community, but I can imagine such a system being used selfishly for software APIs.
It would have officially mean businesses and the US governments are locked by vendors and have no right to copy API in order to provide compatibility towards other systems.
Making « VendorLocking » legally valid in favor of the vendor.
Not gonna lie I was scared by the outcome of that judgement and the catastrophic defense of Google.
I’m now relieved !
However, that would indeed require a ton more work to prove that you did not copy any of the generated work and truly did create yours by yourself.
It's great for software, it'll be an interesting documentary someday. And congratulations to all the lawyers for making a ton of money.
The weird thing is it would of hurt Oracle as much as anyone. I have no clue how anyone w/any technical merit didn't understand that this was a footgun of the largest possible magnitude for them.
Because of the way this decision went, I’m sure Google considers it a worthy investment and Oracle considers it a temporary setback as it pursues other extortion schemes using Sun’s Patents. I wouldn’t be surprised if they have a specific division of lawyers dedicated to finding novel ways of extorting wealth using Patents; this would likely just be one of the cases they were working on.
Come to think of it, from Oracles perspective it was definitely worth a shot, to throw a few millions (if that?) with a chance of winning billions.
I would think this would crack ARM's control over their instruction set though. I can't imagine it'd be worth re-implementing literally the entire thing from scratch though when ARM will willingly sell you IP blocks, as opposed to Intel or ARM which will certainly not.
So the opinion effectively preserves the status quo in the software industry while sidestepping the question of API copyrightability.
"Instead of creating its own declaring code—as Apple and Microsoft chose to do— Google copied verbatim 11,500 lines of Oracle’s declaring code and arranged that code exactly as Oracle had done."
I didn't read the whole opinion, but what is Google's excuse for this? If there's one way to do it, I don't think copyright should apply. But when there's more than one way, why should copyright not provide some protection? I guess just because it's tiny and contains little expression?
Regardless, it seems like very poor judgement to not do a cleanroom implementation here.
They _did_ do a cleanroom implementation, that's the whole issue that makes it an interesting case: are APIs fair use?
What kinds of actions and motivations by Google could have led to a determination that the use was not fair?
Or is Embrace/Extend/Extinguish as practiced by the big tech companies now always protected by fair use?
We see the majority trying to preserve flexibility in fair use throughout, even going so far as to head off arguments that this decision affects others:
> We do not say that these questions are always relevant to the application of fair use, not even in the world of computer programs. Nor do we say that these questions are the only questions a court might ask.
> The fact that computer programs are primarily functional makes it difficult to apply traditional copyright concepts in that technological world. ... In doing so here, we have not changed the nature of those concepts. We do not overturn or modify our earlier cases involving fair use. ... Rather, we here recognize that applications of a copyright doctrine such as fair use has long proved a cooperative effort of Legislatures and courts, and that Congress, in our view, intended that it so continue.
We see Thomas leading this question in dissent:
> Because the majority's reasoning would undermine copyright protection for so many products long understood to be protected, I understand the majority's holding as a good-for-declaring-code-only precedent.
Fair use is a mishmash of vague, impressionistic factors and a long list of cases from which to argue by analogy. It's not sharp-lines law. It's finger painting.
Which is why lawyers so rarely recommend that people rely on fair use in any really meaningful way, outside areas where there have been a lot of court decisions, or where strong industry norms have evolved between repeat players.
This is EXCELLENT news for anyone in software development. Yay for Fair Use.
The Court is apparently not familiar with much of my code :)
We reach the conclusion that in this case, where Google reimplemented a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, Google’s copying of the Sun Java API was a fair use of that material as a matter of law.
Also, while I hate to just repeat things that have already been said, I feel compelled to say
"What a relief!"
because this would have been a complete disaster if they had gotten this decision wrong. In fact, I'm not sure "complete disaster" is a strong enough phrase to reflect what it would have meant for the software industry if this had come down the other way. So getting this looming disaster out of the way is a tremendous relief.
Google implemented exactly enough to create the illusion of letting people use their Java talents then dragged their feet with a half broken out-of-date language environment.
And they did all this to save money, not some sort of noble rebellion or clever hack.
> Sun offered a licensing deal of between US$30 and 50 million. Schmidt said Google would have paid for that license, but they were concerned that Sun had also requested some shared control of Android along with the fee.
A pittance for Google but that vague "some control" sounds really bad right? Well fortunately there's a history here and we know from past licensing deals (J++) this control is enforcing interoperability with other Java implementation. And of course Oracle spells that out pretty easily:
> Oracle states that Sun refused because Google’s intention was essentially to fork Java to a Google version of the language, and to prevent it being inter-operable with other versions, an idea which was “anathema” to the “write once run anywhere” basis of the language.
Google got a cheap license and the only stipulation was "don't fuck up the Java ecosystem by having your OS run Java-but-not-really" but that was too much for them and exactly what they ended up doing!
I don't know why people are acting like this is some victory of open source. Maybe a victory for open source, but championed by a greedy corporation that fragmented the Java ecosystem for years.
I wish Oracle could have taken another angle here, they deserved damages from Google for this. Google literally pulled a J++ and got away with it.
Let me give you one example as an electronic musician. Once upon a time, Steinberg created an API for connecting programs which simulate musical instruments and musical effects (think reverb, echo, flanger, etc.) called VST. This API was always proprietary but everyone ending up using it, including the open source Audacity program which uses an open source re-implementation of the VST API, allowing it to use professional effects when editing tracks.
Well, Steinberg decided that VST2 — the one everyone has been using — was out of date and removed all downloads to the VST2 API, since they wanted users to upgrade to VST3. While a lot of professional music making tools have updated to VST3, others have not, and a lot of tools will never be updated. Steinberg no longer has a copy of the VST2 SDK available for download; they’re really trying to get everyone to update to VST3.
Now, with this horrible “Google vs. Oracle” precedent looming over everyone’s head that a company was allowed to copyright an API, Steinberg could had, in theory, said “VST2 is copyrighted, and Audacity is not allowed to use their own independent implementation of that API” (they didn’t in practice because they know it’s bad business; indeed VST3 is dual licensed, where GPL3 is one of the license options).
With this precedent, the Audacity team can more easily retain their independent implementation of VST2 knowing the legal precedent saying re-implementing an API is fair use.
It was always possible to release APIs as open-source. There's as much chilling effect about proprietary software as there ever was being careful about using licensed work, and that was never a problem.
On the other hand, the hunting season on companies providing software is now open. You're a startup providing a new database, or a well-thought library? Shit, you better take the VC money before someone else does and puts you out of business. And when a company like Amazon comes with an offer, you better not be in a bargaining mood.
The benefits of reimplementing APIs always flow both ways. I'm glad SCOTUS recognised this point.
That is exactly what was the “damage” Oracle sued for.
https://news.ycombinator.com/item?id=26590524
Specifically, this thread about copying the readline API: https://news.ycombinator.com/item?id=26606328
Stallman's contention that a judge would look unfavorably on cloning the API signature because it could be viewed as subterfuge...seems very weakened here, if copying an API is fair use.
I suppose this also gives companies like Amazon a green light for clones of GPL software exposing an API that's identical.
In fact a good chunk of the case law cited today hadn't even hit the courts yet at the time Stallman made that statement.
« Google’s limited copying of the API is a transformative use. Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform — the Android platform — that would help achieve and popularize that objective. »
« Here Google’s use of the Sun Java API seeks to create new products. It seeks to expand the use and usefulness of Android-based smartphones. Its new product offers programmers a highly creative and innovative tool for a smartphone environment. To the extent that Google used parts of the Sun Java API to create a new platform that could be readily used by programmers, its use was consistent with that creative “progress” that is the basic constitutional objective of copyright itself. »
This suggests to me that someone who copies a set of function declarations for the purposes of, say, creating a free-software clone of an existing product might not be able to rely on this decision.
They wouldn't need to rely on this decision.
The courts tend to frown on using IP law as a weapon against interoperability or legitimate competition outside the scope of what the IP law covers. If you get sued for copying Yoyodyne's API in order to develop an otherwise original piece of software whose purpose is to interact with other software that expects Yoyodyne's program, the appeals court is likely to smack the suit down citing Sega v. Accolade and Sony v. Connectix, and the SCOTUS (assuming it gets that far) is likely to agree.
One of Oracle's major arguments was that Android was not interoperable with regular Java, and in Oracle's position the fact that Google copied Java's declaring code just to screw Oracle over put Android outside the bounds of interoperability fair-use protection.
Excerpts:
The nature of the work at issue favors fair use. The copied lines of code are part of a “user interface” that provides a way for programmers to access prewritten computer code through the use of simple commands. As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task. As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system. Given these differences, application of fair use here is unlikely to undermine the general copyright protection that Congress provided for computer programs.
I love this analogy, and I'm going to use it to describe this case from now on. If I have a great idea for a new keyboard, maybe great new clicky keys or something, I have to make it QWERTY. I can't just come up with some random key ordering. And it has nothing to do with how good or bad QWERTY is as an idea. It's just that QWERTY happens to be what people have skills in.
And yes, if ease of use will be a differentiator why people like Apple (whether it's right or wrong), then so is the ability to learn is an attribute to be protected from theft.
I say all this seeing exactly where Swift is heading, and probably why Apple created the language that will run their unified APIs... because there's no other way to join except through their Swift gates.
APIs have been copyrightable (in the US) since 2014(or 15, not sure). This ruling only affects the fair use judgement, and makes no further statement on the question of copyright; meaning APIs are still subject to copyright.
Breyer's decision explicitly avoids deciding whether or not the SSO being copyrightable is good law, but it does essentially provide that it provides only thin copyright.
How would it been possible for Google to do this without just taking the API definitions.
Could they have just use compiler errors?
In what circumstances would non-fair-use copyright then apply?
This case was originally granted back in 2019. It was scheduled for oral argument in March 2020, but was postponed at the last moment until October because of the pandemic. Being postponed at the last moment, it was fully briefed well over a year ago, and the justices likely knew how they would rule in the case for a long time. (It's unclear how much of an impact oral argument actually has on influencing the decisions). That it took so long for a decision to come out--this is the last October hearing to get an opinion--strongly suggested to me that this would be a messy case with several overlapping concurring and dissenting briefs.
It is not. It is a simple 6-2 decision, with a single majority opinion and a single dissenting opinion. I'm reading between the lines here, but it seems pretty clear that Breyer (the majority opinion author) does not believe that APIs are copyrightable in the first place, but doesn't argue that point as he probably does not have enough other votes to agree with him. It's plausible that Breyer had a lengthy section on why APIs weren't copyrightable but that was pulled due to the other justices in the majority rejecting it. We can't know what the voting would break down as, but a 3-3-2 breakdown of "API is uncopyrightable; API is copyrightable, but this is fair use; API is copyrightable, this is not fair use" does not strike me as implausible. (There's not much in favor of this breakdown, note: that I lay it out like this is as much wishful thinking as anything else).
Thomas's dissent--I'll focus on that first--essentially makes two main arguments. The first is that API is copyrightable in its own right (Breyer's opinion assumes that it is for the fair use analysis but doesn't say that it is). The second argument is that Google's copying of the API cannot be fair use. A lot of that argument appears back-reasoned from "Google copied so much of the API and they made so much money off of it, how can it possibly be fair." In a broader sense, however, it's a different mode of fair use analysis than Breyer argues for. Thomas essentially views copyright as a property interest, and fair use is a narrow limitation on property interest. The API is an entity in and of itself here, so even though the API is a tiny fraction of both the original and reimplementing code, you need to look at the amount of the API itself that is being copied to judge how substantial a portion it is. Although when he turns to consider the impact that an independent implementation has on the market for the original, it's not the market of the API itself that matters but the market of the entire implementation.
Now going back to Breyer's opinion, he treats fair use rather differently. First, Breyer essentially invokes the idea that different kinds of copyrighted material deserve different amounts of protection. He draws a distinction between declaring and implementing code, and notes that since only declaring code is being copied, it pushes the factor analysis much more towards being fair use than otherwise. In contrast to Thomas, Breyer notes that commercial use isn't automatically non-fair use, and lists a few examples of where commercial use can indeed be fair use. Also, Breyer pushes hard against the idea of copyright being about property interests, noting that the Constitution expressly provides that copyright is for the progress of science and arts. Whereas Thomas places primacy on the importance of the effect of the market, Breyer instead contends that it's the least important factor here.
All the way back at oral argument, Thomas surprised me with the most insightful question: the fair use factors in the law are very explicitly a nonexhaustive list, so what other factors might exist to sway fair use analysis? At opinion time, Thomas is instead the one to declare that none other exist, while it's Breyer who rather strenuously comments that fair use analysis is not exhaustive, although he does not include any other factors in his analysis.
What's the overall impact, then? APIs may or may not be copyrightable--SCOTUS does not decide. But Breyer essentially suggests that APIs have at best "thin copyright"--a lot of their use may be inherently fair use (the same analysis Breyer does here can reasonably be copy-pasted for a lot of API reimplementation cases). What's more radical is the effect it has on fair use analysis. Breyer states that appeal courts have to reconsider fair use on appeals if juries find a use to be fair or not (that's an easy part of the opinion to miss). Breyer upends the traditional notion of how to balance fair use factors yet again. Essentially, he suggests that the analysis of fair use is dependent in large part on what kind of work is being copied, and the balancing is dependent on the kind of work. He also rejects a lot of the traditional emphasis on market or potential market analysis for fair use. This is somewhat disclaimed for wider application to non-code cases, but you can bet there is now going to be a lot of appeals surrounding fair use over the next few years.
I'll add that Thomas points out that if Breyer wants to talk about "thin" copyright, he should have discussed it within the copyrightability context, not skirting and discussing it in the "fair use" segment. If Breyer does so, Thomas argues, Breyer would find that "thin" copyright is still copyright, and Google will have no argument left to support fair use. All the remaining facts (such as competition, loss royalty, etc.) would support non-fair use.
Oracle could launch a new case but it would have to rely on entirely different merits. If Oracle did have such other grounds for a suit, they would have included them in this case.
https://github.com/JoshCheek/clisp/blob/master/doc/Why-CLISP...
* Some small functions were directly copied, but nothing major
So a computer program instructs processors to do things while books do not necessarily instruct neurons to do things. This seems like a leap. I could write a book with NOP for every word or I could write a program with NOP loops. Are these really instruction to do things? Like so, books do instruct people (aka knowledge).
Google took tons of APIs from a platform and implemented them into... a platform.
If you think designing thousands of classes is not substantial that's a very different argument, different from fair use.
Fair use means yes, APIs are copyrightable, but this is transformative use. And, to anyone with a clue in software dev... no it's not.
It's basically like taking someone else's script as-is and shooting a movie from it, and the court deeming this use of a script "fair use".
The wholesale expropriation of an API is not the same thing as taking a small snippet of a copyrighted work for analysis, commentary, criticism, or scholarship. It is core the value of the work.
Indeed, it's the most important part, because it defines the functionality of the product. It is what the customer sees and interacts with. It is the means by which the customer gets value. You can completely swap out the backend behind the API and the customer will still get value. Change the API and the value goes away.
From a legal perspective, this decision is 100% wrong. The plain language of the law makes that clear.
What should have happened here is that Congress should have passed an amendment to copyright law allowing for fair use of an API. They should have done so after a free and full debate, with due consideration to all economic consequences.
It is not for our black-robed, un-elected overlords to make this decision.
If I specify that my company takes orders that only have certain header columns and must have specific format in certain fields on the bill of goods, is that /specification/ (not the full text I wrote, but the facts of the specification itself) copyrightable? Why? I don't see that the abstract facts of a specification of interoperability should receive any kind of copyright.
https://news.ycombinator.com/item?id=26699106&p=2
https://news.ycombinator.com/item?id=26699106&p=3
(If you've already seen a bunch of these, I apologize for the annoying repetition.)
Interesting to see SCOTUS citing Lotus v Borland, which was originally deadlocked at 4-4 (although Breyer seems to have voted in favour of Lotus back then). Does this elevate the precedential value of Lotus?
...enforcement of the Sun Java API copyright might give Oracle a significant share of these funds. It is important, however, to consider why and how Oracle might have become entitled to this money. When a new interface, like an API or a spreadsheet program, first comes on the market, it may attract new users because of its expressive qualities, such as a better visual screen or because of its superior functionality. As time passes, however, it may be valuable for a different reason, namely, because users, including programmers, are just used to it. They have already learned how to work with it. [...]
This source of Android’s profitability has much to do with third parties’ (say, programmers’) investment in Sun Java programs. It has correspondingly less to do with Sun’s investment in creating the Sun Java API. We have no reason to believe that the Copyright Act seeks to protect third parties’ investment in learning how to operate a created work. [...]
Finally, given programmers’ investment in learning the Sun Java API, to allow enforcement of Oracle’s copyright here would risk harm to the public.
If one were to apply the above logic to anti-trust instead of copyright fair use, one might wonder if the Court could find harm to the public in certain behaviors of e.g. a monopoly email provider or monopoly social networking site.
(A big argument against anti-trust enforcement against Google and others is that the Sherman Act is designed to protect consumers, not competitors.)
> The copied lines of code are part of a “user interface” that provides a way for programmers to access prewritten computer code through the use of simple commands. As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task
> As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system.
The dissent is worrying, though. For a pivotal case that would have had a profound adverse effect on the future of software development had it been decided the other way, there seemed to be a disturbing lack of appreciation of the fundamental issues in play, particularly the practical reasons that programmers separate interface and implementation and the implications of this for interoperability.
With this ruling, either software will be found to be entirely (or mostly) uncopyrightable, which is unlikely, or software copyright will turn into an even bigger legal morass that requires a team of top-tier lawyers just to understand which parts of your software are effectively copyrightable (or potentially infringing) and which aren't.
The Supreme Court should have found in favor of Oracle, and told Google to bring their case before Congress if they're so worried that API copyrightability would destroy the industry.
Using Stripe?
You're literally one-click away from our new Google Payments?
Just change this URL, and you're good?
I'm not as keen about the outcome as others.
It's good for open source in a way but I'm wary of big cos just wiping out smaller one's.
Also - does anyone with insight have something to say about open source APIs being copied, to get around copyleft?
Could GPL'd software now be 're-implemented' without concern?
Am I right that this may essentially end Dart project at Google?
As far as I understand Dart was an attempt to have another Java in case that Oracle/Google conflict will not go anywhere.
As soon as Google will be able to use Java on dart platforms there will be no need for Dart.
Just guessing.
Re-implementing an API is how we got clone PC's when Compaq cloned the IBM BIOS interface and associated ISA bus logic which made Intel based DOS home computers cheaper and affordable for ordinary people.
I am not a huge fan of Google's antics in general, but in this case, I am glad they won.
https://frequal.com/java/SupremeCourtOracleVsGoogleRuling202...
focusing on two areas: * Google had the ability to make their own language and APIs for Android * The chilling effect on future language/API innovation
The great sigh of relief I was unexpectedly gifted this morning upon seeing this at #1 was a nice surprise. Very important precedent, good job.
> Unlike many other computer programs, the value of the copied lines is in significant part derived from the in- vestment of users (here computer programmers) who have learned the API’s system.
This decision doesn't appear to speak to why the 11,500 lines were actually important, other than to 'steal' developers away from Java - which in effect is poaching without the hard paper trail and paystubs.
So in the end, I find this setting us all up for the real battle... the utility of APIs and languages, which will bring us back to settle squarely what is a 'utility' & 'design' patent, and what is a copyrighted material.
I'm curious to know who will take it up -- I doubt anyone of consequence will be copying APIs after this.
So what if APIs were also patented?
Constitutional issues are somewhat of a mix of the political and legal. SCOTUS tries to be apolitical, but by its nature it can override Congress on Constitutional matters, and therefore it's at least somewhat political.
But cases like this are legal. Political credit and blame for this decision should go to Congress, not SCOTUS.
Of course, those interested in the legal process itself may give credit or blame to the justices for their legal positions.
Time to end this one now: https://news.ycombinator.com/item?id=26692575
This marks jurisprudence
What will Java look like at Google in 2030?
It's worth noting - the two dissenting justices were Clarence and Alito, who are both baby boomers over the age of 70, both old school conservatives. Of other two conservative justices, Kavanaugh and Gorsuch (who are also on the early end of Gen X), both sided with Google.[1] I was not expecting that. I thought they would have aggressive views with respect to the possibility of copyright infringement.
Funny moment during the case - Clarence compared Google copying Oracle to a football team stealing an opponent's playbook. That's a really bad analogy and demonstrates a lack of understanding in open source software.
Oh, and before I forget - f*ck you, Larry Ellison.
[1] Justice Barrett came in too late to participate in the decision, I wonder where she would have sided.
How about special-cased ad blocker integrations that stub ad vendor APIs? I feel like that would also run afoul of these increased copyright protections.
Also if Sun was still around would people be rooting for them instead of Google? Oracle isn't exactly easy to love.
I'm not looking for pound keyboard replies from people that disagree, I'm just curious if there are others that have the same feeling.
The SCOTUS decision cuts through the cruft and reaches the right finding in this case. It shows that the Supremes can can pay attention and do the right thing.