No tears will be shed, I am sure, if Google has to pay some billions to fatten the already fat pockets of Oracle but the decision by the Federal Circuit being appealed here made a hash out of key legal foundational items that facilitate the very idea of interoperability in the computing world and therefore cries out to be corrected.

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.

> 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 will. The CAFC's rulings are in open conflict with the normal court that would handle this, the ninth circuit.

It would be easier and clearer, I think, for Congress to intervene. Copyright is a legislative creature, the judgements are about the meaning and scope of the legislation. Congress has the power to clarify it and thereby overrule any previous interpretation taken by any of the relevant courts.

Commentary from someone working directly within the field is always appreciated. Thanks for taking the time to write this out.

The aspect of this case that I don't understand is why, even if APIs are copyrightable, why Google would need a special license for the Android. If Java is available under the GPL, and Android is a derivative work but is also licensed under the GPL, then where's the problem?

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?

Wikipedia says:

"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).

Ah, THAT makes sense. Not having their own system licensed under the GPL would explain why licensing of OpenJDK doesn't make the question irrelevant, and the timeline explains why they didn't just use OpenJDK directly. Thanks!

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... ;)

When Android was started, no embedded system of any kind used glibc. It's now 2019 and still none do. It's not GPL avoidance, it's just glibc being (a) huge (pain) for all the wrong reasons.

Sure, but glibc being bloated doesn't explain why they didn't take working, tested code from glibc and cobble together a stripped-down version instead of starting entirely from scratch. You can absolutely fork a version of glibc that pulls out things like dynamic NSS backends, sunrpc, nscd, etc. even if it won't be accepted upstream, and it'll get you a working libc way faster than writing your own cleanroom libc. (With the important bonus of working with existing software that expects glibc and not just a pure POSIX libc, of which there's quite a bit!)

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.

This is not true. I've worked for two separate companies making soft for STBs and used glibc in both.

what parts of glibc make it trouble for embedded systems? is it the way it uses memory? or just “too large”?

glibc has a reputation for being bloated. Here's a post from 2002 of Linus complaining about it, for example: http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.ht...

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.

The job of a libc involves a lot more than just tracking the kernel APIs: it's got a malloc implementation, string handling, userspace buffered I/O and formatting, locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway), user and group names and not just numeric IDs, DNS resolution, thread handling, math functions, etc. All of that is quite independent of your kernel and hewing closer to Linux doesn't help you with any of it - except maybe the thread stuff, and for that glibc is the standard pthread implementation for Linux so you're probably better off using it anyway since that's what the kernel developers expect. (In other words, libc is the C standard library, not the kernel's client library for its APIs.)

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.

> locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway)

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?

> 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.

> but eglibc contained more than glibc did

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?

IIRC, Google copy/pasted code from Apache Harmony which wasn't legal itself.

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."

>"When Apache resigned from the JCP in protest based on its inability to obtain a license..."

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?

Apache was seeking the ability to access the tests, as passing those tests were the requirement to call it Java. Sun was using trademark (not copyright over API sequence structure and organization) to enforce this, sort of how Firefox does.

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.

For your first point, Google was trying to avoid the GPL (for whatever reason), but since the lawsuit they’ve switched from Apache Harmony to OpenJDK in order to take advantage of it:

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.

OpenJDK wasn't out yet, so they weren't avoiding the GPL, they were avoiding the proprietary license that the Sun JRE was distributed with at that time.

Because Google didn't use Java as distributed by Oracle/Sun or the Java with the GPL license. (in the timeline of the dispute)

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)

IANAL, but this is how I understand it:

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

This doesn't apply because the implementation that Google used wasn't GPLed at all.

The GPL lets you copy code into a completely different program, it's just that you still have to follow the license and comply with all its requirements.

I must admit I have not been following this case too close. But I get the general sense that most people in the CS community is in favor or Google and against Oracle. I'd like to understand it better.

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.

Google REIMPLEMENTED base classes to match what a normal Java app would expect. They complied with the public API as you'd find in javadocs. Oracle claims that is infringement because to make that work, their method signatures look identical to oracle's (and thus Oracle claims they were copied, in violation of copyright law). Google claims that API cannot be copyrightable by definition (an argument that most programmers agree with I feel)

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)"?

Is it similar to how Preact just implements React's API? So the problem here is, that Java's API is not under MIT? And what about all those competing companies that implement AWS S3's API?

