Image 01 Image 03

Tech gurus ask SCOTUS for review of API copyright case

Tech gurus ask SCOTUS for review of API copyright case

Protect innovation!

The tech community is rallying in an effort to convince the Supreme Court to review a federal court decision granting copyright protection to APIs (application programming interfaces.)

A few years ago, tech giant Oracle sued Google when Google’s engineers used Java APIs to build the Android operating system. Although Google designed its own original programs, it based those programs off of the original Java APIs so that independent developers could create apps and programs for use on Android phones.

Pause button. If everything I just said sounded like Greek, the Electronic Frontier Foundation explained in their press release about their request to SCOTUS how APIs work:

Generally speaking, APIs are specifications that allow programs to communicate with each other. So when you type a letter in a word processor, and hit the print command, you are using an API that lets the word processor talk to the printer driver, even though they were written by different people.

The brief explains that the freedom to re-implement and extend existing APIs has been the key to competition and progress in both hardware and software development. It made possible the emergence and success of many robust industries we now take for granted—for example, mainframes, PCs, and workstations/servers—by ensuring that competitors could challenge established players and advance the state of the art.

After Google released its Android OS, Oracle sued Google for patent and copyright infringement. A California judge rejected the claim, saying that an API is essentially a “process or method” that allows different computer programs to talk to one another. (Source code, on the other hand, is treated like a literary work and is covered under copyright laws.)

A federal circuit appeals court disagreed with the analysis and overturned the decision, instead holding that APIs are copyrightable, upending years of industry practice and sending the tech community into a frenzy.

Is this a niche issue? Yes. Is it an important niche issue? Absolutely. From the perspective of a computer scientist or developer, this decision threatens their very ability to create anything new:

“The Federal Circuit’s decision was wrong and dangerous for technological innovation,” EFF Intellectual Property Director Corynne McSherry said. “Excluding APIs from copyright protection has been essential to the development of modern computers and the Internet. The ruling is bad law, and bad policy.”

“For decades, computer scientists and the courts have all understood that copyright doesn’t protect APIs,” EFF Special Counsel Michael Barclay said. “We hope that the Supreme Court will review this case and reverse the Federal Circuit’s misguided opinion, which up-ended decades of industry practice and threatens the basic principles upon which our technology sector was built.”

Think of an API as a foundational building block. When you sit down to build something new, you have a choice: you can create your own building blocks that only your programs will understand, or you can use building blocks that are universally used and understood by many different builders. By using the universal building blocks, you ensure that other builders will be able to understand your work, learn from it, and build off of it. That’s innovation, right?

If the Supreme Court refuses to take this case up, those who own copyright on various APIs will be able to prevent developers from creating compatible programs. This means tools like Twitter, Facebook, and cloud computing services could be frozen in time unless the owners of the API give another entity permission to use the code from the original API implementation.

That’s not innovation, and it should worry you. March on, nerds—I’ll be right behind you.

h/t Computational Legal Studies

DONATE

Donations tax deductible
to the full extent allowed by law.

Tags:

Comments

An API should be neither copyrightable or patentable. It is merely a set of “words”, without structure or form. A set of “words” or interfaces that allow for others to provide expression. It is as deserving of copyright or patent protection as the English Language.

Sadly, Circuit Court Judges, trained in law and not programming are amongst the least qualified people in the world to make these decisions.

“Think of an API as a foundational building block. When you sit down to build something new, you have a choice: you can create your own building blocks that only your programs will understand, or you can use building blocks that are universally used and understood by many different builders. By using the universal building blocks, you ensure that other builders will be able to understand your work, learn from it, and build off of it. That’s innovation, right? ”

Wrong on all points.

An API ( Application Program Interface) is exactly that – a set of ‘exposed’ (accessible) interface conversations (question and answer, or command and responsive action), put there by the choice of the person who wrote the APPLICATION. IOW, the program code. As a programmer, I have written MANY API’s to many code sets / programs. None of them are so exaclted as to be called ‘foundational building blocks’ of anything – except maybe the rest of my program around them.

