Top Oracle Lawyer Attempting To Gaslight Entire Software Community: Insists APIs Are Executable

from the oh-come-on dept

Last week, the Solicitor General of the White House weighed in on Google's request for the Supreme Court to overturn the Federal Circuit's ridiculously confused ruling in the Oracle/Google case concerning the copyrightability of APIs (and whether or not repurposing them is fair use). Not surprisingly, as the Solicitor General has been siding with Oracle all along, it suggests that the Supreme Court not hear the case. Of course, it does so by completely misrepresenting what's at stake in the case -- pretending that this is about whether or not software source code is copyright-eligible:

This case concerns the copyrightability of computer code. To induce a computer to perform a function, a person must give the computer written instructions. Typically, those instructions are written in “source code,” which consists of words, numbers, and symbols in a particular “programming language,” which has its own syntax and semantics. The source code is then converted into binary “object code”—ones and zeros—that is readable by the computer.

It is both “firmly established” and undisputed in this case that computer code can be copyrightable as a “literary work[].” 1 Melville B. Nimmer & David Nimmer, Nimmer on Copyright § 2A.10[B] (2019). Section 101 defines a “computer program” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” 17 U.S.C. 101. And various Copyright Act provisions recognize that a person may own a copyright in a “computer program.”

Except... that's not what this case is about. Even remotely. Literally no one denies that software source code is subject to copyright. The question is whether or not an Application Programming Interface -- an API -- is subject to copyright. As we've been saying from the beginning, the most frustrating thing about this entire case is that you have non-technically savvy lawyers and judges simply refusing to comprehend that an API is not software. It's not executable code. It's not "source code" for software. An API is a set of specifications for allowing the access of data, an application, or service. It's a "method of operation," which is simply not subject to copyright law. Indeed, back in 1996, the Supreme Court ruled in Lotus v. Borland that a user interface to a computer program is not subject to copyright under Section 102(b) as the interface is a "method of operation."

In the Solicitor General's brief, they wipe this away by insisting that the ruling in Lotus v. Borland is different because that was about an interface, whereas this case is about source code.

The Federal Circuit’s construction of Section 102(b) in this case does not conflict with those decisions. See 14-410 U.S. Br. 19-22. In Lotus, the First Circuit invoked Section 102(b) to find that the arrangement of menu commands presented to a software user was an uncopyrightable “‘method of operation’” for the software at issue. 49 F.3d at 815-818. The case did not address the copyrightability of computer code, and the First Circuit has subsequently acknowledged, consistent with the decision below, that Section 102(b) codifies the idea/expression dichotomy.

Right. But this case also does "not address the copyrightability of computer code." Because it's not about computer code.

While it's no surprise that the Solicitor General has now gotten this wrong, what was a little surprising was that Oracle's lead lawyer in this case, spent half the weekend acting like a common Twitter troll, gaslighting the entire software community on Twitter, making repeatedly false claims about APIs, and then attacking anyone who pointed out that she's flat out wrong by accusing them of being Google shills.

Annette Hurst, prior to this nonsense, was fairly widely respected intellectual property lawyer and a big time partner at Orrick, one of the largest law firms in the world. She's been involved in some big copyright cases in the past, such as the famed Mattel v. MGA case (she was on the right side of that one) and also in the important Kirtsaeng case in which she again represented the correct side.

However, when it comes to the Oracle case, she seems to jump in to argue things that are blatantly ignorant of how software actually works. You may recall, after the jury in the district court found that Google's use of the Java APIs were fair use, she laughably insisted that it would kill open source software because it meant software source code couldn't be opened up any more. Except, once again, she was totally confusing an API with executable software code.

Years on, and she's still not just confused, but actively misrepresenting things. Famed and well-respected litigator and law professor Mark Lemley called out the Solicitor General's "indefensible" statement that Lotus v. Borland does not conflict with this ruling, and Hurst responded dismissively:

But, again, she's focusing on the wrong thing. "Software is protected by copyright." Well, duh. No one disagrees. This case is not about that. It's about whether or not an API is protected by copyright. But Hurst keeps conflating executable software code and APIs. And while expert after expert called her out on this on Twitter, she just kept digging in deeper, variously calling any critic a Google shill or, perhaps worse, insisting that APIs are executable code.

