from the off-to-the-races dept

It was only a matter of time until this happened, but Oracle has officially appealed its fair use Java API loss to the Federal Circuit (CAFC). As you recall, after a years-long process, including the (correct) ruling that APIs are not covered by copyright being ridiculously overturned by CAFC, a new trial found that even if APIs are copyright-eligible, Google's use was covered by fair use. Oracle then tried multiple times to get Judge William Alsup to throw out the jury's ruling, but failed. In fact, on Oracle's second attempt to get Alsup to throw out the jury's ruling, citing "game changing" evidence that Google failed to hand over important information on discovery, it actually turned out that Oracle's lawyers had simply failed to read what Google had, in fact, handed over.

And now the case will finally move up a level, as it was always going to do. There should be lots of fireworks here. CAFC is notoriously bad on a variety of issues, but it would take a pretty impressive level of confusion here to mess this up. Going against a jury's findings on fair use is a big ask, and Oracle is likely to try some silly games whining about jury instructions and such. Hopefully CAFC doesn't fall for it. If it does, hopefully, it doesn't muck stuff up as badly as it did with its first ruling in this case, that simply got confused over the nature of what an API actually is.

from the you-wouldn't-reimplement-an-api dept

Yikes. A month ago, we wrote about how Oracle was asking Judge Alsup to agree to another new trial in the Oracle v. Google API copyright case. I joked that they basically had no chance, and Judge Alsup had already rejected their attempts to overturn the jury ruling. But... I may have spoken too soon. In a hearing on the matter earlier this week, Oracle insisted that there needed to be a new trial because Google had withheld information on plans to offer Android on Chromebooks -- something that Google announced at this year's Google IO which happened (awkward!) while the trial was going on.

And this morning, Alsup issued an order telling both sides to provide sworn statements about this. For Google, it's why it had not updated its discovery responses to include the plans for Android on Chromebooks, and for Oracle, whether it, too, had neglected to update its discovery responses (and specifically calls out a misrepresentation by Oracle):

By THURSDAY AUGUST 25, AT NOON, Christa Anderson, counsel for Google, shall
submit a sworn statement explaining why the discovery responses referenced in Court yesterday
were not updated, including the full extent to which counsel knew Google’s intention to launch
a full version of Marshmallow, including the Google Play Store, for Chrome OS.

By the same date and time, Annette Hurst, counsel for Oracle, shall submit a sworn
statement setting forth, after full inquiry, the full extent to which Oracle neglected to update its
discovery responses by reason, in whole or in part, of one or more rulings by the judge. The
same statement shall explain why counsel repeatedly represented that the Jones v. Aero/chem
decision required an “evidentiary hearing” when that decision, as it turns out, made no mention
of an “evidentiary hearing” and instead remanded because no “hearing” or other consideration
at all had been given to the issue of discovery conduct by the district judge.

This does not mean that there absolutely will be a third trial, but it's at least more of a possibility than most observers thought possible. I honestly don't see how Android on Chromebook really matters for the fair use analysis. Oracle argues that since most of the talk on the market impact was limited to phones and tablets, that may have impacted the jury, but that's kind of laughable. The reality is that Oracle just wants another crack at a decision it disagrees with.

Of course, all of this is really a stupid side show. The real underlying problem was the Federal Circuit's decision that APIs were covered by copyright, despite almost no one actually thinking that's true. The whole fair use trial was an awkward mess, mainly because all of the arguments weren't so much about "fair use" but about whether or not anyone actually considered APIs to be covered by copyright. Going through another such trial would just be a mess.

But the other area where a new case may come about is that Judge Alsup made clear that Oracle was also free to bring new cases on new uses of Android to see if they were also fair use, meaning that any time Google does anything new with Android, it may face a new fair use trial. They wouldn't need to do this if the CAFC had just recognized that APIs are not covered by copyright, but it didn't and here we are in a big heaping mess.

By the same date, counsel shall meet and confer and advise the Court whether the form
of judgment should be amended to reflect that it is not a final judgment but a Rule 52(c)
judgment on partial findings, given that Oracle is entitled to challenge further uses of Android
herein.

from the because-of-course dept

Is there no goodwill that the Pokemon Company's lawyers won't step in and kill off? With the popularity of Pokemon Go, some third parties had started trying to develop some services to go with it, and as part of that, a few have tried to create Pokemon Go APIs. A user going by the name Mila432 had created an unofficial Pokemon Go API in Python, and posted it to GitHub. If you go now, you may notice that the Readme now reads:

see you in court nianticlabs, with love from russia xoxo

That's because the Pokemon Company (not the game developer Niantic, but rather the Nintendo subsidiary that owns a piece of Niantic along with all the Pokemon rights) sent Mila432 a legal nastygram claiming that the creation of the API could violate the Computer Fraud and Abuse Act (CFAA). Mila432 posted screenshots to Reddit. We have all the screenshots posted at the end of this post.

The letter first claims that creating this API is a violation of Pokemon's Terms of Use as well as Pokemon Go's Terms of Service. But, more importantly (and ridiculously) it claims a violation of the CFAA -- a law we've discussed many times before, mainly for it being the one law "that sticks" when no law was actually broken, but you've done something people dislike "with a computer." Here's what Pokemon's lawyers have to say:

Additionally, your actions with respect to the Mila 432/Pokemon_Go_API potentially violate the federal Computer Fraud and Abuse Act ("CFAA"), a statute that prohibits the unauthorized access of servers and access which exceeds authorization, as well as similar state statutes. And your inducement of others to violate numerous terms of service provisions violates the CFAA. While notice is not a prerequisite to liability, Pokemon hereby puts you on notice that you are barred from accessing Pokemon servers or infrastructure, and barred from facilitating access by others. Any continued access, whether directly or at your direction or on your behalf, will be unauthorized.

See that language right there, about putting Mila432 "on notice" and saying that s/he is barred? That's straight out of the very recent Facebook v. Power.com decision in California, where the court ruled that once a company (in that case, Facebook) had sent a cease-and-desist notice, any further access was a CFAA violation. We were troubled by that ruling, and the use of it here further illustrates how problematic it was.

Now, yes, you can argue that unauthorized APIs can cause problems for games -- and that's true. Of course, it can also help make them more compelling by allowing others to build on the game and add more value. But, wherever you come down on that debate, going legal seems pretty silly. Niantic, for its part, had simply gone the technology route of limiting access to third-party servers, to deal with some quality of service problems created by such third parties accessing its system. That is, rather than totally freak out about such APIs, it noted the actual problem (overloaded machines) and sought to fix it through technology.

It's just the Pokemon company that took it up a few unnecessary notches to pull out a big gun like the CFAA. But, I guess, how can I be surprised? This is the same company that legally fucked over a party by Pokemon fans at PAX last year, suing the people who organized it.

from the ain't-done-yet dept

This is somewhat surprising, but good: after a few days of deliberation, the jury in the redo of the Oracle v. Google case concerning Google's use of Java's APIs in Android has resulted in a jury verdict finding that Google's use was allowed as fair use. There's not much to unpack here beyond what we've already written about the case. The jury form was a simple question of whether or not the use was covered by fair use, with a "Yes" check box meaning "finding for Google" and a "No" check box finding for Oracle The jury checked yes.

So, a few quick thoughts:

All things considered this is a good ruling in that it doesn't lead to a crazy situation that undermines the reimplementation of APIs and other structures in different software, so *phew*.

This still sucks because fair use was the wrong vehicle. The APIs never should have been considered copyright-eligible in the first place, just as the judge in the original trial explained in his very detailed opinion. It's only because an excessively confused federal circuit appeals court mucked things up, that the case had to go back down and be redone over fair use.

The trial itself was a weird one, because they weren't really allowed to talk about the first trial and how a very large number of people in the tech industry didn't think that APIs were covered by copyright at all. So that resulted in some weird conversations to explain why no one really thought this was infringing. They couldn't say no one thought APIs were covered by copyright, so they had to talk about "open" and "free" in ways that were slightly misleading.

If anything, this may be the most important fair use case to turn on factor 2, "the nature of the copyrighted work." That's a factor that rarely is a very big deal, but without being able to (re)challenge the copyrightability, the focus was mostly on the nature of APIs and how the tech industry viewed them as free to be reused.

Of course, no matter what the verdict was there would be an appeal, and that's absolutely true. Oracle will appeal. But it does make it more difficult to appeal. Oracle will have to challenge specific aspects of things, and will likely focus on the jury instructions, which it will argue unfairly biased the jury or something along those lines.

The Court of Appeals of the Federal Circuit (CAFC) is still a disaster, and while I hope they don't, there's still a decent chance they'll end up siding with Oracle on appeal. Remember, CAFC is a court that normally focuses on patent laws and has a long and disgraceful history of loving to expand intellectual property and believing, incorrectly, that any kind of use is "theft."

But, in the meantime, this at least lifts something of a cloud over the industry, and we can hope that (1) CAFC will get it right and if they don't (2) that the Supreme Court will fix it, rather than ignore it, next time around.

Overall, a good result of a bad process and a confused judicial system. For now.

from the there's-more-to-this-than-fair-use dept

Attorneys for the Oracle and Google companies presented opening statements this week in a high-stakes copyright case about the use of application-programming interfaces, or APIs. As Oracle eagerly noted, there are potentially billions of dollars on the line; accordingly, each side has brought "world-class attorneys," as Judge William Alsup noted to the jury. And while each company would prefer to spend their money elsewhere, these are businesses that can afford to spend years and untold resources in the courtroom.

Unfortunately, the same can't be said for the overwhelming majority of developers in the computer industry, whether they're hobbyist free software creators or even large companies. Regardless of the outcome of this fair use case, the fact that it proceeded to this stage at all casts a long legal shadow over the entire world of software development.

If Google wins at this stage, it's tempting to declare the nightmare of that Federal Circuit opinion behind us. After all, fair use is a right -- and even if API labels are subject to copyright restrictions, those restrictions are not absolute. Google prevailing on fair use grounds would set a good precedent for the next developer of API-compatible software to argue that their use too is fair.

Tempting, but not quite right. After all, there is a real cost to defending fair use. It takes time, money, lawyers, and thanks to the outrageous penalties associated with copyright infringement, comes with a substantial risk. Beyond all those known costs, wedging a layer of copyright permissions culture into API compatibility comes with serious unknowable costs, too: how many developers will abandon ideas for competitive software because the legal risks are too great?