When I write a piece of code, I own the copyright to it, including the right to permit or not permit others to use it. I did not write it so ‘that other builders will be able to understand your work, learn from it, and build off of it’. What interfaces I design into it or not (GUI, API, etc), I decide, I choose, and I do it for my own reasons, accountable to no one, my own original work.

This means I hold copyright. Not patent (a different animal entirely), but copyright. When someone else writes code to do the same thing, even perhaps with a superficially identical API structure, fine, they did not violate my rights at all. If I write an API that says “SaveFile (myfile as string)” in a DLL, that is much too minor, too obvious, too obvious, to hold copyright. Example – if I write the words “Good morning” in my book, and you later write the words “Good morning, dear”, you did not violate my copyright on my book. If you directly copied the 5 pages of code behind ‘SaveFile’ it, you did. If you wrote other code to save a file, you did not. You can still use ‘SaveFile’ to invoke it. This is an API call.

    Paul in reply to pjm. | November 25, 2014 at 7:42 am

    Me writing code that conforms to an api you wrote does not even require your code to be there or for me to ever see it, possess it or run it. How can I infringe (eg. copy) your copyright if I don’t do any of those things?

    I think it is important to distinguish between internal and external APIs. External interfaces are declared as such specifically so that they may be utilized by other programs. A USER of both of our programs is responsible for ensuring they have appropriate rights for both sets of code, but programmer B merely writing code that conforms to a public API does not violate programmer A’s copyright.

    All that being said, the Oracle suit went way beyond just API’s…Google built a virtual machine (Dalvik) which implements the bulk of the entire Java language.

      pjm in reply to Paul. | November 25, 2014 at 9:58 am

      Agreed. The exposed method call is not the code itself.

      The code is inherently copyrighted, the actual line to call or invoke it is trivial.

      AN API is an Application Program INTERFACE, IE the exposed names and calling syntax of non-exposed codesets.

      My house has a door, and a living room. The door is the publicly exposed method to get in, the stuff in the living room is mine, hands off unless I tell you otherwise.

      You can duplicate my door, it is publicly visible, but you can not take my stuff.

        Milhouse in reply to pjm. | November 25, 2014 at 5:26 pm

        And the second circuit has said that if I build my own house, I may not put a door in it, or at least not on the side, because you have a patent-like copyright on the idea. If we were talking about actual doors, the ridiculousness of this would be obvious; doors obviously can be patented but are not subject to copyright. But because this door is made of written code, which is subject to copyright, the suit seems to have superficial merit, and it’s not obvious until you look at it how ridiculous it is.

        One more attempt at a layman’s example: Suppose pjm manufactures voice-activated doors that open with the phrase “open sesame”. Suppose his doors become extremely popular, so that everyone is used to saying “open sesame” whenever they want a door to open. Now it’s 20 years later, and his patent has run out, so a bunch of manufacturers start making doors that work the same way. And pjm jumps in and says: “Hey, my patent on voice-activated doors may have run out, but my copyright on the phrase ‘open sesame’ has not; if you want to make voice-activated doors you must use different phrases to open them, and people who buy your doors will have to learn a different phrase, and everyone who wants to visit them will have to learn it as well, and remember which phrase to use for that person’s door, so people who don’t want to bother with all that will stick with my doors that open to the famliar phrase”.

        Or suppose pjm claims that when competing door manufacturers print instructions on how to open their door by saying “open sesame”, that violates his copyright on that very instruction.

        That is what Oracle is claiming against Google, and what the second circuit agreed with.

From my limited readings into Oracle v. Google, at issue is Oracle’s claim that Google lifted Oracle’s copyrighted API declaring source code. Not at issue is that Google wrote original code to utilize existing Java APIs, nor that Google defined APIs compatible with existing Java APIs.

    It seems the media coverage around this is using the term API for what I would call “language” or “syntax.” I suppose in an abstract sense it is the interface to the bytecode compiler.

    Milhouse in reply to Erasmus. | November 25, 2014 at 5:31 pm

    Yes, they copied header files. There’s a lot of creative thought that goes into designing an API, but once you’ve designed it there’s really only one way to write the header files that describe it. There is no spark of creativity in writing a header file, so it’s not copyrightable.

