Supreme Court Asked To Make It Clear That APIs Are Not Copyrightable

from the fingers-crossed dept

Thu, Oct 9th 2014 3:50pm — Mike Masnick

Back in May, the Court of Appeals for the Federal Circuit (CAFC), long famous for messing up patent law, decided to take a short break and mess up copyright law as well, by declaring APIs copyrightable (the case ended up before CAFC instead of the 9th Circuit because it originated as a patent case, even though all the patent issues were gone). The district court had ruled otherwise, and that judge, William Alsup, had actually gone into great detail to explain why copyright shouldn't apply to APIs. Alsup had learned to code Java to better understand the case, and you could basically tell from his ruling that he was quite worried that appeals court judges wouldn't take the time to truly understand the issues at play. He was right. Making APIs copyrightable is bad news for innovation in a variety of ways.

But, of course, CAFC is not the final stop in the line (even if some patent trolls wish it were). As was fully expected, Google has now asked the Supreme Court to hear an appeal on the case. Google's petition is a good read highlighting the "disarray" in the various different circuits about whether or not copyright law applies to APIs. The law itself (Section 102(b)) is pretty explicit: "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." Many of us clearly think that APIs fit under this as a system or method of operation. But, others disagree.

Some courts follow the statute’s plain meaning, holding that Section 102(b) precludes copyright protection for all systems or methods of operation, including those in computer programs. See, e.g., Lotus, 49 F.3d at 815. Like the Federal Circuit, however, other courts have rejected the statutory text and held that Section 102(b) is merely a reminder of the dichotomy between ideas (which are not copyrightable) and expressions of ideas (which generally are). See, e.g., Whelan Assocs., Inc. v. Jaslow Dental Lab., Inc., 797 F.2d 1222, 1234 (3d Cir. 1986). In those courts’ view, a “method of operation” embodied in a computer program is copyrightable so long as its creator could have designed it in different ways.

Having shown the circuit split to help entice the Supreme Court to hear the case, Google then explains why it's simply wrong to interpret the law to say that APIs are covered by copyright.

The Federal Circuit’s error is confirmed by the extent to which it would eliminate a fundamental distinction between patent and copyright law—and thus allow copyright to be used as an end-run around the limits on patent protection, including this Court’s recent decisions on patent-eligibility.

Basically, you may be able to patent a system and method (as many patents themselves note in their titles), but it shouldn't be copyrightable.

While the Supreme Court has a history of being pretty bad on copyright law, it has been pretty good (especially lately) on patent law -- in particular smacking down CAFC -- and the Google filing plays up to that fact, arguing that this is just another case of CAFC interpreting the law incorrectly.

The Federal Circuit’s error is all the more glaring because it is essentially the same error for which this Court has repeatedly reversed the Federal Circuit in patent cases. The court of appeals criticized the district court for confusing “the threshold question of what is copyrightable—which presents a low bar—and the scope of conduct that constitutes infringing activity.” App. 17. It then transformed Section 102(b)’s limits on copyright eligibility into just one of several factors to be considered as part of a fair-use defense....

The Federal Circuit had similarly held that the limits on patent eligibility are minimal and that other requirements of the Patent Act do the real work in limiting monopoly protections. See, e.g., Research Corp. Techs., Inc. v. Microsoft Corp., 627 F.3d 859, 869 (Fed. Cir. 2010) (referring to Section 101 of the Patent Act as a “coarse eligibility filter”). This Court has repeatedly corrected that misperception in recent years, stressing the importance of enforcing Section 101’s limits on patentable subject matter—including for software-related patents. See, e.g., Alice, 134 S. Ct. 2347; Ass’n for Molecular Pathology v. Myriad Genetics, Inc., 133 S. Ct. 2107 (2013); Mayo, 132 S. Ct. 1289; Bilski v. Kappos, 130 S. Ct. 3218 (2010). But the Federal Circuit would now eviscerate the analogous limitation on copyright eligibility for some of the same types of works.

Hopefully the Supreme Court recognizes this, takes the case and... (most importantly) doesn't make things worse.

OraclevGoogleGooglecertpetition1 (PDF)OraclevGoogleGooglecertpetition1 (Text)

Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.

Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.

While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.

–The Techdirt Team

Filed Under: apis, cafc, copyright, supreme court
Companies: google, oracle

16 Comments

If you liked this post, you may also be interested in...

Reader Comments

Subscribe: RSS

View by: Time | Thread

Martin, 9 Oct 2014 @ 11:57pm

A really well written petition by Google, although I wonder if they ought not to have given "API" a clearer definition.
[ link to this | view in chronology ]
Ninja (profile), 10 Oct 2014 @ 3:13am

Alsup had learned to code Java to better understand the case

