20 ms·

While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. One of the big open questions is "

by jxf 6y ago

While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use: > To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.” That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory: > Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment. I'll count that as a win, on balance.

pdoconnell 6y ago
In general the court seems to try to go to the easiest decision point in a case. The copyrightability of an API is less relevant if the user being sued should win regardless because of fair use. This is better than a plurality decision where there's multiple reasonings on API copywrite that make future decisions difficult. Here at least the court gives guidance on how to think about evaluating fair use in this context, which lower courts can apply.
kyrra 6y ago
Thomas's dissent explicitly points this out. Without diving into "are APIs copyrightable?", the majority are skipping what should have been evaluated first before saying if they were fair-use or not.
- GavinMcG 6y ago
  Why should it have been evaluated first? I understand the intuition you're getting at: logically, the first question could make the second irrelevant. But if the second question resolves the issue even when the first is construed in favor of the other party, what's the rationale for demanding the court focus on the first question?
  - ghaff 6y ago
    IANAL, but I can imagine something like the following: A. We decide this is fair use based on the small number of LOC used and call it a day B. OR we can decide that APIs are not copyrightable even though they're self-evidently creative works because of the importance of interoperability based on something something related to Borland v. Lotus, a case that we couldn't agree on the last time it came up. Hey folks. Let's do A.
    - Gh0stRAT 6y ago
      While I agree that APIs should not be copyrightable, the Supreme Court has been criticized for "legislating from the bench". Avoiding the temptation to set bigger and more far-reaching precedents than is strictly necessary for the case at hand avoids giving the impression that the judicial branch is doing the job of the legislative branch.
      - hctaw 6y ago
        This is something I struggle with, personally. I have fundamental problems with an unelected council that serves for life creating law. However, we have an extremely inefficient form of Government that doesn't allow for quick adaptation, and legal questions will arise tomorrow that did not occur to legislators today. The courts are supposed to help resolve any ambiguity. The question over whether or not APIs are copyrightable is, however, not a question of ambiguity. APIs are software (or documentation, or source code, etc), and any category you place them into is copyrightable under the current law. If we don't want APIs to be copyrightable, then they must have explicit exemptions carved out in the law. The courts are bound to consider an API as copyrighted right now, and the only question is whether violating that copyright is fair-use. I think the Court did the right thing in skirting the question. That's up to legislators, the Court cannot help. We need fundamental reform of IP protections for software anyway.
        sprayk 6y ago
        Slow legislation is a feature rather than a bug. Less opportunity for reactionary laws based on emotion or a collective misunderstanding of events that we later regret. It's not a perfect deterrent, obviously, e.g. the Patriot Act
- deleted 6y ago
  [deleted]
- lostcolony 6y ago
  Yeah, but Thomas said "The majority can not square it's fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable". Which is obviously false. A fair use analysis can -only- take place if the assumption is the code is copyrightable; if the majority had first decided the code was not copyrightable, fair use is immaterial. Thomas' argument, if followed, would either have led to this same decision, or would make the opposite point he was trying to make.
  - notsureaboutpg 6y ago
    If you read the whole dissent, it makes sense. He's saying that the fair-use analysis the majority used would render any kind of declaring code de facto not copyrightable, since the majority is essentially saying that the traits of declaring code make any implementation of it fair-use by default.
  - avs733 6y ago
    Over the years, the STEM professional in me has become increasingly intrigued by the ways in which law progresses because it is so fundamentally different from my preferred method of making sense of the world. Within that, and with my incredibly limited understanding of how law evolves in the courts...it seems like Thomas says demonstrably incorrect things more frequently than I am comfortable with.
    - deleted 6y ago
      [deleted]
    - rrrazdan 6y ago
      Interesting. In my very limited understanding I have a very opposite view, specifically around Justice Thomas. If you read pdonis’s reply to your parent, you will see that Thomas was rather correct in the way law should have applied in this case. I find that in the limited few of few cases I have read , I politically like the judgement made but I identify more with how Thomas thought about the case. Really fascinated by the American legal system. In some ways really elegant and so much better than the legal system in my own country.
  - 6y ago
- amalcon 6y ago
  That point is super weird, because the court has a tendency to make the narrowest ruling that is able to resolve the case in front of them. Clearly the fair use question is more narrow than the question of copyrightability of APIs.
- gnopgnip 6y ago
  APIs and most code is copyrightable, they are original works of authorship fixed in a tangible medium, all that is required by he Copyright Act of 1976. It doesn't look like either party in this case claimed the code was not eligible for copyright either If they shouldn't be copyrightable because the world would be better off, interoperability between business is harmed, it is up to congress to change the law. Historically legislation like this harms smaller companies mostly, larger companies can better afford to deal with the requirement to license or the cost/work required to stick to fair use or litigate over it, so the larger companies that can afford to lobby to change the law aren't going to want them changed. This case certainly sets precedent that API re-implementation can be fair use, not that it always is. Fair use is very fact specific, based on a four part test where having one part in favor can be fair use, and having three parts in your favor can still be infringement. A future case with products that would have a more substantial effect on the market of the original work, or had more of the original work reused than was strictly necessary could very well be infringement. With regards to "the amount and substantiality of the portion used" in this case less than 1% of the original code was copied just measuring the lines of code. Substantiality is harder to put a number on, but arguably it was only a small portion of the original product. This is a very low and for many other APIs a more substantial portion would need to be copied to be useful. The precedential value of this case is unclear without either the law changing, or further litigation.
  - Natanael_L 6y ago
    How often does the API itself exceed the level of creativity of uncopyrightable plain lists of facts? It's not clear to me that it should be considered copyrightable on its own, especially with the fact that copyright explicitly do not cover functional elements. The declarations only instructs you on how to interact with the actual code, and AFAICT rarely add any creative height on top of what's in the main source code. If presence and order of keywords was sufficient, such legal precedence would create collateral damage at levels that is beyond absurd - outside of software, this would extend to atypical calendar formats, plenty of paper forms, automatic telephone voice menus, map projections, and so much more. Calling it "destructive" wouldn't suffice. Entire industries would be leveled by uncooperative rent seekers that hold old copyrights.