Google asserts that an API cannot be copyrighted at all, and that even if it can, their usage of it falls under fair use. Indeed, if Oracle were to win, it would mean re-implementations of AWS services (like S3, or other services within LocalStack) would likely be infringing, although it may be mitigated in non-commercial uses.

Yes. And oracle claims that copying the public method signatures IS infringement.

I'm trying to understand the same thing. I think the idea is something like the render method basically behaves the same whether it is React or Preact but the actual code inside of Preact's render method is written from scratch. Although, in the case of Preact, it's probably not necessary because of the license for React?

Yes. All actual implementation code was not oracle's

Actually, there were 8 lines (of out however many million) that all parties agree was copied, but that's been ruled de minimis. All the implementation code they're ruling on now is not orcale's.

I wonder if this is somehow similar to how PC clones reimplemented IBM PC's BIOS. Can this be used as a precedent in this case?

Is there a reason this just applies to software, or is the principle more general?

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.

The principle is more general.

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.)

>They can understand it, but not use it.

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.

As an Android developer during the first G1 era, I feel that Google was really taking advantage of the well established Java developer base.

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.

Right but what if the java API is nominally “secondary”: “oh use this Byzantine Android api we have ... but if you just treat it like java, it’ll guess what you mean, ruby-magic-method style”?

"Super Size" is a McDonald's trademark, so it falls under different rules.

I'm guessing many menu items are trademarked as well.

https://trademarks.justia.com/744/51/super-size-74451719.htm...

Right, but I think my example sidesteps the trademark complication because Wendy’s doesn’t brand it as supersizing; they just respond to “supersize” requests in accordance with McDonald’s public spec.

Yeah, I was being pedantic with my response.

The more general principle is that interchangeable parts of a system aren't covered by IP outside of active patents.

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.

> That's what patents are for.

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

Okay that's a rejection of API copyright entirely (which I mostly agree with), but I was more interested in the internal logic of it all: that is, if I accepted API copyright, and if it's a fully general concept (not just software), could you have a situation where Wendy's is prohibited from correctly guessing what you "really mean" by asking for your meal to be supersized?

The fast food analogy feels weird to me because of trademark implications.

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.

The article says:

> 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.

Oracle claims public method signatures as code. If that is true then their claim is valid. I don't think you'd find any actual programmer who'd consider public API signatures as copyrightable code.

> APIs are clearly creative and not trivial work that should be protected.

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.

Would you consider C header files copyrightable? Aren’t they the “API”?

I understand the argument but have yet to see one that has a logical consistent separation of API and the rest of the code. In other words, if you go down the API = recipe path then you logically should go down the code = recipe path as well. After all, code is nothing but a complex recipe for a processor to execute.

> In other words, if you go down the API = recipe path then you logically should go down the code = recipe path as well. After all, code is nothing but a complex recipe for a processor to execute.

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.

The API doesn't actually run on the CPU, it's just metadata.

Can you expand on what "actually run" and "metadata" mean in this context?

When the code of a function is compiled fully until CPU instructions, the line declaring the function name and arguments disappears in the process; it's only used as metadata by the compiler (AOT or JIT).

There's no x86/ARM/etc instructions that represent a function declaration.

Note that many languages embed function names in the binary, though they would work just as well with any other name that mangled in a way that wouldn't break ABI.

No java code you write is represented by an x86/ARM/etc instruction. Everything disappears when it's compiled to byte code. If that's what makes an API metadata then every line of Java written is just metadata.

Disagree. 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.

I'm not sure what you're disagreeing with, but all the Java code you write definitely does go away

> 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.

The question is to what extent that content is functionally necessary.

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.

The code that ends up getting executed is formally equivalent to the JVM bytecode, but the method signatures completely disappear.

Agreed, I think code is more like a recipe than an API is. But I don't think the parent was arguing that APIs should or shouldn't be copyrightable because of how they compare to recipes, they were just answering your question as to how they can be clearly differentiated from code.

This clearly isn't a reasonable standard for asserting copyright. By the same logic:

* 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.

>* 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

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?

> Why should we draw the line at the code 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.

I think the key point here is that an API is a specification of functionality, and therefore is an idea (the idea being the idea of program which other code interacts with in a particular way). There is no way to write a runtime environment compatible with Java programs without having the same API (and its possible to develop an identical API only looking at the documentation). While it might involve creative work to come up with an idea, ideas aren't copyrightable[1]. On the other hand, the implementation of an API is clearly an expression of the idea of a particular public interface, so it should be protected by copyright. IANAL though.

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

