Hacker News Reader

Comment by dmitrygr | Hacker News Reader

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

View on HN

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.

I'm an actual programmer and I consider API signatures copyrightable. I spend a significant amount of time as a lead developer laying out class structure and method names for a more junior developer to actually implement. APIs are clearly creative and not trivial work that should be protected.

I think copying an API in a compatibility layer should be protected as fair use, but I don't think you should be able to start your development by copying an API someone else created.

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

>Because code provides a concrete, complete, formally understandable semantics. Code is not an "abstraction" over different concrete implementations; it is a specific, concrete implementation.

It's not any more concrete than an API. Your Java code compiles to different bytecode depending on the version of Java you use. It then further changes to machine code that differs based on the JVM installed, operating system, and processor.

>While compilers may substitute the code for another variant that preserves the same behavior, they are required to ensure that this substitution preserves observable behaviors (unless those are undefined behaviors), and the behavior that is to be preserved is defined entirely by the execution of the original code.

While [programmers] may substitute the [implementation code] for another variant that preserves the same behavior, they are required to ensure that this substitution preserves observable behaviors (unless those are undefined behaviors), and the behavior that is to be preserved is defined entirely by the [definition] of the original [API].

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?

No, for the same reasons that it's not infringement to write code like:

  def full_name
     return self.first_name + " " + self.last_name
  end

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.

Reply on news.ycombinator.com