1. 114
  1.  

  2. 25

    Well, that’s a relief. I’d be upset if copyrighting code meant you couldn’t use its API without a license.

    1. 9

      Thanks for nothing I guess:

      Given the rapidly changing technological, economic, and business-related cir- cumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute. We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copy- righted. We shall ask instead whether Google’s use of part of that API was a “fair use.” Unlike the Federal Circuit, we conclude that it was.

      The majority opinion of the supreme court simply assumed that APIs are subject to copyright, because it makes their work easier.

      Bad, but not unexpected – lawyers have a tendency to muddy up clear black-or-white laws, to ensure that it keeps producing a steady stream of new lawsuits for them.

      Google copied roughly 11,500 lines of code from the Java SE pro- gram. The copied lines are part of a tool called an Application Pro- gramming Interface (API).

      Jeeez. Maybe we should have more lawyers like Alsup, and fewer lawyers that can’t even get the basics right?

      This decision is pretty much a law for the rich, the poor get screwed.

      1. 9

        Copyright with fair use is a reasonable conclusion–and if you read the dissent, it suggests an assumed difference between implementing and declaring (e.g., API) code. So, I wouldn’t be too grumpy about this.

        1. 5

          if you read the dissent

          I read it and it disagrees with what you claim:

          Is declaring code protected by copyright? I would hold that it is.

          and

          Congress rejected categorical distinctions between declar- ing and implementing code.

          and

          The majority holds otherwise—concluding that every fac- tor favors Google—by relying, in large part, on a distinction it draws between declaring and implementing code, a dis- tinction that the statute rejects.

          The point is that fair use is something decided in front of courts, which is enough to make people afraid of exercising their rights.

          “APIs are not copyrightable” would be a decision, where one could safely tell Oracle/… to simply fuck off.

          1. 4

            “APIs are not copyrightable” would be a decision, where one could safely tell Oracle/… to simply fuck off.

            That’s a taller order than the reading of fair-use.

            Pretend you’re on the other side of this. How would you argue that APIs are and implementations are both copyrightable?

            1. 3

              That what was pretty much the general assumption since decades until the IP courts decided to mess with it right in this case.

              There was never a credible actor that ever questioned this before that.

        2. 5

          I’m pretty sure that making the narrowest consistent finding is in the job description somewhere. Fair Use exists exactly to solve this kind of problem without requiring copyright to be shot down, and fixable creative works are presumed copyrighted with limited exceptions, so if Fair Use applies, the court is entitled to dodge the question of copyright, which would make for a much larger precedent. If you want to force the issue, you have to sue over a matter that Fair Use can’t fix.

          1. 4

            Assume the law of excluded middle, as judges are wont to do, and then finish the case analysis by taking the other branch: Assume that APIs are not subject to copyright. Then the case is nigh moot.

            What they mean by this language is to emphasize that they are not deciding, in this current opinion, whether APIs are copyrightable.

            1. 2

              That’s what I wrote.

              1. 6

                Courts have no reason to talk about matters which aren’t germane to the petitions directly before them, and every reason to avoid excessive meddling.

                No “muddy[ing] up clear black-or-white laws” has happened here. The court recognizes that the law as written says that the API code would be copyrightable, since it is part of a “computer program”. The case before the court could be taken to challenge that law, but the court chose not to disturb the statute.

                I don’t see how this opinion opens up new legal fronts. Rather, it should help settle questions about whether common sorts of API-oriented copyright infringement are legally actionable, and could simplify or even avoid legal confrontations.

                1. 2

                  The court recognizes that the law as written says that the API code would be copyrightable

                  I don’t believe that they did, they said if “we assume, for argument’s sake, that [APIs are] copyrightable, […] the copying here at issue nonetheless constituted a fair use” (page 1 of the opinion, page 5 of the pdf) and on page 15 “we believe we should not answer more than is necessary to resolve the parties’ dispute. We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted. We shall ask instead whether Google’s use of part of that API was a “fair use.” “.

                  In other words they intentionally avoided the question entirely.

                  1. 1

                    Yes. But they are not ignorant to the content of the statute (p12):

                    In 1980, Congress expanded the reach of the Copyright Act to include computer programs. And it defined “computer program” as “‘a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.’” §10, 94 Stat.3028 (codified at 17 U. S. C. §101).

                    And this is in the context of the petition for cert (p14) right before your quote:

                    Google’s petition for certiorari poses two questions. The first asks whether Java’s API is copyrightable. It asks us to examine two of the statutory provisions just mentioned, one that permits copyrighting computer programs and the other that forbids copyrighting, e.g., “process[es],” “system[s],” and “method[s] of operation.” Pet. for Cert. 12. Google believes that the API’s declaring code and organization fall into these latter categories and are expressly excluded from copyright protection.

                    They here explicitly raise the idea that the statute is applicable but overridden by an exemption in another statute. A cert petition is like a request for the court to confirm that the law operates as described in the code, and as we all seem to agree, the court is declining to take it up directly.

                    1. 1

                      They here explicitly raise the idea that the statute is applicable but overridden by an exemption in another statute. A cert petition is like a request for the court to confirm that the law operates as described in the code, and as we all seem to agree, the court is declining to take it up directly.

                      Yes, I think we all agree on this much.

                      You are (or were, but I will assume still are) also arguing to what I quoted previously though, that

                      The court recognizes that the law as written says that the API code would be copyrightable

                      I don’t think they are doing this.

                      They are obviously not ignorant of the statute, but your page 12 quote does not support them saying that APIs are “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result”. It is just them quoting the law before they go on to apply it. Consider that in the same way they quote this part of the law, in the paragraph split between pages 12 and 13 they also quote the following section of the law - if you try and read between the lines from them quoting a law to saying it applies you would have to conclude that copyright both applies and does not.

                      Third, the statute sets forth limitations on the works that can be copyrighted, including works that the definitional provisions might otherwise include. It says, for example, that copyright protection cannot be extended to “any idea, procedure, process, system, method of operation, concept, copyright protection cannot be extended to “any idea, procedure, process, system, method of operation, concept, […]

                      Likewise page 14 is just them stating what Google asked for, and then immediately afterwards they are going and saying “and we’re only ruling on the second half of what they asked for”. The Supreme Court declining to rule on something (much like them declining cert) is not them staking out the opposite position, it’s them deferring judgement on the question until a later case.

        3. 21

          Reading the conclusions is a good time. The dissent brushes up against some interesting points:

          And if companies may now freely copy libraries of declaring code whenever it is more convenient than writing their own, others will likely hesitate to spend the resources Oracle did to create intuitive, well-organized libraries that attract programmers and could compete with Android.

          This somewhat mirrors the ongoing issue we’ve got around large companies like Amazon munching up open-source libraries for hosting and not giving much in the way of profits back to the developers. This is a defining question of our generation of programming.

          Computer code occupies a unique space in intellectual property. Copyright law generally protects works of authorship. Patent law generally protects inventions or discoveries. A library of code straddles these two categories. It is highly functional like an invention; yet as a writing, it is also a work of authorship.

          This struck me as an interesting point, and a nice nudge in the exploration of why software is weird.

          First, Google eliminated the reason manufacturers were willing to pay to install the Java platform. Google’s business model differed from Oracle’s. While Oracle earned revenue by charging device manufacturers to install the Java platform, Google obtained revenue primarily through ad sales. Its strategy was to release Android to device manufacturers for free and then use Android as a vehicle to collect data on consumers and deliver behavioral ads. With a free product available that included much of Oracle’s code(and thus with similar programming potential), device manufacturers no longer saw much reason to pay to embed the Java platform.

          I credit Justice Thomas here with saying the quiet part out loud: Google aren’t the good guys here (neither are). I like this bit because it clearly shows what can happen when somebody with a totally different (arguably more anti-consumer) business model appears and just spends cash removing your entire product line as an afterthought. Like, super happy to see this talked about.

          A work is “transformative” if it “adds something new, with a further purpose or different character, altering the first with new expression, meaning, or message.” […] Now, we are told, “transformative” simply means—at least for computer code—a use that will help others “create new products.”

          This is a super important point, and I’ll bet my hat it’ll come up again and again in the next decade of software litigation. Like, by definition, the whole point of APIs is that they can’t be transformative works–they can’t add anything new or change things, because then you break the API. This is probably why the majority opinion taking the fair-use position is important–it lets them work around what is clearly not a transformative work. If people can leverage the point about the majority redefining “transformative” in this case, though, that opens up some interesting precedent for later.

          But the proper denominator is declaring code, not all code.

          Justice Thomas here points out that the majority’s observation of “lol well method signatures were only a small percent of the total codebase” is bunk, because the part of the code for declarations–and not implementation–is what matters. Again, just a nice observation.

          The majority purports to save for another day the question whether declaring code is copyrightable. The only apparent reason for doing so is because the majority cannot square its fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable.

          This is the money shot for the dissent, and it’s a fair criticism. The USC punted on software copyright–as might be expected–and instead seemed to say “okay, declarative code being reused is fair use”. This is especially interesting if you favor programming languages where the type system does most of the heavy lifting or if you use a language that leans heavily into declaration (say, SQL). Again, a fun present for future courts.

          The dissent also has some real gems:

          In the 1990s, Oracle created a programming language called Java.

          First, this is plainly factually incorrect–that was Sun Microsystems.

          More interestingly though, this is kind of a rentier problem: if there is a moral right to the business opportunities presented by a software (which, due to his belief that software straddles both copyright and patent, and thus can be thought of as an authored work in addition to being an invention) it seems strange that that moral right is ignored once the company employing the authors is acquired. Like, it suggests a fast-and-loose conflation of the authors of the code, their employers, and whichever vultures end up purchasing their employers. I’m not saying this is new, mind you–just that this is maybe an interesting way of looking at the problems we have.

          First, Oracle never had lock-in power.

          Big if true, and also would probably alarm their shareholders.

          Second, Oracle always made its declaring code freely available to programmers. There is little reason to suspect Oracle might harm programmers by stopping now.

          Ha. Ha ha. Bwahahahahahaha

          ~

          Read the writeup; I just cherry-picked some neat bits from the dissent. It’ll be worth your time.

          1. 11

            First, this is plainly factually incorrect–that was Sun Microsystems.

            First page, second sentence, footnote:

            A different company, Sun, created the library. But because Oracle later purchased Sun, for simplicity I refer to both companies as Oracle.

            1. 4

              Good catch, but it’s a bit tacky to say “Oracle spent all this money developing the libraries, we should feel sorry for them” when the less simple history directly undercuts that points: “okay well technically Sun did and then ran themselves into the ground and Oracle decided they could make massive rent off of the Sun IP and…look just feel bad for Oracle okay”.

              1. 8

                Just note this is an important principle of economics. If you build a valuable business, you have the right to sell that business, thereby converting its theoretical value into immediate cash.

                This is also the principle behind shareholding. The investors who funded the development of Java are (probably) not the same investors who sold to Oracle. Those who funded a valuable thing were able to sell their more valuable ownership stake to somebody else and realize a profit.

                It’s an important principle, because often somebody has something valuable which they are not really in a position to fully materialize. Small companies get taken over by larger ones because the small company might have a good product but needs more capital to scale, so the transaction allows both groups to benefit. And Sun, a company selling UNIX servers to (approximately) nobody, was not in a position to obtain value from many of the things that it had.

                Somehow in the context of patents people forget the principle. It’s easy to dismiss an actor as a patent troll, but the sale of patents and copyrights is what allows an individual to do something and get paid for it despite not being in a position to build a global business themselves. It may be true that the buyer didn’t invent the thing or do the initial development, but if they’re unable to act as if they had, they have no reason to buy it, and the smaller entity that did the initial development has no reason to do the work since they can’t build the business, etc.

            2. 6

              Thanks for the quotes, this was a good read.

              Like, by definition, the whole point of APIs is that they can’t be transformative works–they can’t add anything new or change things, because then you break the API.

              I’m not sure I agree here. Yes, the API itself isn’t transformed, but if the entire work is taken as the scope (the 2+ million lines of code) then reimplementing the API can absolutely transform the work. If you wrote a book where each chapter had a clever title, and then I wrote a book with the same chapter titles but different content (but such that the content still reflected the chapter titles), that still seems transformative to me.

              1. 1

                That’s an interesting case–I’m neither a lawyer nor a court judge–to consider.

                I think that there is some ability to copyright or patent organizations of information, e.g. technical taxonomies like ICD-10 or the Dewey Decimal System…that being the case, if there was an index in the book that you also copied or if the titles were a key component of looking stuff up in the book, maybe it wouldn’t be as transformative. This is also kind of the root of the API problem.

                Edit: or perhaps, if they’re a system, you can’t copyright them. Ugh.

              2. 2

                spends cash removing your entire product line as an afterthought

                Was there a real product line? Who exactly was ever going to purchase Java SE as a product for mobile devices? Considering that OpenJDK is FOSS.

              3. 11

                GPL’ed header files are now holed below the waterline.

                1. 8

                  So is windows.h. That’s probably a good thing, over all.

                  1. 1

                    windows.h has been independently re-derived a number of times, making it a nonissue regardless.

                    1. 3

                      How are those cases different from what Google did with Java?

                      1. 5

                        Copyright protects your work from being copied by others. If I look at the windows.h that microsoft distributes and use that as a basis for my own windows.h, it’s possible that what I produce constitutes a derivative work that thus infringes on microsoft’s copy rights. (This is what google v oracle was about.)

                        However, if I derive the windows api in the context of a clean room, the result is not a derivative work and thus not infringing. This, for instance, is what the wine and reactos projects have done, and wine expressly prohibits people who might have had contact with windows source code from contributing for this reason.

                        1. 1

                          What if you clean room derive a 100% identical header?

                          (Not impossible if the original, say, didn’t have comments and was formatted with a tool like clang-format which you’ve also decided to use…)

                          1. 2

                            clean room derive a 100% identical header?

                            Then that’s fine, as long as you didn’t copy it from the original.

                            1. 1

                              Or better put, where do you draw a line between clean room based development output vs an actual system you are converting?

                          2. 2

                            The work that Oracle claims is copyrighted in this case is the “Structure Sequence and Organization” of the APIs, which is a term they created that somehow includes things like names.

                            I presume Moonchild’s point is that people have reversed the windows ABI into an API many times, and the ABI doesn’t include the requisite elements to be copyrightable even if Oracle is right that their API is copyrightable. I’m not sure I agree with that argument, but it is an interesting one.

                      2. 2

                        Even if they’re C++ libraries where everything is in the header file?

                        (You just know some court’s going to be unable or unwilling to distinguish between declarations and code.)

                        1. 2

                          Shit, hadn’t thought of that. Good catch.

                          1. 1

                            I don’t know, this is a massive fair use question! You would have to show that there’s broad knowledge of the header file contents in particular.

                            Java being Java is where the fair use conclusion came in. Millions of people knowing The Java API definitions! I think it’s non controversial to state that Java APIs are more universally known than almost anything under the sun

                            And this case in the outset is like “look this is complicated and fast moving, we’re going to state stuff here but don’t consider it broad in scope”. Pretty tough fight to win IMO

                          2. 7

                            I usually try to do by best to design APIs which have a good user experience. Sometimes this is easy; often it is not. The usual process is something like this: 1) write some library, 2) use it, 3) improve the library based on the experience of using it, 4) use it in another program in some other way, 5) tweak things a bit more, 6) have some idea, 7) rewrite things, GOTO 2.

                            This is a process that can take months or even years. Quite often the technical implementation isn’t that hard – or even trivial – but finding a good API to use it which balances control with “elegance” (whatever that may be, exactly) is something I often find hard part.

                            That there are so many mediocre and outright bad APIs out there proves the point I’m not the only one who finds this hard; I suppose the difference is that I enjoy working on this kind of stuff more than some others, so I spend a bit more time on it.

                            Anyhow; it seems to me that APIs are substantial creative works which are non-trivial to produce, just like the actual implementation. If we accept that code can be copyrighted, then I don’t see how it’s that far-fetched or ridiculous to copyright APIs too. I have a lot of reservations about the entire copyright system as implemented today, but that’s a different discussion then whether or not APIs are copyrightable under current law.

                            1. 6

                              Note that the court explicitly avoided ruling on whether or not APIs were copyrightable in this case, they said even if they were copyrightable, this wasn’t infringement.

                              I’ll argue that they shouldn’t be anyways.

                              Copyright is supposed to grant you a monopoly on only your work, not the copying of any other work.

                              There are variety of ways this shows up into law in order to make it a question that courts can rule on consistently. Copyright missuse (attempting to use your copyright to gain a monopoly on something else invalidates your copyright), merger doctrine (if there’s only one way to do something, it’s not copyrightable), the prohibition on copyrighting functional elements, and the general distinction between copyright and patents. Attempting to copyright an API, is attempting to create a monopoly on running the works that use that API. That’s fundamentally not allowed. You can reach that conclusion in multiple ways (I prefer the merger doctrine), but the principle is just that simple.

                              Fundamentally copyright is a poor fit for software IMO, because it only protects non-functional creative elements. It turns out to work, because all of our code includes both, but it’s a poor hack. As long as we’re relying on that poor hack, it’s pretty clear to me that APIs do not fall into the subset of things protected (regardless of whether or not you think they should be protected morally).

                              1. 2

                                The decision assumed APIs were copyrightable here. They didn’t make a final determination on the question, because they found that even if API definitions are copyrightable then this would have been fair use because of the scope of usage of Java and the relatively few “innovations” at play here.

                                But to be honest the copyright thing could totally remain at play and I could see somebody like Stripe prevailing at suing a competitor with an API-compatible clone.

                                1. 2

                                  It seems like an HTTP (or any network) API would be much more difficult to claim copyright over because there are so many ways to “say” the same thing, and you can’t claim copyright over an abstract design AFAIK (though IANAL). If you implemented your HTTP API using Rails, and I implemented my clone with Django, there’s no identical code. In the Oracle case, Google copied the exact header files, not just the abstract idea. In any event, it feels like a tough sell.

                              2. 2

                                For those who might have forgotten the twists and turns of this interminable saga, this post from Techdirt has a potted history of the case, as well as some commentary on the decision:

                                https://www.techdirt.com/articles/20210405/09243546552/supreme-court-sides-with-google-decade-long-fight-over-api-copyright-googles-copying-java-api-is-fair-use.shtml