That's absolutely ridiculous. With this logic, any time I implement an interface that I didn't myself make, it's a copyright violation. I shouldn't even consider making something iterable because then Oracle could take me to court for violating their copyright. All I'm doing is implementing an API they laid out. In this case, it's clearly intended to be copied, but they can't have it both ways. It's either ok, or it isn't.

In your opinion, would that apply to web APIs too?

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?

But what about backend code that reimplements full_name, for instance, what Amazon Maps does with the Google Maps API? https://developer.amazon.com/docs/maps/differences.html

Isn't your argument that `def full_name` is copyrightable, though? Why not the rest, then?

Treis is arguing his case reasonably and made points that are worth engaging with. His comment does not deserve its current grey status. We need people representing this perspective to have a good discussion.

On one hand I feel APIs are an important asset for any business. Platforms and programs can literally succeed or fail because of how their APIs are designed. Personally, I've spent as much as 1/3rd of my time on some projects in just thinking about APIs and go through dozens of iterations. If someone then copies verbatim, I would certainly feel getting robbed. On the other hand, APIs has to be public and copiable for people to do things like mocks or wrappers. Also, re-implementation is what allows progress and competition. It doesn't seem like a good thing for society for APIs as uncopiable without royalty. It looks like we are literally here on the edge of reasoning trying to argue if the border of your house is also your property. These are the kind of philosophy-heavy cases SC should definitely spend time on.

To run Java on your devices, you have to get it licensed. It takes lots of money and time to create a rich ecosystem like Java. Google never paid for permission to use Java in andriod. Instead they copied Java and deliberately went around all the the patients and copywrite which includes the API debate as evidence google deliberately avoided copywrite.

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.

A nitpick: "copyright", not "copywrite". It's about the _rights_ of respective parties.

The case has evolved quite a bit, so here's a quick summary:

- 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.

Not just reimplementing. If you for instance have to call an external service and you mock their API for testing then you've violated copyright. The same thing if you create a Facade for that API. Just as a matter of course everyday that you write code you are probably interacting with or creating code that violates this Copyright.

* 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.

You missed a couple. Somewhere in there after it was declared that APIs can be copyrighted, the district court found that Google's use of them was fair use, and then the Federal Circuit overruled that, too.

Also, there were some patent infringement claims that didn't last long, and those are the only reason the Federal Circuit ever got involved rather than the appeal going to the Ninth Circuit. So far, the only "precedent" established by this case is that copyright trolls should always include at least a token patent claim so that they can appeal to the more IP-friendly Federal Circuit.

It would also mean that all the PC BIOS manufacturers have been violating IBM's copyright for decades.

Wouldn't AMD be guilty of copying the x86 instruction set then?

Some parts of x86 were licensed, and AMD needed to pay Intel to use them. Then when AMD built on x86 and made x86-64, Intel had to pay AMD to use that, so they just made an agreement to license both to each other forever. [0]

0: https://en.wikipedia.org/wiki/X86-64#Licensing

The reason AMD needed to license x86 from Intel and why Intel needed to license x86-64 from AMD was because both were patented.

Yes, this is the Java API declarations. If you open up the JavaDoc for Java and look at the list of classes and functions, stuff like java.util.HashMap and System.out.println. Google wrote all of those classes and methods from scratch. Oracle's claim is that this was not okay because copyright covers APIs.

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)

I'm on Google's side for two reasons. 1) API compatibility is good for all of us and what happens if someone claims copyright on a function that adds to integers? 2) And most importantly, Oracle bought SUN for sole explicit purpose of trying to shakedown Google over Android. This isn't a case of not being able to recoup time and money for Oracle. It is a sham and akin to patent trolls. I hope they continue to wither and die.

//adds two numbers

int add(int a, int b);

Oracle is claiming nobody else is allowed to make an add() method with that signature.

It’s more complex than that. Copyright only forbids copying. Truly independent arrival at the same work isn’t actionable. So if the only overlap in code is this sort of coincidental or “there is really only one way to do this” situations, you shouldn’t be found liable.

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.

> “there is really only one way to do this” situations

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.

IANAL but even if it's determined that APIs are copyrightable, `add(...)` would almost certainly be considered public domain. There's no way to track down the original author, and whoever it was never claimed ownership