Clone this judge asap. The nromal would be to see the judge disregard the need to better understand the thing and simply deliver an awful ruling.
[ link to this | view in chronology ]
- DannyB (profile), 10 Oct 2014 @ 5:30am
  
  Re:
  Some judges try to understand an issue well so that they ruling they give is truly evil not just merely awful.
  
  A few judges try to understand an issue to give a good ruling.
  
  Other judges try to understand an issue's effects on the rich, powerful, or those connected with the judge or his friends before giving a ruling.
  [ link to this | view in chronology ]
DannyB (profile), 10 Oct 2014 @ 5:31am

Status quo
For decades, APIs have not been considered copyrightable.
[ link to this | view in chronology ]
- John Fenderson (profile), 10 Oct 2014 @ 7:58am
  
  Re: Status quo
  Yes, they are trying to change the application of the law. The way it has worked traditionally is that the APIs themselves aren't copyrightable. You copyright the documentation of them. Because, you know, the whole reason that software engineering never became a successful business is the lack of enough IP protection. /s
  [ link to this | view in chronology ]
Anonymous Coward, 10 Oct 2014 @ 7:19am

Electronic interfaces of all types have been patented for years. APIs are basically just the 'digital' equivalent of copper and silicon.

But I do miss the pre-patent-crazy era of open standards, when my socket-7 motherboard could be used with processors from Intel, AMD, Cyrix, or any other company. Then Intel patented its interface, locking out competitors, giving customers a black eye, and burdening motherboard manufacturers with the additional cost of designing two versions of every board. And the 1990s tech bubble burst, perhaps not as a completely unrelated event.

And while APIs are clearly not copyrightable, just because they can be patented doesn't mean they should be.
[ link to this | view in chronology ]
Dan T., 10 Oct 2014 @ 7:41am

Wasn't the ARC/PKWARE suit of the late '80s about the copyrightability of user interfaces and file formats (among other things; there were also trademark claims)? It resulted in Phil Katz abandoning the ARC-compatible archive file format and creating ZIP instead, giving him the last laugh when that format went on to dominate file archiving.
[ link to this | view in chronology ]
antidirt (profile), 10 Oct 2014 @ 9:21am

Many of us clearly think that APIs fit under this as a system or method of operation. But, others disagree.

I guess count me as one who disagrees. It's not the functionality that's copyrighted, it's the expression. All computer code is functional--that's the point. But that doesn't mean it's not copyrightable. And it's not just the expression that's at issue here. It's also nonliteral elements such as the structure and sequence. Any reason you don't mention that?
[ link to this | view in chronology ]
- John Fenderson (profile), 10 Oct 2014 @ 9:48am
  
  Re:
  Perhaps because APIs are not specific computer code (the expression) at all, but rather are more like a communications specification, a protocol. APIs are an algorithm, a method of operation.
  [ link to this | view in chronology ]
  - antidirt (profile), 10 Oct 2014 @ 12:20pm
    
    Re: Re:
    Perhaps because APIs are not specific computer code (the expression) at all, but rather are more like a communications specification, a protocol. APIs are an algorithm, a method of operation.
    
    They perform an operation, but the code itself is expression. It's the copying of the code, including the copying of the structure of the code, that's at issue. Oracle isn't claiming that the functionality is copyrighted. Google was and is free to write it's own code that performs the same function.
    [ link to this | view in chronology ]
