Google/Oracle’s $9B Copyright Case Could Be Headed for the Supreme Court
newsweek.com
newsweek.com
My comment at the time the decision was rendered: "This ruling will do what its [the Federal Circuit's] prior expansive reading of patent law did: it will set up a legal standard that invites lawyers and litigants to engage in endless second-guessing over copyright and fair use in areas of connectivity and inter-operability in the computing world and this in turn, as a standing invitation to litigate, cannot be good for future development." (See https://news.ycombinator.com/item?id=16691774 for fuller analysis)
The Supreme Court quite often fails to take up discretionary appeals even if the issues loom large for a particular industry or even if an important case was wrongly decided. Sometimes it does so to resolve conflicting rulings among lower federal courts on an important issue; other times, because a case raises important issues of public policy. Don't know if this case will fit the criteria (it didn't on its first cycle of appeal - see my comment here: https://news.ycombinator.com/item?id=9801251#9802457; also, https://news.ycombinator.com/item?id=4050490#4051761).
I have long been an advocate for solid protection of IP rights but the Federal Circuit here has almost fetishized the idea of copyright protection to the point where it has, in the API and fair use areas, become a caricature of itself. Strong correction is needed on the legal merits of the case.
Let us hope that the high level of interest in the tech community, as revealed by the number and quality of amicus briefs filed, will prompt the Supreme Court to intervene and bring soundness and clarity to an important area of law that affects the tech world in profound ways.
It will. The CAFC's rulings are in open conflict with the normal court that would handle this, the ninth circuit.
Conversely, by Oracle's logic, any application that uses the Java API would be a derivative work (the method signatures are perfect copies), and thus the app would need to be either GPL itself or pay for a commercial license for Java. This, too, seems incompatible with existing practice (e.g., Apache's Java applications are licensed under its own open-source license which is more permissive and thus can't be a derivative work under the GPL.
What am I missing here?
edit:
http://www.groklaw.net/pdf3/OraGoogle-959.pdf
"Two of the three questions from the jurors have focused on Apache, but the issue is actually very simple: Apache never obtained any license from Sun permitting its use of the Java specifications for Harmony. As made clear by Apache itself, Apache never had a license from Sun or Oracle for Harmony. Apache had no rights to Java technology that it could give to Google. This not even a case in which there is a “cloud over Apache,” to use the Court’s phrase (4/20/2012 Trial Tr. 1114:16-20). Apache simply had no title at all, and has publicly conceded as much: When Apache resigned from the JCP in protest based on its inability to obtain a license, it stated in its resignation that the “Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses.” (TX 1045 at p. 2.) Thus, Google’s use of Apache Harmony provides no defense for Google. Oracle seeks an instruction to the jury that will prevent confusion and clarify that Google’s use of Harmony provides no defense to Oracle’s copyright infringement claims."
Wasn't Apache seeking a license for a collection of tests, not the right to implement the API itself? And what, under Oracle's argument, would be the legal status of GNU GCJ/Classpath?
I'd imagine that Oracle sees GCJ/classpath as infringing, but there's not enough money in enforcing that to be worth it. That's all gut feeling though, and I don't know of any information that'd let us confirm one way or another.
The GPL only means that you can read, run, change, and distribute code. It does not affect copyright. The individuals/companies working on a GPL program still retain their copyright for each bit of code contributed (authored). Because of that, copying code into a completely different program without consent of each author can be problematic. In addition, only the authors can sue to enforce the license.
This is why the FSF requires contributors to assign copyright to the FSF: https://www.gnu.org/licenses/why-assign.en.html
https://arstechnica.com/tech-policy/2016/01/android-n-switch...
For your second point, using an API is different from consuming it; among other things, you don’t generally copy and paste the full method declarations into your own code.
Google used an Apache licensed re-implementation called Harmony, which was GPL incompatible to begin with. (The project was created specifically to not be GPL licensed, to AVOID the GPL as well as to negate any GPL protections)
"At this point in time, the OpenJDK implementation offered by Sun was not as mature or complete as the Java Standard Edition. Instead of licensing Java, Google chose to develop a cleanroom version of the Java Standard Edition libraries, developing the libraries from a completely fresh start without any access to Sun's code."
OpenJDK was released in 2007. Android was founded in 2003 and acquired by Google in 2005. It's entirely possible that if the schedules had been shifted a few years, Android would have gone with OpenJDK.
Note that OpenJDK is available under the GPL with the "classpath exception," allowing you to link non-GPL software against it (sorta like the LGPL). Android avoids the GPL in userspace, to the extent of writing their own libc (apparently glibc being under LGPL was not enough).
Also, OpenJDK is now 12 years old... It seems like forever, and it's kind of weird that events that old are still relevant to live legal disputes, but... I guess that's the speed of software vs. the speed of the U.S. legal system... ;)
Independently of that glibc also has organizational issues. You see this in some major projects flipping back and forth on it, like Debian switching to EGLIBC in 2009 and then back to glibc in 2015. You continue to see this with the very slow (or outright rejection) adoption of new syscalls: https://lwn.net/Articles/655028/
It's important to remember glibc is not libc for Linux, and distinctly does not behave as such. If your platform is unapologetically Linux to the core, wouldn't you want something else that tracks the kernel API better?
And it's not like Android was unique in not using glibc, either. The *BSD's don't, either.
Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it. Even on Android, disk is cheap.
EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use.
The BSDs don't use glibc because of licensing concerns, not because they dislike glibc's bloat. (Their own libcs implement just as much, because programs use those features.) My claim upthread was that Android avoided glibc for licensing concerns, not for technical unsuitability; giving the BSDs as an example seems to agree with that argument.
This is part of where glibc's bloat comes from. Locales are important, yes, but when your libc's versions are bad and you have to ship an alternative anyway (icu4c), then the one in glibc is just pure, wasted bloat.
But ignoring that aspect since not every program needs internationalization, this just becomes bloat in the libc.
This is really not something a libc (or any standard library) should be handling. Even if it's just because it's an area that moves too fast for a standard library to typically keep up with, and needs a faster deployment cycle.
> Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it.
Not entirely true. You're assuming everyone is using a single shared version, which isn't universally true. Some need static for reasons, and there's multiple shared versions not one for 32bit vs. 64bit or strict versioning requirements.
Also not all functions are free to add. __attribute__((constructor)) exists, after all, and is hugely not free of course. Similarly pages are not purely loaded on-demand, they are prefetched. Depending on where you've added those functions and how the resulting layout happened, you may now be getting fewer prefetch hits than you did before.
> Even on Android, disk is cheap.
No, not really. Today is the size of glibc less important? Maybe, sure. Was that true back in the Android 1.0 days? No. There are some numbers here: http://www.etalabs.net/compare_libcs.html glibc is stonking massive compared to what a C library really needs to do and, critically, has the largest minimum dirty page sizes. That's a shared library creating not-shared memory usage.
> EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use.
Someone forked GLIBC and ripped a bunch of stuff out and you're taking that as a good sign GLIBC was intended for embedded use? What?
If that were what happened, then you'd have an argument, but eglibc contained more than glibc did (the primary motivator was that glibc refused to support architectures that the maintainer didn't like; they also had patches to support compiling things out, but that's more source code and certainly isn't ripping anything out). If you don't know this history I have trouble taking the rest of your argument seriously.
That "more" being "you can remove things." Straight from the project:
> EGLIBC's goals included reduced footprint
> A primary feature of EGLIBC is support for configurability. You can build EGLIBC without support for NIS, locales, or other things that you may not need in your embedded system.
So sure a full-fat EGLIBC was as big as GLIBC, but that was clearly not the point of making all the big stuff removable, and binary compatibility was not guaranteed as a result.
> the primary motivator was that glibc refused to support architectures that the maintainer didn't like
Given that reducing size is the first listed goal in both the opening description and the mission statements it seems like your claim is more about what you wish was true than anything else.
Furthermore the "why not contribute to GLIBC?" FAQ states "The GLIBC maintainers have stated that they wish to focus on server and workstation systems." Given servers with non-x86 architectures definitely exist (PowerPC says hello), along with GLIBC supporting an exhaustive list of architectures anyway, it seems this is really just about size after all. Unless your argument is GLIBC maintainers held a grudge against ARM specifically?
Also, Android isn't "embedded" in the sense you're thinking of: the first Android phone had a 528 MHz ARM processor with DSP coprocessor, 256 MB boot disk + storage on microSD, and 192 MB RAM, which was quite a bit more powerful than e.g. the computer I had in 1995 (75 MHz Pentium, 16 MB RAM, 1 GB disk) that ran Red Hat Linux 6 just fine and definitely far more powerful than the machines glibc was originally developed on. So glibc was certainly not too big for Android. And plenty of "embedded systems" along the lines of Android did / do in fact use glibc, from OpenEmbedded to Emdebian to Maemo.
Heck, there was even a project called "embedded glibc" (EGLIBC), which is now the official glibc.
Can someone please explain in technical terms exactly what Google copied and what is Oracle complaining about? Is it just the Java API declarations? Most of the articles I find try to explain the issue in layman's terms which makes it harder for me to understand exactly what was copied.
There was also a bit of similar code for obvious reasons. For example, how many ways are there to implement "bool rangeCheck(int idxRequested, int maxValidIdx, int minValidIdx)"?
> after Google incorporated 11,500 lines of Oracle’s Java code
I'm pretty sure the article is wrong and you're right as that's consistent with what I've read before.
I think copying an API in a compatibility layer should be protected as fair use, but I don't think you should be able to start your development by copying an API someone else created.
Creativity is not a sufficient condition for being copyrightable. An obvious example is functional things that are patentable are also (supposed to be) creative inventions but can't be copyrighted, and then there are things like recipes, which are a representation of a creative work but aren't themselves copyrightable.
That's the argument here, not whether programming is a creative act.
There's no x86/ARM/etc instructions that represent a function declaration.
> When you write a Java statement you are clearly intending for certain instructions to get executed as a result of processing that statement. When you write a method signature, that doesn't represent any kind of intention for something to take place.
If we accept this argument then that means APIs are more copyrightable than code. Instructions, as in the context of recipes or process definitions, are not copyrightable. If we say code is an intent for something to be executed then that's an argument that it should not be copyrightable. Saying that an API is different and not simply instructions means that it should be subject to copyright.
It is possible to have two different programs that do the same thing. And therefore the exact code used is copyrightable.
But it is not possible to compile my code written for Oracle against Google instead unless the method signatures match exactly. Therefore the method signatures are more functionally necessary than the exact code.
Recipes that are a list of ingredients are not copyrightable. Recipes that describe putting love into each stroke of mixing the ingredients and how you learned to spread the frosting just so from your gram are copyrightable.
IMHO, the API is the former, code is the latter. The fact that both code and the API are recipes does not imply you have to choose between both being copyrightable or neither being copyrightable.
How many ways are there to write a create user API besides POST /user/?
Does that mean every company should then be taken to coury as well?
def full_name
return self.first_name + " " + self.last_name
end* If I provide an outline of a political argument to a opinion columnist for them to write up in detail, I should own copyright on the argument and prevent anyone else from making it
* If I describe a novel combination of techniques to use in a photoshop to create an interesting effect, I own copyright to the process and prevent anyone else from using it
* If I come up with a new hairstyle that goes viral and becomes popular, I should own copyright to the hairstyle and be able to stop anyone else having it.
These are all bad ideas, and so is allowing copyrighting APIs. Being a genuine creative work requiring significant labour is simply not a high enough bar on its own.
What is code if not an outline for someone else to write up in detail? Your java code is compiled to byte code and then further onto machine code. Why should we draw the line at the code level of abstraction but not take the step to the API level of abstraction?
Because code provides a concrete, complete, formally understandable semantics. Code is not an "abstraction" over different concrete implementations; it is a specific, concrete implementation. While compilers may substitute the code for another variant that preserves the same behavior, they are required to ensure that this substitution preserves observable behaviors (unless those are undefined behaviors), and the behavior that is to be preserved is defined entirely by the execution of the original code.
It's not any more concrete than an API. Your Java code compiles to different bytecode depending on the version of Java you use. It then further changes to machine code that differs based on the JVM installed, operating system, and processor.
>While compilers may substitute the code for another variant that preserves the same behavior, they are required to ensure that this substitution preserves observable behaviors (unless those are undefined behaviors), and the behavior that is to be preserved is defined entirely by the execution of the original code.
While [programmers] may substitute the [implementation code] for another variant that preserves the same behavior, they are required to ensure that this substitution preserves observable behaviors (unless those are undefined behaviors), and the behavior that is to be preserved is defined entirely by the [definition] of the original [API].
Edit: As a secondary point, remember that the point of copyright isn't to protect authors, it is "To promote the Progress of Science and useful Arts".
[1] https://en.wikipedia.org/wiki/Idea%E2%80%93expression_divide
In a sense, Wendy’s “reimplements” the “supersize my combo meal” interface.[1] They call it “biggie-sizing”, but...
Let’s say Wendy’s instructs employees that “if someone asks for a meal to be supersized, handle the request as if they had asked for it to be biggie-sized”. Could that conceivably be an API copyright violation?
[1] McDonald’s lets you “supersize” your order which means paying extra to get a larger drink and order of fries.
I'm guessing many menu items are trademarked as well.
https://trademarks.justia.com/744/51/super-size-74451719.htm...
According to copyright law, you can copyright creative expression but not anything that is necessary to the functionality of what you're building. However those might be protected under patents, trademark, or trade secrets laws.
Previous to this case, the code that implements the API can be copyrighted, since it is possible to implement the functionality with different code. But the code that specifies the API interface is absolutely required for compatibility if you want code that is written for one system to be compiled against the other.
However a national precedent put down by the Federal Circuit (the same court that caused software patents to blossom out of control) decided that there is enough creative expression in API interfaces for them to be copyrighted, despite them being necessary for compatibility.
Most people in software think that the previous precedent was better. Hopefully the Supreme Court will agree. (They overturn the Federal Circuit more often than not.)
Going to your fast food example, I'm pretty sure that trademark law applies, which is quite a bit different. But you can't copyright or trademark the act of making the meal larger. (You could patent it..but McDonald's didn't. And even if they had, the patent would now be expired.) But you can trademark the term used to ask for it. And so Wendy's is not allowed to use that term. They can understand it, but not use it. However at some point if "supersize" falls into common use, Wendy's could file a lawsuit saying that it is generic, and THEN they could use it. (Losing trademark due to a term becoming generic is one of the differences between trademark law and copyright law.)
Right, and isn't that what Google is doing?
"Hey, if you send a message in the Java language/API, we will understand it and do the same thing that a real java program will do."
"Hey, if you request that a meal be supersized, we'll understand what you intend and execute the Biggie-size operation, which matches what McDonald's would do."
Of course, there is the difference that, unlike Wendy's, Google is (analogous to) telling everyone "you can ask the cashier to supersize your meal" instead of just rolling their eyes and accommodating confused consumers.
>Going to your fast food example, I'm pretty sure that trademark law applies,
As in the sibling subthread, I think the example sidesteps the trademark complication because Wendy's doesn't ever use "supersize" in promotion, they just passively accept user-initiated requests that use the term, and do so in a way compatible with their McDonald's-derived expectations.
Having developers already understand Java, was a huge thing for Android when it first came out.
So when you say:
> Wendy’s doesn’t ever use “supersize” in their promotions
IANAL, So I’m not sure Google didn’t do the same...
I also think Oracle is also not happy with that.
Magnuson-Moss guarantees that third-party replacement parts don't void a warranty. A brake disc that interfaces with a hub and caliper specification can be sourced from a variety of vendors. The OEM has no say in the matter unless there is patent or trademark infringement involved. I can also make and sell my own vehicle that is compatible with the same brake discs of an OEM provided there is no IP infringement.
Just because Oracle used copyrighted IP to create a public interface doesn't mean that copyright can extend across that boundary. Copyright does not extend into the realm of mechanisms for information exchange. That's what patents are for.
The analogy I would use is, should the shape and usage of a steering wheel be copyrightable? Should a company be able to prevent someone else from building a car that has the same steering wheel, stick-shift, break on the left/gas on the right interface? After all, you could easily argue that building an intuitive car interface was a difficult, creative act. A ton of work has gone into making modern cars intuitive, and it's not like any of that design is obvious or trivial.
The answer to that question has profound implications for the ability of businesses to compete, and much more profound implications for our general ability as consumers to get products that act the way we expect, and to avoid radical amounts of vendor lock in.
Imagine a world where the interface for shifting gears was different for every car brand, or where notifications like turn signals, or errors like a check engine light couldn't be copied. It would make the automotive market uniformly more annoying, more dangerous, and less competitive.
Yes. Software was not well-anticipated by intellectual property law and has primarily been interpreted as an original creative work of the author(s) rather than a series of functional/operational commands that produce a "virtual mechanism" of sorts.
Patents are really the correct model for this. Under patent law, software would be protected for 20 years instead of 100+ years, and the details of the invention would have to be disclosed in exchange for the state-granted monopoly rather than occurring automatically without any effort.
Imagine a world where proprietary software would only be legally protected if the publisher first disclosed the source code and design documents in a publicly-available patent filing.
IANAL
If you look at this morally, Google used Java without paying. Pay up. If you look at this under a lens. Google never broke any laws because they looked up every patient and copywrite Oracle now owns and went around it. So technically, they didn't copy anything Oracle claims to own. All except, for one little minor detail in the API copywrite. Which of they can prove, then google stole Java.
Unfortunately, Google is very good at PR and has quite a big fan base. So all you'll hear is praise for the GOOG.
- Oracle claimed that Google copied parts of Java for Android
- Claims about copying code were weak (very little was copied) so that was dropped and this became a question about copying the Java APIs
- The judge initially on the case (Alsup) had the jury assume that APIs could be copyrighted and they said it was a copyright violation
- Same judge then declared that APIs cannot be copyrighted
- Oracle appeals to Federal Circuit (?) which declared that APIs can indeed be copyrighted
- Case sent back down to Alsup and Google found guilty
- Google appeal to the Supreme Court
Now the question is will they agree whether APIs can be copyrighted or not. If so, then Google is far from the only victim here, as anyone reimplementing someone else's API is in trouble.
Torts are, effectively, non-criminal wrongs against someone else. An unfairness or unevenness that has taken place. You are liable for the damage to another party, but you are not guilty of a crime. You can be forced to pay the other party, but you cannot go to jail.
Civil cases also have lower standards of proof to hold someone liable compared to guilt in a criminal case. In a criminal case, the standard is "beyond a reasonable doubt", but in civil cases, it's usually "preponderance of the evidence", which more or less means, it's more likely they are responsible than not responsible. (This is also why someone may be not be found guilty in a murder trial, but following that, a family may receive financial compensation through a civil suit that holds them liable for the person's death. It's much easier to cross the bar for a civil case.)
* Implementing a Language Spec? Copyright violation.
* Mocking an external service? Copyright violation.
* Wrapping a library call? Copyright violation.
The ability treat an interface as a distinctly different thing from an implementation is core to what we do in our jobs everyday. And the importance of being able to use, wrap, or mock out an interface without fear of legal jeopardy is essential to being able to do the work that we do.
int add(int a, int b);
Oracle is claiming nobody else is allowed to make an add() method with that signature.
Can I get a corporate lawyer's salary now
Think of it like I Want To Hold Your Hand by the Beatles. I bet 500 songs used the line “I feel happy inside,” but it’s not copyright infringement.
But if steal half the lyrics, it’s infringement. Same would be true for APIs, if they are found to be copyrightable.
In the context of building API compatibility, there is indeed only one way to do this so this ruling would mean any attempt at compatibility is a copyright violation.
If true, this would have some fascinating consequences. For example, HTTP is an API. Presumably Tim Berners-Lee could sue the creators and users of all HTTP servers for violating his copyright.
(note: not a lawyer, not even all that smart)
If you accept that the organization of a library of functions is copyrighted and requires a license to reproduce, it leads to the question of whether a program which merely uses said library would be considered a reproduction. When writing a library I might declare that 'sin' is in 'Math' by writing "namespace Math { float sin(float); }" which programmers call a declaration. Someone using the library might write "float sine = Math::sin(angle_as_float);", but as a programmer you can look at that call and see that it tells you that 'sin' is in the 'Math' package, same as the declaration. If Oracle's lawsuit is successful, and we agree that using a function is a reproduction of its SSO, all programs which merely interface with any other program through a library of functions would be copying the SSO. Given that nobody in the industry has ever considered SSO of an interface to be copyrightable, we've never made technical decisions or built legal agreements around it. The immediate effect is that decades of software written to run on top of Windows would suddenly discover that their code is jointly copyright Microsoft, users of an SQL database would discover that their database queries are jointly copyright the SQL server vendor or the SQL specification authors or both, and on and on across the entirety of computing.
The second issue is that Java was not the first language to put the 'sin' function in the 'math' package. For example, C places 'sin' inside 'math.h'. Is there someone with standing to sue Oracle for copying C? It's not like people really create interfaces out of whole cloth very often, you can usually find the incremental progression and improvement over time.
I expect that corporations will simply ignore the bad ruling if it does come down. If they didn't the number of new license negotiations and lawsuits would be staggering.
So Google might have simply used Java's code without ever being able to source a license. So here the case is not merely copying API but source code too.
If you read the case history, even Google's key employees knew this, they were worried and they did try to acquire the license till end but failed to do so, they proceed to move on with the project. (Disruption mindset? Will pay the fine if caught later?)
Google surely underestimated who they were messing with.
I think the process where the legislature writes a vague law and leaves it for the courts to decide what it actually means over a series of cases has fallen down badly here.
We could do a better job of getting test cases through the courts that clarify the law.
Or we could invent new mechanisms for turning rulings from specific cases into general principles that people can rely on.
Or we could allow somewhat more hypothetical cases in certain circumstances.
As I understand it, in the US, after a few cases like the Phoenix BIOS one people came to believe that a clean-room reimplementation of an exisiting interface was generally permitted, and so people stopped suing and we didn't get a flow of cases exploring the limits of that principle.
So now when Oracle comes along and points out that the Java API is a lot bigger, and arguably more creative, than the PC BIOS call interface, there isn't an existing case that settles the question.
I can see why there's reluctance to allow people to get courts to decide hypothetical questions, but this case seems to be a decent example of when it would be helpful: if Google had had the option of getting a ruling ahead of time on whether its Java library clone was permitted, it might have saved an awful lot of time and money.
A judge can use examples and hypotheticals (called "obiter dictum"), but that doesn't create a binding precedent and later judges may ignore it, refute it or alternatively convert it into precedent by adopting the reasoning in a decision.
It was pretty clear, until this case. What's different here is that Oracle initially had both patent and copyright claims, and appeals to cases involving patents go to the Court of Appeals for the Federal Circuit (CAFC) instead of to the appeals court that normally serves the district court that came from (9th Circuit, in this case).
When an appeal goes to CAFC because of patent claims, CAFC handles the entire appeal. Result: instead of this being decided be an appellate court that has extensive experience in copyright (9th Circuit) in this case, and even with similar issues within copyright, it ends up at CAFC which is not nearly as experienced in the relevant areas of law.
CAFC is supposed to follow the precedent from the circuit the appeal came from in matters like this that hitched a ride with a patent issue, which is why there was so much surprise and consternation at their ruling. As far as I can see, most lawyers and legal scholars though 9th Circuit precedent would result in a win for Google.
Personally, I dislike the way other things piggyback their way to CAFC. Besides the problem mentioned above of it putting issues before CAFC that they are not experienced with, it also makes for weird precedent.
Whenever CAFC goes in a different direction from one of the regular appeals courts, you then have a situation where you effectively have two different rules in that area in that circuit, one for when the case also has a patent issue and one for when it does not.
And sometimes laws simply get reinterpreted, after hundreds of years precedent.
Even in Canada there have been multiple occasions where Parliament did not act within the time limit and now there is no law at all.
The insight I got from that exercise was that, to him, APIs represent a product (e.g. I put a lot of effort into making this API, it's nice and clean, why should someone else be allowed to copy it?) and the implementation is typically straightforward grunt work, with intrinsically less value (e.g. we all know how to square a number).
As a developer, it was easy for me to sympathize with that thinking, because who hasn't been amazed by how elegant some of the APIs are and how difficult it is to create a simple, yet powerful API?
However, I believe that in the general case, it is the implementation that's the difficult part, which is why I'm against copyrighting APIs. Anyone can come up with an API for a Map, not everyone can create an efficient implementation of HashMap.
Doesn't this sound vaguely familiar? I think it's the same argument as "ideas vs execution", it's just that, as a community, we've discussed the pitfalls of ideas, NDAs and execution an order of magnitude more than copyrighting APIs vs implementation, and so there's less of a divide.
If you side with Oracle and you agree that execution > idea, then you should consider that implementation > API, and, similarly to how you can't copyright an idea, you shouldn't be able to copyright APIs.
In the case of Oracle vs Google, both the API and the implementation are trivial, which is a special case of the more general "API vs implementation", and it is unfortunate that a precedent will be set for the general case, based on a special case. That sounds like a recipe for future trouble.
The problem is that copyright protection has requirements beyond the above sentiment, which can just as easily apply to something that needs to be patented rather than copyrighted. You can't get copyright protection just because you feel you deserve it.
The criteria for copyright is originality and creativity. [2] It doesn't matter if understanding hashcodes is hard. Mathematical functions are not copyrightable. [3] Whereas elegant vs inelegant APIs demonstrate there is creativity in the API design process. Google engineer Bob Lee agreed [4]
>Q. Would you say that designing APIs is a creative activity?
>THE WITNESS: Yes, absolutely.
Copyrights are not patents. Clean room designs are perfectly legal. [5] Google could have avoided the entire fight, but Google failed to prove they did a clean room design.
Quite the opposite, Oracle was able to show that Google made direct copies of the code. The evidence at trial showed that Google decompiled at least eight Java files and copied them each in their entirety. [6]
[1] https://arxiv.org/pdf/1605.05274.pdf
[2] https://copyright.uslegal.com/enumerated-categories-of-copyr...
[3] https://www.copyright.gov/circs/circ31.pdf
[4] http://www.groklaw.net/pdf3/OraGoogle-398(Ex3).pdf
EDIT: For those unable to read between the lines, HN is a large forum read by thousands of people of different backgrounds. Often when someone suggests something, small actions can add up to create a large problem. DDOSing/Doxing is never acceptable for any situation. I want to "do something" but without accidentally creating a problem.
What you can do as a developer is to ensure your company is not using any of oracles cash cows.
I don't recall any computer/software companies actually backing Oracle, other than Oracle itself.
(Obviously this is not a unanimous support list, as I believe Microsoft has filed in Google's favor.)
“Treating APIs as copyrightable has a profound negative impact on interoperability and innovation. And it goes against decades of tradition and common practice in the software world.”
https://www.eff.org/deeplinks/2017/05/eff-asks-federal-circu...
>The Transformative Factor: The Purpose and Character of Your Use
>In a 1994 case, the Supreme Court emphasized this first factor as being an important indicator of fair use. At issue is whether the material has been used to help create something new or merely copied verbatim into another work.
https://fairuse.stanford.edu/overview/fair-use/four-factors/
IMHO simply re-implementing an API is not creating something new. It's just redoing something that has already been done. A translation layer from one API to another is a new thing separate from the original API.
If Google/Oracle can copyright APIs, then they are free to use their market positions to block competition because the very ability to inter-operate with other programs would be infringement, and their monopoly forces everyone to acknowledge their presence.
If Google/Oracle cannot copyright APIS, then they're free to use their market positions to snuff out upstarts by copying / re-implementing their programs.
Whether some method signatures are the same is just evidence suggesting copyright infringement, not infringement itself. I can write a song with some of the same words as another song. That doesn't answer the question of whether that's copyright infringement.
Do you have examples of this? I’m having a hard time thinking of types of programs that are susceptible.
I’d argue that the small businesses have much more to lose by APIS being copyrightable as you then are locked out of ecosystems. You’d have to pay to play to build compatible or replacement products. If this was the rule of the land in the 70s+ would we have had GNU tools or BSDs?
Most issue at the Supreme Court are highly detailed in some other area of expertise: medicine, economics, foreign policy, agriculture, the environment.
And the court with the most experience in tech, the Fed. Cir. decided in a way that most here don’t like.
Not sure how this affects some other domains, like company A developing their own new database engine that shares API with some existing db (to facilitate easy migration).
considering the fallout would extend far past Google, yes.
That said, courts generally don't focus on "how important" something is - that's supposed to be Congress' job. The exceptions are where the importance triggers some other area of law.
This is still in certiorari phase (i.e., SCOTUS hasn't decided whether or not to hear it), but there's already 15 separate briefs filed all urging SCOTUS to hear the case, and only Oracle is opposing it. There's nothing you can do at this point to urge SCOTUS as to whether or not to hear it.
Assuming that SCOTUS will hear the case (which is probably pretty likely--this is a Big, Important IP question which means the only reason not to hear it is if there's a better case coming along soon to hear it), the best chance at influence is an amicus curiae at that point. Talking to your company's legal representation is probably the best bet to get on one of the amicus curiae, but if you don't have any legal experience, you're probably not going to be capable of writing an effective amicus.
Considering that SCOTUS is being very directly asked to rule on the copyrightability of APIs (and fair use, if they are copyrightable), not reaching the question is pretty much only possible if they dismiss the case as improvidently granted.
(IANAL, this is just the best guess of a layperson.)
If Oracle wins, others can claim that their API is copyrighted and weaponize copyright law to sue anyone they don't want to interoperate with them -- despite the whole point of APIs being that interoperability.
If Google wins, it means anyone will be able to hijack the syntax, semantics, and interfaces of an ecosystem verbatim for commercial ends to promote an incompatible implementation, like they've done with Android. To protect against this, patents and NDAs will proliferate, and black-box organization and SaaS business models will solidify as the only (commericially) sensible way of distributing software.
Maybe I'm missing something, but your comment seems to boil down to "If Oracle wins, people won't be able to copy APIs, which is awful! If Google wins, people will be able to copy APIs, which is awful!" Surely you have to be on one side or the other?
0: https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine
I'd argue it vastly expanded the Java ecosystem, and the original part is unharmed. It's not necessarily getting unearned growth from the success of Android, but at the same time it's a huge stretch to say it was harmed.
Sun did that themselves with Java ME. In 2008 when Android was released the newest version of Java SE, Java 6, was released in 2006. The newest version of Java ME, however, was 1.3 released in 2000.
Java ME was 8 years out of date before Android was released.
And Java ME wasn't even one platform. It was a collection of optional extensions.
It seems like exactly the same intent to me. They want people making “Android” apps not Java apps.
In short, Oracle has claimed they bought Java from Sun to make a mobile OS that would've been licensed to manufacturers, and by stealing the Java API from them, devalued that purchase by launching Android for free.
Oracle wanted to rent seek on Java for phones, but then Google built a replacement and now they're crying salty tears about it.
Mobile and embedded environments can't run the full Java, and Sun's attempts at this (Embedded Java, Personal Java, MIDP/Jave ME) were awful. Oracle's claims that they were going to make a competitive mobile OS are dubious at best. I joined Oracle's Mobile division in 2001 until 2006, and at the point I left, my impression was that they were more or less wrapping it up, and merged the OracleMobile division back into Oracle Collaboration Suite to work on Enterprise apps like Calendar and Mail.
It is much more likely, given Oracle's history, and the public statements of James Gosling, that Oracle was more or less interested in purchasing Sun's customer base/rolodex, and patent portfolio to shakedown. They had no interest in Sun Labs, Solaris, UltraSPARC T1/Rock/MAGC, or making products out of any of cool tech Sun had developed. Sun had a lot of customers who would buy expensive Solaris boxes, who would be prime customers for databases and ERP software.
The computer industry got its start in spite of copyright, not because of it. Homebrew hackers cloned commercial systems. PC clone makers cloned IBM's BIOS. Intel clone makers clean room cloned x86 chips. Piracy was rampant, and it was the primary way other engineers learned. In the early days of the Web, the very nature of "View Source" allowed everyone to copy everyone else's Website, their markup techniques, their CSS, their Javascript. Again, it is how people learned, how the ecosystem evolved.
Look at what you're doing, someone who has claimed support for OSS in the past, you're supporting the argument that a corporation (Oracle), known for taking a buzz saw to acquisitions to get their customer base Gorden Gecko style, who ships mostly badly engineered software, poor poor Oracle, had their plans for a licensing shakedown, foiled by someone creating a viable smartphone OS that has enabled literally thousands of OEMs to build a vast ecosystem of devices for free.
Would you say the same thing about the developers of WINE if it actually started making an impact in Windows value? What if Google held a copyright over some Web APIs (perhaps Widevine video DRM stuff) that every website used, and they sued Mozilla over a cleanroom implementation that devalued the acquisition, would you be against Mozilla?
I'm literally shocked by anyone taking the position that clean-room API reimplementations deserve copy protection, especially people who claim to support OSS, and anyone defending the rights of $100 billion market cap companies to own API copyrights. This isn't some small time 3rd party library developer being deprived of living expenses. The ability for clean-room reimplementations to happen is how we break monopolies, its how network path-dependencies get disrupted by providing inter-rim migration paths. It's the entire history of the computer industry. It's how Coherent cloned Unix.
GNU and Linux largely cloned AT&T's existing Unix suite of tools in user space. These are essentially APIs, and their organization and collection, certainly represents a creative endeavor. If we were to accept this defense of Oracle, we would be forced to conclude that Unix was massively devalued as well.
The fact that competition that executes better on your idea than you do can devalue your product should not be a defense to have government and courts intervene on your behalf.
What I find dubious is not that Oracle might try to make a mobile OS (your argument against this is the subjective opinion that it was "awful"), but Google's claims that their use of the Java API was "fair use". Building a non-interoperable competitor for commercial licensing based on their work doesn't come anywhere near the terms of fair use. By Google's own admission, the choice to do this was an attempt to leech off of developer familiarity with Java rather than any sort of compatibility need.
java.io, java.util, java.lang are re-mixes of every other OO runtime going back to smalltalk. I'm not buying this idea that reimplementing List, Map, Set, InputStream, et al, without copying source needs protection.
Moreover, the fact that oodles of subsets of the Java APIs existed for a decade, and Sun never once took any of them to court, buttresses the argument that the CREATORS of the API were not interested in protecting against reimplementation. Even GNU Classpath wasn't a proper fully compatible version of the Java APIs, it could not pass the TCKs, but Sun did not threaten it.
Yes, Google likely chose Java because hundreds of thousands of developers already spoke it. Just like Objective-C choose C and Smalltalk, because so many people already spoke it. What's wrong with building a system that will have a low learning curve and easy to transition to if it is very similar to what people already know? C# was created by Microsoft to resemble Java for similar reasons.
I'm really befuddled by your position.
Hijacking means taking control away from someone, I don't see how that happened here.
The main difference is that developers will have more tools to fight unintended or unwanted uses of their API, such as clones, emulators, scraper tools, etc. There's concerns to be had, sure, but it's not the end of the world by any means, and a lot of those will fall under fair use in a way that Android does not.
Did they copy the core class names and the different method and attribute names for these objects but rewrote everything else from scratch?
I dont know java but but lets say it was ruby and then i made xruby and copied the same type of things. So, Random.rand (in xruby) still produced a similar random Float like in ruby. But the code that was called by Random.rand was entirely written by me from scratch? Is that the idea?
Then you implement a language called Crystal that uses Ruby syntax and its stdlib looks a lot like Ruby's, but it can't run Rails because it's designed for car navigators, not webapps.
The Ruby Company comes after you and says that if you wanted to reuse their APIs you should've bought a license.
In the case of ruby vs crystal, I think the courts will rule on the side of crystal!
Either that's word twisting (e.g. "platform" means something different or the commercial license was implicit) or just false.
1) The US legal code explicitly excludes "methods of operation" from being copyrightable. Does an API count as "methods of operation"? And if so, what ground does Oracle have left to stand on?
2) If this case goes Oracle's way, does this set the precedent that ANY re-implementations of an existing API are in violation of copyright? I don't know who now owns the original rights to Unix, but if they decide to come after Linux where does that leave us?
We can't know until a decision is made, but this could likely start a precedent for any re-implementations.
The curent copyright holders of UNIX are Micro Focus, who acquired it via buying Attachmade, who had bought Novell, who had bought UNIX System Laboratories from AT&T. Micro Focus mainly sells COBOL and is apparently hellbent on ignoring UNIX as much as possible (multiple people have tried to reach out to them about Ancient UNIX and possibly licensing some missing parts like PWB/UNIX and System III, but the best they've had is a salesperson being confused and trying to sell SUSE Linux). If they ever regain their institutional knowledge that they hold copyrights to UNIX and this decision happens, well, it's open season for Micro Focus v. Red Hat.
It would also allow Google a very good entry on the enterprise market where it could push GCP down its clients' throats, imho there's no other way for them to catch up with AWS and Azure.
I fail to see how it's not copyrightable as such. It appears to be a collection of facts (the interface of the implementation). These are not copyrightable, unless it meets the following:
"the work must be a collection and assembly of pre-existing material, facts, or data; the work must contain the selection, coordination, or arrangement of those materials; and the work is created by virtue of the particular selection, coordination, or arrangement of an original work of authorship."
I can't see how "arrangement of those materials" and "virtue of the particular selection or arrangement" isn't obvious here?
Oracle is pursuing the path where this case is literally about the contents of text files with words, which are supposedly well defined and understood under copyright law.
That is a bit disingenuous. Using your analogy it would be the subject sentence of every paragraph in the book.
The creation of something like Java should be protected by the patent system which at least has an expiration time of a couple decades rather than a century like copyright.
Google taking Java and reimplementing it without paying a penny to Sun (who was requiring a license to other manufacturers at the time) does seem unfair. But I think the law should provide something like the “FRAND” standard for patents, or the mandatory mechanical license for copyright, to prevent a company from blocking interoperability.
As far as who’s actually right on the law today.... the SCOTUS decisions will be interesting to read :-)
Google could probably do a lot of damage to Oracle if they wanted.
Google has already been found guilty of Copyright Infringement (and then admitted it by invoking the "fair use" defense).
They are in the hole already. This is just ironing out the details of how much Google is in the hole.
Oracle using a technicality to ask 9B for something they used to give away for free can backfire.
Kotlin from jetbrains is where developer mindshare is today ;)
> Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
> This code is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 only
[0] http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/tip/src/share/...
I'm not arguing for OP though, I'm just saying that we all have a choice in what technology to use.
The Software Directive explicitly permits reverse engineering for interoperability.
Interoperability is not explicitly defined, but is widely understood to relate to interfaces. API, or Application Programming Interfaces, are of course interfaces. Hence you can reverse engineer APIs to create something interoperable, without infringing copyright.
This topic has even gone to the CJEU, the top European court. World Programming implemented a language and library compatible with SAS. SAS sued. Ultimately, the court found in favour of World Programming.
Of course, despite reimplementation of APIs clearly being legal in Europe, a ban in the US could still have a chilling effect, due to the international and cross border nature of software development.
Sure it can, unless it's patented, but patents aren't claimed here.
You don't get to pick your own narrow definition of "interoperability" and claim that it's the only one that applies. Requiring 100% compatibility with compiled code quite obviously makes it trivial for the creator of the original work to completely subvert that right to reverse engineer. European courts would almost certainly choose to interpret that right in a way that allows it to have real power.
However a visit or letter from a large litigious opponent is likely to strike fear into the hearts of most regardless of the legal merits of the case. For example this has been effective for Microsoft in licensing patents they cover aspects of the Android operating system[1].
0. https://en.wikipedia.org/wiki/TRIPS_Agreement 1. https://blogs.technet.microsoft.com/microsoft_on_the_issues/...
Read the CAFC's opinion. Pretty cut and dry in favor of Oracle. APIs are not an abstract idea, but a concrete expression of an idea, thus protected by copyright. Google could have chosen its own expression, but decided to copy Oracle, which is against the law.
And Lunacy and Figma shouldn't be able to open Sketch files?
Edit: if it's unclear, making APIs patentable would prevent all of the above. API compatibility is essential to compete with big players.
Do you have any reasoning for treating magic numbers different from English-like names for the purpose of determining copyright eligibility?
If APIs are copyrightable, this actually might be good for open source projects such as Redis and MongoDb where cloud providers are just taking their API and creating implementations. This has been a huge issue for sustainability of these kinds of open source initiatives when a multi-billion dollar corporation can just come through, take the API and write their own implementation.
Not all creative expression is copyrightable just because it's creative expression. You could argue that basically everything is creative expression at some level.
Oracle isn't arguing that you can't use java api's in general without a license. Its arguing that if you wanna create a new platform you can't copy copyrighted code. Doesn't matter how small it is, google has demonstrated that it was intentional and instrumental in helping android grow.
If Google would have even changed namespaces in question API I would not be having to take Oracle's side here.
Imagine if Google pulled the same stunt targeting your startup - i.e. verbatim copying your software's method signatures - would you be ok with it?
This case has been going on since 2010. It's time Google let it go. They lost.
We don't learn anything from the fact that Google negotiated for a broad licence, decided not to take one, and used a clone which copies only the API definitions.
If API definitions aren't copyrightable then Google didn't do anything wrong. If they are then it did.
The idea that API definitions may not be copyrightable certainly isn't a wild theory that Google made up for this instance.
The commercial nature of the work is just one factor determining fair use. Another is "the amount and substantiality of the portion used in relation to the copyrighted work as a whole". And the API structure is a quite small part of the JDK as a whole, and has a different nature than implementation code as well.
Computer science reverse engineering often means recreating the same code, maybe even line by line. Allowing anyone to copyright an API would break the internet.
Imagine writing quicksort in a popular language as an excercise. Usually there's only a few straightforward ways to do it, so the same code has been written tons of times. If the original writer had copywrite, nobody could use quicksort.
But Google didn't just coincidentally happen to match the Java api; they intentionally copied the method signatures then reimplemented the methods. The issue at hand is copying all the method signatures, not reimplementing the methods. I don't know whether that is or should be a copyright violation or not, but it's different from what you described in your comment.
This is the same as writing an S3 compatible java client. If you want to be able to substitute one directly for another, the method signatures have to be the same even if all the implementations are different.
This also mirrors how kernel interfaces work. Xen, GVisor, and many others implement the exact same kernel interfaces as Linux because they have to to work. If the API was copyrightable any contributor that designed one of these interfaces could prevent these projects from existing
For example, recipes are also not copyrightable.
(IMHO, it's an interface, like a power socket or a light switch. You make it fit, and then it works.)
Is math.abs with one parameter copyrightable? What about Math.abs?
If it was so cut and dry this case wouldn’t have dragged on