It couldn't enter the public domain until 2116 unless the original author explicitly released it, which they did not because almost nobody does that.

Then who does the copyright belong to? Why that date?

120 years after the first version of Java was published. It would be owned by Oracle.

I was referring to the add(...) function

int add(int x, int y);

Can I get a corporate lawyer's salary now

Google says it did clean room implementation but investigation uncovers that Google copied and pasted a lot of code to rush through development and there were strict guidelines set to remove the use of word "Java" from the source code repository which even delayed some of their launch

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.

Oracle's remaining claim is that functions having particular names and belonging to particular packages is copyrighted by them and was replicated by Google. For example, the function to calculate the sine of an angle is named 'sin' and belongs to the Math package. They don't claim any particular text was copied, they claim that this structure, sequence and organization (SSO) of the functions was copied from Java. Supposing Oracle's legal theory were correct, this would give rise to two major categories of problems.

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.

Google copied the API, but didn't make the runtime compatible with Java ME, SE or EE. Oracle says you can reimplement Java API, but only if you're making a complete Java-compatible runtime, one you can run a regular .class or a .jar in. If you simply reuse some APIs because you want to exploit people's familiarity with Java APIs, you are committing copyright infringement.

One of the four fundamental factors in any fair use determination is the "the amount and substantiality of the portion used in relation to the copyrighted work as a whole". If Oracle wants to claim that Google effectively didn't copy enough of Java, it sounds like they need new law.

Compatibility is a requirement for using the Java TCK and getting permission to use the Java trademarks. I don't believe Oracle has ever made it clear what the conditions are for getting a copyright license for the API alone.

Java EE is not compatible with Java ME

As far as I'm concerned, it's a huge failure that, over thirty years after computer programs were explicitly added to copyright law, it isn't clear to what extent APIs are copyrightable, and we have to watch lawyers argue over strained analogies to chapter titles in Harry Potter books.

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.

> As far as I'm concerned, it's a huge failure that, over thirty years after computer programs were explicitly added to copyright law, it isn't clear to what extent APIs are copyrightable, and we have to watch lawyers argue over strained analogies to chapter titles in Harry Potter books.

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.

CAFC has continually shown itself as a renegade court which might be corrupted or captured by the "intellectual property" industry. We can presume they will consider everything copyrightable and everything patentable. They've continually tried to circumvent supreme court rulings to make things more patentable. The same can be applied to copyright.

Do you really want our senators, who usually old enough to remember hunting dinosaurs, writing these laws though? At least in court informed experts can be called. Congress only hears from experts if they so choose (surprise: they usually don't so choose)

I think there are other options.

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.

Courts don't decide hypothetical questions. They decide on the case before them, constrained by the precedents of previous cases.

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.

What do you think lobbyists are for?

My big issue with vague laws is that decisions with colossal impact in the United States are determined by 9 people.

And sometimes laws simply get reinterpreted, after hundreds of years precedent.

This is really a failure of Congress. SCOTUS shouldn't even be in the business of forcing reinterpretations of these laws - Congress should realize it's being (mis/re)-interpreted and reactively clarify. That's how the system worked until we got a deadlocked legislature and it's how it works in other countries.

In Canada it’s common for the Supreme Court to give parliament time to fix issues with a law before it’s ruled unenforceable. Under the argument a small delay is better than a free for all.

This is true in the US too, but gridlock doesn't fix itself in the time period.

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.

30 years were the Unix wars. I wonder what consequence were if APIs were considered then.

I've discussed this topic once with a developer who sided with Oracle, which was a fun exercise for me, because I side with Google.

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.

> I put a lot of effort into making this API, it's nice and clean, why should someone else be allowed to copy it?

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.

Abstract ideas can be hard. It's not about triviality of the APIs that should exclude them from copyrightability, it's about their abstractness. That's how you should bust such arguments.

I hope Google wins the legal case for the sake of maintaining an innovative software industry. But at the same time I still think that they acted like jerks by creating their own proprietary pseudo Java for Android rather than negotiating a formal agreement with Sun. Now the Java ecosystem is fragmented so many Java tools and libraries can't be used for Android development. That's bad for everyone.

Is there anything we can do as developers? Obviously I don't want to DDOS/DOX the supreme court, but can we write letters or do anything else to show _how massively important_ this is?

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.

Donate to the EFF - they write amicus briefs and generally empower the legal profession to have that understanding.

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.

How does it impact us as developers either way? Both are titans that have contributed vital pieces of tech infrastructure as well as committed evil acts in their space. Oracle is arguably more evil here, but is it that big of a tragedy if Google loses? They have obscene amounts of cash; what difference does it make if a pile of cash goes from one evil pocket to another? Please if you downvote give an explanation. I honestly want to know what's at stake here for us.

> How does it impact us as developers either way?

“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...

Controlling how the issue is framed has a larger impact than who wins. Whether APIs are copyrightable is beside the point and no matter who wins, we all lose:

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.

> 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.

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?

This is only true if you exclude the middle ground of APIs being copyrightable with fair use exceptions. In other words, you can't kick start your program by copying the structure of another, but you can create a compatibility layer to your novel program.

I don't see how creating a compatibility layer makes it fair use. Unless you're only using 5% of the original API or have a strictly educational use you're going to be in violation. Even then you'll need to fight it out in court if the original party is litigious like Oracle and there's absolutely no guarantee that you'll get a jury that understands and is friendly to the concept for Fair Use. Media companies have been basically claiming that Fair Use is a myth for many years now, often successfully.

Because it's transformative:

>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.

Well at stake is ”Can you own the copyright of an API”. I think this is a pretty big question.

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).