jcranmer 6y ago
I noticed that comment too early on. Breyer's opinion comes pretty close to saying "it's at best 'thin copyright'" but the fact that it's explicitly disclaimed makes me think that this is to some extent a compromise position: rather than arguing about whether SSO is copyrightable and risk a bigger split, just concede it because the fair use is sufficient here.
- ece 6y ago
  That's exactly why fair use exists. A teacher showing a movie in class is fair use, editing a clip for memes is fair use, making backups is fair use. APIs are copyrightable, but independent implementations are fair use, this is an outright win IMO. SSO might or might not be copyrightable in all of these cases, but we have certainty with fair use for specific cases. In deference to OP, the question was never "Are APIs copyrightable?" The question was is what Google did in taking header information and doing their own implementation fair use, and it's unquestionably good now that the SCOTUS said this is fair use. Make sure to actually do your own implementation though. Sun/Oracle didn't want to fragment Java, they copyrighted the language spec, and provided the JVM under SCSL before GPL. Java isn't fragmented, Sun/Oracle got what they wanted.
  - ece 6y ago
    Ops, I meant to say s/APIs/software projects/ are copyrightable, as the question of copyrightable APIs within software projects was sidestepped by the court. It's a lot easier to say what Google did was fair use than decide where to draw the line on where an API is in a software project and whether it is copyrightable or not.
  - jcranmer 6y ago
    When SCOTUS accepted the cert petition, it granted two questions: a) are APIs copyrightable and b) if they are, is Google's use fair. Breyer's opinion explicitly lays this out, but doesn't explore API copyrightability any further than "assume it is for this discussion." Playing Kremlinology here, it feels like Breyer originally had an opinion that explained that APIs were not copyrightable, but sacrificed that section of the opinion to build a 6-2 majority. It's really weird that the opinions took so long to come out for how simple they end up being--why is this coming it in early April instead of early/mid February if it's written like this? My supposition is that there was a much more sharply divided court, running a 3-3-2 or 4-2-2 opinion, and by dropping the discussion of whether or not the APIs were copyrightable and instead saying "it's at best thin copyright" (i.e., it's copyrightable but good luck ever winning infringement) the opinions collapsed down into a more simple outcome. One thing's for sure: this is the case I'm most interested in finding out all the backroom discussions that went on here.
marcosdumay 6y ago
> That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory Well, if you can an API for any primary purpose that not making software compatible with the one you are copying, then it's not really an API. It's perfectly fine if you can't frame it and sell around as a painting.
shadowgovt 6y ago
I'm not sure why it's claimed they skirted the question... If I understand correctly, the Court answered the question when they issued bench instructions that APIs were to be considered copyrightable. Is the difference that there's no SCOTUS precedent on the issue because it wasn't addressed in this case? Because (IANAL but) I'd assume the bench direction is itself precedent... In that if another circuit court tried to run a case as if the question was in the open, the Court would again ruler-slap them and say "No, assume APIs are copyrightable, plain language of the law."
- gpm 6y ago
  They did not say that APIs were copyrightable, they said that if "we assume, for argument's sake, that [APIs are] copyrightable, [...] the copying here at issue nonetheless constituted a fair use". From page 1 of the opinion, i.e. the actual ruling, which follows the "syllabus" in the pdf. The syllabus is basically just a summary. It's page 5 of the pdf.
  - shadowgovt 6y ago
    I see; the difference is SCOTUS vs. circuit court of appeals precedent. I was referring to the decision of May 9, 2014 that overrulled the Alsup court assertion that APIs are not subject to copyright. But that decision was not from SCOTUS but from the appeals court for the circuit. Current status, if I understand correctly, is that SCOTUS has not weighed in on whether APIs may be subject to copyright, and precedent in (Edit: Ninth Circuit) should be that they are to be considered copyrightable (and, I suppose, "no precedent in this circuit or from the Supreme Court" in all other circuits).
    - gpm 6y ago
      I don't think federal circuit rulings on non patent matter are binding precedent anywhere? I could be wrong about that. I certainly doubt there binding precedent on just one federal district (and not either all the district courts in the relevant circuit, or all district courts period).