- Zonker, 10 Oct 2014 @ 11:31am
  
  Re:
  The problem here is that Oracle is claiming that the functionality of their API is copyrighted and that Google infringed by writing their own independent implementation (expression) of that functionality. By your own argument Oracle should fail here, but the CAFC patent court (and why is a patent court hearing a copyright case again?) ruled otherwise.
  
  Read again: Google wrote a clean room implementation of a subset of the Java API designed for use on mobile phones. This was to ensure compatibility with existing Java programs capable of running on such a device. Oracle bought Sun with the hopes of creating their own Java Mobile platform and failed. Oracle sued Google for succeeding with their own independent implementation of the Java API where Oracle failed because Google did not use Oracle's failed implementation instead.
  
  Oracle sued Google for NOT copying Java Mobile in its entirety and writing their own Android implementation instead.
  [ link to this | view in chronology ]
  - antidirt (profile), 10 Oct 2014 @ 12:18pm
    
    Re: Re:
    The problem here is that Oracle is claiming that the functionality of their API is copyrighted and that Google infringed by writing their own independent implementation (expression) of that functionality. By your own argument Oracle should fail here, but the CAFC patent court (and why is a patent court hearing a copyright case again?) ruled otherwise.
    
    From the Federal Circuit’s opinion:
    It is undisputed that the Java programming language is open and free for anyone to use. Except to the limited extent noted below regarding three of the API packages, it is also undisputed that Google could have written its own API packages using the Java language. Google chose not to do that. Instead, it is undisputed that Google copied 7,000 lines of declaring code and generally replicated the overall structure, sequence, and organization of Oracle's 37 Java API packages. The central question before us is whether these elements of the Java platform are entitled to copyright protection.
    Source: http://www.cafc.uscourts.gov/images/stories/opinions-orders/13-1021.Opinion.5-7-2014.1.PDF
    
    How do you square your claim that it’s the functionality and not the expression that’s at issue with the Federal Circuit’s statement that it’s 7,000 lines of code (the literal elements) plus the “structure, sequence, and organization” (the nonliteral elements) that’s at issue?
    [ link to this | view in chronology ]
    - Edward Teach, 10 Oct 2014 @ 2:58pm
      
      Re: Re: Re:
      My, what "lawyerly" reasoning.
      
      You are a lawyer, or have some law training or education, and intend to practice "Intellectual Property" "law", right?
      [ link to this | view in chronology ]
    - Zonker, 10 Oct 2014 @ 3:35pm
      
      Re: Re: Re:
      The 7,000 lines are non-implementing code that make up the class and method names and declarations of the 37 packages of Java. They are not copied, their form is determined and required by the API itself to be functional. Basically what the functions were named, the inputs they accept, and the outputs they return. In other words, the API minus the actual implementation.
      
      Example:
      public static int add(int a, int b) {
      //***Your implementation here***
      }
      
      Oracle would claim that two lines were copied here, the first line declaring the method name and arguments, and the last line consisting of just a closing bracket.
      
      The district court explained this as similar to the Table of Contents of a reference book minus the contents of the chapters themselves. Structure, sequence, and operation (SSO) was already tried in SCO vs IBM and rejected from copyright protection by the Tenth Circuit, which contradicts the patent court's opinion on the matter.
      
      Those 7,000 lines were the minimum SSO framework necessary to be able to create a compatible implementation of the Java API. Even if SSO were copyrightable, and the Tenth Circuit already said it is not in SCO vs IBM, 7,000 out of the 2.8 million lines of code in the version of Java claimed infringed comes to about 0.25 percent copied. 25 out of every 10,000 lines of code. Round that to the nearest percent and you get 0% infringement. If that isn't de minimus then practically nothing is.
      
      If Oracle were to succeed in changing well established law on APIs, I would expect them to face an immediate avalanche of lawsuits over their implementation of ODBC, SQL, C/C++, etc. in their own products.
      [ link to this | view in chronology ]
      - Netizen, 8 Feb 2015 @ 12:56pm
        
        Re: Re: Re: Re:
        "Even if SSO were copyrightable, and the Tenth Circuit already said it is not in SCO vs IBM"
        
        Do you have a link to this decision of the Tenth Circuit?
        [ link to this | view in chronology ]
    - Zonker, 10 Oct 2014 @ 4:13pm
      
      Re: Re: Re:
      What's more, Oracle is arguing that Google should have copied the entirety of Java rather than implement their own subset of it removing all the desktop/server oriented bloat that has no place on a phone or portable device. Since Google could not legally remove the unnecessary bloat from the Java language and distribute that as Java (license requires it all intact), they wrote their own implementation instead.
      
      They are literally arguing that Google infringed their copyrights by not copying the whole free to use Java Enterprise language and distributing it in its entirety on mobile devices as Java. The additional bloat and inefficiency this would incur is precisely what caused Java Mobile to fail even faster than Windows Phone did.
      
      Here's what Sun's former CEO said about Google's Android:
      Schwartz also confirmed to Google counsel Robert Van Nest that Sun promoted the open use of Java APIs as well. “You had to if you wanted to see that language broadly accepted,” Schwartz explained. “Those APIs enabled people to write full, complete applications that leverage all the technology underlying the platform.” He added that the distribution of those APIs across the world enabled the adoption levels that Sun was seeking.
      To further boost those adoption levels, Sun had to find a way to be bigger than Microsoft, and Schwartz said that was made possible with the open Java community. Partners included Oracle, SAP, Sybase, and many other Silicon Valley giants. “It would give us something to pull together that was bigger than the monopoly itself,” Schwartz remarked....
      
      However, even though Schwartz said that Sun wanted to get revenue from Google if a partnership could be hammered out, Schwartz said that the deal did not fall apart for money. “We probably would have paid them to work with us on a Java phone,” Schwartz admitted.
      
      Ahead of the announcement of Android in 2007, Schwartz told Van Nest that Sun was aware of a few things about Android, including that Google would be using the Java languages and APIs.
      [ link to this | view in chronology ]