This is not just wrong, it's head-slappingly, stupidly wrong. And every single reply to Hurst are people telling her it's wrong in so many different ways.

As more and more people called out this nonsense, literally her only claim was to argue that anyone taking the other side must have been funded by Google.

What's doubly ironic here is that the link she puts in that post, is to a shadowy non-profit whose only role in life is to write up laughingly misleading reports accusing tons of people of being Google shills based on shoddy (to downright incorrect) research. It has been forced to run multiple corrections to its bad reporting. And, the best part is: for an organization that claims its sole purpose is to shine a light on what it claims is Google's secret funding... the Google Transparency Project refuses to name a single one of its own donors. Though, there is one who has taken credit: Oracle. The very company which has probably paid Hurst's employer enough money for her to buy a few very nice homes just on this case alone.

Hurst may be a great copyright lawyer, but she doesn't know shit about what an API is, and, incredibly and unfortunately, has convinced the Federal Circuit that an API is no different than software. She may succeed in convincing the Supreme Court that as well, as she's apparently convinced the Solicitor General. None of that makes it right however. And her going around parading her ignorance and attacking those who actually know what the fuck they're talking about concerning the difference between an API and executable code is a disgrace.

This is not something that one can just say it's a difference of opinions over. We can disagree over whether or not APIs should be covered by copyright. That's an opinion. We can disagree over whether or not Google's copying of an API should be considered fair use. We can disagree over what we think the state of copyright should be. But what no one can deny is that an API is not executable code. And yet, Hurst continues to argue it and (ridiculously) has convinced some courts of this blatantly incorrect thing, which is helping her client get the opinions it wants on the other things above. And that's despicable.

Filed Under: annette hurst, apis, cafc, copyright, interfaces, methods of operation, software, solicitor general, source code, supreme court
Companies: google, oracle

Supreme Court Asks White House To Weigh In On Copyrightability Of APIs

from the anyone-confident-that-this-white-house-understands-the-issue? dept

Back during an earlier round of the never-ending legal dispute between Oracle and Google concerning whether or not APIs can be covered by copyright the Supreme Court requested that the White House weigh in on its opinion -- leading then Solicitor General Donald Verrilli (formerly a top lawyer for the MPAA) to weigh in with what we argued was a painfully clueless brief. The underlying issue here, from the very beginning, revolves almost entirely around the simple point: do you actually understand what an API is? If you do -- and recognize that it's fundamentally different from executing software code -- then this is an easy case. An API is simply an instruction set -- a recipe of sorts -- for being able to interface with a particular program. And US copyright law is clear that copyright cannot apply to any "idea, procedure, process, system, method of operation, concept, principle, or discovery."

An API is easily covered by that designation, but because you have non-technical lawyers who can't understand the difference between software operating code (which is copyrightable) and an API (which is not) they argue that the two are virtually identical, and thus APIs should be covered by copyright. Tragically, that argument worked at the appeals court (it didn't work at the district court, where Judge Alsup already had some coding history and famously taught himself how to program in Java to better understand the facts of the case).