jhanschoo 6y ago
> That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory: >> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment. It's even weaker than you think. It was important that Google's use of Java's API was on a non-competing product. It's still quite up in the air what happens if you provide a generic library using your competitor's API without licensing it from them.
- sesuximo 6y ago
  The dissent point out “non-competing” is a bit of a stretch as this affected contracts oracle had.
  - notsureaboutpg 6y ago
    The dissent really made me think that, as the law stands, Google is in the wrong here, and what everyone is really trying to do is figure out how to allow copying / reimplementing APIs since that probably makes business / programming / innovation easier.
- extropy 6y ago
  How is J2ME not competing?
  - deleted 6y ago
    [deleted]
  - monocasa 6y ago
    Because A) J2ME targeted feature phones. B) Google isn't accused of copying J2ME when you get down to it. The parts that make ME distinct from SE weren't reimplemented in Android's Harmony fork (looking strongly at javax.microedition), and a lot of packages that SE implemented that ME didn't were present in Android.
- 6y ago
pfdietz 6y ago
Making APIs copyrightable is a GOOD thing. It means they aren't patentable.
- sn_master 6y ago
  What does that even mean? Algorithms and logical constructs like computer code aren't patentable under US law if that's what you're talking about.
- CogitoCogito 6y ago
  Could you explain your line of thinking here a bit more?
  - pfdietz 6y ago
    https://patentlyo.com/patent/2017/05/overlapping-protecting-innovations.html https://patentlyo.com/patent/2017/05/overlapping-protecting-...
    - wtallis 6y ago
      Generally, a comment such as this should also include some words from you about what kind of point you're trying to make by referring to the longer work. I think you're trying to use this blog post as evidence that patent and copyright protection are mutually exclusive, but from skimming this post it seems to only say that they should be mutually exclusive, while the Federal Circuit apparently disagrees. So at the very least, you would need to also point out how this Supreme Court decision reaffirms the blog post's position and strikes down the Federal Circuit on that question. But that seems to be far beyond the subject matter that the Supreme Court has actually ruled on today. And you still haven't addressed why anyone should prefer APIs to be covered by copyright rather than patent law, when patents have much shorter duration and are more easily challenged.
      - pfdietz 6y ago
        The blog post presents legal arguments why (with existing SCOTUS rulings) they should be considered separate. I could repeat all that, or just ask you to read it.
iamcreasy 6y ago
I suppose Supreme court decision over this matter sets precedence for any future cases.
- iamcreasy 6y ago
  Why the downvote? You can read more about it here: https://en.wikipedia.org/wiki/Precedent https://en.wikipedia.org/wiki/Precedent
williesleg 6y ago
The bigger story is Justice Thomas is saying Big Tech needs to be regulated like utilities.
fnordprefect 6y ago
One of the big open questions is "are APIs copyrightable?" The Australian equivalent to the US Supreme Court considered this over 20 years ago, and imho got the correct result (not copyrightable): http://www.austlii.edu.au/cgi-bin/viewdoc/au/cases/cth/HCA/1999/49.html http://www.austlii.edu.au/cgi-bin/viewdoc/au/cases/cth/HCA/1... IMHO they got the Huffman table wrong, although arguably it was the result compelled by an overprotective approach.
- ifore 6y ago
  It seems that it was somewhat inevitable given the US vs Australian distinction on whether to protect Creativity vs Effort (years ago I investigated this rabbit hole when I had a client who wanted to set up a White Pages clone site by buying the data from someone who had digitised it [with a lot of manual entry!] by low-paid Indians. They were very disappointed when I told them to contact an IP lawyer because it was almost certainly going to get them sued) I did cry a little at the court's assertion creating the huffman table required "a very great deal of hard work". Gather a corpus of databases you have lying around, count the occurrences of each byte value and apply a <50 line algorithm that has been around since the 1950s and is a pretty standard university assignment. "a very great deal of hard work" indeed. Presumably division 4A / s47D would now allow the cloning of the data table if decided today -- are you aware of any post-1999 case law?
btilly 6y ago
While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. It is even less decisive than you're saying. The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are. And for fair use, one of the statutory factors is the "effect" of the copying on the "market for or value of the copyrighted work." That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory: The fact that one statutory factor points one way doesn't stop another from pointing the other. And part of their decision is the conclusion that Google's copying increased the value of Java. That will generally not be true when APIs get copied. In particular if I am trying to create a product that competes with yours, and I copy your API for the purpose of interoperability, I'm going to have an uphill battle claiming fair use. Because my product directly reduces the market for your product. To name some historically important examples, Microsoft copied the APIs for JavaScript from Netscape, Microsoft copied APIs from Lotus 1-2-3 for Excel, and Wine copied APIs from Windows for Linux. The outcomes famously were that Netscape went out of business, Lotus 1-2-3 was discontinued, and Linux became somewhat more viable.
- curt15 6y ago
  >The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are. Federal Circuit's ruling would only be precedent in the 9th circuit. As it does not have original jurisdiction in copyright disputes (only patent cases), it doesn't supercede any copyrightability rulings in other circuits, for instance the 1st circuit's holding in Lotus v Borland that the Lotus macros were not copyrightable as a "method of operation". And today's opinion cites Lotus v Borland several times even though the original 1996 Supreme Court case was deadlocked at 4-4.
  - wtallis 6y ago
    > Federal Circuit's ruling would only be precedent in the 9th circuit. I think it's even narrower than that: the Federal Circuit's ruling on non-patent aspects of the case isn't binding precedent outside of Oracle v. Google. District courts in the Ninth Circuit and the appeals court are free to ignore the Federal Circuit ruling in future cases and look to only rulings from the Ninth Circuit and Supreme Court as binding precedent.