Also, "who owns POSIX?" Is it the extremely litigious SCO?

thanks. This does have a huge effect on all sw devs.

If Oracle wins, next time you re-implement an existing API someone can sue you.

I shriek at the idea of 9 SCOTUS justices trying to understand how API's work and making that decision for all of us. I'm sure those men and women are highly intelligent, in their field of law, but I just don't have much faith in them understanding the difference between printf(...) and libc.a

If google’s lawyers cannot explain the issues on a way that high intelligent lay people under stand it, then they aren’t doing their job.

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.

You don't have to be a doctor to rule on an abortion case. Same principle applies here, as it should.

That may not be the best example...

printf and libc are not much of an issue as the c standard library and the posix specification were explicitly created to allow for multiple implementations of the API.

I mean, that didn't stop SCO from suing everyone under the sun the first go around.

> but is it that big of a tragedy if Google loses?

considering the fallout would extend far past Google, yes.

On one hand I hate google. On the other oracle winning could mean the end of wine. My heart is divided.

There is already a long list of amici curiae filings at SCOTUS asking them to look into this case and helping inform them: https://www.scotusblog.com/case-files/cases/google-llc-v-ora...

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.

There is also the not-unlikely possibility that the court takes the case but then rules in an extremely narrow way that leaves open the larger question about the copyrightability of APIs.

The petition for certiorari has to explicitly lay out the questions that are to be answered by SCOTUS. In this case, the questions are: (1) Whether copyright protection extends to a software interface; and (2) whether, as the jury found, the petitioner’s use of a software interface in the context of creating a new computer program constitutes fair use.

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.

It appears they denied the previous petition from Google in 2015. Why is this one different?

One possible answer: the Federal Circuit remanded the case back to district court for further proceedings, and there would be another chance for appeal after those proceedings completed. SCOTUS may have decided to kick the can down the road. From what I understand, this is not uncommon; complex cases sometimes offer multiple opportunities for appeal, and higher courts will sometimes decide to say "no" to the earlier opportunities even if they eventually say "yes" to one of the later ones. Sometimes, higher courts like to let things play out more fully at the lower levels, since it allows the record and arguments to further develop, and so they feel they have a better foundation to base their own decision on. (Plus, with a huge workload, there is something to be said for delaying taking on something big as long as you can.)

(IANAL, this is just the best guess of a layperson.)

A lot of people/companies contacted the judges last time but some were actually companies backing Oracle (eg microsoft?)

What you can do as a developer is to ensure your company is not using any of oracles cash cows.

EFF has collected all of the briefs submitted throughout the dispute at https://www.eff.org/cases/oracle-v-google

I don't recall any computer/software companies actually backing Oracle, other than Oracle itself.

The article says the BSA (Business Software Alliance) has filed a brief in Oracle's favor. This is their membership: https://www.bsa.org/membership