Now that the case is back on appeal to the Supreme Court, looking specifically at questions of fair use around the reuse of an API, the Supreme Court has (somewhat oddly) asked the White House to weigh in again. As part of its Monday orders it invited the White House to give its opinion on whether or not it should even hear the case (not yet on the actual merits of either side's case):

The Solicitor General is invited to file a brief in this case expressing the views of the United States.

Of course, there's a very different White House with a very different Solicitor General. Of course, I have no idea if the current Solicitor General's office knows anything about coding or knows why an API is not operating code, and it seems like a total crapshoot to expect the Solicitor General to have an informed opinion on this matter. So it's not entirely clear why the Supreme Court expects it will -- but now that it's asked, we should probably expect something from the White House on this issue. As has been noted in the past, when the Supreme Court does ask the Solicitor General to weigh in, it often has an impact on the case -- especially when the question is simply on whether or not the Supreme Court should hear the case in the first place. Given that, one hopes that the Solicitor General will support the petition to hear the case and revisit the CAFC's ongoing confusion over copyright law.

Filed Under: apis, copyright, interfaces, software, solicitor general, supreme court
Companies: google, oracle

Insanity Wins As Appeals Court Overturns Google's Fair Use Victory For Java APIs

from the this-is-bad dept

Oh, CAFC. The Court of Appeals for the Federal Circuit has spent decades fucking up patent law, and now they're doing their damndest to fuck up copyright law as well. In case you'd forgotten, the big case between Oracle and Google over whether or not Google infringed on Oracle's copyrights is still going on -- and it appears it will still be going on for quite a while longer, as CAFC this morning came down with a laughably stupid opinion, overturning the district court's jury verdict, which had said that Google's use of a few parts of Java's API was protected by fair use. That jury verdict was kind of silly in the first place, because the whole trial (the second one in the case) made little sense, as basically everyone outside of Oracle and the CAFC had previously understood (correctly) that APIs are simply not covered by copyright.

Section 102(b) of the Copyright Act says quite clearly:

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.

And an API is pretty clearly a procedure, process, system or method of operation -- it's just instructions on how to access certain elements, similar to a recipe. But, CAFC (who shouldn't be hearing this case in the first place) simply couldn't be bothered to comprehend what an API is, and insisted that because to the judges non-technical brains, an API looks the same as software, it must be copyrightable as software. That was after Judge Alsup in the district court (following trial #1) had spent quite a lot of time explaining to CAFC why APIs are not copyrightable.

Thus, we had the second trial, which was weird, because all of the arguments about fair use, were couched in this weird "um, well, it's not really copyrightable at all, but CAFC says it's copyrightable, so let's just say it's fair use" argument. And the jury then said, yes, it's fair use.

But CAFC has now rejected that and sent the case back to the lower court for a third trial for damages. And, while we normally expect bad reasoning from CAFC decisions, this one is particularly stupid. In short, CAFC's reasoning is basically "we think this is infringement, and thus we're going to handwave around the law to make sure that it's infringement." It's bad. And, again, CAFC shouldn't even be hearing the case. CAFC hears appeals on patent cases, and originally there were a few patent claims in this case, but they all got dumped at a very early stage. So this case should have gone to the 9th Circuit (who also might have messed it up, but it has at least a marginally better record than CAFC).

Anyway, the CAFC does an awful lot of handwaving around historical precedent to justify its decision to basically start from scratch in going through the fair use four factors. As we've discussed multiple times, one of the problems with the four factors test is that it allows a court to choose who it likes better, and then twist the four factors to give it the outcome it wants. That appears to be what is happening here. On the first factor (nature of the use), CAFC basically says "we think the jury is stupid, this is obviously commercial use, and thus it goes against Google." Google had argued (and the jury had implicitly agreed) that because Google doesn't charge for Android, and interoperability and progress of innovation enabled by using similar API setups are not inherently commercial motives, that this was fair use. The court basically says "but Google has so much money!" which is not how a fair use argument works. But... CAFC.

That Google might also have non-commercial motives is irrelevant as a matter of law. As the Supreme Court made clear when The Nation magazine published excerpts from Harper & Row’s book, partly for the purpose of providing the public newsworthy information, the question “is not whether the sole motive of the use is monetary gain but whether the user stands to profit from exploitation of the copyrighted material without paying the customary price.” Harper & Row, 471 U.S. at 562. Second, although Google maintains that its revenue flows from advertisements, not from Android, commerciality does not depend on how Google earns its money. Indeed, “[d]irect economic benefit is not required to demonstrate a commercial use.” A&M Records, 239 F.3d at 1015. We find, therefore, that, to the extent we must assume the jury found Google’s use of the API packages to be anything other than overwhelmingly commercial, that conclusion finds no substantial evidentiary support in the record. Accordingly, Google’s commercial use of the API packages weighs against a finding of fair use.

On the question of transformative use, the lower court had suggested that using the APIs in a "fresh context" (such as for smartphones) could be seen as transformative. But, again CAFC says "nope."