hyperpallium2 6y ago
Always seemed crazy to me that interoperability was ever in doubt. Copyright in a private, internal API seems reasonable in principle. RIP kotlin-first on android?
- pjmlp 6y ago
  Kotlin never fixed anything on this area, beacause it is a guest language for the JVM, and the whole Android tooling depends on Java and JVM, ART only runs on the devices. So to be fully Java/JVM free with Kotlin-first, Google and JetBrains would need to re-write the Android world to run on ART or Kotlin/Native, including anything that might come from Maven central.
anonymouse008 6y ago
> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment. I'm waiting for an ambitious attorney to figure out how to frame this as poaching talent from an ecosystem to bring to another.
bobbyi_settv 6y ago
> One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use: Doesn't deciding that it's fair use specifically mean that they think it is copyrightable? The fair use doctrine specifically refers to the use of copyrighted material.
- AnimalMuppet 6y ago
  No. "Assume it's copyrightable. It's still fair use." That means you don't have to answer "Is it copyrightable?" The Supreme Court generally prefers to not answer questions that they don't have to answer.
  - shemnon42 6y ago
    So in programmer speak if (!isFairUse(workUnderInvestigation) && copyrightable(originalWork)) { bigCopyrightPayout(); } Short circuit on the and operator. It's fair use, so copyrightable will not be evaluated. Evaluating copyrightable has an obervable side effect of creating a precedent.
    - AnimalMuppet 6y ago
      Yes, exactly that. Why do the && in that order? Because isFairUse(workUnderInvestigation) was a much less expensive operation than copyrightable(originalWork) for this particular value of originalWork.
      - shemnon42 6y ago
        That is the order scotus considered it.
        AnimalMuppet 6y ago
        Right, and that's why SCOTUS considered it in that order. Deciding API copyright was a much bigger decision than deciding fair use.
grumple 6y ago
I think the focus on fair use is even better. It means that EVEN IF you can copyright the API, it doesn't matter because others can reimplement it. So not only can corps not stop that, but courts might rule later that the copyrights are totally invalid.
- ece 6y ago
  Exactly this, the same protection that memers have in editing content (but not copying the full implementation), software engineers now have too thanks to fair use.
TeeMassive 6y ago
> One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use Also what people fails to realize with fair use is that it is up to the defendant raise a fair use defense and then a judge has to approve of that defense as a valid one (Viva Frei explains this https://youtu.be/AzQz1LrjCWk?t=253 https://youtu.be/AzQz1LrjCWk?t=253 ).Meaning Oracle can still go on with its lawfare campaign against those who made the mistake of basing their tech on theirs.
- wtallis 6y ago
  Oracle would have to come up with new patent claims in order to get another case before the Federal Circuit, which is their best (only?) hope for having their API copyright claims upheld.
- pwdisswordfish6 6y ago
  Fortunately, although it is pay-to-play, it's not pay-to-win. Oracle (or any other well-heeled player) can spend half a million or more in legal fees trying to go after a small company, but that doesn't mean that company has to match costs.
redis_mlc 6y ago
> Google copied these lines not because of their creativity or beauty The court mentioned "creativity or beauty" because US copyright was originally about artistic originality before the widened application for software. So what the court is saying is that the copied lines are not substantial and also not creative enough to infringe on the original work. I don't see that mentioned elsewhere in this thread.
Abishek_Muthian 6y ago
Not from U.S. Would the discussions, consultations between the judges and the independent subject matter experts be published? Surely there must have been such extensive discussions right? Or is the judgement based upon the subject matter experts presented as witness from both sides themselves? I'm intrigued by how judgements are passed in such intricate technical matters.
- dragonwriter 6y ago
  > Would the discussions, consultations between the judges and the independent subject matter experts be published? No such consultation exists. > Or is the judgement based upon the subject matter experts presented as witness from both sides themselves? Since this was a decision as a matter of law, and not one turning on disputed facts (the Supreme Court can decide cases on either basis), the judges are the relevant subject matter experts.
  - Abishek_Muthian 6y ago
    Thank you for the succinct answer.
smokey_circles 6y ago
>The court skirted that question, and instead focused on whether it was fair use Because the federal courts already ruled that APIs are eligible for copyright [0]. Google wanted to overturn the ruling that they were in violation of copyright and argued they used Java's APIs fairly under copyright law. The court will not answer questions not put to it, and Google (I presume) felt they had a better shot at getting the court to agree it was fair usage, rather than arguing copyright should not apply here. 0: https://www.paleudislaw.com/federal-circuit-rules-that-apis-are-eligible-for-copyright-prote.html https://www.paleudislaw.com/federal-circuit-rules-that-apis-...
- dragonwriter 6y ago
  > The court will not answer questions not put to it, and Google (I presume) felt they had a better shot at getting the court to agree it was fair usage, rather than arguing copyright should not apply here. This is false; Google appealed on both copyrightability and fair use, and the Supreme Court agreed to hear both issues.
_the_inflator 6y ago
Exactly. Coming from law, sometimes like in this case, some topics can be left undecided, if it does not change the result. Even if the code could have been copyrighted, it would still be considered fair use. Translated into developers speech: this is some sort of early return. ;)

