We had two Soylentils write in with this breaking news. See other reports at Ars Technica, BBC, and c|net.
Supreme Court rules in Google's favor in copyright dispute with Oracle over Android software:
The Supreme Court on Monday sided with Google against Oracle in a long-running copyright dispute over the software used in Android, the mobile operating system.
The court's decision was 6-2. Justice Amy Coney Barrett, who was not yet confirmed by the Senate when the case was argued in October, did not participate in the case.
The case concerned about 12,000 lines of code that Google used to build Android that were copied from the Java application programming interface developed by Sun Microsystems, which Oracle acquired in 2010. It was seen as a landmark dispute over what types of computer code are protected under American copyright law.
Oracle had claimed at points to be owed as much as $9 billion, while Google claimed that its use of the code was covered under the doctrine of fair use and therefore not subject to copyright liability. Android is the most popular mobile operating system in the world.
See also:
Supreme Court hands Google a victory in a multibillion-dollar case against Oracle
In addition to resolving a multibillion-dollar dispute between the tech titans, the ruling helps affirm a longstanding practice in software development. But the Court declined to weigh in on the broader question of whether APIs are copyrightable.
Justices wary of upending tech industry in Google v. Oracle Supreme Court fight
Several of the other justices, including Chief Justice John Roberts, suggested they were sympathetic to Oracle's copyright claims.
Still, they appeared reluctant to rule in Oracle's favor because of arguments made by leading computer scientists and Microsoft, in friend-of-the-court briefs, that doing so could upend the industry.
https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
Held: Google's copying of the Java SE API, which included only those lines of code that were needed to allow programmers to put their accrued talents to work in a new and transformative program, was a fair use of that material as a matter of law. Pp. 11–36.
(Score: 3, Informative) by Anonymous Coward on Monday April 05 2021, @07:17PM (15 children)
This has been the law for 30 years
https://www.law.cornell.edu/supremecourt/text/499/340 [cornell.edu]
(Score: 0) by Anonymous Coward on Monday April 05 2021, @07:24PM (14 children)
APIs themselves are design decisions, not just their implementation.
What this points to is that laws are inadequate dealing with this issue.
(Score: 2) by DannyB on Monday April 05 2021, @07:31PM (6 children)
One thing SCOTUS pointed out in their decision was that regardless of the letter of the law, they didn't want to upend decades of what was ordinary universal practice within the industry -- that APIs can be copied.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 1) by The Mighty Buzzard on Tuesday April 06 2021, @03:42AM (5 children)
That's not their decision to make. They have no legal authority granted them towards those ends.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Tuesday April 06 2021, @01:17PM
It IS their decision to make when one court tries to overturn decades of established precedent by other courts in the land.
If a law is indeed so ambiguous as to be read in two opposite ways, it is for the Supremes to fix the interpretation; and if judges can decide to read a law in an opposite way just because, the Supremes can too.
(Score: 2) by DannyB on Tuesday April 06 2021, @01:53PM (3 children)
Why is it not the SCOTUS's decision to make?
It IS their decision to interpret laws. Even throw out laws, either partially or in whole.
Example: A state has a law criminalizing something consenting adults agree to do of their own free will in private causing no unwanted harm to anyone else. Police mistakenly break in to wrong apartment and discover two adults engaged in a violation of this law. SCOTUS recognized the law as unconstitutional.
There can be other reasons SCOTUS could throw out a law. Even for something as simple as being unconstitutionally vague. "The town's queen can declare 'off with their head!' to any person in town whom the queen is presently displeased with."
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 1) by The Mighty Buzzard on Tuesday April 06 2021, @02:17PM (1 child)
Common practice is not law until it has been around long enough and universally enough to attain the status of common law. And courts do not have the authority to rule on common business practices, only law. Now they could say it has attained common law status and rule from that direction but that's not what they did.
My rights don't end where your fear begins.
(Score: 2) by DannyB on Tuesday April 06 2021, @05:41PM
As you say, they definitely did not do that.
Instead they simply took the path of least inductance and declared Google's use to be fair use.
I can't argue with it. It is functionally necessary to exactly comply with an API in order to create a legal work-alike implementation. Like building third party ink cartridges that will work in a modern printer.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Tuesday April 06 2021, @06:34PM
SCOTUS spends most of it's time deciding whether it has the authority to decide things.
The liberals: When the law is vague, interpret the law in a way that makes sense.
The conservatives: When the law is vague, refuse to read anything into it that is not in the plain text. If it is vague enough, declare the law unconstitutionally vague. Refuse to ever make a decision that rightfully belongs to congress. If congress wants to fix the law, it will.
This decision is actually interesting because some of the conservative justices signed on for an interpretation that makes sense, but can't be found in the plain text of the statute. The statute says computer code is copyrightable. And it says that fair uses are allowed even of copyrightable things. But it never says that reimplementing an API is a fair use.
If you are just now figuring out your judicial philosophy, now is a good time to ask yourself: Would you rather have a SCOTUS that uses it's discretion to try to do the right thing, or would you rather have a SCOTUS that refuses to overstep it's authority?
(Score: 2) by HiThere on Monday April 05 2021, @08:02PM (3 children)
SOME APIs are design decisions. Others are just recognition of common practice.
E.g., consider the common example of sine, implementing that as:
float sin (float val)
is only creative to the extent of whether you are passing the argument in radians, degrees, mils, or something else. I guess float vs. double would be another plausible "creative" decision, but I think it's primarily functional. Returning an integer or a string would be just silly, and requiring the argument to be an integer or a string would be stupidly clumsy.
OTOH, it's a valid argument that the APIS aren't design decisions, they are only records of design decisions. The actual design decisions are the implementations. I'm not sure I totally buy that, however, considering the nature of "interface" elements.
Really, I pretty much agree with the argument that current law doesn't properly deal with technical documentation. That said, I definitely prefer my software to be GPL.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by DannyB on Tuesday April 06 2021, @01:58PM (1 child)
EVEN IF, even if an API is a design decision, and is an expression of creativity, it should not be a copyright infringement to copy that API to create a work-alike or compatible implementation.
A compatible implementation of anything, by definition, must conform to all externally visible interfaces.
A car radio replacement, must be able to fit the same bracket, and connect to the same connectors to be a drop-in replacement. An in-cabinet dishwasher must have the same hook-ups as the one it replaces.
This is a well understood principle.
SCOTUS did not decide whether APIs could be copyright protected, but assuming for the moment that they can be, Google's use of the API was not a copyright infringement. This alone establishes a precedent. Google's purpose was to use a work-alike implementation.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 1) by The Mighty Buzzard on Tuesday April 06 2021, @02:58PM
If it's an expression of functionality it's not an expression of creativity. You don't get to have both in the IP game, though that doesn't stop folks from trying like hell.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Tuesday April 06 2021, @06:12PM
Your example disproves your argument. As it happens, sin was one of the APIs at issue in this case.
But it was not:
It was:
The assignment of APIs to packages and classes was the creative element, and it was present in every single API, obviously.
(Score: 0) by Anonymous Coward on Monday April 05 2021, @08:13PM (2 children)
Here’s the thing - if someone came out with something they called have but with different API names, Sun would have sued them. Remember J++? Different enough that Sun claimed it would fragment Java implementations, damaging Java.
Remember when SCO tried to claim it owned the copyrights on c? The function names aren’t copyrightable, just the bodies, which can be implemented in many different ways. Same with the runtime startup library shipped with the compiler.
(Score: 2) by hendrikboom on Tuesday April 06 2021, @02:58AM (1 child)
what Sun was objecting to was calling it Java, which had been trademarked, and use of the name Java was allowed only if you followed the Java spec to the letter. Therefore the lawsuit and the ensuing renaming of J++ from Java to J++.
(Score: 3, Informative) by DannyB on Tuesday April 06 2021, @02:09PM
What Sun was objecting to, and won $1.2 BILLION was that Microsoft had clearly violated the black and white text of the agreement they signed to license Java.
The agreement expressly stated that certain namespaces could not be extended in any way, creating an incompatible or "enhanced" or "extended" version. The very presence of a compatible but "extended" version violates the principle of Write Once Run Anywhere. That is why the license agreement expressly forbade that.
Wandering quasi off topic:
The zealousness with which Sun pursued this is why Java really is write once, run anywhere. At least it is, more so, than almost anything I can think of that came before it. Some ahead-of-time (AOT) languages (eg, C and others) might achieve this at the source code level. The UCSD p-System (Pascal) (early 1980s) achieved this at the binary level, like Java. Compile a p-System program (any source language, but usually Pascal) into p-Code, and it ran on any p-System from an Apple II to a Dec Vax, IBM, etc. With Java, I can (and did) take a program (mandelbrot) I wrote in 2004, and ran it on a Raspberry Pi which: (A) did not exist at the time, (B) it's ARM instruction set did not even exist in any sense I was aware of, and certainly no Java implementation existed for ARM, and (C) it's operating system (Linux) is different than what I tested my program on (Windows, Macintosh) during development. With Raspberry PI, it is evident that even Linux provides a certain level of write-once-run-anywhere, in that as long as your Linux program is built in tools available as standard packages in Linux, you can typically recompile your program on a new architecture, such as ARM (Raspberry PI) -- or soon RISC V.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.