There's a reason people say that if you love fair use, you should give it a day off once in a while. Even the vital doctrine of fair use shouldn't be the only outlet for free speech. In many areas, an absence of copyright, or the use of permissive public licenses, can foster more creativity than fair use alone could. Sadly for now, in the world of software development it's the paradigm we have.

from the fundamentally-not-understanding-that-apis-are-not-software dept

Copyright expert and professor Pam Samuelson, one of the most respected scholars of copyright law, has published a short paper explaining what she calls the "three fundamental flaws in CAFC's Oracle v. Google decision." As you may recall, that ruling was a complete disaster, overturning a lower court decision that noted that application programming interfaces (APIs) are not copyrightable, because Section 102 of the Copyright Act pretty clearly says that:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

But CAFC got super confused, and basically ignored 102 while misunderstanding what an API actually is. After the White House itself got confused, the Supreme Court refused to hear the case. This means that the CAFC ruling stays in place, despite it being at odds with lots of other courts. And this might not be a huge problem, since most copyright cases won't go to CAFC. The only reason the Oracle case went to CAFC was because it started out as a patent case, and CAFC gets all patent appeals, even if the appeal has nothing to do with patents. Except... of course, now there's incentive to toss in a bogus patent complaint along with a questionable "interface copyright" complaint just to get it into CAFC's jurisdiction.

Samuelson's paper is a good read (and we'll get to it), but I'd actually argue it's a bit too tame, and leaves out the really fundamental flaw in the CAFC ruling and in the White House brief: these non-programmers don't realize that an API is not software. Almost all of the mistakes stem from this simple fact. They assume that an API is software. And this is highlighted very clearly in the CAFC ruling where they quote Pam Samuelson out of context and then completely miss what she's actually saying. Here's from that ruling:

Google argues that “[a]fter Sega, developers
could no longer hope to protect [software] interfaces by
copyright . . . Sega signaled that the only reliable means
for protecting the functional requirements for achieving
interoperability was by patenting them.” ...
(quoting Pamela Samuelson, Are Patents on Interfaces
Impeding Interoperability...). And, Google relies heavily on articles written by
Professor Pamela Samuelson, who has argued that “it
would be best for a commission of computer program
experts to draft a new form of intellectual property law for
machine-readable programs.” Pamela Samuelson,
CONTU Revisited: The Case Against Copyright Protection
for Computer Programs in Machine-Readable Form.... Professor Samuelson has more
recently argued that “Altai and Sega contributed to the
eventual shift away from claims of copyright in program
interfaces and toward reliance on patent protection.
Patent protection also became more plausible and attractive
as the courts became more receptive to software
patents.”...

Although Google, and the authority on which it relies,
seem to suggest that software is or should be entitled to
protection only under patent law—not copyright law—
several commentators have recently argued the exact
opposite. See Technology Quarterly, Stalking
Trolls, ECONOMIST, Mar. 8, 2014, http://www.economist.
com/news/technology-quarterly/21598321-intellectualproperty-
after-being-blamed-stymying-innovationamerica-
vague (“[M]any innovators have argued that the
electronics and software industries would flourish if
companies trying to bring new technology (software
innovations included) to market did not have to worry
about being sued for infringing thousands of absurd
patents at every turn. A perfectly adequate means of
protecting and rewarding software developers for their
ingenuity has existed for over 300 years. It is called
copyright.”); Timothy B. Lee, Will the Supreme Court save
us from software patents?, WASH. POST, Feb. 26, 2014, 1:13
PM, http://www.washingtonpost.com/blogs/the-switch/wp/
2014/02/26/will-the-supreme-court-save-us-from-softwarepatents/
(“If you write a book or a song, you can get copyright
protection for it. If you invent a new pill or a better
mousetrap, you can get a patent on it. But for the last
two decades, software has had the distinction of being
potentially eligible for both copyright and patent protection.
Critics say that’s a mistake. They argue that the
complex and expensive patent system is a terrible fit for
the fast-moving software industry. And they argue that
patent protection is unnecessary because software innovators
already have copyright protection available.”).

But this is just wrong. If you actually look at Samuelson's quotes, she's talking about interfacesnot software. Notice in every quote she is not actually talking about the software itself, but "interfaces," "functional requirements" and "program interfaces." The absolute worst is the first quote, where Samuelson writes "interfaces" and CAFC inserts a "[software]" to imply that it's the same thing. It's not. The two paragraphs are not actually at odds. It is entirely reasonable to argue that interfaces shouldn't be protected by copyright (thanks to Section 102) and that software should not be patentable.

It only looks like they're disagreeing if you're confused and you think that an API is the same thing as the software itself. But that's like saying a recipe is the same as a meal or that a dictionary is the same as a novel that uses those words. It's not the same thing.

So while Samuelson's new paper is great, I still feel like she holds back on that key issue, which is so just blatantly wrong, and seems to underline why non-technical people (including the judges in this case) got so confused. Of course software is copyrightable. The argument is over whether or not an API necessary for interoperability is copyrightable. And, as Samuelson's paper notes, it had been widely accepted prior to the CAFC ruling that the answer is no because they're "procedures, processes, systems and methods" under Section 102.