by jxf 6y ago

pdoconnell 6y ago

In general the court seems to try to go to the easiest decision point in a case. The copyrightability of an API is less relevant if the user being sued should win regardless because of fair use. This is better than a plurality decision where there's multiple reasonings on API copywrite that make future decisions difficult. Here at least the court gives guidance on how to think about evaluating fair use in this context, which lower courts can apply.

kyrra 6y ago

Thomas's dissent explicitly points this out. Without diving into "are APIs copyrightable?", the majority are skipping what should have been evaluated first before saying if they were fair-use or not.

GavinMcG 6y ago
Why should it have been evaluated first? I understand the intuition you're getting at: logically, the first question could make the second irrelevant. But if the second question resolves the issue even when the first is construed in favor of the other party, what's the rationale for demanding the court focus on the first question?
- ghaff 6y ago
  IANAL, but I can imagine something like the following: A. We decide this is fair use based on the small number of LOC used and call it a day B. OR we can decide that APIs are not copyrightable even though they're self-evidently creative works because of the importance of interoperability based on something something related to Borland v. Lotus, a case that we couldn't agree on the last time it came up. Hey folks. Let's do A.
  - Gh0stRAT 6y ago
    While I agree that APIs should not be copyrightable, the Supreme Court has been criticized for "legislating from the bench". Avoiding the temptation to set bigger and more far-reaching precedents than is strictly necessary for the case at hand avoids giving the impression that the judicial branch is doing the job of the legislative branch.
    - hctaw 6y ago
      This is something I struggle with, personally. I have fundamental problems with an unelected council that serves for life creating law. However, we have an extremely inefficient form of Government that doesn't allow for quick adaptation, and legal questions will arise tomorrow that did not occur to legislators today. The courts are supposed to help resolve any ambiguity. The question over whether or not APIs are copyrightable is, however, not a question of ambiguity. APIs are software (or documentation, or source code, etc), and any category you place them into is copyrightable under the current law. If we don't want APIs to be copyrightable, then they must have explicit exemptions carved out in the law. The courts are bound to consider an API as copyrighted right now, and the only question is whether violating that copyright is fair-use. I think the Court did the right thing in skirting the question. That's up to legislators, the Court cannot help. We need fundamental reform of IP protections for software anyway.
      - sprayk 6y ago
        Slow legislation is a feature rather than a bug. Less opportunity for reactionary laws based on emotion or a collective misunderstanding of events that we later regret. It's not a perfect deterrent, obviously, e.g. the Patriot Act
deleted 6y ago
[deleted]
lostcolony 6y ago
Yeah, but Thomas said "The majority can not square it's fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable". Which is obviously false. A fair use analysis can -only- take place if the assumption is the code is copyrightable; if the majority had first decided the code was not copyrightable, fair use is immaterial. Thomas' argument, if followed, would either have led to this same decision, or would make the opposite point he was trying to make.
- notsureaboutpg 6y ago
  If you read the whole dissent, it makes sense. He's saying that the fair-use analysis the majority used would render any kind of declaring code de facto not copyrightable, since the majority is essentially saying that the traits of declaring code make any implementation of it fair-use by default.
- avs733 6y ago
  Over the years, the STEM professional in me has become increasingly intrigued by the ways in which law progresses because it is so fundamentally different from my preferred method of making sense of the world. Within that, and with my incredibly limited understanding of how law evolves in the courts...it seems like Thomas says demonstrably incorrect things more frequently than I am comfortable with.
  - deleted 6y ago
    [deleted]
  - rrrazdan 6y ago
    Interesting. In my very limited understanding I have a very opposite view, specifically around Justice Thomas. If you read pdonis’s reply to your parent, you will see that Thomas was rather correct in the way law should have applied in this case. I find that in the limited few of few cases I have read , I politically like the judgement made but I identify more with how Thomas thought about the case. Really fascinated by the American legal system. In some ways really elegant and so much better than the legal system in my own country.
- 6y ago
amalcon 6y ago
That point is super weird, because the court has a tendency to make the narrowest ruling that is able to resolve the case in front of them. Clearly the fair use question is more narrow than the question of copyrightability of APIs.
gnopgnip 6y ago
APIs and most code is copyrightable, they are original works of authorship fixed in a tangible medium, all that is required by he Copyright Act of 1976. It doesn't look like either party in this case claimed the code was not eligible for copyright either If they shouldn't be copyrightable because the world would be better off, interoperability between business is harmed, it is up to congress to change the law. Historically legislation like this harms smaller companies mostly, larger companies can better afford to deal with the requirement to license or the cost/work required to stick to fair use or litigate over it, so the larger companies that can afford to lobby to change the law aren't going to want them changed. This case certainly sets precedent that API re-implementation can be fair use, not that it always is. Fair use is very fact specific, based on a four part test where having one part in favor can be fair use, and having three parts in your favor can still be infringement. A future case with products that would have a more substantial effect on the market of the original work, or had more of the original work reused than was strictly necessary could very well be infringement. With regards to "the amount and substantiality of the portion used" in this case less than 1% of the original code was copied just measuring the lines of code. Substantiality is harder to put a number on, but arguably it was only a small portion of the original product. This is a very low and for many other APIs a more substantial portion would need to be copied to be useful. The precedential value of this case is unclear without either the law changing, or further litigation.
- Natanael_L 6y ago
  How often does the API itself exceed the level of creativity of uncopyrightable plain lists of facts? It's not clear to me that it should be considered copyrightable on its own, especially with the fact that copyright explicitly do not cover functional elements. The declarations only instructs you on how to interact with the actual code, and AFAICT rarely add any creative height on top of what's in the main source code. If presence and order of keywords was sufficient, such legal precedence would create collateral damage at levels that is beyond absurd - outside of software, this would extend to atypical calendar formats, plenty of paper forms, automatic telephone voice menus, map projections, and so much more. Calling it "destructive" wouldn't suffice. Entire industries would be leveled by uncooperative rent seekers that hold old copyrights.

