Supreme Court Sides With Google In Decade-Long Fight Over API Copyright; Google's Copying Of Java API Is Fair Use
from the good-news dept
It's taken over a decade, but the Supreme Court has finally said that Google's copying of the Sun Java API for Android was clearly fair use in a 6-2 ruling (Barrett did not take part since she was not on the Court when the case was heard). The background of this case is actually kind of important to understanding what just happened, so here's a quick(ish) recap.
As you'll probably know, this case began in 2010 when Oracle, which had just taken over Sun, sued Google for patent infringement. The patent parts were quickly tossed out and what remained was what referred to as a "sideshow" to the main event: a question about whether APIs could be covered by copyright. Pretty much all historical evidence, including an important Supreme Court ruling from the 1990s, said no, interfaces are not covered by copyright.
Oracle and friends then spent the next decade deliberately gaslighting basically everyone who doesn't understand what an API is, and insisting that it's the same as executable code. The district court, under Judge William Alsup, who somewhat famously taught himself Java to better understand the issues in the case (he already knew how to code and was a hobbyist programmer), correctly found that APIs are not subject to copyright as they represent a "system or method of operation" which is explicitly not covered by copyright, as per Section 102(b) of the Copyright Act.
Rather than go to the 9th Circuit (as it should have) the case went to the Federal Circuit, which hears all patent appeals. That was because the case began as a patent case, even though it no longer was. CAFC judges are somewhat infamous for never finding a patent issue they couldn't screw up, and decided to extend that to copyright. In the ruling overturning the lower court, they made it clear that because they were code illiterate they could not understand the difference between executing code and an API, even though it's like the difference between a novel and a dictionary.
The case went back to the district court, where the jury this time sided with Google, this time saying that the use of the code was covered under fair use. That whole trial was a little weird, because reading between the lines, you could see that nearly all the arguments for why copying an API was fair use were really about why an API shouldn't be covered by copyright at all (as per Alsup's original ruling) and then squeezing that square peg into the round hole of fair use to make it work. Once again, however, CAFC got flummoxed by an API looking like code and overturned -- which is quite crazy because CAFC had, in its first ruling, insisted that the jury should decide this issue (as a matter of fact) and then when the jury said "fair use" CAFC suddenly decided that it was a matter of law that it could overrule.
Finally, we get to the Supreme Court. From oral arguments, it wasn't clear where the court was leaning -- with some good questions and some crazy questions. But with today's ruling, it's clear that the smarter questioners won out. The majority opinion was written by Justice Breyer, who has always been the best Justice on copyright issues, and had the support of Justices Roberts, Kagan, Gorsuch, Kavanaugh, and Sotomayor.
Breyer starts out by noting (thankfully, unlike the CAFC judges) that it's important to understand just what an API actually is.
Consider in more detail just what an API does. A computer can perform thousands, perhaps millions, of different tasks that a programmer may wish to use. These tasks range from the most basic to the enormously complex. Ask the computer, for example, to tell you which of two numbers is the higher number or to sort one thousand numbers in ascending order, and it will instantly give you the right answer. An API divides and organizes the world of computing tasks in a particular way. Programmers can then use the API to select the particular task that they need for their programs. In Sun’s API (which we refer to as the Sun Java API), each individual task is known as a “method.” The API groups somewhat similar methods into larger “classes,” and groups somewhat similar classes into larger “packages.” This method-class-package organizational structure is referred to as the Sun Java API’s “structure, sequence, and organization,” or SSO.
For each task, there is computer code, known as “implementing code,” that in effect tells the computer how to execute the particular task you have asked it to perform (such as telling you, of two numbers, which is the higher). See Oracle, 872 F. Supp. 2d, at 979–980. The implementing code (which Google independently wrote) is not at issue here. For a single task, the implementing code may be hundreds of lines long. It would be difficult, perhaps impossible, for a programmer to create complex software programs without drawing on prewritten task-implementing programs to execute discrete tasks.
But how do you as the programmer tell the computer which of the implementing code programs it should choose, i.e., which task it should carry out? You do so by entering into your own program a command that corresponds to the specific task and calls it up. Those commands, known as “method calls,” help you carry out the task by choosing those programs written in implementing code that will do the trick, i.e., that will instruct the computer so that your program will find the higher of two numbers. If a particular computer might perform, say, a million different tasks, different method calls will tell the computer which of those tasks to choose. Those familiar with the Java language already know countless method calls that allow them to invoke countless tasks.
And how does the method call (which a programmer types) actually locate and invoke the particular implementing code that it needs to instruct the computer how to carry out a particular task? It does so through another type of code, which the parties have labeled “declaring code.” Declaring code is part of the API. For each task, the specific command entered by the programmer matches up with specific declaring code inside the API. That declaring code provides both the name for each task and the location of each task within the API’s overall organizational system (i.e., the placement of a method within a particular class and the placement of a class within a particular package). In this sense, the declaring code and the method call form a link, allowing the programmer to draw upon the thousands of prewritten tasks, written in implementing code. See id., at 979–980. Without that declaring code, the method calls entered by the programmer would not call up the implementing code.
The declaring code therefore performs at least two important functions in the Sun Java API. The first, more obvious, function is that the declaring code enables a set of shortcuts for programmers. By connecting complex implementing code with method calls, it allows a programmer to pick out from the API’s task library a particular task without having to learn anything more than a simple command. For example, a programmer building a new application for personal banking may wish to use various tasks to, say, calculate a user’s balance or authenticate a password. To do so, she need only learn the method calls associated with those tasks. In this way, the declaring code’s shortcut function is similar to a gas pedal in a car that tells the car to move faster or the QWERTY keyboard on a typewriter that calls up a certain letter when you press a particular key. As those analogies demonstrate, one can think of the declaring code as part of an interface between human beings and a machine.
The second, less obvious, function is to reflect the way in which Java’s creators have divided the potential world of different tasks into an actual world, i.e., precisely which set of potentially millions of different tasks we want to have our Java-based computer systems perform and how we want those tasks arranged and grouped. In this sense, the declaring code performs an organizational function. It determines the structure of the task library that Java’s creators have decided to build. To understand this organizational system, think of the Dewey Decimal System that categorizes books into an accessible system or a travel guide that arranges a city’s attractions into different categories. Language itself provides a rough analogy to the declaring code’s organizational feature, for language itself divides into sets of concepts a world that in certain respects other languages might have divided differently. The developers of Java, for example, decided to place a method called “draw image” inside of a class called “graphics.”
Not a bad description for an 82-year-old Supreme Court Justice (kudos to his clerks and the various parties and amici that briefed this). One of the big debates in the lead up to the case, and at oral arguments, was what "analogy" best represented what an API was. You can see above Breyer mention the Dewey Decimal System, which is a pretty good analogy. Then he includes another:
Consider a comprehensive, albeit farfetched, analogy that illustrates how the API is actually used by a programmer. Imagine that you can, via certain keystrokes, instruct a robot to move to a particular file cabinet, to open a certain drawer, and to pick out a specific recipe. With the proper recipe in hand, the robot then moves to your kitchen and gives it to a cook to prepare the dish. This example mirrors the API’s task-related organizational system. Through your simple command, the robot locates the right recipe and hands it off to the cook. In the same way, typing in a method call prompts the API to locate the correct implementing code and hand it off to your computer. And importantly, to select the dish that you want for your meal, you do not need to know the recipe’s contents, just as a programmer using an API does not need to learn the implementing code. In both situations, learning the simple command is enough.
Of course, reading this you might hope that Breyer is about to go all the way to the point that he should and say that APIs, as systems and methods, are clearly not covered by copyright under 102(b). But, unfortunately, he does not. The majority opinion goes for the 2nd best option, just saying that this is fair use. But there are still some fascinating tidbits on the way there. Incredibly, Breyer quotes Thomas Macaulay's amazing speech on copyright in 1841 that we've quoted on Techdirt many times before. I wasn't expecting to see it here, however. But here is Breyer explaining how copyright is a "tax":
Macaulay once said that the principle of copyright is a “tax on readers for the purpose of giving a bounty to writers.” T. Macaulay, Speeches on Copyright 25 (E. Miller ed. 1913). Congress, weighing advantages and disadvantages, will determine the more specific nature of the tax, its boundaries and conditions, the existence of exceptions and exemptions, all by exercising its own constitutional power to write a copyright statute.
And then he notes that Congress has put limits on copyright, including the limits on what is subject to copyright (Section 102), and then other limitations found throughout the Copyright Act, including fair use (Section 107). Breyer then notes that even though Google asked the Court to say APIs are not covered by copyright, since they can answer the fair use question and dispose of the issue, the court will just assume that APIs are subject to copyright for the sake of exploring fair use, and leave the actual question of copyright and APIs to another day (groan).
A holding for Google on either question presented would dispense with Oracle’s copyright claims. Given the rapidly changing technological, economic, and business-related circumstances, 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.” Unlike the Federal Circuit, we conclude that it was.
Still, the fair use analysis itself is quite interesting. It notes that software copyright has been a tricky question in general, given that it has both creative literary elements and functional elements (which are not supposed to be covered by copyright).
Generically speaking, computer programs differ from books, films, and many other “literary works” in that such programs almost always serve functional purposes. These and other differences have led at least some judges to complain that “applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.” Lotus Development Corp. v. Borland Int’l, Inc., 49 F. 3d 807, 820 (CA1 1995) (Boudin, J., concurring).
These differences also led Congress to think long and hard about whether to grant computer programs copyright protection. In 1974, Congress established a National Commission on New Technological Uses of Copyrighted Works (CONTU) to look into the matter. §§201–208, 88 Stat. 1873–1875. After several years of research, CONTU concluded that the “availability of copyright protection for computer programs is desirable.” Final Report 11 (July 31, 1978). At the same time, it recognized that computer programs had unique features. Mindful of not “unduly burdening users of programs and the general public,” it wrote that copyright “should not grant anyone more economic power than is necessary to achieve the incentive to create.” Id., at 12. And it believed that copyright’s existing doctrines (e.g., fair use), applied by courts on a case-by-case basis, could prevent holders from using copyright to stifle innovation. Ibid. (“Relatively few changes in the Copyright Act of 1976 are required to attain these objectives”). Congress then wrote computer program protection into the law. See §10, 94 Stat. 3028.
The upshot, in our view, is that fair use can play an important role in determining the lawful scope of a computer program copyright, such as the copyright at issue here. It can help to distinguish among technologies. It can distinguish between expressive and functional features of computer code where those features are mixed. It can focus on the legitimate need to provide incentives to produce copyrighted material while examining the extent to which yet further protection creates unrelated or illegitimate harms in other markets or to the development of other products. In a word, it can carry out its basic purpose of providing a context-based check that can help to keep a copyright monopoly within its lawful bounds. See H. R. Rep. No. 94– 1476, pp. 65–66 (1976) (explaining that courts are to “adapt the doctrine [of fair use] to particular situations on a caseby-case basis” and in light of “rapid technological change”); see, e.g., Lexmark Int’l, Inc. v. Static Control Components, Inc., 387 F. 3d 522, 543–545 (CA6 2004) (discussing fair use in the context of copying to preserve compatibility); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F. 3d 596, 603–608 (CA9 2000) (applying fair use to intermediate copying necessary to reverse engineer access to unprotected functional elements within a program); Sega Enterprises Ltd. v. Accolade, Inc., 977 F. 2d 1510, 1521–1527 (CA9 1992) (holding that wholesale copying of copyrighted code as a preliminary step to develop a competing product was a fair use).
Breyer notes his confusion over Justice Thomas' dissent (we'll get there) and says that Congress clearly meant for fair use to apply to software:
We do not understand Congress, however, to have shielded computer programs from the ordinary application of copyright’s limiting doctrines in this way. By defining computer programs in §101, Congress chose to place this subject matter within the copyright regime. Like other protected works, that means that the owners of computer programs enjoy the exclusive rights set forth in the Act, including the right to “reproduce [a] copyrighted work” or to “prepare derivative works.” 17 U. S. C. §106. But that also means that exclusive rights in computer programs are limited like any other works. Just as fair use distinguishes among books and films, which are indisputably subjects of copyright, so too must it draw lines among computer programs. And just as fair use takes account of the market in which scripts and paintings are bought and sold, so too must it consider the realities of how technological works are created and disseminated. We do not believe that an approach close to “all or nothing” would be faithful to the Copyright Act’s overall design.
Breyer notes that CAFC got things correct in saying that fair use is both a matter of fact (for juries) and of law (for judges) -- though leaves out that in the first go-round, the CAFC suggested otherwise. So he rejects Google's suggestion that the jury ruling on fair use should stand without judicial review. However, he still says that the jury was correct in the finding of fair use after going through the standard four factor test. The fact that the work in question was an API weighs heavily in the fair use determination, as part of the "nature of the work" test (the second of the four factors). The majority opinion notes that the key parts of the API, the declaring code, are not that "close to the core" of the purpose of copyright:
The declaring code (inseparable from the programmer’s method calls) embodies a different kind of creativity. Sun Java’s creators, for example, tried to find declaring code names that would prove intuitively easy to remember. Id., at 211. They wanted to attract programmers who would learn the system, help to develop it further, and prove reluctant to use another. See post, at 10 (“Declaring code . . . is user facing. It must be designed and organized in a way that is intuitive and understandable to developers so that they can invoke it”). Sun’s business strategy originally emphasized the importance of using the API to attract programmers. It sought to make the API “open” and “then . . . compete on implementations.” App. 124–125. The testimony at trial was replete with examples of witnesses drawing this critical line between the user-centered declaratory code and the innovative implementing code....
These features mean that, as part of a user interface, the declaring code differs to some degree from the mine run of computer programs. Like other computer programs, it is functional in nature. But unlike many other programs, its use is inherently bound together with uncopyrightable ideas (general task division and organization) and new creative expression (Android’s implementing code). Unlike many other programs, its value in significant part derives from the value that those who do not hold copyrights, namely, computer programmers, invest of their own time and effort to learn the API’s system. And unlike many other programs, its value lies in its efforts to encourage programmers to learn and to use that system so that they will use (and continue to use) Sun-related implementing programs that Google did not copy.
Although copyrights protect many different kinds of writing, Leval 1116, we have emphasized the need to “recogni[ze] that some works are closer to the core of [copyright] than others,” Campbell, 510 U. S., at 586. In our view, for the reasons just described, the declaring code is, if copyrightable at all, further than are most computer programs (such as the implementing code) from the core of copyright. That fact diminishes the fear, expressed by both the dissent and the Federal Circuit, that application of “fair use” here would seriously undermine the general copyright protection that Congress provided for computer programs. And it means that this factor, “the nature of the copyrighted work,” points in the direction of fair use.
As for the purpose and character of the use, that also leans towards fair use in important ways -- highlighting the transformative nature of Google's use for Android here:
Here Google’s use of the Sun Java API seeks to create new products. It seeks to expand the use and usefulness of Android-based smartphones. Its new product offers programmers a highly creative and innovative tool for a smartphone environment. To the extent that Google used parts of the Sun Java API to create a new platform that could be readily used by programmers, its use was consistent with that creative “progress” that is the basic constitutional objective of copyright itself. Cf. Feist, 499 U. S., at 349–350 (“The primary objective of copyright is not to reward the labor of authors, but ‘[t]o promote the Progress of Science and useful Arts’” (quoting U. S. Const., Art. I, §8, cl. 8)).
The opinion also rejects the idea that just because Google was copying the API for commercial reasons somehow means it's not fair use:
There is no doubt that a finding that copying was not commercial in nature tips the scales in favor of fair use. But the inverse is not necessarily true, as many common fair uses are indisputably commercial. For instance, the text of §107 includes examples like “news reporting,” which is often done for commercial profit. So even though Google’s use was a commercial endeavor—a fact no party disputed, see 886 F. 3d, at 1197—that is not dispositive of the first factor, particularly in light of the inherently transformative role that the reimplementation played in the new Android system.
One of the key arguments Oracle and its supporters made was that Google's actions were done in "bad faith" because it first tried to negotiate a license with Sun, and when that failed, just copied the API. However, Breyer points out that this just doesn't matter:
As for bad faith, our decision in Campbell expressed some skepticism about whether bad faith has any role in a fair use analysis. 510 U. S., at 585, n. 18. We find this skepticism justifiable, as “[c]opyright is not a privilege reserved for the well-behaved.” Leval 1126. We have no occasion here to say whether good faith is as a general matter a helpful inquiry. We simply note that given the strength of the other factors pointing toward fair use and the jury finding in Google’s favor on hotly contested evidence, that factbound consideration is not determinative in this context
On the "amount and substantiality of the portion used", again the majority says this leans towards fair use. It mentions, in passing, that some of this could depend on whether the whole product being copied is all of Java or just the API, but then notes that doesn't really matter. The important question is whether or not Google copied more than it needed to to achieve the transformative use it set out to accomplish. And there the court says that Google did not go too far:
Google copied those lines not because of their creativity, their beauty, or even (in a sense) because of their purpose. It copied them because programmers had already learned to work with the Sun Java API’s system, and it would have been difficult, perhaps prohibitively so, to attract programmers to build its Android smartphone system without them. Further, Google’s basic purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. The “substantiality” factor will generally weigh in favor of fair use where, as here, the amount of copying was tethered to a valid, and transformative, purpose. Supra, at 25–26; see Campbell, 510 U. S., at 586–587 (explaining that the factor three “enquiry will harken back to the first of the statutory factors, for . . . the extent of permissible copying varies with the purpose and character of the use”).
We do not agree with the Federal Circuit’s conclusion that Google could have achieved its Java-compatibility objective by copying only the 170 lines of code that are “necessary to write in the Java language.” 886 F. 3d, at 1206. In our view, that conclusion views Google’s legitimate objectives too narrowly. Google’s basic objective was not simply to make the Java programming language usable on its Android systems. It was to permit programmers to make use of their knowledge and experience using the Sun Java API when they wrote new programs for smartphones with the Android platform. In principle, Google might have created its own, different system of declaring code. But the jury could have found that its doing so would not have achieved that basic objective. In a sense, the declaring code was the key that it needed to unlock the programmers’ creative energies. And it needed those energies to create and to improve its own innovative Android systems.
Finally, there's the impact on the market question. The majority opinion goes back and forth presenting the arguments on both sides and then notes that if Oracle was allowed to completely lock up the Java API, it would go against copyright's basic objectives and potentially harm the public! It's really nice to hear that stated so clearly:
Finally, given programmers’ investment in learning the Sun Java API, to allow enforcement of Oracle’s copyright here would risk harm to the public. Given the costs and difficulties of producing alternative APIs with similar appeal to programmers, allowing enforcement here would make of the Sun Java API’s declaring code a lock limiting the future creativity of new programs. Oracle alone would hold the key. The result could well prove highly profitable to Oracle (or other firms holding a copyright in computer interfaces). But those profits could well flow from creative improvements, new applications, and new uses developed by users who have learned to work with that interface. To that extent, the lock would interfere with, not further, copyright’s basic creativity objectives
Finally, Breyer notes that all of this is completely consistent with past Supreme Court precedent, and they're not overturning anything:
The fact that computer programs are primarily functional makes it difficult to apply traditional copyright concepts in that technological world. See Lotus Development Corp., 49 F. 3d, at 820 (Boudin, J., concurring). In doing so here, we have not changed the nature of those concepts. We do not overturn or modify our earlier cases involving fair use—cases, for example, that involve “knockoff ” products, journalistic writings, and parodies. Rather, we here recognize that application of a copyright doctrine such as fair use has long proved a cooperative effort of Legislatures and courts, and that Congress, in our view, intended that it so continue. As such, we have looked to the principles set forth in the fair use statute, §107, and set forth in our earlier cases, and applied them to this different kind of copyrighted work.
Well done. It would have been nicer if they'd also offered a clean answer on whether or not APIs are subject to copyright at all, but in absence of that, this will be a useful fair use case going forward.
As for the dissent from Justices Thomas (co-signed by Alito)... it's weird. First it says that the majority should not have ignored the copyrightability question -- though it argues that if that had been explored, APIs would clearly be covered (again, I believe this is wrong). Thomas falls for the same trap that the CAFC judges did -- insisting that because it's all confusing to them, API code and executable code are basically the same thing, because they "are bound together." This is just weird. The Supreme Court has, in the past, recognized that multiple parts of the same work, even those that are bound together, can have some elements that are covered by copyright and some that are not. Why Thomas and Alito ignore this is beyond me.
Their fair use analysis is similarly just wrong. Whereas the majority found all four factors favored Google, Thomas/Alito insist that three "decisively favor Oracle." Again, Thomas demonstrates his technical ignorance in insisting that declaring code and implementing code are effectively no different. Regarding the harm on the market, Thomas insists that the majority is all speculative, and the fact that the European Commission has fined Google for antitrust practices shows that if the Court is worried about lock-in, it should be worried about Google, not Oracle. There is a kernel of a point in there, but it's got nothing to do with the case at hand.
Thomas then gives the freakout we've been hearing from Oracle supporters for the last decade: that saying an API is not covered by copyright (or copying it is fair use) will somehow eviscerate copyright on software.
Now, we are told, “transformative” simply means—at least for computer code—a use that will help others “create new products.” Ibid; accord, ante, at 26 (Google’s copying “can further the development of computer programs”).
That new definition eviscerates copyright. A movie studio that converts a book into a film without permission not only creates a new product (the film) but enables others to “create products”—film reviews, merchandise, YouTube highlight reels, late night television interviews, and the like. Nearly every computer program, once copied, can be used to create new products. Surely the majority would not say that an author can pirate the next version of Microsoft Word simply because he can use it to create new manuscripts.
But that's just ludicrous. The majority decision lays out all the ways Google copying the API resulted in new products -- because it enabled more programmers to write apps for Android. It's not saying that the Android copy itself was to create products. Thomas is completely misreading the issue, and I can assure you that no court is going to read the majority decision to say that standard piracy is now fair use.
Thomas claims that the majority is conflating transformative use with derivative use, but it's actually Thomas who is doing that with the above paragraph. The majority is not saying that derivative use is obviously fair use, but if the effort is transformative, using functional specs to create a system for others to make use of, then it can be transformative. Google's use wasn't derivative -- it was building an entirely different system, and wanted to include some familiar guideposts for developers.
Hilariously, after previously insisting that the Java declaring code and implementing code were too inextricably tied together to separate out what was copyrightable and what was not, Thomas then rejects that in looking at the amount used factor -- saying we must only look at the declaring code.
But the proper denominator is declaring code, not all code. A copied work is quantitatively substantial if it could “serve as a market substitute for the original” work or “potentially licensed derivatives” of that work. Campbell, 510 U. S., at 587. The declaring code is what attracted programmers. And it is what made Android a “market substitute” for “potentially licensed derivatives” of Oracle’s Java platform. Google’s copying was both qualitatively and quantitatively substantial.
The entire dissent is a mess of nonsense and question-begging.
In the end, this is a good decision and helps avoid the disaster that would have occurred if Oracle's viewpoint had won out. Somewhat ironically, as we've pointed out before, Google winning on this argument is actually good for competition, as it will also create more opportunities for new companies to undermine Google's own position in the market as well. This is a good ruling and the entire software development community can breathe a bit easier.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: api, apis, clarence thomas, copyright, declaring code, fair use, java, java apis, stephen breyer
Companies: google, oracle, sun
Reader Comments
Subscribe: RSS
View by: Time | Thread
Lotus v Borland
Minor error: After Lotus v. Borland was decided by the first circuit, the Supreme Court divided 4-4 so it was upheld by default but didn't set a formal precedent.
I agree that everyone except Larry Ellison believed that the issue was settled decades ago.
[ link to this | view in chronology ]
Re: Lotus v Borland
Pardon my French, but as a professional software developer, I'd like to use this chance to reiterate: fuck Larry Ellison, and fuck Oracle (though I repeat myself). He/they are a cancer on the entire software world.
[ link to this | view in chronology ]
Which is a little disappointing but entirely in-character for the Roberts Court. This SCOTUS tends to prefer narrow rulings to broad ones.
Still, as you say, this is the next-best thing. Catastrophe averted.
[ link to this | view in chronology ]
Re:
My fear, aside from the court reaffirming the CAFC court mistake, was that they would sidestep the issue somehow. That they determined APIs to fall under fair use will hopefully not be so narrow, and will significantly settle the issue from this point onwards.
[ link to this | view in chronology ]
It settles the issue of whether APIs fall under Fair Use. It doesn’t settle the issue of whether APIs are copyrightable, which is something SCOTUS could’ve explored but chose not to because ¯_(ツ)_/¯
[ link to this | view in chronology ]
Re:
It appears you dropped this \
[ link to this | view in chronology ]
Happily, case very narrow. No effect on "active" code.
Just happy that "The Alert SP Oiler" was in time with comment in the prior piece of how you'd cheer this.
[ link to this | view in chronology ]
And you call other people “astroturfers”…
[ link to this | view in chronology ]
"Ah, victory"
Truth be told, I was very happy to see the outcome of this case. For all the people calling for Justice Breyer to retire, cases like these are why I'd rather wait until he feels he's done.
[ link to this | view in chronology ]
Re: "Ah, victory"
Yeah, that worked out great for Ginsburg.
[ link to this | view in chronology ]
Re: Re: "Ah, victory"
Ironically, knowing Ginsburg's views on copyright, had she been alive to make a decision here, the decision would have been a 6-3 one rather than a 6-2 one.
[ link to this | view in chronology ]
Re: Re: Re: "Ah, victory"
And if she'd retired in 2009, it might have been 7-2.
[ link to this | view in chronology ]
Re: Re: Re: Re: "Ah, victory"
I am curious how this would have worked out, though. Justice Souter retired at that time, satisfied that there would not have been two vacancies at once. In addition, Justice Stevens retired in 2010, so we'd be looking at three vacancies filled within the span of 2 years. Not unmanageable, given that Richard Nixon's four-justice ensemble was installed within 3 years, but I can only wonder about what could have been.
[ link to this | view in chronology ]
Re: Re: "Ah, victory"
Justice Breyer, to my knowledge, does not have the same health issues and opposing party politics that respectively preceded and succeeded the Ginsburg vacancy. As such, given his personality and statements in interviews saying that he plans to retire rather than die in office, I think he'll know when to stop.
[ link to this | view in chronology ]
Re: Re: Re: "Ah, victory"
Yes, it's nineteen whole months until the next Senate election; obviously there's no chance of opposing party politics being a barrier to a Supreme Court nomination any time soon.
[ link to this | view in chronology ]
I Agree with the dissent that they should not have ignored the copyrightable questions.. I never understood the philosophy that courts often take that presents their role as solely to decide individual cases they are looking at and not making any decisions on how the laws should be interpreted unless it's absolutely unavoidable. As if their end goal is to have every citizen come up with their own unique interpretation of the law and they want as to reside over as many disputes as they can
[ link to this | view in chronology ]
Re:
It is my understanding that if the courts, as a general principle, identify one reason that will conclude the matter at hand, then they typically focus on this one item. It will decide the case, they will write their reasoning, but will ignore other aspects of the case. Few cases will thoroughly explore all possible legal avenues.
Operating in this way probably makes the workload easier for judges, and could lead to a greater number of cases being decided. This may benefit the public if many cases are pending, and only a limited number of cases can be heard. Also, if one aspect of a case is murky, and won't actually decide the case, the judges may figure that another case in the future will be more appropriate for making a decision.
[ link to this | view in chronology ]
Re: Re:
Yeah but making your legal interpretations as broadly applicable as you can would alleviate the load in the long run.
If there are multiple decisions at play, to be more efficient they should start with the one that is broadest applicable (which would alleviate the most future load) and work their way narrower only after explaining why the decision on the broader one doesn't resolve the issue at hand..
Murky aspects are exactly why you need someone to make a call.. If they ruled on the copyrightable issue, it could potentially prevent a ton of burden from fair use cases which are completely unclear and are basically all case by case, or at least let us know that all that burden from fair use cases is unavoidable.
I'm sure they must know better than I do, I just haven't managed to find a satisfactory explanation to understand it myself.
[ link to this | view in chronology ]
Re: Re:
But by the same line of reasoning, simply confirming Alsup's original finding, that -- as a matter of long-established, basic Copyright Law (the aforementioned Section 102b) -- computer programming API's simply aren't even copyrightable in the first place, would also have concluded the matter at hand, even more definitively; and the whole "Fair Use" question would then have been swept aside as entirely moot, as it should have been all along.
[ link to this | view in chronology ]
Re:
Federal courts are courts of limited jurisdiction, and under the U.S. Constitution, exist only to decide ``case and controversies''. They are not supposed to offer advisory opinions or decide things not before them. Indeed, if a case settles, they lose jurisdiction. In criminal matters, if the defendant dies, there is no more case or controversy.
[ link to this | view in chronology ]
Re: Re:
Right, but there were 2 questions before the court - one on ability for an API to be copyrighted in the first place and one on Fair Use. They punted the first and decided on the second.
[ link to this | view in chronology ]
Re: Re: Re:
Once that one was decided, there was no longer any remaining case or controversy. If the use was a fair use, then the court need not understand or decide whether an API is a proper subject of copyright.
When a case settles or otherwise becomes moot, there is no remaining case or controversy because a decision will no longer affect the parties. From that it follows that they are less motivated to spend money and effort to fully advocate their side.
While courts sometimes go on to decide things likely to recur yet evading review, in re: Providence Journal, 293 F.3d 1 (US 1st Cir. 2002), that is not a requirement of the job.
[ link to this | view in chronology ]
I also would have liked the uncopyrighteability-of-dictionaries to be clearly stated. But that is a subtler issue (most non-techies don't realize that engineers define their own purely-functional languages; lawyers fondly rejoice in the delusion that they speak English.)
As the appeals court didn't grasp the distinction between declarations and programming code, the Supreme Court COULD have sent it back to them to learn the distinction, and pervert the facts some other way instead. I can see why the Supreme Court chose rather to school the appeals court on the basics of fair use--certainly something that is always needed, and not just for the sake of programmers. (Note--in the real world, fair use is a much bigger and more-pervasive issue than any kind of software copyrights.)
[ link to this | view in chronology ]
Re:
As interesting idea about the dictionaries.. Is there actually a definable difference between a dictionary for english, latin and a made up one like your engineering example or a even a klingon or elven one?
[ link to this | view in chronology ]
Re: Re:
TBH, I think the "Dewey Decimal System" referenced in the actual court opinion is a much better analogy for an API than a dictionary. I could see the argument that there is some creativeness in the exact wording of a word's definition. The Dewey Decimal system, on the other hand, simply provides a location reference to find a book, much like how an API provides a reference on where to find a set of instructions that needs to be run. There's no creativeness in that.
[ link to this | view in chronology ]
Re: Re: Re:
A hyperlink is a good example of an API that most people are familiar with enough to understand how they work. You shouldn't really need an analogy
[ link to this | view in chronology ]
Re: Re: Re: Re:
I mean, you're right, but aren't there a bunch of countries that keep trying to tax hyperlinks as though they're stealing copyrighted material? I'm not sure enough idiots really understand hyperlinks to make them a viable example.
[ link to this | view in chronology ]
Re: Re: Re:
Don't you know the Dewey Decimal system???? https://www.youtube.com/watch?v=XHbdoO7uCkk
[ link to this | view in chronology ]
Re: Re: Re:
The Dewey Decimal System is also a good example because if it wasn't created and codified, someone would make a different one that is almost exactly the same.
We see this a lot in software where someone re-invents the wheel, and it looks almost identical to the API/library/wheel someone else wrote that they'd never knew existed. It has to do with function rather than creativity.
[ link to this | view in chronology ]
Re:
If I recall correctly, SCOTUS has in fact tried schooling the CAFC that way, on quite a number of occasions already, on rather similar matters -- to little if any observable effect.
(At least, with little effect on the Court of Appeals learning or understanding the relevant distinctions -- but quite remarkable effect in spurring the appeals court to find new ways of perverting the facts.
[ link to this | view in chronology ]
Me explaining a 3-branches diff to my kids
Supreme Court justices understand what they have learned.
Elected officials understand what major donors pay them to learn.
[ link to this | view in chronology ]
So, I wrote a book using all the chapter (and "book") titles from "A Tale of Two Cities", but as an analogy to technological ecologies, and set in space. Am I supposed to pay for a copyright license for having used those chapter titles?
How about if it involved space werewolves getting their furry on?
[ link to this | view in chronology ]
Re:
Copying chapter titles isn't remotely like an API, showing that you don't have any idea what an API is.
You should feel bad, Clarence.
[ link to this | view in chronology ]
Re: Re:
It's a very apt analogy, especially when you are talking about writing books -- like science text books. That it is overly simplified compared to computer systems -- well, its an analogy.
The chapter titles give you an idea of what is expected to be found in that chapter. Quite often they are grouped together in sections, like earth science or astronomy. The specific chapter definition will be a marker for the knowledge that can be found there. The specific implementation of the chapter (what's in it, pictures, subheadings, etc.) are left to the reader to implement. You could have many different versions of a science book come out of the same set of chapter titles. If you allowed for more flexibility and went to something fiction, then skies the limit to what creativity can flow from a skeleton of definitions that don't have to follow the original plot. But I digress.
All analogies fail in the long run, but why do you assert that this one is poor? Do you have a better one?
[ link to this | view in chronology ]
This is easier to understand if you had been working with standard "intrinsic" function names since ... before Larry Ellison started a company to implement someone else's language definition....
Take, for instance, Fortran as a historical example. Fortran was distributed as three things: (1) a compiler, that converted computer instructions in a certain format into a usable machine-language program on some computer; (2) a library of functions that anyone might need (everything from file I/O to trigonometric functions), and (3) a manual, describing what form instructions had to appear in, and how the library functions were to be invoked. (1) and (2) were copyrighted. (3) was also copyrighted, but with a difference: it consisted of some arrangement of facts, and the facts contained in (3) were pejorative-deleted scatological-deleted expletive deleted NOT copyrightable. Fortran manuals often exhibited fairly similar formats, structures, and facts: nobody who could find the top edge of a punch card thought that constituted copyright infringement.
A Fortran compiler had, built into it, long lists of function names, the type of parameters each function took, and--for a random and changeable subset of those functions--the actual computer code to implement the function. Many intrinsic functions were simply translated into function calls into the supplied library. But nobody imagined that the names of the functions could be copyrighted: in fact, the U.S. Government (Department of Defense) required anyone who wanted to sell computers to them, be able to show that their function names matched the ones defined in the "Standard" (American National Standards Institute) manual.
Step forward to a C distribution, consisting of (1) compiler (2) standard library, and (3) manual. But there was a clever observation here: that long list of function names and parameters encoded in the Fortran compiler, could now be written in machine-readable form. So the C distribution also included (4) separate standard files ("include files") listing all those function names and parameter types (declarations), and (5) a separate preprocessor, which could insert separate files--standard or otherwise--into a C program before compilation.
Everyone who was sane or tech-savvy (i.e. everyone but SCO's moronic MBAs and lawyers) recognized that "include files" consisting only of declarations were not copyrightable--and it did not make sense to copyright them because THEIR PRIMARY USE WAS TO BE COPIED into every C program. And besides, the standard include file organization was so simple that it would be impossible to distinguish non-functional elements. That is, this is much more like a phone directory even than an English dictionary.
Do not confuse "include files" with "function declarations". Include files could contain anything that ordinary C source program files could contain (and vice versa). The point is, "functional" (in the copyright sense) declarations were distributed as a multi-chapter dictionary or directory of C function names and types.
Step forward to Java. Once again, the standard function declarations were organized in a hierarchical structure that might (or might not) appear in separate files. Once again, the compiler depends on those declarations to check the validity of function calls in user-written programs. But what, in essence is functionally different between package definitions in Java, and Fortran manual pages providing lists of "functions by abstract category"? The Java package definition, whose form is purely functional, has even less claim to copyrighteability than the Fortran manual page.
Although, it must be admitted, many of the Fortran function names remain in Java--an heinous violation of IBM's precioussss intellectual property ... in other words, the sort of thing that Larry Ellison is 110% wholly-on-board-with.
[ link to this | view in chronology ]
Re:
And even IBM wrote an amicus curiae in favor of Google.
[ link to this | view in chronology ]
Re:
It is long past time that someone drove a silver tipped, garlic soaked stake through the heart of that suite, as it is still rumbling on
[ link to this | view in chronology ]
Re:
Java seems to be a lot more similar to C/C++ than anything else. a lot of method names and syntax are exactly the same.
[ link to this | view in chronology ]
Re: Re:
However, in C and C++, you have to declare pointers. In Java everything is a pointer.
[ link to this | view in chronology ]
Guess it's the lawyers who get the most of the money...
So, this time fair use was on google's side. But the truth is still that you need to spend millions on lawyer's fees before fair use is properly considered. Thus normal users and companies cannot rely on existence of fair use unless they have plans to spend money on lawyers enough to bring the cases to supreme court.
[ link to this | view in chronology ]
And I’m sure that’s your excuse for getting rid of Fair Use, since you’re already in favor of annihilating the public domain.
Fuck off.
[ link to this | view in chronology ]
Re:
Why are you now in the side of giant companies? Those are the only people who can benefit from fair use, given that lower courts decided fair use completely differently than supreme court?
[ link to this | view in chronology ]
No. No, they are not.
[ link to this | view in chronology ]
Re: Re:
This is a most ridiculous assertion.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
"Those are the only people who can benefit from fair use"
Every storyteller since the dawn of time benefited from fair use, as did every inventor since we discovered fire.
Your assertion that because imaginary property law has propelled a bunch of lower courts to be more draconian in interpretation than the higher ones is a reason against fair use...honestly, that's just a claim that the only proper fix for an unjust law is to make sure it gets to be unfair to everyone equally - rather than that the law in question be abolished.
As if I needed more proof that the copyright cult consists of religious fanatics...
[ link to this | view in chronology ]
Re: Guess it's the lawyers who get the most of the money...
Since I am not the Great Cornholio, I do not need you for my bunghole.
Go away.
[ link to this | view in chronology ]
Re: Re: Guess it's the lawyers who get the most of the money...
"Are you threatening me"?? https://www.youtube.com/watch?v=Ii8H2tYcFYY
[ link to this | view in chronology ]
Re: Guess it's the lawyers who get the most of the money...
So, this time fair use was on google's side. But the truth is still that you need to spend millions on lawyer's fees before fair use is properly considered. Thus normal users and companies cannot rely on existence of fair use unless they have plans to spend money on lawyers enough to bring the cases to supreme court.
I see that others are upset with you given your ridiculous opinions on copyright seen in the past, but this is a legitimate concern regarding fair use. There are efforts under way to deal with it, including creating common best practices for fair use, and so rulings like this are useful mostly for big legal questions regarding new ideas not yet decided by courts.
[ link to this | view in chronology ]
Re: Guess it's the lawyers who get the most of the money...
That's a problem, but history suggests that you would replace it with a far worse problem.
[ link to this | view in chronology ]
Re: Re: Guess it's the lawyers who get the most of the money...
The whole google vs oracle java api splatter would have been avoided if only google had followed copyrights and not copied those 13,000 lines of java apis. Now they spent 10 years fighting the issue in court when they should be developing new products for the world. How many users are without working phone because android ecosystem couldn't reach cheaper phone segments and instead spent the money and resources to fighting their competitors (and partners) in courts?
[ link to this | view in chronology ]
Re: Re: Re: Guess it's the lawyers who get the most of the money
Back in the real world:
Google did follow copyright law completely and to the letter, taking not a single letter of copyrighted material.
The one and only reason the lawsuit exists is not because of anything Google did, but because Oracle are nothing but greedy cybersquatting scammers now.
[ link to this | view in chronology ]
Re: Re: Re: Guess it's the lawyers who get the most of the money
Are you really saying that a $1Trillion+ company, with more than $150b/year in revenue and over 100k employees can only do one thing at a time?
[ link to this | view in chronology ]
Re: Re: Re: Re: Guess it's the lawyers who get the most of the m
no, but somewhere deep within their android department there is a bank account containing 6 billion dollars earmarked for the situation that oracle wins their lawsuit. It reads in big letters "DO NOT TOUCH UNTIL ORACLE LAWSUIT IS RESOLVED... and that kind of idle money means that they cannot develop products to the world as efficiently as possible.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Guess it's the lawyers who get the most of t
So about a 0.3%/year over the last 10 years?
Wow, massive hit to their ability to do work /rolleyes.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Guess it's the lawyers who get the most of t
"...but somewhere deep within their android department there is a bank account containing 6 billion dollars earmarked for the situation that oracle wins their lawsuit."
That's not how large companies operate. Google, like every other major corporation, operates on an optimized cashflow model, meaning that revenue not earmarked for stock payouts will be reinvested to make reinvestment and cost as equal to revenue as possible. Money sitting still earns no interest and does not make new money, which is a capital sin for a publicly traded company. Every major corporation will have liquid capital on hand as close to 0 as possible for this reason.
Unexpected expenditure will always be covered by Google waving their triple-A credit rating at a bank who will have them set up with a loaner account with nigh-unlimited boundaries. Again, this is how every major corporation operates.
This is how GM and other major companies, in 2009, still had to beg for bailouts from Uncle Sam, because despite the business still floating pretty well, the national freeze on bank lending meant GM couldn't lay their hands on money to pay salaries and vendors.
After 2009 a lot of corporations saw themselves forced to try to adopt to a buffer model where they keep enough cash on hand to still operate for at least a month in case another national bank shutdown happens. But that's the only reason for a company to sit on a wad of cash; because the banks closing is the only way the wallet snaps shut.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Guess it's the lawyers who get the most
And if you look at which year oracle vs google java lawsuit started, it's pretty damn near this 2009 year. (actual start was 2011), so the buffering might be still used when the lawsuit began..
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
The fact that someone has to fight off a court case that someone else started is, by itself, a terrible metric to decide whether someone's perspective is correct or otherwise. It doesn't prove whether the person being sued is right or wrong, it just proves that the plaintiff has a bone to pick and money to spend (or waste) on the court system.
But then again considering it's you, who believes Prenda Law wasn't breaking the law by lying to the court, it's not surprising that you think people should be guilty upon accusation.
[ link to this | view in chronology ]
Not a catastrophe
Judge Alsup understood the issue. No one above him did. The Supremes recognized that something stupid was going on and stopped it, but for reasons that made sense to lawyers, not coders.
[ link to this | view in chronology ]
Half the problem here is that not just APIs but computer code itself should not be copyrightable. Nobody codes so that people can see the "creativeness" of their code. (They might code so that people can see the functionality and efficiency of their code, but that's not the same thing - and even that's rare.)
[ link to this | view in chronology ]
Re:
I have no problems with computer code of sufficient complexity being copyrighted (API's aren't code), it's after all an expression of sorts but allowing copyright on code that implements basic functionality is just silly.
[ link to this | view in chronology ]
Re:
I despise cutesy, "creative" code. The more someone does this to prove how creative they are or how code should absolutely have a copyright, the less fit for a production environment it always is. There is a reason the C-obfuscation winners write that way for a contest and not for production.
[ link to this | view in chronology ]
Re:
Nobody writes novels so that people can see the ``creativeness'' of their writing, either. Likewise for newspaper columns.
Yet, truly, I have seen some code which was a thing of beauty, and even written a few lovely bits. And I have written newspaper columns which I like to think both educate and entertain (and occasionally win Fla Press Assn awards).
Surely, despite the fact that I did not write to show off ``creativeness'', I or my assignee should be entitled to copyright in these original works.
I agree, by the way, as to no copyright in the API: that is a required setting of values into registers before making the calls, and the anticipated return values in registers and carry flags. Your creative efforts to use my underlying code require that you conform to my calling sequence, so that is more of a fact than creative material. Indeed, if my code is widely adopted in thousands of devices, it may become something of a scenes a faire situation where everyone considers it a standard, like the disapproving father in Nichols v. Universal Pictures, 45 F.2d 119 (US 2d Cir. 1930).
[ link to this | view in chronology ]
Re: Re:
Gadsby by Ernest Vincent Wright, says that they sometimes do.
[ link to this | view in chronology ]
Cancer
Oracle, and Sun Microsystems before it, are a cancer on the rest of the computing world.
[ link to this | view in chronology ]
Excellent Analysis
[ link to this | view in chronology ]
PRAISE THE COURT
RETURN THE CONGRESS lol
[ link to this | view in chronology ]