A second flaw was the CAFC’s overbroad view of the extent to which the “structure, sequence
and organization” (SSO) of computer programs are protectable by copyright law. During the
1980s, some courts regarded program SSO as having a broad scope of protection under copyright
law. But in the last two and a half decades, courts and commentators have recognized that the
SSO concept is too imprecise and misleading to be useful in software copyright cases. The SSO
concept does not help courts make appropriate distinctions between protectable and
unprotectable structural elements of programs. Procedures, processes, systems, and methods of
operation, almost by definition, contribute to the SSO of programs that embody them. However,
this does not make those elements protectable by copyright. The design of many program
structures, including APIs, is inherently functional and aimed at achieving technical goals of
efficiency. This disqualifies them as protectable expression under U.S. law.

Anyway, the rest of the paper is a good read, and hopefully it means that eventually this issue will get back to the Supreme Court -- and one hopes, at that time, someone can at least get through to them that an API is not software.

The appeals court ruling, by the Court of Appeals for the Federal Circuit (CAFC) (famous for getting patent cases wrong over and over and over again) didn't just get things wrong, it got things laughably wrong, confusing the difference between APIs and software throughout, and quoting people entirely out of context (including taking things so out of context that it often pitted people on the same side against each other, solely because CAFC misread what they were saying). The case was appealed to the Supreme Court, and we were shocked and dismayed to see the Obama administration further reinforce the errors of the CAFC ruling in telling the Supreme Court not to hear the case. The filing by Solicitor General Donald Verrilli repeatedly confused software with APIs and insisted that there was really no difference between the two. That's just wrong. It's not a matter of debate. It's just wrong.

One would have hoped that with a ton of computer science experts explaining to the Supreme Court how CAFC got things wrong, the Supreme Court might recognize that the Obama administration was confused, but for whatever reason, the Supreme Court has declined to hear the case.

This is dangerous. The world of software and innovation relies on the kind of interoperability and the ability to connect via things like APIs. As we've noted, this is like claiming you can copyright an entire language, rather than the creative works written in those languages. Making APIs proprietary and locked up puts a ton of innovation at risk.

As for Google and Oracle directly, this probably doesn't matter much. They're two giant companies, certainly. And now that the case returns to the lower court, they'll either settle or fight it out over fair use (and hopefully win on that front as well). But saying fair use allows this is very, very different than saying there's no copyright on the API. And for smaller companies this will have a tremendous ripple effect, and will undoubtedly lead to a slower pace of innovation. The kinds of touchstones that people build on will no longer happen. Under this ruling, it basically overrules previous rulings that said pull down menus were not copyrightable. But with this ruling in place, it's hard to see how that's still true. Expect to see a bunch of ridiculous lawsuits over minor copying of functions like that.

While this case may eventually be resolved on fair use grounds (or through settlement), there are still two potential areas of hope. First, the "precedential" power of this ruling is actually somewhat limited. CAFC precedents are more or less meaningless in this context. CAFC handles all patent cases, and the only reason it heard this case was because it started as a patent case, even though those issues were resolved much earlier. So, while CAFC has made this particular ruling, it does not mean that the 9th Circuit, where this case was actually heard has to abide by it. The appeals court for the 9th circuit could rule otherwise (though it is somewhat famous for its own nutty copyright rulings).

Perhaps if this issue returns to another appeals court, and that court gets it right, the issue will return to the Supreme Court with a clear circuit split. And by then, we can hope, the people staffing the Solicitor's General office will finally include at least one person who understands the difference between code and APIs.

The really stunning thing in all of this is just how factually wrong many of the arguments were, and that the CAFC and Obama Administration bought them. These weren't questions of interpretation or opinion. They just flat out got the facts wrong, based on an astounding level of ignorance about a rather basic concept of an API not being software. Just because they both look like "code" does not make them both code. It would be nice if the people actually making these decisions weren't so easily fooled by their own ignorance.

from the twits dept

Mike recently made the case that in the information age, platforms would do better to be open rather than closed. Being open means allowing that thing you started to branch off in many directions making you more useful to more people. Being closed means you get control. Yay. One of the examples of a platform that had initially been open and has since been becoming more closed is Twitter. What once began as a platform that was built up by users and outside groups all making even better use of Twitter than Twitter had managed for itself, has since devolved into stories of staunch refusal to allow the evolution to continue.

Twitter’s decision to pull the plug on Politwoops is a reminder of how the Internet isn’t truly a public square. Our shared conversations are increasingly taking place in privately owned and managed walled gardens, which means that the politics that occur in such conversations are subject to private rules. (In this case, Twitter’s terms of service for usage of its API.) Days after Politwoops launched in 2012, Twitter contacted the Sunlight Foundation and told us, "Your service violates our API Terms of Service on a fundamental level." We explained the goals of the project and agreed to create a human curation workflow to ensure that the site screened out corrected low-value tweets like typos, links and Twitter handles. We implemented this layer of journalistic judgment with blessings from Twitter and the site continued.

We are truly mystified as to what prompted the change of heart, and it's deeply disappointing to see Twitter kill a project they had supported since 2012. It is also disturbing to us that our feed was cut almost three weeks ago and our only direct communication came from Twitter last night, when we were told that their decision was not something that we could appeal, and, most surprisingly, they were not interested in reviewing any of the email conversation from 2012. Clearly, something changed — and we’re not likely to ever know what it was.