Google’s arguments are without merit. As explained below, Google’s use of the API packages is not transformative as a matter of law because: (1) it does not fit within the uses listed in the preamble to § 107; (2) the purpose of the API packages in Android is the same as the purpose of the packages in the Java platform; (3) Google made no alteration to the expressive content or message of the copyrighted material; and (4) smartphones were not a new context.

CAFC also, once again, shows that it still doesn't understand why APIs and code are not the same thing:

That Google wrote its own implementing code is irrelevant to the question of whether use of the APIs was transformative. As we noted in the prior appeal, “no plagiarist can excuse the wrong by showing how much of his work he did not pirate.” Oracle, 750 F.3d at 1375 (quoting Harper & Row, 471 U.S. at 565). The relevant question is whether Google altered “the expressive content or message of the original work” that it copied—not whether it rewrote the portions it did not copy.

But that's not the relevant question. The relevant question is how the copied text is being used, and in Google's case it's in a completely different context, which is why it had to write its own implementing code. Again, this is fallout from CAFC's earlier wrong decision in that it still does not understand that API instructions are not the same as implementing code itself.

The court also more or less laughs at the idea that Google had "good faith" reasons for doing what it did:

Ultimately, we find that, even assuming the jury was unpersuaded that Google acted in bad faith, the highly commercial and non-transformative nature of the use strongly support the conclusion that the first factor weighs against a finding of fair use.

On factor two of the four factors analysis -- the nature of the work -- CAFC again actually gives that one to Google and says that the jury could have found that weighed towards fair use, but immediately points out that it's going to give this factor less weight, because... it still doesn't understand the difference between APIs and software, and insists that if it gave this factor any weight, it would destroy the idea of copyright for software. Of course, that's only true if you can't tell the difference between an API and software.

We note, moreover, that allowing this one factor to dictate a conclusion of fair use in all cases involving copying of software could effectively negate Congress’s express declaration—continuing unchanged for some forty years—that software is copyrightable. Accordingly, though the jury’s assumed view of the nature of the copyrighted work weighs in favor of finding fair use, it has less significance to the overall analysis.

On factor three, concerning the amount use, the court again is so incredibly confused it's frustrating. Google has long held (and the jury and the lower court appeared to agree) that it used the bare minimum of the Java API to enable basic interoperability in building apps for Android. But CAFC is so tied up in its own made up reality, that it insists no reasonable jury could agree with this:

Even assuming the jury accepted Google’s argument that it copied only a small portion of Java, no reasonable jury could conclude that what was copied was qualitatively insignificant, particularly when the material copied was important to the creation of the Android platform.

Eventually, though CAFC says factor 3 could be either "neutral" or "arguably weighs against" fair use.

On to factor four -- the impact on the market. Factors one and four tend to be the ones that courts focus on the most. And, here, Oracle has spent plenty of time whining that its own total failure to capitalize on Java in the mobile market should be blamed on Google's copying piece of its API as opposed to the reality, which is that Oracle completely botched its own efforts in the space, because it's Oracle. The court more or less ignores various points about how Oracle wasn't really in the mobile market and more or less says "Google was super successful, so clearly it was at the expense of Oracle."

Given the record evidence of actual and potential harm, we conclude that “unrestricted and widespread conduct of the sort engaged in by” Google would result in “a substantially adverse impact on the potential market for the original” and its derivatives.