(Obviously this is not a unanimous support list, as I believe Microsoft has filed in Google's favor.)

You say this as though you'd normally DOS or dox someone you disagree with, or that it's a normal course of action for a developer, or something that a reasonable person would consider.

Why would the thought of DDOSing the supreme court even cross your mind?

If every developer wrote a letter to the SC, that might (depending on how they handle such letters) function as an inadvertent DDoS - similar to the HN hug of death.

I'm not sure what can be done. The entire software industry is threatened by Orcale's greed at this point.

This whole case is contrived, and both actors acted in bad faith, so the outcome will be troubling no matter what.

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.

How did Google "hijacking" the Java API harm Oracle? If it didn't, why should anyone need to "protect" against such a thing happening in future?

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?

It segmented the Java ecosystem into two parts. Android doesn't keep up-to-date with current Java version changes and creates friction. It seems similar to what Microsoft did to Java in the late 90's [0] (without the malicious intent).

0: https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine

> It segmented the Java ecosystem into two parts.

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.

> It segmented the Java ecosystem into two parts.

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.

> without the malicious intent

It seems like exactly the same intent to me. They want people making “Android” apps not Java apps.

JavaME is also fragmented because those phones are the least likely to get updates.

Mobile phone companies used to license Java from Oracle. Instead, they all now use Android instead, a ripped off implementation of Java. Oracle claims they had intentions of moving further into the smartphone space (most mobile Java implementations a decade ago were on dumbphones, AFAIK), but Android shot their plans and the value of their purchase of Java to heck.

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.

Having coded for Android and JavaME, I can say that JavaME would have never worked right in the smartphone space. It's whole process lifetime architecture is wrong for smartphones. It basically only works with one app running that gets killed on quit otherwise you kill your battery as if your phone doesn't go to sleep.

The law is not intended to protect your business model from competition.

Oracle wanted to rent seek on Java for phones, but then Google built a replacement and now they're crying salty tears about it.

In fact, the law is intended to protect your business from competition, when that competition is repackaging and reselling your original work. That's the entire point of intellectual property law.

Prior to all of this, for practically a decade, open source projects had been reimplementing parts of Java. For example, I used Java for coding on the original Palm Pilot via Ghost (http://www.cs.utah.edu/~mcdirmid/ghost/) and SuperWaba projects. (https://en.wikipedia.org/wiki/SuperWaba) No one had any problem with this activity prior to Oracle, not even Sun, it was pretty much established a long history that this was acceptable behavior, Sun even encouraged it to some extent, as long as you didn't call the result Java(TM).

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.

Open Source -- as in Source Code. GPL protects source. The stuff you actually fork when you type 'git clone'. You really think Richard Stallman would be opposed to someone cleanroom re-implementing a GNU GPL'ed software from scratch that has a compatible API? Stallman called Android a major step forward, and if anything, his problems had nothing to do with subsetting Oracle's API, but issues surrounding Tivoization and binary blobs.

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.

Arguably, APIs have been found copyrightable, and the solution is simple: Include a license with your API. In a lot of cases in the modern era, APIs have terms anyways, because they're tied to web services. So adding a clause about being able to implement them is trivial, for any intended use of an API.

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.

> 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

Hijacking means taking control away from someone, I don't see how that happened here.

The Supreme Court mostly isn't about which side wins. They could come up with a useful way to adjudicate which wouldn't lead to either of the sets of costs you mention.

I'm trying to understand what was copied by Google.

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?

Imagine Ruby was closed source, but you were allowed to make open source implementations that ran Ruby programs.

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.

Interesting. I was thinking it was like google copy and pasted oracle's code, kept the function definitions and then re-wrote the innards. To me if code is truly treated as a literary work then it doesn't really matter how the end product behaves. It matters whether the text was copied.

In the case of ruby vs crystal, I think the courts will rule on the side of crystal!

Yes, that is exactly it.

> "Before Android," Oracle’s lawyers write in their brief to the Supreme Court, "every company that wanted to use the Java platform took a commercial license...including smartphone manufacturers BlackBerry, Nokia and Danger."

Either that's word twisting (e.g. "platform" means something different or the commercial license was implicit) or just false.

What they licensed to BlackBerry, Nokia and Danger was of course the Java ME runtime.

I really only have two questions about this case:

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?

> 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.

CFAC has ended "methods of operation" where software is concerned. The phrase no longer applies.

Oracle now has a market cap of about $170 billion, give or take a few billion, I'm pretty sure that if a company like Google put its mind to it it could purchase Oracle outright.

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.

Buying oracle might kill them. Like a tiger eating a poisonous snake and getting bitten

IANAL... but it seems to me copyrighting an API instead of the actual implementation would be like trying to copyright the idea of "chair" or "wheel" which is not possible AFAIK.

A better metaphor is probably to look at an API as a design blueprint. For instance a blueprint of a house. Describing in detail all the components that goes into creating the house, plumbing, electricity, rooms etc. Clearly it is a lot of work to come up with such a design.

In that analogy, Google used the blueprint at the level of "living room goes here; closet is next to the bathroom". They then redesigned the plumbing and electricity from scratch.

A table of contents, stripped of editing, is generally not copyrightable as is. It falls under mere listings of ingredients or contents exemptions.

An API is more than a table of contents. When I write a method and give it a name and define what parameters it accepts, that is just as much part of the code as the inner workings of the method itself. I'm not a big fan of copyrighting in general but I am struggling to see understand how the code that defines an interface is separate from the rest of the code.

> It's copying the table of contents, but writing your own chapter text

That is a bit disingenuous. Using your analogy it would be the subject sentence of every paragraph in the book.

Not sure if that is great metaphor either. Blueprints describe everything, including implementation.

My understanding is that code is treated basically as a literary work [0] with copyrighting. So the API definition is a part of the codebase. I do not think the analogy to copyrighting an idea is applicable. Unless they are trying to separately just have a copyright on the API? If that is the case, I'm not even sure how it would have been filed?

[0] https://www.copyright.gov/eco/help-type.html

IMO copyright protection is way too strong and long lasting for this type of thing.

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 :-)

Supreme Court should bust the bad decision about copyrightability of APIs.

I'm surprised the board at Oracle has let things go this far.

Google could probably do a lot of damage to Oracle if they wanted.

How so?

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.

Buddy, EVERYTHING in this trial is about fair use.

Oracle using a technicality to ask 9B for something they used to give away for free can backfire.

Sun didn’t give it away for free. They charged manufacturers for licenses for J2ME - Until google came along and blew up their business with android.

It's mindblowing how so many developers are quick to build on the Java ecosystem... an ecosystem backed by a company so hell-bent on stifling innovation.

Java was created by Sun. Oracle bought them mainly to sue Google.

Kotlin from jetbrains is where developer mindshare is today ;)