You can sense the boiling anger and pure confusion beneath the surface of the text. Twitter, which had been fully aware of what Politwoops was, did, and why, had allowed the service to operate for years and then suddenly pulled the plug for the same reason it gave initially before dismissing that reason. This would be enough to infuriate any developer, nevermind one focused solely on creating more openness and accountability. It must feel like a slap in the face to the Sunlight Foundation to have the opposite of their aims be utilized in the shuttering of their service.

Earlier today we spoke to the Sunlight Foundation, to tell them we will not restore Twitter API access for their Politwoops site. We strongly support Sunlight’s mission of increasing transparency in politics and using civic tech and open data to hold government accountable to constituents, but preserving deleted Tweets violates our developer agreement. Honoring the expectation of user privacy for all accounts is a priority for us, whether the user is anonymous or a member of Congress.

Which tells us nothing, exactly as I'm sure Twitter intended. This is simply a recitation of the excuse, not the reason why the decision made in 2012 suddenly got reversed with very little communication to the Sunlight Foundation. So what's the answer?

Control, of course. The doors that close on once-open platforms operate on greased hinges, it seems, where the smallest thrust on those doors causes them to slam shut. Twitter is allowed to do this, of course, but closing the platform that still uses the "@" symbol and retweets, both conceived of by people outside of Twitter, isn't a recipe for continued relevance.

from the oh-gosh-no dept