jcranmer 6y ago

I noticed that comment too early on. Breyer's opinion comes pretty close to saying "it's at best 'thin copyright'" but the fact that it's explicitly disclaimed makes me think that this is to some extent a compromise position: rather than arguing about whether SSO is copyrightable and risk a bigger split, just concede it because the fair use is sufficient here.

ece 6y ago
That's exactly why fair use exists. A teacher showing a movie in class is fair use, editing a clip for memes is fair use, making backups is fair use. APIs are copyrightable, but independent implementations are fair use, this is an outright win IMO. SSO might or might not be copyrightable in all of these cases, but we have certainty with fair use for specific cases. In deference to OP, the question was never "Are APIs copyrightable?" The question was is what Google did in taking header information and doing their own implementation fair use, and it's unquestionably good now that the SCOTUS said this is fair use. Make sure to actually do your own implementation though. Sun/Oracle didn't want to fragment Java, they copyrighted the language spec, and provided the JVM under SCSL before GPL. Java isn't fragmented, Sun/Oracle got what they wanted.
- ece 6y ago
  Ops, I meant to say s/APIs/software projects/ are copyrightable, as the question of copyrightable APIs within software projects was sidestepped by the court. It's a lot easier to say what Google did was fair use than decide where to draw the line on where an API is in a software project and whether it is copyrightable or not.
- jcranmer 6y ago
  When SCOTUS accepted the cert petition, it granted two questions: a) are APIs copyrightable and b) if they are, is Google's use fair. Breyer's opinion explicitly lays this out, but doesn't explore API copyrightability any further than "assume it is for this discussion." Playing Kremlinology here, it feels like Breyer originally had an opinion that explained that APIs were not copyrightable, but sacrificed that section of the opinion to build a 6-2 majority. It's really weird that the opinions took so long to come out for how simple they end up being--why is this coming it in early April instead of early/mid February if it's written like this? My supposition is that there was a much more sharply divided court, running a 3-3-2 or 4-2-2 opinion, and by dropping the discussion of whether or not the APIs were copyrightable and instead saying "it's at best thin copyright" (i.e., it's copyrightable but good luck ever winning infringement) the opinions collapsed down into a more simple outcome. One thing's for sure: this is the case I'm most interested in finding out all the backroom discussions that went on here.

marcosdumay 6y ago

> That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory Well, if you can an API for any primary purpose that not making software compatible with the one you are copying, then it's not really an API. It's perfectly fine if you can't frame it and sell around as a painting.

shadowgovt 6y ago

I'm not sure why it's claimed they skirted the question... If I understand correctly, the Court answered the question when they issued bench instructions that APIs were to be considered copyrightable. Is the difference that there's no SCOTUS precedent on the issue because it wasn't addressed in this case? Because (IANAL but) I'd assume the bench direction is itself precedent... In that if another circuit court tried to run a case as if the question was in the open, the Court would again ruler-slap them and say "No, assume APIs are copyrightable, plain language of the law."

gpm 6y ago
They did not say that APIs were copyrightable, they said that if "we assume, for argument's sake, that [APIs are] copyrightable, [...] the copying here at issue nonetheless constituted a fair use". From page 1 of the opinion, i.e. the actual ruling, which follows the "syllabus" in the pdf. The syllabus is basically just a summary. It's page 5 of the pdf.
- shadowgovt 6y ago
  I see; the difference is SCOTUS vs. circuit court of appeals precedent. I was referring to the decision of May 9, 2014 that overrulled the Alsup court assertion that APIs are not subject to copyright. But that decision was not from SCOTUS but from the appeals court for the circuit. Current status, if I understand correctly, is that SCOTUS has not weighed in on whether APIs may be subject to copyright, and precedent in (Edit: Ninth Circuit) should be that they are to be considered copyrightable (and, I suppose, "no precedent in this circuit or from the Supreme Court" in all other circuits).
  - gpm 6y ago
    I don't think federal circuit rulings on non patent matter are binding precedent anywhere? I could be wrong about that. I certainly doubt there binding precedent on just one federal district (and not either all the district courts in the relevant circuit, or all district courts period).

jhanschoo 6y ago

> That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory: >> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment. It's even weaker than you think. It was important that Google's use of Java's API was on a non-competing product. It's still quite up in the air what happens if you provide a generic library using your competitor's API without licensing it from them.