And, thus, the court then weighs factors one and four most heavily, and says it's not fair use, and back to Northern California we go for trial number three, specifically on the damages question. I imagine Google will appeal this, either asking for an en banc rehearing or to the Supreme Court. The Supreme Court refused to hear the previous request on the question of copyrightability of APIs, so this is probably a long shot. However, there are a few oddities within the ruling that maybe will catch someone's attention at the Supreme Court (and the Supreme Court has spent years dunking on CAFC and mocking its dumb decisions, so maybe they'd like to do that again).

Honestly, the most concerning part of the whole thing is how much of a mess CAFC has made of the whole process. The court ruled correctly originally that APIs are not subject to copyright. CAFC threw that out and ordered the court to have a jury determine the fair use question. The jury found it to be fair use, and even though CAFC had ordered the issue be heard by a jury, it now says "meh, we disagree with the jury." That's... bizarre.

Anyway, considering the importance of interoperability in software, this case is yet another potential disaster, limited only by the fact that CAFC doesn't cover any particular region and most copyright cases aren't influenced by CAFC precedent since those cases would flow up through the other appeals courts. However, you can see how someone wishing to go after others for API infringement might just throw in a silly patent claim just get it into CAFC. Hopefully the Supreme Court steps in and fixes this, but if not, it would be nice (I know, I know...) if Congress actually stepped up and pointed out that APIs are not covered by copyright at all. And while they're at it, they should burn CAFC to the ground. It was a dumb idea in the first place and should be shut down.

Filed Under: api, apis, cafc, copyright, fair use, interfaces, interoperability, programming
Companies: google, oracle

Software Copyright Litigation After Oracle v. Google

from the still-a-mess dept

Many observers, including me, predicted that the 2014 decision of the U.S. Court of Appeals for the Federal Circuit (“CAFC”) in Oracle America v. Google would provoke a new wave of litigation concerning copyright and interoperability. In particular, we worried that the decision would encourage dominant vendors to bring copyright claims against competitors that replicated interface specifications for the purpose of interoperating with the dominant vendors’ products. We were right.

Sure enough, Oracle America has factored into at least four cases so far. One of these cases settled, one is on appeal, and the other two likely will be appealed in the near future. The latter two cases also involve patent claims, so appeals will be heard by the CAFC. (The CAFC has nearly exclusive appellate jurisdiction over cases with patent claims.) One can assume that the plaintiffs added the patent claims to ensure CAFC jurisdiction.

GDC v. Dolby Laboratories

This is the case that settled. Dolby Laboratories provides advanced motion picture theatre sound systems. GDC Technology develops software and hardware that interoperates with the Dolby systems. Dolby facilitated this interoperability by making its interface specifications available to GDC. It appears that Dolby stopped providing this information after it acquired Doremi, a media server manufacturer. Evidently, this acquisition made GDC a more direct competitor. Emboldened by the CAFC’s Oracle America decision, Dolby demanded that GDC stop using Dolby interface specifications to interoperate with Dolby products. Furthermore, Dolby insisted that GDC cease telling customers that GDC had the right to use this interfaces information to interoperate with Dolby products.

Dolby’s conduct prompted GDC in April 2016 to bring a declaratory judgment action in federal court in California against Dolby Laboratories seeking a declaration that Dolby does not own a copyright in the “protocols and interconnection codes” Dolby developed for digital cinema systems. In the alternative, GDC sought a declaration that fair use permitted it to use the specifications for the purpose of achieving interoperability. The parties settled the dispute in November 2016. According to the joint press release, “as part of the resolution, GDC will dismiss its lawsuit against Dolby, and GDC and Dolby will grant each other licenses that will allow their respective theater management systems to interoperate with the other party’s digital cinema servers.” The other terms of the settlement agreement were not made public.

SAS Institute v. World Programming

This case currently is on appeal to the Fourth Circuit, and has the most complex procedural history. The district court ruled that the input and output formats the defendant copied were not protectable under copyright, but found that the defendant breached license restrictions on reverse engineering. A jury subsequently assessed damages of $26 million, which the court then trebled to $79 million under North Carolina’s unfair trade statute.

SAS, a company based in North Carolina, creates an integrated suite of business software products known as the SAS System. The SAS System allows users to perform a variety of data access, management, analysis, and presentation tasks. The SAS System can run on various kinds of computers ranging from PCs to mainframes. Users can perform tasks on the SAS System by writing programs in the SAS Language. Additionally, SAS developed a version of the SAS System called SAS Learning Edition to help users learn how to program in the SAS Language.

World Programming Limited (“WPL”), a U.K. company, developed World Programming System (“WPS”), which can run SAS Language programs and produce similar outputs. Thus, WPL provides users with a competing platform on which they can run the programs they have written in the SAS Language, thereby avoiding being locked-in to the SAS environment.

To develop WPS, WPL reverse engineered copies of the SAS Learning Edition. However, the license under which WPL obtained SAS Learning Edition prohibited reverse engineering of the software. It appears that WPL’s development activities occurred in the U.K., but it distributed its software in the United States.

SAS sued WPL in the U.K. in 2009 and in the U.S. in 2010. The U.K. case proceeded more quickly. The U.K. High Court requested guidance from the highest court in the European Union, the Court of Justice of the European Union (“CJEU”), on whether software functionality, programming languages, and data formats were protectable under the EU Software Directive. The CJEU ruled in 2012 that these elements were not protectable. On the basis of this ruling, the U.K. court entered final judgment for WPL in 2013.

In April 2014, WPL moved for summary judgment in the U.S. action in North Carolina, arguing that the U.K. judgment had preclusive effect on many issues under theories of comity and collateral estoppel. In other words, WPL argued that SAS couldn’t re-litigate in the United States what it had already lost in Europe.

The district court ruled on the summary judgment motion in October 2014. The district court held that it was not bound by the U.K. court’s conclusion that the EU Software Directive rendered unenforceable the SAS Learning Edition license terms restricting reverse engineering. This is because the district court found that North Carolina law differed significantly from EU law on the question of the validity of the contractual provisions prohibiting reverse engineering. Thus, the district court granted summary judgment to SAS on its breach of contract claim.

With respect to SAS’s copyright infringement claim, the district court refused to give preclusive effect to the U.K court’s ruling that copyright did not protect the program elements WPL copied on the ground that WPL failed to demonstrate the similarity of U.S. and U.K. law on this issue. This is a questionable ruling. The U.K. court and the CJEU based their decisions on the Software Directive’s articulation of the idea/expression dichotomy. The idea/expression dichotomy is a fundamental principle of copyright law worldwide, including U.S. copyright law. Therefore, there is no reason to conclude that a program element the CJEU considers to be unprotectable under Article 1(2) of the Software Directive also is not protectable under section 102(b) of the U.S. Copyright Act.

Despite refusing to grant preclusive effect to the U.K. court’s determination that WPL’s copying did not infringe, the district court ultimately reached the same conclusion based on its own analysis of U.S. copyright law. It was undisputed that WPL had no access to SAS’s source code, and thus WPL did not copy any SAS code, nor the structure, sequence, and organization of that code. Instead, SAS based its copyright claim on WPL’s copying of the SAS System’s input and output formats. The district court rejected the claim, reasoning that SAS in essence was “asking the court to find that defendant’s software infringes its copyright through its processing of elements of the SAS Language….” This meant that “plaintiff seeks to copyright the idea of a program which interprets and compiles the SAS Language….” The court refused to allow such broad protection.

SAS resisted the conclusion that WPL did not copy protected expression by arguing that “this case is on all fours” with Oracle America. The court rejected this argument. The court noted that in Oracle America, Google had copied strings of Java code. Here, by contrast, “there is no evidence that defendant has copied specific strings of SAS language, or specific strings of source code for plaintiff’s software, only that its software can function with these SAS Language elements.”

A trial was held on damages for WPL’s breach of the SAS Learning Edition license; fraudulent inducement in obtaining the Learning Edition; and violation of North Carolina’s Unfair and Deceptive Trade Practices Act (“UDTPA”). In 2015, the jury found SAS was damaged by WPL’s breach of the license in the amount of $26 million; WPL fraudulently induced SAS to enter into the license agreement; and WPL’s conduct violated the UDTPA. On account of the violation of the UDTPA, the district court trebled the actual damages to a total of $79 million.

WPL and SAS cross-appealed. Because SAS did not bring any patent infringement claims, the appeal will be heard by the Fourth Circuit rather than the CAFC. SAS and its amici, Mathworks and the Business Software Alliance, have recently filed briefs. In their briefs, SAS and its amici completely ignore what the copyright aspect of this case is really about: whether copyright enables SAS to lock its users into the SAS System after they have invested millions of dollars writing their own programs in the SAS Language.

Synopsys v. ATopTech

In our third case following Oracle America, a jury in California found that the defendant infringed the command set in the plaintiff’s software. Because the case also involves patent claims, the CAFC will hear the appeal of this dispute as well.

Both Synopsys and ATopTech develop software for the “place-and-route” function in the design of computer chips, i.e., software that plans the layout of a chip and the electrical connections among its various components. Synopsys also produces “sign-off” or “static timing analysis” software, which checks the timing of the chip design created by the place-and-route software.

Synopsys claimed in federal court in California that ATopTech had copied into ATopTech’s place-and-route product, Aprisa, part of the command set from Synopsys’s sign-off product, PrimeTime. Command sets include the names and syntax of commands, options, parameters, variables, objects, and attributes. ATopTech filed a motion for summary judgment that it did not copy protectable expression, but the court in a terse ruling found that Synopsys “raised a triable issue” as to whether the copied elements were expressive. Similarly, the court found there were triable issues relating to ATopTech’s merger and fair use defenses. After trial in March 2016, the jury found that ATopTech infringed Synopsys’s copyright in its command set, and awarded Synopsys $30 million in damages.

The court then conducted a bench trial on ATopTech’s equitable estoppel defense. ATopTech argued that Synopsys encouraged its usage of the command set “in order to meet customer demand for improved interoperability between place-and-route and sign-off products when the two types of products are offered by different vendors.” The court denied the defense, finding that there was no evidence that Synopsys had actual or constructive knowledge that ATopTech had copied the command set. The court also rejected ATopTech’s assertion that Synopsys by its conduct misled ATopTech to believe that it would not assert its copyright in its command set.

As noted above, Synopsys brought patent infringement claims against ATopTech in addition to its copyright claims. This means that any appeal in this case will also be heard by the CAFC.

Cisco v. Arista

In our last post-Oracle America case, a jury in California recently found that the Cisco command line interfaces copied by Arista were not protected by copyright under the scenes a faire doctrine. Because Cisco also brought patent claims against Arista, the CAFC will hear this appeal as well.

Arista Networks develops switches and other network products that compete with the market leader, Cisco Systems. In 2014, after the CAFC’s decision in Oracle America, Cisco sued Arista for allegedly copying 500 of Cisco’s command line interface (CLI) commands when developing its EOS network operating system. The CLI is the primary mechanism for network engineers to interact with switches and routers in which Cisco operating systems are installed. The 500 commands consist of two, three, or four words reflecting multi-level textual hierarchies. Before trial, the district court ruled that four “building blocks” of the CLI (the multiword command line expressions, modes and prompts, command responses, and help descriptions) could be protected as a compilation, and left it to the jury to consider whether merger or scenes a faire rendered Arista’s copying noninfringing. The court further ruled that because the individual elements of each of these building blocks were not protectable, the compilations were entitled only to thin protection. Under Ninth Circuit precedent, this meant that infringement could be found only if there was virtually identical copying.

At trial, Arista’s lawyers -- who also represented Google in its litigation with Oracle America -- argued that the CLI was an industry standard Cisco encouraged others to use. Arista raised three defenses: merger, scenes a faire, and fair use. In December 2016, the jury rejected the merger and fair use defenses, but agreed that Arista’s use did not infringe under the scenes a faire doctrine. Under the scenes a faire doctrine, courts deny protection to expression that is standard, stock or common to a particular topic or that necessarily follow from a common theme or setting. Granting copyright protection to the necessary incidents of an idea would effectively afford a monopoly to the first programmer to express those ideas.

As noted above, any appeals in the case will be heard by the CAFC because Cisco’s complaint also alleged patent infringement (a claim the jury rejected).

Of the three cases that did not settle, two will be appealed to the CAFC. Given the random nature of judicial assignments, there is a good chance these appeals will be heard by different panels from that in Oracle America. Hopefully these panels will not feel too constrained by the Oracle America opinion. After all, CAFC panels often disagree with one another in patent cases.

(These cases, and the Oracle America decision, are discussed in greater detail in my book Interfaces on Trial 3.0: Oracle America v. Google and Beyond.)

Republished from the Disruptive Competition Project

Filed Under: apis, copyright, interfaces, lawsuits, patents
Companies: google, oracle

Command Line Interface Copyright Case: Not Fair Use... But Not Infringing Thanks To Scenes A Faire

from the we-didn't-put-the-accents-in-the-title,-since-they-break-some-rss-readers dept

While the Oracle/Google case tends to get most of the attention when people talk about the copyrighting of interfaces, there was another big "interfaces on trial" case that just completed between Cisco and Arista Networks. Cisco insisted that Arista was infringing on its Command Line Interface (CLI) by using some of the same commands that Cisco equipment used. Arista responded by pointing out that a command line interface is hardly unique, and Cisco itself had been pushing the command line interface as an industry standard, and also that this whole lawsuit was just silly (they didn't quite put it in those terms, but...). Like the Oracle/Google case, this one had a patent issue attached at the hip, which got tossed off early on. That matters, because it means that the inevitable appeal will go up through CAFC, the appeals court that specializes in mucking up patent law. CAFC infamously took its "mucking up patent" skills to copyright law a few years back, in the Oracle/Google case when it decided that APIs were copyright-eligible subject matter, upending years of common wisdom, legal precedent and the clear text of the Copyright Act about interfaces.

Of course, in the Oracle/Google case, after CAFC's disastrous decision, Google still came out ahead (so far) when a jury decided that its copying of the APIs was "fair use." In the Cisco/Arista case that just concluded, the jury went in a slightly different direction. It rejected the fair use argument, but still said the work wasn't infringing, because of the scènes à faire doctrine, which is one of those few copyright legal doctrines experts will throw in (along with "de minimis" when reminding people that fair use is not the only exception to copyright). The basis of scènes à faire is that it's something within the work where there are only a very small number of ways to do something, and thus, it's quite likely that multiple parties will do the same thing, meaning that any copyright will be greatly limited. Scènes à faire is French for "scenes that must be done."

In other words, the jury more or less said that using the command line interface was so basic to the operation of this kind of equipment, that it would be ridiculous to expect each vendor to come up with something different. Unfortunately, the jury didn't see the use as fair use, which Cisco has already jumped on as a sort of moral victory, but one that may come up later, if Cisco can successfully overturn the ruling on scènes à faire. Of course, if this case weren't forced to go through CAFC on appeal, it would have been nice to have been able to challenge the question of whether or not there's any copyright on Cisco's CLI at all, but thanks to CAFC's failure to comprehend that an interface is different than software, this is where we are. I fully expect that CAFC will somehow muck up this case too on appeal, but hope to be pleasantly surprised.

Filed Under: cafc, command line interface, copyright, fair use, interfaces, scenes a faire
Companies: arista networks, cisco

Computer Scientists, Legal Experts Explain To Supreme Court Why APIs Are Not Copyrightable

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.

Filed Under: api, apis, computer scientists, copyright, copyrightable subject matter, functions, interfaces, software
Companies: ccia, eff, google, oracle, public knowledge

HP And RIM Produce Similar Device... Don't Freak Out

from the man-bites-dog? dept

ChurchHatesTucker points us to a recent story about how RIM's Playbook tablet device and interface looks incredibly similar to HP's TouchPad tablet device interface (using WebOS), but rather than get all freaked out about "copying," the two companies seem to handle this maturely, noting that it's just the nature of innovation. HP's initial response more or less suggests that RIM copied HP, but uses it as an opportunity to position itself as a leader in the space, rather than a follower:

From HP:

"It's a fast innovation cycle and a fast imitation cycle in this market, so we just know that we have the creative engine here to continue to build on what we have, and we'll keep innovating, we'll keep honing and those guys hopefully will continue to see the value in it and keep following us by about a year."

RIM (Blackberry) responds.

"Well, when you�re trying to optimize user experience that juggles multitasking, multiple apps open at once and on a small screen, you�re going to get people landing on similar kinds of designs."

Notice no legal threats. No claims of intellectual property violations. Some might claim this is a "non-story," but in an age when the default so often seems to break out the lawyers, cease-and-desists and threats (if not outright lawsuits), it's nice to see a response like this. In some ways it's more of a story, since it seems so rare.

Filed Under: competition, copying, innovation, interfaces, tablets
Companies: hp, rim