The Obama administration made a really dangerous and ignorant argument to the Supreme Court yesterday, which could have an insanely damaging impact on innovation -- and it appears to be because Solicitor General Donald Verrilli (yes, the MPAA's old top lawyer) is absolutely clueless about some rather basic concepts concerning programming. That the government would file such an ignorant brief with the Supreme Court is profoundly embarrassing. It makes such basic technological and legal errors that it may be the epitome of government malfeasance in a legal issue.

We've written a few times about the important copyright question at the heart of the Oracle v. Google case (which started as a side show to the rest of the case): are software APIs covered by copyright. What's kind of amazing is that the way you think about this issue seems to turn on a simple question: do you actually understand how programming and software work or not? If you don't understand, then you think it's obvious that APIs are covered by copyright. If you do understand, you recognize that APIs are more or less a recipe -- instructions on how to connect -- and thus you recognize how incredibly stupid it would be to claim that's covered by copyright. Just as stupid as claiming that the layout of a program's pulldown menus can be covered by copyright.

The judge in the district court, William Alsup, actually learned to code Java to help him better understand the issues. And then wrote such a detailed ruling on the issue that it seemed obvious that he was writing it for the judges who'd be handling the appeal, rather than for the parties in the case.

Unfortunately, the judges at the federal circuit court of appeals (CAFC) didn't pay attention and made a completely ignorant ruling, in which it became so clear that they didn't understand the difference between software and an API that it was almost embarrassing. The decision quoted people in ways that were completely out of context, where the CAFC judges clearly misunderstood what was being said. This ruling would fundamentally kill off important forms of innovation if allowed to stand. It would be a disaster.

So, of course, the case has been appealed to the Supreme Court -- and that's where Donald Verrilli steps in. The Supreme Court asked the Solicitor General if the US had an opinion on the case. This apparently led to a healthy debate within the Obama administration over the position it should take. I know that there are people within the administration who understand these issues. Hell, Ed Felten has just been appointed deputy CTO for the administration and he, of all people, recognizes the difference between an API and software (in fact, he signed onto an amicus brief saying as much). He also (more than most) understands the copyright side of things and the potential impact of getting this wrong.

But instead of listening to the people who actually understand the technology, it appears that Verrilli sided with the copyright maximilist/technology-ignorant faction in the government. The final brief argues that the Supreme Court should stay out, that the CAFC got it right, and that it's impossible to distinguish between APIs and software. Because Donald Verrilli has absolutely no clue how software works. That's a fundamentally ridiculous argument, and argued out of near total ignorance of the basic facts of this case.

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

An API is, quite simply, a "system or method of operation." It's not copyrightable. That should be the end of the story. And yet, everyone who doesn't get this keeps arguing that an API is the same thing as software itself. This is just flat out wrong. But Verrilli makes the same mistake:

Despite the inherently functional character of all computer code, the Copyright Act makes clear that such code can be copyrightable. Nothing about the declaring code at issue here materially distinguishes it from other computer code, and petitioner has identified no genuine conflict of authority concerning Section 102(b)’s applicability to circumstances like these. Although petitioner has raised important concerns about the effects that enforcing respondent’s copy-right could have on software development, those concerns are better addressed through petitioner’s fair-use defense, which will be considered on remand.

No, no, no and no. Everything about the declaring code distinguishes it from other computer code if you understand the first thing about computer programming. One is computer code. One explains an interface for communicating with computer code. They're fundamentally different things.

It's like arguing that there is fundamentally no difference between a recipe and a fully cooked meal.

And yet, that's exactly what Verrilli and the Obama administration are now arguing to the Supreme Court. Because they don't understand even the most fundamental things about code, and assume that because an API looks like computer code (because whoever wrote this brief is ignorant of coding), they're the same thing.

Later in the filing, Verrilli, again, seems to assume that an API is the same thing as "computer code."

If the Copyright Act contained no explicit references to computer code, one might reasonably conclude that such code is not protectable “expression” at all. Computer code differs in a fundamental way from many traditional means of literary expression. A book or newspaper article is meant to be read and comprehended by a human being as a description of an idea or story. Although many copyrightable written documents explain how practical tasks should be per-formed, there is typically a clear distinction between the written explanation and the actual performance of the task. Computer code, by contrast, is both expression and the actual means by which a computer is induced to perform the desired function. It therefore would not be unnatural to describe computer code as a “method of operation” or “system.” Nor would it be unreasonable to conclude that, as between a book on bicycle-building and the actual construction of a bicycle, computer code is more analogous to the latter.

Again, the entire basis of this paragraph is arguing something no one is arguing against. Everyone agrees that computer code is copyrightable. What we're arguing is that APIs are not computer code -- because they're not. But because Verrilli and others can't seem to wrap their head around this, they just lump it all together. And the argument, based on this faulty premise continues:

The Copyright Act as a whole makes clear, however, that the functional character of computer code cannot be sufficient to bring it within Section 102(b). If that were so, no computer code would qualify for copyright protection;

This makes no sense. At all. Of course, computer code is copyrightable. But an API that is just a method of how to interact with that code is not computer code.

yet the Copyright Act unequivocally recognizes that a person can own a copyright in computer code.... Rather, the uncopyrightable “method of operation” or “system” or “process” is the underlying computer function triggered by the written code—for example, an algorithm that the computer executes to sort a data set. The code itself, however, is eligible for copyright protection.

Again, yes, of course the code is copyrightable. But the code is not the API. It's incredible how fundamentally the Solicitor General doesn't seem to grasp this simple concept.

When the filing eventually tries to get around to the difference between an API and software code itself, it basically just throws up its hands, saying "well, it looks like code, so it's all the same to us."

That distinction does not withstand scrutiny. Both declaring code and implementing code ultimately perform the same practical function: They instruct a computer to work. The declaring code tells the computer to call up the implementing code, and the implementing code tells the computer to perform an operation, such as executing a sorting algorithm. Both are necessary components of a Java or Android method. And neither the declaring code nor the implementing code is what a programmer physically types when invoking a method.

Yes, and the recipe and the ingredients are both "necessary components" of a meal, but that doesn't make them the same thing. Hell, to be more specific, the recipe and the description of how to prepare a meal are both necessary and they look fairly similar. But in copyright law the recipe is not copyrightable, while the description may be. That's the same thing with software code and APIs. But because the folks who wrote this brief are either ignorant -- or ridiculously chose to ignore those who do understand these things -- we get this absolutely embarrassing brief from the US government. It's a travesty.

Furthermore, Verrilli seems to be suggesting that the important Lotus v. Borland case which found that the layout of a computer program's menu structure were not covered by copyright, was decided incorrectly!

The precise rationale of Lotus is not clear. Parts of the opinion purport to rest on the proposition that Section 102(b) can foreclose copyright protection for original expression.... But other parts of the opinion seem to apply a principle analo-gous to the merger doctrine, to the effect that, be-cause there was only one menu hierarchy that would allow users to operate the spreadsheet program in substantially the same way, the menu hierarchy (un-like the underlying code) could not acquire copyright protection.... Whatever the rationale of Lotus, however, the decision cannot reasonably be read to treat Sec-tion 102(b) as applicable to computer code itself, a form of expression that the Copyright Act clearly protects and that the First Circuit took pains to distinguish.

Also very wrong, is Verrilli's repeated claim that these are issues that can be handled by a fair use analysis, rather than the question of whether or not API's are copyrightable at all:

Indeed, many of petitioner’s specific contentions will be relevant to its fair-use defense on remand. For example, although it would be anomalous to use Section 102(b) to distinguish between different segments of a single work of authorship..., Section 107(3) instructs courts to consider “the amount and substantiality of the portion [of a copyrighted work] used in relation to the copyrighted work as a whole” in adjudicating a fair-use defense. That petitioner copied only respondent’s declaring code while writing its own implementing code should therefore be a relevant factor in the lower courts’ fair-use analysis.

But this, too, is wrong. There's a big difference in saying "this is not copyrightable" and "this can be used thanks to fair use." Fair use is (unfortunately) limited and dependent on a number of factors. Something that is not covered by copyright is open to all comers. The difference is really important and the Solicitor General doesn't even care at all.

Unfortunately, the Supreme Court often follows the Solicitor General's advice on cases (though, not always). If it does so here, it would be a travesty and truly dangerous for innovation. As a ton of top computer experts (including now deputy CTO Felten) noted in their own brief (put together by the EFF), the lack of copyright in APIs has been a key element in defining the way the digital world works. To find otherwise would be a massive hit to basic innovation. As that brief explained

Today, open, uncopyrightable APIs continue to spur the creation and adoption of new technologies. When programmers can freely reimplement or reverse engineer an API without obtaining a costly license or risking a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to develop. Moreover, compatible APIs help enable people to switch platforms and services freely, and to find software that meets their needs regardless of what browser or operating system they use. Without the compatibility enabled by the open nature of APIs, consumers could be forced to leave their data and programs behind when they switch to a new service.

The freedom to reimplement APIs also helps developers rescue “orphan” software or data—systems that are no longer supported by their creators. When a company stops supporting a computer platform or service, the ability to freely reimplement APIs protects the communities that rely on that software. Government entities and non-profits are especially susceptible to the orphan programs problem as they often cannot afford to upgrade and are left using legacy technologies for years or decades.

It would be truly ridiculous that, just because the MPAA's former top lawyer is so ignorant that he can't comprehend the difference between an API and actual software, that the Supreme Court would allow such a terrible ruling as CAFC's to stand.

from the let's-try-this-again dept

Back in May, the appeals court for the Federal Circuit (CAFC) enhanced its reputation of consistently getting basic patent law wrong by deciding to get copyright law wrong too, in declaring that APIs were copyrightable subject matter, in the Oracle v. Google lawsuit. As we explained at the time, the court appeared to make some rather serious fundamental errors, not understanding the difference between software and interfaces (and worse, totally misquoting some experts). Last month, Google asked the Supreme Court to review the case. On Friday, a bunch of interesting amicus briefs were filed, asking the Supreme Court to fix the CAFC's big mistakes.

Perhaps the most interesting was put together by the EFF, and was signed by 77 computer scientists, including many of the most well-known and most respected computer scientists around, including Hal Abelson, Brian Behlendorf, Ward Cunningham, Peter Deutsch, David Dill, Dave Farber, Ed Felten, Mitch Kapor, Alan Kay, Brian Kernighan, Guido van Rossum, Avi Rubin, Bruce Schneier and Bjarne Stroustrup among others. There are a lot more, obviously, but those were just a few of the names that stood out.

The key point made in the filing is that this upsets decades of what was considered a settled matter in computer science, while highlighting how much of computer history was built off of the recognition of non-copyrightable APIs, allowing for the creation of interoperable systems, much of which drove the early computer revolution. Here's the summary from the brief:

For decades, computer scientists have relied on
the open nature of APIs to enable rapid innovation in
computer technology. For decades, circuit courts have
supported that reliance, concluding that Section 102(b) of
the Copyright Act protects a programmer’s source code
as creative expression, but does not cover the processes,
systems, and methods of operation that code may employ
to interface with other software. The district court
correctly followed that precedent and rejected Oracle’s
claim that the Java APIs could be copyrightable. Sadly, the
Federal Circuit chose to split with the other circuits and
reverse the district court. That decision upended decades
of industry practice and threatens the basic principles
upon which our technology sector was built.

Not surprisingly, the Federal Circuit’s decision has
been harshly criticized. As many commentators have
noted, if the Federal Circuit’s view had been accepted
at the birth of modern computing, many important
technologies would never have existed, and/or succeeded.
For example, the widespread availability of diverse, cheap,
and customizable personal computers owes its existence to
the lack of copyright on the specification for IBM’s Basic
Input/Output System (BIOS) for the PC. And open APIs
were essential to many modern computing developments,
including those of operating systems such as UNIX,
programming languages such as “C,” the Internet’s
network protocols, and cloud computing.

Today, open, uncopyrightable APIs continue to spur
the creation and adoption of new technologies. When
programmers can freely reimplement or reverse engineer
an API without obtaining a costly license or risking a
lawsuit, they can create compatible software that the
interface’s original creator might never have envisioned
or had the resources to develop. Moreover, compatible
APIs help enable people to switch platforms and services
freely, and to find software that meets their needs
regardless of what browser or operating system they use.
Without the compatibility enabled by the open nature of
APIs, consumers could be forced to leave their data and
programs behind when they switch to a new service.

The freedom to reimplement APIs also helps
developers rescue “orphan” software or data—systems
that are no longer supported by their creators. When
a company stops supporting a computer platform or
service, the ability to freely reimplement APIs protects
the communities that rely on that software. Government
entities and non-profi ts are especially susceptible to the
orphan programs problem as they often cannot afford to
upgrade and are left using legacy technologies for years
or decades.

Next up, is a filing from CCIA written in part by Jonathan Band, which is noteworthy in part because Band co-wrote the book on copyright and interfaces (first published nearly 20 years ago), explaining how interfaces aren't copyrightable and why that simple fact was responsible for so much of the computer revolution. This filing similarly notes how much of history was driven by interoperability, but also digs deeper into what a mess it would be if the CAFC's view was determined to be correct:

If a company could exercise proprietary
control over the interface specifications implemented
by its products, that company could determine which
products made by other firms – if any – would be
compatible with its software. And should that company
have a dominant position in a particular market, it
could use its control over compatibility to expand its
dominant position into adjacent markets. Moreover,
such authority would extend the rights under copyright
beyond what is necessary to protect the original
expressive elements that have traditionally been
offered protection under American copyright law, and
it would override limitations on copyright crafted to
protect the public good.

Such a broad monopoly would have serious
implications for consumer welfare. In the absence of
competition during the effective lifespan of the product,
the first developer would have little incentive to
develop more innovative and less costly products.
These negative consequences would be compounded
by the fact that the personal computer revolution and
the emergence of the Internet have produced an
overwhelming need for interconnection between
different elements of computer systems. Prohibiting
competitors from accessing de facto standard interface
specifications would lock users into a particular
operating system or network software environment,
and would inhibit the transfer of data between users
with different computing environments....
The Petition
shows a host of real-world problems and economic
harms that would result if API copyright could foreclose
compatibility, including the cost of rewriting
interface code formerly understood to be unprotected,
and lock-in costs resulting from consumers’ inability
to switch operating systems or cloud computing
providers.... Lock-in would deter competition, investment, and innovation in the
burgeoning cloud computing industry, which is known
to be sensitive to policy changes in copyright.

In short, in the computer industry, overly broad
intellectual property protection directly restricts
competition and innovation. This was the status quo
in the computing environment in the 1970s. Once a
buyer purchased a computer system, the buyer was
essentially locked-in to that system: the system was
incompatible with products manufactured by other
companies, and conversion costs were high. Although
“locking in” was extremely profitable for dominant
vendors such as IBM, competitors and users suffered
from high prices, indifferent service, limited choice,
and slow innovation.

CCIA also reminds the Supreme Court that Oracle (and Sun) not to long ago were among those who fought strongly for the position that interfaces were not copyrightable and that interoperability should be allowed. The filing notes that Sun and Oracle fought hard against parts of the DMCA when it was introduced that would have blocked interoperability. For example:

In a 1998 press release, Michael Morris, then Vice
President and General Counsel of Sun Microsystems, argued
that the DMCA as introduced would “impose[ ] a new and
unnecessary layer of restraint on lawful access to those unprotected
elements of computer programs that are necessary to
achieve interoperability, thus placing developers of interoperable
products at the mercy of proprietary vendors.”

That resulted in changes to the DMCA to make sure that interoperability was allowed. And yet, now, Oracle (via its Sun acquisition) is trying to argue that the exact opposite is true.

Finally, Public Knowledge also submitted an interesting brief which lays out the ridiculous situation we're in today with an analogy using amusingly named stand-ins and products:

Say that Delphi Corporation manufactures screws. It
hits upon a new design for a screw socket—the interface
between screw and screwdriver—that is more efficient
than the prevailing Phillips and flathead insertions. Capitalizing
on this novel idea, Delphi manufactures a line of
screws using this socket, which it calls Sumatra.
The Sumatra socket is wildly popular. New lines of
screwdrivers are made for the Sumatra socket. Engineering textbooks praise the Sumatra design. Wood-workers teach their sons and daughters to use it. And
competing screw manufacturer Zillion decides to make
its own screws compatible with the Sumatra socket. The
screws otherwise differ, but use the Sumatra socket so
that woodworkers need not purchase new tools.

Only then does Delphi declare the Sumatra socket a
sculptural work, suing Zillion for copyright infringement.

Rather than focusing on more recent rulings concerning software, the Public Knowledge brief goes all the way back to Baker v. Selden from 1879, which found that you couldn't copyright a set of blank ledger forms.

Oracle repeatedly points to the “intricate web of connections" of the Java API, in an effort to suggest that
its structure, sequence and organization of the API is
copyrightable. Oracle Brief, supra, at 26. But so too
can uncopyrightable blank forms constitute an intricate
web of connections. Selden’s book included 19 forms and
24 pages of demonstrative explanation designed “to compress almost innumerable accounts under a few specific,
intelligible heads.” .... For either blank forms or APIs, intricacy does not confer copyrightability.

Given that an API is factually on par with a blank
form, it is unsurprising that the reasoning of Baker directly applies to the copyrightability of APIs. Baker held
that blank ledger forms, including the “ruled lines and
headings,” could not properly be the subject of copyright.... The Court said that copyright cannot
cover “systems” or an “art”; the Java API is certainly a
system, one that teaches the “art” of using the Java system....

The Java API is on all fours with the blank forms
of Baker, both factually and legally. Since copying of
the blank forms in Baker was permissible, copying of
the Java API is too.

It's also nice to see the Public Knowledge brief call out the simple factual errors in the CAFC ruling (some of which we pointed out in our post at the time):

... the Federal Circuit misunderstands arguments that interfaces
are more properly protected by patent law than copyright law... Google,
several amici below, and the district court merely proffered the unremarkable argument that functional elements should be excluded from copyright law by § 102(b) and the idea/expression dichotomy... But the Federal Circuit mistook them to mean that software may only be
patentable or copyrightable, but not both. The Federal Circuit further assumed that criticisms of
software patents equate to suggestions to expand copyrightable subject matter to cover interfaces.

These propositions are flawed. First, the Federal Circuit t neglects that there is matter outside the realm of both
copyright and patent; the court apparently supposed that
every element of a software program must fit into one or
the other. Second, the Federal Circuit fails to differentiate the discrete elements of a given software product that
may be copyrightable and those that may be patentable,
instead lumping those elements together into a single entity. Third, the Federal Circuit conflates programming
interfaces with computer programs generally.

Hopefully, these and other arguments convince the Supreme Court of just how wrong the CAFC was in its ruling. Recently, the Supreme Court has been pretty bad on copyright cases, while generally good on patent cases, so it's always a little nerve-wracking when copyright cases get there. The one bit of good news is that the Supreme Court has clearly found itself regularly questioning CAFC's interpretation of laws, since most of those patent cases come up via CAFC. The only reason this copyright case went to CAFC was because it started out as a patent case, though the patent issues got tossed out early on.