sesuximo 6y ago
The dissent point out “non-competing” is a bit of a stretch as this affected contracts oracle had.
- notsureaboutpg 6y ago
  The dissent really made me think that, as the law stands, Google is in the wrong here, and what everyone is really trying to do is figure out how to allow copying / reimplementing APIs since that probably makes business / programming / innovation easier.
extropy 6y ago
How is J2ME not competing?
- deleted 6y ago
  [deleted]
- monocasa 6y ago
  Because A) J2ME targeted feature phones. B) Google isn't accused of copying J2ME when you get down to it. The parts that make ME distinct from SE weren't reimplemented in Android's Harmony fork (looking strongly at javax.microedition), and a lot of packages that SE implemented that ME didn't were present in Android.
6y ago

pfdietz 6y ago

Making APIs copyrightable is a GOOD thing. It means they aren't patentable.

sn_master 6y ago
What does that even mean? Algorithms and logical constructs like computer code aren't patentable under US law if that's what you're talking about.
CogitoCogito 6y ago
Could you explain your line of thinking here a bit more?
- pfdietz 6y ago
  https://patentlyo.com/patent/2017/05/overlapping-protecting-innovations.html https://patentlyo.com/patent/2017/05/overlapping-protecting-...
  - wtallis 6y ago
    Generally, a comment such as this should also include some words from you about what kind of point you're trying to make by referring to the longer work. I think you're trying to use this blog post as evidence that patent and copyright protection are mutually exclusive, but from skimming this post it seems to only say that they should be mutually exclusive, while the Federal Circuit apparently disagrees. So at the very least, you would need to also point out how this Supreme Court decision reaffirms the blog post's position and strikes down the Federal Circuit on that question. But that seems to be far beyond the subject matter that the Supreme Court has actually ruled on today. And you still haven't addressed why anyone should prefer APIs to be covered by copyright rather than patent law, when patents have much shorter duration and are more easily challenged.
    - pfdietz 6y ago
      The blog post presents legal arguments why (with existing SCOTUS rulings) they should be considered separate. I could repeat all that, or just ask you to read it.

iamcreasy 6y ago

I suppose Supreme court decision over this matter sets precedence for any future cases.

iamcreasy 6y ago
Why the downvote? You can read more about it here: https://en.wikipedia.org/wiki/Precedent https://en.wikipedia.org/wiki/Precedent

williesleg 6y ago

The bigger story is Justice Thomas is saying Big Tech needs to be regulated like utilities.

fnordprefect 6y ago

One of the big open questions is "are APIs copyrightable?" The Australian equivalent to the US Supreme Court considered this over 20 years ago, and imho got the correct result (not copyrightable): http://www.austlii.edu.au/cgi-bin/viewdoc/au/cases/cth/HCA/1999/49.html http://www.austlii.edu.au/cgi-bin/viewdoc/au/cases/cth/HCA/1... IMHO they got the Huffman table wrong, although arguably it was the result compelled by an overprotective approach.

ifore 6y ago
It seems that it was somewhat inevitable given the US vs Australian distinction on whether to protect Creativity vs Effort (years ago I investigated this rabbit hole when I had a client who wanted to set up a White Pages clone site by buying the data from someone who had digitised it [with a lot of manual entry!] by low-paid Indians. They were very disappointed when I told them to contact an IP lawyer because it was almost certainly going to get them sued) I did cry a little at the court's assertion creating the huffman table required "a very great deal of hard work". Gather a corpus of databases you have lying around, count the occurrences of each byte value and apply a <50 line algorithm that has been around since the 1950s and is a pretty standard university assignment. "a very great deal of hard work" indeed. Presumably division 4A / s47D would now allow the cloning of the data table if decided today -- are you aware of any post-1999 case law?

btilly 6y ago

While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. It is even less decisive than you're saying. The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are. And for fair use, one of the statutory factors is the "effect" of the copying on the "market for or value of the copyrighted work." That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory: The fact that one statutory factor points one way doesn't stop another from pointing the other. And part of their decision is the conclusion that Google's copying increased the value of Java. That will generally not be true when APIs get copied. In particular if I am trying to create a product that competes with yours, and I copy your API for the purpose of interoperability, I'm going to have an uphill battle claiming fair use. Because my product directly reduces the market for your product. To name some historically important examples, Microsoft copied the APIs for JavaScript from Netscape, Microsoft copied APIs from Lotus 1-2-3 for Excel, and Wine copied APIs from Windows for Linux. The outcomes famously were that Netscape went out of business, Lotus 1-2-3 was discontinued, and Linux became somewhat more viable.

curt15 6y ago
>The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are. Federal Circuit's ruling would only be precedent in the 9th circuit. As it does not have original jurisdiction in copyright disputes (only patent cases), it doesn't supercede any copyrightability rulings in other circuits, for instance the 1st circuit's holding in Lotus v Borland that the Lotus macros were not copyrightable as a "method of operation". And today's opinion cites Lotus v Borland several times even though the original 1996 Supreme Court case was deadlocked at 4-4.
- wtallis 6y ago
  > Federal Circuit's ruling would only be precedent in the 9th circuit. I think it's even narrower than that: the Federal Circuit's ruling on non-patent aspects of the case isn't binding precedent outside of Oracle v. Google. District courts in the Ninth Circuit and the appeals court are free to ignore the Federal Circuit ruling in future cases and look to only rulings from the Ninth Circuit and Supreme Court as binding precedent.

