Hacker News Reader

Comment by dmitryminkovsky | Hacker News Reader

I'm glad about this outcome, because I agree the other outcome would have had a devastating effect on software development.

I also appreciate this fair use argument, especially when you point out the code in question was 0.4% of the entire API.

Still, I'll always struggle with the idea that "the amount and substantiality of the portion used" when copying an interface is comparable to copying an implementation. The interface is, intellectually, the substantially heavier, "bigger picture" component of the API than the implementation. In my view they are apples and oranges.

So, I'm glad this was the outcome. But I'll always feel like there was something wrong with Googe taking the Java SE interfaces and using them like they did, gratis.

View on HN

> especially when you point out the code in question was 0.4% of the entire API.

Honestly, the fact that it's 0.4% is a BS heuristic. What if they spent a year and all they did was refactor the code so that codebase was 1.43 million lines instead of 2.86? Would that mean these lines of code are 2x as powerful?

Lines of code is an indicative heuristic, but not a deterministic one.

I think they took "line" to refer to a Java method signature/prototype, so even if a method signature has each parameter wrapped to its own physical line on-disk, the whole method declaration still counts as "one line".

...at least I hope that's what they did.

It's one thing to steal algorithms but for interoperability to remain possible it is necessary for API to remain "fair use". I can't agree with you that this is a bad thing for them to copy Java SE interfaces.

I understand we can’t have copyrights on APIs, but something about it just doesn't feel "fair" to me, though.

Fair use makes sense to me when you're talking about the table of contents of a book. If I take the table of contents of a famous novel and write my own chapters, it makes sense to me that the owners of that book shouldn't be able to sue me. No one is going to read my book instead of Faulkner's. There's no equivalency there.

If I take an API (the table of contents equivalent of software), that's seems totally different, if not the opposite really: the interface is what matters, and the implementation is secondary. If you apply the analogy to a novel, it's as if I took the table of contents of a famous novel, write my own chapters, and it'll be equivalent to the famous novel. My chapters could be slightly "worse", but readers wouldn't necessarily notice a difference between my version or Faulkner's.

> the interface is what matters, and the implementation is secondary.

But that's kind-of the point IMO - if we take a free-market approach to this, copying (or sort of "standardizing" onto) an API allows for more innovation, since it's not a prohibitive up-front cost to switching the implementation. We don't copyright (or I guess patent, and I know they're different) the user interface of a fridge. Any fridge can have 2 doors and a slide-out freezer, but it's the actual implementation that would matter to a user - how energy-efficient it is, how cold it can get, extra conveniences (maybe akin to API extensions) like a water/ice dispenser that still can be "copied"/used by other fridges. And I'm sure that maybe those "interfaces" were patented originally, but it seems absurd now that they're so commonplace to restrict who can implement them.

If you copied the table of contents of a famous book and happened to make the book significantly better then there's a chance people would read your book instead of the famous one. Should the original owner be allowed to sue you in that case?

I think the same applies for APIs. It's only taking away users from the original implementation if the new one is better.

Substantiality was only one factor in the decision. There were lots of others, such as raison d'être of copyright, "promoting the progress of science and art". Because allowing copying of APIs is more important to the "progress of science and art" than the economic impact on the creator of the API, APIs are thusly not copyrightable.

> APIs are thusly not copyrightable

This is NOT what the Court found. At the very top of the Opinion, it says "we assume, for argument’s sake, that the material was copyrightable. But we hold that the copying here at issue nonetheless constituted a fair use."

Fair enough. I had taken that to mean they were assuming a given to then prove the negative.

if I remember my history correctly Google did not, Android was purchased by Google by that time the choice to use Java SE as the API was already made

While true, it's not particularly relevant. When you acquire a company you're taking on its liabilities along with its assets.

There's a line in here that says "In the 1990s, Oracle created a programming language called Java." that is funny on its face, but is written this way for the exact reason you're talking about.

To their credit, they are explicit (in a footnote I believe) about equating Sun and Oracle.

Yes, it is one of the first footnotes.

But the comment was not really about liabilities, but even in that context I think the history is still relevant.

Rewriting history the way we do in the context has all kinds of problems associated with it

With that logic, Oracle didn't create Java either. It was purchased by Oracle from Sun in 2009, after Google had already created the Android API.

I can recommend focusing on Justice Thomas' dissent, which contains a section related to this topic. I believe Justice Thomas agrees with your assessment, and he raises concern that the SCOTUS has essentially made APIs practically uncopyrightable (in that they will 100% of the time find that it's fair-use to use them). I actually disagree with him, but only in one sub-category: I think a SCOTUS ruling would be harder to predict in a situation where someone 100% copied an API that had no implementation. That removes the mitigating factor of what portion of the work was used.

