10 ms·

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 arg

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.

shadowgovt 6y ago
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.
- spacemanmatt 6y ago
  Justice Thomas wrote explicitly that he thought the majority blurred the lines between implementation and declaration. I think he's wrong by virtue of some disability to follow the winning argument logically. Clarence is sheer idiot.
  - dang 6y ago
    Please make your substantive points without calling names. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - spacemanmatt 6y ago
      An idiot, in modern use, is a stupid or foolish person. I don't think I have used the term incorrectly.
      - dang 6y ago
        Calling someone stupid or foolish is calling names in the sense that the site guidelines use that term. They ask you to omit all that from your posts to HN. Would you please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules?
- chris_wot 6y ago
  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.
- bluedays 6y ago
  Thomas is almost always on the wrong side of history. If you want your API non copyrightable, don't make it public. Problem solved.
  - Someone 6y ago
    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.
- Silhouette 6y ago
  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.
  - rocqua 6y ago
    > 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.
    - CapitalistCartr 6y ago
      The judicial branch did decide this.
    - rocqua 6y ago
      Sigh, I made a mistake mixing up the order of judicial and legislative in the sentence.
      - Silhouette 6y ago
        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.
- chasil 6y ago
  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.
  - guscost 6y ago
    > 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".
    - sn_master 6y ago
      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.
      - guscost 6y ago
        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.
    - matthewdgreen 6y ago
      > 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.
syshum 6y ago
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
- CydeWeys 6y ago
  While true, it's not particularly relevant. When you acquire a company you're taking on its liabilities along with its assets.
  - steveklabnik 6y ago
    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.
    - reikonomusha 6y ago
      To their credit, they are explicit (in a footnote I believe) about equating Sun and Oracle.
      - steveklabnik 6y ago
        Yes, it is one of the first footnotes.
  - syshum 6y ago
    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
- sn_master 6y ago
  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.
moron4hire 6y ago
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.
- JumpCrisscross 6y ago
  > 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."
  - moron4hire 6y ago
    Fair enough. I had taken that to mean they were assuming a given to then prove the negative.
deleted 6y ago
[deleted]
stjohnswarts 6y ago
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.
- dmitryminkovsky 6y ago
  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.
  - coolreader18 6y ago
    > 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.
  - xmprt 6y ago
    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.
mbesto 6y ago
> 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.
- DaiPlusPlus 6y ago
  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.

shadowgovt 6y ago

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.

spacemanmatt 6y ago
Justice Thomas wrote explicitly that he thought the majority blurred the lines between implementation and declaration. I think he's wrong by virtue of some disability to follow the winning argument logically. Clarence is sheer idiot.
- dang 6y ago
  Please make your substantive points without calling names. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - spacemanmatt 6y ago
    An idiot, in modern use, is a stupid or foolish person. I don't think I have used the term incorrectly.
    - dang 6y ago
      Calling someone stupid or foolish is calling names in the sense that the site guidelines use that term. They ask you to omit all that from your posts to HN. Would you please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules?
chris_wot 6y ago
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.
bluedays 6y ago
Thomas is almost always on the wrong side of history. If you want your API non copyrightable, don't make it public. Problem solved.
- Someone 6y ago
  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.
Silhouette 6y ago
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.
- rocqua 6y ago
  > 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.
  - CapitalistCartr 6y ago
    The judicial branch did decide this.
  - rocqua 6y ago
    Sigh, I made a mistake mixing up the order of judicial and legislative in the sentence.
    - Silhouette 6y ago
      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.
chasil 6y ago
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.
- guscost 6y ago
  > 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".
  - sn_master 6y ago
    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.
    - guscost 6y ago
      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.
  - matthewdgreen 6y ago
    > 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.

syshum 6y ago

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

CydeWeys 6y ago
While true, it's not particularly relevant. When you acquire a company you're taking on its liabilities along with its assets.
- steveklabnik 6y ago
  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.
  - reikonomusha 6y ago
    To their credit, they are explicit (in a footnote I believe) about equating Sun and Oracle.
    - steveklabnik 6y ago
      Yes, it is one of the first footnotes.
- syshum 6y ago
  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
sn_master 6y ago
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.

moron4hire 6y ago

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.

JumpCrisscross 6y ago
> 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."
- moron4hire 6y ago
  Fair enough. I had taken that to mean they were assuming a given to then prove the negative.

deleted 6y ago

[deleted]

stjohnswarts 6y ago

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.

dmitryminkovsky 6y ago
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.
- coolreader18 6y ago
  > 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.
- xmprt 6y ago
  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.

mbesto 6y ago

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

DaiPlusPlus 6y ago
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.