But Kotlin does run on Oracle's JVM, no?

Runs on OpenJDK as well...

That's Oracle's too.

But it's open source. GPL. And it's not just Oracle that contributes to Java... (OpenJDK and Java Community, Red Hat, Azul Systems, IBM, Apple Inc, SAP SE)... We've had Amazon and AdoptOpenJDK compile and distribute their own binaries as well. We could fork it if we had to.

https://en.wikipedia.org/wiki/OpenJDK

Really? In what way does it differ from Oracle Java SE ?

In that it is GPL+Link Exception licensed. The copyright still belongs to Oracle. See this[0] example:

> 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/...

Since Java 11 only in commercial support model. Code bits are about same.

OpenJDK is under GPL (+exceptions) now, it wasn't at the time. As long as you don't use oracle's binary builds these concerns don't apply anymore.

You may want to consider this affects literally every piece of software in every language that has ever called into another library.

People have been using Java for decades, when it wasn't even backed by Oracle. It's impractical to think people can just throw out millions of lines of Java code and hours of experience and knowledge just because of some "omg Oracle evil" argument.

How many developers make that decision as far as work goes?

Every developer that continues to use Java or takes on a project that uses Java makes that decision, either explicitly or not. The market for Java developers exist because Java developers keep developing in Java.

I'm not arguing for OP though, I'm just saying that we all have a choice in what technology to use.

Many developers do not have a say as to what technology to use in a company.

If anyone knows, how much would this affect non-US technology processes and legislature? What would an outcome of this mean for Asia and Europe?

What Google did is very clearly lawful under European Union law.

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.

Except Google didn't provide interoperability, you can't run Java applications on Android. A lens company can study how a camera company mount works and sell compatible lenses. A camera company cannot study another camera company's mount to make an incompatible mount that uses similar circuitry and protocols to help lens companies support it faster.

> Except Google didn't provide interoperability, you can't run Java applications on Android.

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.

> A camera company cannot study another camera company's mount to make an incompatible mount that uses similar circuitry and protocols to help lens companies support it faster.

Sure it can, unless it's patented, but patents aren't claimed here.