hyperpallium2 6y ago

Always seemed crazy to me that interoperability was ever in doubt. Copyright in a private, internal API seems reasonable in principle. RIP kotlin-first on android?

pjmlp 6y ago
Kotlin never fixed anything on this area, beacause it is a guest language for the JVM, and the whole Android tooling depends on Java and JVM, ART only runs on the devices. So to be fully Java/JVM free with Kotlin-first, Google and JetBrains would need to re-write the Android world to run on ART or Kotlin/Native, including anything that might come from Maven central.

anonymouse008 6y ago

> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment. I'm waiting for an ambitious attorney to figure out how to frame this as poaching talent from an ecosystem to bring to another.

bobbyi_settv 6y ago

> One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use: Doesn't deciding that it's fair use specifically mean that they think it is copyrightable? The fair use doctrine specifically refers to the use of copyrighted material.

AnimalMuppet 6y ago
No. "Assume it's copyrightable. It's still fair use." That means you don't have to answer "Is it copyrightable?" The Supreme Court generally prefers to not answer questions that they don't have to answer.
- shemnon42 6y ago
  So in programmer speak if (!isFairUse(workUnderInvestigation) && copyrightable(originalWork)) { bigCopyrightPayout(); } Short circuit on the and operator. It's fair use, so copyrightable will not be evaluated. Evaluating copyrightable has an obervable side effect of creating a precedent.
  - AnimalMuppet 6y ago
    Yes, exactly that. Why do the && in that order? Because isFairUse(workUnderInvestigation) was a much less expensive operation than copyrightable(originalWork) for this particular value of originalWork.
    - shemnon42 6y ago
      That is the order scotus considered it.
      - AnimalMuppet 6y ago
        Right, and that's why SCOTUS considered it in that order. Deciding API copyright was a much bigger decision than deciding fair use.

grumple 6y ago

I think the focus on fair use is even better. It means that EVEN IF you can copyright the API, it doesn't matter because others can reimplement it. So not only can corps not stop that, but courts might rule later that the copyrights are totally invalid.

ece 6y ago
Exactly this, the same protection that memers have in editing content (but not copying the full implementation), software engineers now have too thanks to fair use.

TeeMassive 6y ago

> One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use Also what people fails to realize with fair use is that it is up to the defendant raise a fair use defense and then a judge has to approve of that defense as a valid one (Viva Frei explains this https://youtu.be/AzQz1LrjCWk?t=253 https://youtu.be/AzQz1LrjCWk?t=253 ).Meaning Oracle can still go on with its lawfare campaign against those who made the mistake of basing their tech on theirs.

wtallis 6y ago
Oracle would have to come up with new patent claims in order to get another case before the Federal Circuit, which is their best (only?) hope for having their API copyright claims upheld.
pwdisswordfish6 6y ago
Fortunately, although it is pay-to-play, it's not pay-to-win. Oracle (or any other well-heeled player) can spend half a million or more in legal fees trying to go after a small company, but that doesn't mean that company has to match costs.

redis_mlc 6y ago

> Google copied these lines not because of their creativity or beauty The court mentioned "creativity or beauty" because US copyright was originally about artistic originality before the widened application for software. So what the court is saying is that the copied lines are not substantial and also not creative enough to infringe on the original work. I don't see that mentioned elsewhere in this thread.

Abishek_Muthian 6y ago

Not from U.S. Would the discussions, consultations between the judges and the independent subject matter experts be published? Surely there must have been such extensive discussions right? Or is the judgement based upon the subject matter experts presented as witness from both sides themselves? I'm intrigued by how judgements are passed in such intricate technical matters.

dragonwriter 6y ago
> Would the discussions, consultations between the judges and the independent subject matter experts be published? No such consultation exists. > Or is the judgement based upon the subject matter experts presented as witness from both sides themselves? Since this was a decision as a matter of law, and not one turning on disputed facts (the Supreme Court can decide cases on either basis), the judges are the relevant subject matter experts.
- Abishek_Muthian 6y ago
  Thank you for the succinct answer.

smokey_circles 6y ago

>The court skirted that question, and instead focused on whether it was fair use Because the federal courts already ruled that APIs are eligible for copyright [0]. Google wanted to overturn the ruling that they were in violation of copyright and argued they used Java's APIs fairly under copyright law. The court will not answer questions not put to it, and Google (I presume) felt they had a better shot at getting the court to agree it was fair usage, rather than arguing copyright should not apply here. 0: https://www.paleudislaw.com/federal-circuit-rules-that-apis-are-eligible-for-copyright-prote.html https://www.paleudislaw.com/federal-circuit-rules-that-apis-...

dragonwriter 6y ago
> The court will not answer questions not put to it, and Google (I presume) felt they had a better shot at getting the court to agree it was fair usage, rather than arguing copyright should not apply here. This is false; Google appealed on both copyrightability and fair use, and the Supreme Court agreed to hear both issues.

_the_inflator 6y ago

Exactly. Coming from law, sometimes like in this case, some topics can be left undecided, if it does not change the result. Even if the code could have been copyrighted, it would still be considered fair use. Translated into developers speech: this is some sort of early return. ;)