picture this.
you write an article.
someone else copies and pastes it elsewhere, adds on word, posts it.
you ok with that?
api really not that far from that.
its the “blocks” you allow others to use to interact with your program.
like it or not the person that created that api (or article) owns it.
EFF does a lot of good things, they also do a lot of bad things.
this is one of those bad things.
they want everything to be free.
I can’t stand oracle but they were right and google knows it.they knew it before they even tried to get away with it but chose to do what they did anyway.

    in your analogy of a printed page, someone else can buy (license) your work and post it in the window of their shop for all to see.

    reading a written page is a better analogy for executing/calling an API. doing so does not require ownership or even possession of the page.

    writing new code which conforms to, or calling an API does not require me to ever possess your code.

    consider the case of network based APIs. Your code resides on your server but is accessible to the entire Internet. Does that mean everyone in the world is violating your copyright?

      someone else can also buy (license) your api.
      you said it right there, writing new code which calls the api. thats different.
      network based,I don’t know really, thats a tricky one. I’ve never personally seen a network one like that which didn’t have gpl (or similar) license though which negates the issue.
      I would guess someone that lets everyone access and take it either needs to use license like that or state you can see it but not take (just as a simple term) it. Someone just calling that api probably not guilty of anything but if they edit it and add to it (extend) I would say (if license is stated) yes they are guilty. they would still be using the source code they didn’t write. me leaving a door unlocked does not absolve a thief of their transgressions.

      pjm in reply to Paul. | November 25, 2014 at 10:06 am

      “consider the case of network based APIs. Your code resides on your server but is accessible to the entire Internet. Does that mean everyone in the world is violating your copyright?”

      Yes. If they use the ‘work product’ of it, yes. A codeset is not a static page to be read, it is an active thing that does work.

      Even if it does not, you still can not copy it. Even if it was a plain *.txt file, you can not copy it and use it (beyond fair use doctrine etc), nor use my copy on my server as if it were your own.

        Paul in reply to pjm. | November 25, 2014 at 11:31 am

        my written word here is protected under copyright law just like my code is.

        the English language is a mutually accepted way of codifying thought, just like any programming language is, and a specific set of words codifies a specific thought (this one) just like an API does. both are “work products.”

        by your logic, you’re violating my copyright as you read this word, just as you claim I would be violating your web-based API above.

        “reading” something does not mean you are copying it, executing it, or possessing it in any way. you might copy my written word before you read it, or you might copy my program before you examine the API; in those cases you would be in violation of my copyright (potentially). but you could also read my work or examine my API without copying my work product, in which case you are not violating anything.

          pjm in reply to Paul. | November 25, 2014 at 2:13 pm

          Right and wrong. You conflate ‘seeing’ and ‘using’.

          Yes, if you had not publicly published your comment here to be read by everyone, I would not have the ability to read it. By publishing it here, you gave the world permission to read it.

          If I copy your written word without permission ( other than ‘fair use’), I violate your copyright in it. More so if I re-distribute it.

          If I copy your program (assuming I had any right to do so ? Did you make it publicly available ? OR just a picture of your house from the outside (API = front door) ? You can drive by and see my house, but you can not enter it or use it.

          Having a (even a legal) copy of your (compiled executable or DLL etc) program does not allow me to examine any API. Except by hacking / reverse engineering, of course, which are illegal.

          Milhouse in reply to Paul. | November 25, 2014 at 5:34 pm

          Reverse engineering is not illegal!

I’ve spent 25 yrs writing code including many API’s. What is not said here is that most often there are public API’s and private API’s. Public API’s are for the consumption of others. That is their purpose in life. Private API’s are just as accessible as public API’s but they are not documented because you don’t want just anyone to use them. Patent and copyright of API’s would grind the industry to a halt. Literally.

I cannot imagine that Oracle has thought this one thru. Their software engineers are using non-Oracle API’s all the time. That is a guarantee. Talk about a lose-lose scenario.

    I agree; I doubt Oracle thought this one through. I betcha this is just another example in a long list of rash actions by their arrogant prick of a CEO. He’s just trying to screw IBM, Google and others after purchasing Sun by putting a bunch of restrictions on Java.

You conflate the actual meaning (to a programmer) of ‘public’ and ‘private’. These are declarations of scope, in code. Just because I call my API method ‘Public Savefile()’, does not mean that I intend it for use by others without my advance permission.

Given further that it most likely in turn calls various other PRIVATE routines that do the real work does not mean that they have in turn been made into public property.

‘Public’ vs ‘private’ scope declaration is a matter of software architecture, not ‘granting rights to others’.

I still agree with Google (as I understand it), that using a similar or even identical calling line format is not ‘copyright violation’, if they wrote their own code behind it. And yes, Oracle and everyone else does the same thing.

    Paul in reply to pjm. | November 25, 2014 at 11:44 am

    OK, I believe this is a very important distinction:

    You wrote “…using a similar or even identical calling line format is not ‘copyright violation’…”

    In my mind, the API is what you are referring to as the “calling line format”. Right before I popped over here to check this thread, I wrote this:

    RTFEditorKit kit = new RTFEditorKit();

    RTFEditorKit, by pure happenstance, is a Sun API. The syntax “new RTFEditorKit()” is the way in which I initiate the object from within my program. This syntax is what I refer to as the Application Programming Interface; it is the protocol which defines how my program can talk to Sun’s program.

    By writing that line of code, I am NOT in violation of their copyright… I can write that line of code without their program ever residing on my machine… it’s a form of “fair use.”

    However, to EXECUTE their code by running my code which calls their API, I must have their object code (jar file) on my machine. At this point, I have their work product in my possession and I am potentially in violation of their copyright if I don’t have proper license.

      pjm in reply to Paul. | November 25, 2014 at 2:32 pm

      “In my mind, the API is what you are referring to as the “calling line format”.”

      Yes, exactly. The INTERFACE ( to an exposed, IE ‘public’ method)… Not the whole method, just the one line to invoke it.

      “RTFEditorKit kit = new RTFEditorKit()”

      OK, you invoked a SUN method called RTFEditorKit, and created an object call kit. IF you have their code ( in whatever distro’d embodiment they make available) to send that instruction to.

      Without sending to their code ( or other with same ‘front door’ aka interface), RTFEditorKit is a meaningless mumble of letters, not an API call. And you did not initiate anything other than an error (‘object or method not found’ or similar) without their ( or other) code to know WTF it means.

      Residence of said code being irrelevant (client, LAN, or WAN) of course.

      Agree with your last, exactly. Add that ‘If you wrote your OWN jar with that method name ‘RTFEditorKit’ exposed ( but one that you wrote yourself, not SUN’s version), that JAR is your property, and the simple line to invoke an object ( via your own code) is not at issue, nor a violation, nor is your JAR.

        Paul in reply to pjm. | November 25, 2014 at 3:24 pm

        “Without sending to their code ( or other with same ‘front door’ aka interface), RTFEditorKit is a meaningless mumble of letters”

        That is the nut of the Oracle v. Google case right there.

        Google’s Dalvik implements many/most of the Java interfaces but it’s wholly their code under the hood.

        Ellison was trying to have it both ways. Java gained massive traction in the industry largely because it was so open. But his timing was really bad buying Sun as the virtualization trend took off, so he lashed out like he always does and tried to sue a bunch of the biggest Java users, in order to extort them.

        I imagine he’ll ultimately lose in court, and in the meantime many of the best and brightest Sun engineers were aghast at his antics and have already moved on to greener pastures.