Ironically the most protected APIs may be the ones nobody implements.

That’s a good thing. The ability to copy an API allows more competition, helps improve services as others provide similar functionality, and forces improvement because it becomes easier to migrate from one service to another.

One thing I do see happening is that sensitive and expensive to develop algorithm internals may be prevented from leaking into APIs. I, again, don’t see this as anything other than a win for devs. An API is fundamentally used to get stuff done, if a developer doesn’t need to know the implementation details I overall think this is a win for the developer using the API.

Thomas is almost always on the wrong side of history. If you want your API non copyrightable, don't make it public. Problem solved.

I think you mean “If you want your API copyrightable, don't make it public”, not “If you want your API non copyrightable, don't make it public”

Now, how do you let third parties program against that non-public API? Would only showing it to licensees be a legal way to do that?

If so, and if the API becomes popular, I don’t see how to prevent those licensees from leaking the API to the world, say through small code snippets on Stack Overflow.

I believe Justice Thomas agrees with your assessment, and he raises concern that the SCOTUS has essentially made APIs practically uncopyrightable (in that they will 100% of the time find that it's fair-use to use them).

That would seem a reasonable outcome, for much the same reason that copyright not protecting the appearance of fonts under US law is reasonable. Yes, it is overriding copyright protection for a creative work that would otherwise apply. However, it does so because a greater good is served, in this case by ensuring that interoperability cannot be encumbered, something which (as the majority opinion alludes) goes against the very purpose of copyright under US law.

> Yes, it is overriding copyright protection for a creative work that would otherwise apply. However, it does so because a greater good is served

One could argue that this is for the judicial branch, not the legislative branch, to decide.

The judicial branch did decide this.

Sigh, I made a mistake mixing up the order of judicial and legislative in the sentence.

The main legal basis for the majority opinion seems to be fair use, so isn't the system operating as intended? The legislators set out a principle of fair use in statute. The court applied that principle in the context of this specific case.

Had Justice Thomas' opinion prevailed, most everything within POSIX was originally copyright by AT&T USL as part of System V, and would be owned by the current holders of that intellectual property.

Anyone using fork(), stat(), open(), or other basic parts of the UNIX development environment would be in violation.

Those copyrights were purchased by Novell at some point, and I believe ended up with Attachmate.

One would think that the C Programming Language is also covered by copyright via the K&R books, which would put anyone using printf() in the same position.

That is truly a nightmare scenario.

> That is truly a nightmare scenario.

Absolutely, but courts are supposed to interpret the law, not rule whichever way avoids nightmare scenarios.

The risk of going too far in that direction (and this is by no means the first case in which SCOTUS c̶l̶e̶a̶r̶l̶y̶ may have rationalized a decision for pragmatic reasons) is that it makes the court more corruptible. I am glad the majority ruled this way, because I agree that it leads to a better outcome in this case. On the other hand, any departure from a pure interpretation of the law is very dangerous, because it normalizes the more-corruptible mode of operation, and that can lead to another kind of "nightmare scenario".

If it reaches SCOTUS, it means the law is already ambiguous the way its written and that no one interpretation is obviously the correct one.

You would certainly hope so, but that logic just passes the responsibility to interpret law faithfully onto the lower courts, which are also perhaps more easily corrupted.

> On the other hand, any departure from a pure interpretation of the law is very dangerous

You should read the law in question. This would be Section 107 of the Copyright Act, which defines "fair use". It's extremely vague and is best interpreted as a set of considerations that the courts should take into account so that they can handle situations like this one on a case by case basis. If Congress wanted to be more prescriptive, they could (ETA: and if they become unhappy with the courts' decisions they still can in the future), but I think that would lead to worse outcomes.

Makes sense, and I am definitely not an expert on fair use. I'll cross out "clearly" in my aside above.

I was really just responding to the implication that SCOTUS did the right thing because "it would be a nightmare scenario" otherwise.

> courts are supposed to interpret the law

The law also states that copyright's purpose is to stimulate progress of the arts, and that's why fair use is possible. Interpreting the law also means establishing the limits of fair use.

Good point.

No, fair use is possible because of the First Amendment. While it is now adopted in statute, the statute was codifying a Constitutional limit that courts previously found in copyright protection grounded in the First Amendment, not the Copyright Clause.

But, still, yes, determining the scope and applicability of fair use is part of applying the law.

Ah, I had heard of the first amendment thing but I thought it was why government work must be in the public domain (i.e. putting it under copyright would prevent reproduction and therefore infringe first amendment rights).

Reply on news.ycombinator.com