Hacker News Reader

Comment by staticautomatic | Hacker News Reader

Except Oracle hasn't claimed a copyright on its API's. It claims a copyright on their structure and organization

You're referring to a distinction that's largely a peculiarity of how technological terminology has been shoehorned into an ad-hoc legal framework; there's no real deep insight here. If you ask the lawyers in this case what "an API" (singular) is, they'll give you a definition that's more on par with what a developer would call a single function/method signature. If you ask a developer to name some common APIs he uses, he'll list off named collections of functions, and such collections in the abstract are pretty much what Oracle's suing over. So when a developer rather than a lawyer says that Oracle's suing over "the Java API", they're trying to convey the correct meaning, and using the right terminology for the context. "Structure, sequence and organization of APIs" sounds much more like a legal test (in the same vein as the factors considered in determining fair use) rather than a decent name for the kind of creative work at issue.

You've conveniently avoided mentioning the most significant question, which is whether the implementation was different.

I'm pretty sure that's not actually in question any more. And it's quite orthogonal to the question of whether it's appropriate to simplify "copyright of structure, sequence and organization of the API" down to "copyright of the API".

I don't think "copied the declarations" and "copied the declarations and implementation" are interchangeable or generally understood to be interchangeable. If you told me someone "copied your API", I would absolutely assume that they'd copied the implementation and not just the declarations or the way the declarations were organized/named. The "SSO" language is not an arbitrary or legal distinction. It is a technical one that is necessary to convey the exclusion of the implementation precisely because people would otherwise assume we were also talking about the implementation when we say "API".

> If you told me someone "copied your API", I would absolutely assume that they'd copied the implementation and not just the declarations or the way the declarations were organized/named.

That's just you being unreasonable. I've literally never seen anyone else make a similar assertion or assumption, while the opposite is very common—most APIs that get copied are ones where the source code to the implementation is not even readily available to be copied, or where even looking at the original implementation's source code is dangerous for the author of a clone because of its license terms.

Confusing the API with the entire standard library implementation is not a common mistake, especially among people who pay any attention to this legal case.

> The "SSO" language is not an arbitrary or legal distinction. It is a technical one that is necessary to convey the exclusion of the implementation precisely because people would otherwise assume we were also talking about the implementation when we say "API".

The "SSO" language is not about clarifying that the API is separate from the implementation; that distinction is pretty clear on its own. It's about trying to make sure the API doesn't run afoul of copyright law's exclusion of "any idea, procedure, process, system, method of operation, [...]", by making APIs out to be something more than just a collection of parts that are individually not copyrightable.

Confusing the API with its implementation may not be a common mistake among people following this case, but the people following the case are not the ones deciding it (much as I wish that were true).

Huh? That's irrelevant and wasn't a question you raised before.

The implementation was different in this case though, so apart from the above the answer to this question also doesn't support what you are arguing.

It's very much relevant to what we're talking about when we talk about "the API". I am skeptical that when people think about what the above reply described as the "creative work at issue", they're not thinking about the implementation at all.

That's an effectively non-replaceable subset of the API. So in almost all cases that matter, it's equivalent to a copyright on "the API".

In 886 F.3d 1179 (2018) [1][2], the Fed. Cir. noted that:

"62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise the language itself will fail."

"On remand, the parties stipulated that only 170 lines of code were necessary to write in the Java language. It is undisputed, however, that Google copied 11,500 lines of code — 11,330 more lines than necessary to write in Java. That Google copied more than necessary weighs against fair use."

[1] https://scholar.google.com/scholar_case?case=107451649356761... [2] https://www.leagle.com/decision/infco20180327178

What? Java String alone has close to 100 members and even without function bodies would be over 170 lines unless you put every method on a single line.

Here's some additional context in from a lower court: Oracle Am., Inc. v. Google Inc., No. C 10-03561 WHA (N.D. Cal. Jun. 8, 2016) [1]:

"Oracle has portrayed the Java programming language as distinct from the Java API library, insisting that only the language itself was free for all to use. Turns out, however, that in order to write at all in the Java programming language, 62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise, the language itself will fail. The 62 "necessary" classes are mixed with "unnecessary" ones in the Java API library and it takes experts to comb them out. As a result, Oracle has now stipulated before the jury that it was fair to use the 62 "necessary" classes given that the Java programming language itself was free and open to use without a license"

"That the 62 "necessary" classes reside without any identification as such within the Java API library (rather than reside within the programming language) supports Google's contention that the Java API library is simply an extension of the programming language itself and helps explain why some view the Java API declarations as free and open for use as the programming language itself. At least to the extent of the 62 "necessary" classes, Oracle agrees."

[1] https://casetext.com/case/oracle-am-inc-v-google-inc-19#N196...

>Oracle has portrayed the Java programming language as distinct from the Java API library

I don't suppose it will persuade you that String (and many other classes) are in the Java.lang package.

> I don't suppose it will persuade you that String (and many other classes) are in the Java.lang package.

From the prior source [1], immediately below the previously-quoted text:

"Trial Exhibit 980, The Java Application Programming Interface, Volume 1, is a book that covers four packages and refers to them as the "core packages." According to the back cover of the book, these four packages "are the foundation of the Java language. These libraries include java.lang, java.io, java.util, and java.net. These are the general purpose libraries fundamental to every Java program."

[1] https://casetext.com/case/oracle-am-inc-v-google-inc-19#N196...

Here is Trial Exhibit 980:

https://www.docketalarm.com/cases/California_Northern_Distri...

TFA: Copyright law specifically excludes "systems" and "methods of operation" from copyright protection.

Sounds like a "clean room implementation" is needed, and that Google copied more than what was needed for inter-op.

If so, Google might lose the case, but the legal precedent would be you can copy apis but not implemention (unless that's the only way to implement them).

Reply on news.ycombinator.com