US legislation and precedents are not binding in other legal jurisdictions throughout Asia and Europe. There are international agreements (such as TRIPS[0]) that aim to provide a degree of intellectual property law consistency across the world but if Oracle prevails in this case it does not follow that APIs would be automatically copyrightable in all TRIPS signatory nations.

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/...

If Oracle wins this lawsuits does that mean it’s the death kneel for AWS cloning open source wire protocols like MongoDB ?

Is this copyability issue for software APIs or more general? I feel like if I copied the full user interface of an iPhone (the way it looks and interacts with the user) and provided my own imementation I'm still liable?

The Supreme Court should, and probably will, deny cert.

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.

Under that interpretation, I'm curious what you view as different than IBM vs Compaq about the original PC bios?

The law is the law. Wishing it were different doesn't make it so. Which means that yes, Compaq and other PC clone makers may have broken the law by reimplementing the PC BIOS. The BIOS API does not depend on named functions but rather on specific values appearing in CPU registers, so I'm not sure how copyright applies to that. Maybe a "structure, sequence, and organization" argument à la Whelan v. Jaslow.

> The BIOS API does not depend on named functions but rather on specific values appearing in CPU registers, so I'm not sure how copyright applies to that

Do you have any reasoning for treating magic numbers different from English-like names for the purpose of determining copyright eligibility?

No, I don't. Which only supports the copyrightability of the BIOS API, and the illegality of BIOS clones (and hence, early PC clones).

The SCOTUS already denied cert on the question of copyrightability. The question now is whether it's fair use.

It isn't fair use. Fair use under U.S. law refers to excerpting a copyrighted work for certain purposes including news reporting, research, scholarship, criticism, and parody. If Google copied the APIs without any of these uses in mind (almost a certainty in the case of Android), they infringed on Oracle's copyright. Period.

The test doesn't include any such list of purposes. That said, yeah, it's probably not fair use.

17 U.S.C. §107 does include a list of purposes which, while not exhaustive, is intended to show the sort of things which constitute fair use -- things which Android's use of Java code is far removed from.

That isn't too surprising, given that functional compatibility really isn't the kind of thing you would expect a copyright law to discuss. If copyright is being stretched to cover this new realm, then it also needs to be assessed for what should qualify as fair use in this realm.

So does that mean Word, which implemented WordPerfect APIs, is illegal?

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.

Or Oracle when they implemented SQL?

One thing I hope everyone agrees with is that API design is an art. Often coming up with a good API is as significant a task as actually implementing it. An API that is intuitive yet flexible and extensible is tricky to design.

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.

Cooking is also art but recipes are not copyrightable.

Not all creative expression is copyrightable just because it's creative expression. You could argue that basically everything is creative expression at some level.

Did Redis and MongoDB copyright their APIs?

Copyright is automatic, so if APIs are copyrightable, the answer is necessarily "yes".

I'm looking for a distinction between code and an API. I think that the code that defined the APIs is copyrightable. If someone copied that code, it seems relatively cut and dry. Now if someone produced a similar interface but with entirely their own code, then it seems fine?

This is the first time I've read anything in depth about this and I gotta say Oracle's case feels stronger and google is tilting at windmills. Oracle wrote something, google copied it.

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.

Google’s argument is that method declarations are not code. And since this case is about copyright the question is whether declarations like that are ideas that can be protected under copyright law.

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

They copied the API interfaces. I'm sure every developer has done the same a multitude of times. If you want to talk to the same REST API using the same client, you've probably written an exact copy of the code a bunch of others have written.

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.

Correct me if I'm wrong, but my understanding of copyright is that if you come up with something independently you're not violating copyright. So if you and I both write code to interact with the same REST API and end up writing identical code, there's no violation.

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.

Not really, the interface signatures need to be the same for normal Java code to work. There's only one way to write the interfaces, code would be identical even reverse engineered.

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

But what would have been the solution? They could have just made it ToString_Google() and HashMap_Google. This is so far beyond anyone actually having their rights impinged upon at this point that the only winner to this whole thing can be the lawyers making money hand over fist.

That's akin to saying that someone wrote about English grammar and you copied it in your comment by structuring your sentence in a certain way, using punctuation, etc.

It's more akin to someone who wrote a book and I copied the title and each chapter heading and then rewrote each chapter in my own words.

Perhaps not the best analogy since that could fall into Derivative Work category depending on the judge's interpretation of reimplementing APIs.