Cancel

Jeff Chandler

Automattic Doesn’t Claim Copyright On Their APIs

Oracle Featured Image
photo credit: Håkan Dahlström – cc

In a crucial courtroom decision involving Google v.s Oracle, the United States Court of Appeals for the Federal Circuit ruled in favor of Oracle. The main part of the appeal is whether Oracle can claim copyright on Java APIs and if Google infringed that copyright. If the ruling stands, it would create a major setback to innovation and collaboration.

The Electronic Frontier Foundation has a great write up on the ruling and the implications it could have for the internet.

The implications of this decision are significant, and dangerous. As we and others tried to explain to the court, the freedom to reimplement 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 mainframes, PCs, workstations/servers, and so on—by ensuring that competitors could challenge established players and advance the state of the art. In other words, excluding APIs from copyright protection has been essential to the development of modern computers and the Internet.

Between 2004 and 2009, which I consider to be the crazy Web 2.0 years, the one commonality among all of the services was their APIs. The APIs enabled sites, services, and applications to creatively use the data to create mashups. In June of 2005, Google released a publicly available API to their Google Maps product. The API ignited a flurry of creative new ways to use and display the data. The ruling would prevent open innovation from happening without explicit permission to use API calls.

Automattic Takes The Pro-Active Approach

Automattic, the parent company of WordPress.com, has taken a pro-active approach. On May 12th, Automattic changed their guidelines to specify that their APIs are not copyrighted.

One more thing – APIs like ours enable the kind of collaboration that makes the Internet great. We don’t think APIs are copyrightable subject matter, and don’t claim copyright in our APIs.

In the section of the the document discussing intellectual property, Automattic clarified they do not claim any copyrights to their APIs that may arise under US law.

3. Intellectual Property. [The Automattic APIs are subject to certain intellectual property rights in the US and other countries (though Automattic does not claim copyrights in the Automattic APIs that may arise under US law). You agree to abide by such rights, all applicable laws, and any additional copyright notices or restrictions to which any Content is subject.]

Although innovation wouldn’t cease completely with copyrighted APIs, it would be more difficult thanks to the red tape involved. Patent trolling is already a serious problem and if the court ruling stands, API copyright trolls would probably be the next big thing.

Google will likely file an appeal to the Supreme Court and there is a long way to go before the case is over. Regardless of the final ruling, the Automattic APIs are copyright free. Hopefully, other service providers take the same pro-active approach.

Category:
Tags: , , ,
24

24 responses to “Automattic Doesn’t Claim Copyright On Their APIs”

  1. I’m only part-way through the decision, but it doesn’t appear to have anything at all to do with making API calls; rather, it has to do with Google incorporating implementing API code from Java into Android.

    In other words: Google wasn’t merely calling a Java method using Java’s API (e.g. max( $var1, $var2 )); rather, Google actually copied the code to implement its own max() method.

    Basically: Google didn’t want to open-source its own code (so it couldn’t utilize the Oracle GPL license for the APIs) and didn’t want to ensure interoperability with the JavaVM (so it couldn’t get certification to use Oracle’s commercial license) – so Google instead just copied the Java API code and incorporated it wholesale into Android, as Android APIs.

    To make a WordPress analogy: this case appears quite similar to Thesis 1.8, which had to be rewritten because it was found to have incorporated core WordPress implementing code.

    This decision, and Automattic’s subsequent announcement, are indeed interesting; in part, because what courts consider to be “APIs” and what developers consider to be “APIs” aren’t necessarily the same thing.

    • And to go a step further, the decision actually reaffirms that the use declarative API code does not infringe on copyright, under the merger doctrine:

      As to the declaring code, the [district] court concluded that “there is only one way to write” it, and thus the “merger doctrine bars anyone from claiming exclusive copyright ownership of that expression.” The [district] court further found that the declaring code was not protectable because “names and short phrases cannot be copyrighted.” As such, the court determined that “there can be no copyright violation in using the identical declarations.”

      This decision reaffirms the Galoob v. Nintendo and Computer Associates v. Altai decisions, and strengthens the protections against copyright infringement claims that would otherwise arise from mere use of “APIs”.

    • It’s interesting you bring up Thesis because I was thinking about it in the back of my mind when I was writing this post. I’d have to go back in the archives but because of the implementation of WordPress code in Thesis, it was violating the WordPress copyright/GPL License and was considered a derivative. I’ve probably got that all screwed up but it was something similar to that.

      Based on research and my own feelings, the fear is that common phrases, words, and calls could become copyrighted thus really hampering open innovation and creativity. I think this is why Google is claiming a defense of Fair Use.

      • Based on research and my own feelings, the fear is that common phrases, words, and calls could become copyrighted thus really hampering open innovation and creativity.

        Understandable, but this decision has nothing to do with infringement based on “common phrases, words, and calls. It has to do with wholesale copying and incorporation of implementing code.

        What Google did, and what Oracle claims and the appeals court affirms is copyright infringement, is analogous to someone copying the entire /wp-includes/ directory, files and all, into a new CMS.

        • So then, if the ruling stands, what happens? Everything I’ve read has a “sky is falling” mentality and this ruling is bad bad bad.

          • I don’t know? Maybe people aren’t actually reading the ruling?

            I’m not all the way through it, so I could be wrong; but it’s not that difficult to follow.

  2. I don’t get it. Weren’t Automattic totally in support for claiming copyright over API’s in this way previously? Whenever I see these rulings, I compare them to the situation with WordPress copyright, yet this move by Automattic seems counter to their previous stance.

    Or am I missing something here?

    • Well, there is Automattic and their APIs and how they want developers to utilize them and then there is the WordPress open source project with APIs itself that I believe was the focal point of Thesis since it contained verbatim copy-pasted API code thus, inherited the GPL and violated the copyright of WordPress though all of that had more do to with GPL compliance and at what point is it a derivative work than copyright I believe.

      • Yeah, but there were a lot of people including (I assume) Automatticians who were referring to the WordPress API internal calls as being copyrightable, hence could not be transferred to non-GPL projects. The whole time I’ve been reading about this Java debate over the past few years, I’ve been directly equating it to those WordPress internal API calls/function names.

        Perhaps I have been confusing things in some way, but I’m not sure how.

        • You are definitely confusing copyright with licensing. They are not the same at all, though copyright laws are used to enforce the GPL licensing.

          • I understand that licensing and copyright are not the same thing, but the previous debates in the community were over how licensing was affected by copyright of the internal WordPress API’s. That’s where I’m confused, as I thought the stance of Automattic was that API’s should indeed be covered by copyright, which is the opposite of what is said on the page linked to above.

    • What I’m confused about is: why is Automattic asserting enforcement or non-enforcement of WordPress copyrights? Doesn’t the WordPress Foundation hold all WordPress project copyrights?

      • I assumed it was only the dot com API’s, not WordPress core API’s. I have diabolical internet here right now though, so am struggling to load the page to check.

      • I think there is confusion here. It’s Automattic waving their copyrights as applicable to US law to their APIs. If you take WordPress the open source project out of the equation, then does it make more sense what Automattic did?

        WordPress.org shouldn’t even be part of the conversation since it’s not related. This is about Automattic, their APIs for interacting with WordPress.com and claiming no copyright on them.

  3. No, I understand that. But I thought their previous stance (or at least many Automatticians stances) was that API calls are copyright protected. Everything I read at the time was in reference to the internal WordPress core API’s, but I assumed the same would apply here.

    I assumed they’d be extremely pro Oracle in this situation, but it seems I was quite wrong on that front.

    EDIT: I think I got confused as to was replying to what, but my comment still applies, so I’ll leave it here :)

  4. Okay, I made it through the entire decision.

    The more I read of the decision, the more I think it actually strengthens copyright protections upon which GPL and copyleft philosophy rely. The crux of the case isn’t fair use, but rather copyrightability. The appeals court essentially asserts that that district court’s decision implies that no software is copyrightable, based on the copyrightability analysis methods the district court used. The appeals court reverses the district court’s decision regarding copyrightability of Structure, Sequence, and Organization (SSO) of the APIs in question, affirms the district court’s decision that interoperability needs did not render the APIs uncopyrightable, and remands to the lower court the fair-use defense upon which the jury hung.

    As you can see from the conclusion, this decision is actually a win for free software, because it affirms the fundamental copyrightability of software SSO and declaring code, in addition to the copyrightability of implementing code. To wit:

    For the foregoing reasons, we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages at issue are entitled to copyright protection. We therefore reverse the district court’s copyrightability determinations with instructions to reinstate the jury’s infringement verdict. Because the jury hung on fair use, we remand Google’s fair use defense for further proceedings consistent with this decision.

    If the court hadn’t held that declaring code and SSO are copyrightable, someone could take the entire /wp-includes/ directory, files and all, keep all the same file structure, organization, and function/class names and declarations, then rewrite all of the implementing code, and distribute it as a new work not subject to the GPL under which WordPress is distributed.

    Let me try to explain a bit better.

    The question of the implementing code isn’t really at issue. Even Google admits that the implementing code is copyrightable. Google took the SSO, and wrote new/original implementing code for all of the API declaring code. (Except for the implementing code in 8 files that Google reverse-engineered, and the rangeCheck method – the use for which Google claimed fair use as de minimus. This issue, and Google’s fair use claim, was remanded to the circuit court for further proceedings.)

    What Oracle was appealing, in part, was the circuit court’s decision that their expression of an idea, as embodied in the programmatic structure, declarative conventions, and nomenclature (i.e. the Structure, Sequence, and Organization, or SSO), was not copyrightable. The appeals court agreed with Oracle, in that the way they chose to organize and define some 7,000 lines of code represented copyrightable creative expression.

    The actual functionality (i.e. the idea being implemented) is not copyrightable. Java has a max() function that determines which of two integers is the larger integer value. Google could have chosen to write a separate function, with the same or a different name, to accomplish the same purpose, and would not have violated Oracle’s copyright. But the court held that, as a whole (37 APIs, with however many classes, and class methods), since it included a deliberate, creative expression (SSO), met the very low bar of creativity used in determining copyrightability. But the copyrightability applies to the collection as a whole.

    Think of it as a compilation of public domain, classical poems. The poems themselves are not copyrightable; but the act of compiling those poems in a particular manner represents copyrightable creativity. That’s the core of what’s at issue here, with respect to the API structure and declarative code.

    Note the distinction in applicability of the merger doctrine. The appeals court holds that use of the Java API is not copyrightable under the merger doctrine, but in writing a new API, wholesale copying of the declaring and implementing code does not fall under the merger doctrine:

    The focus is, therefore, on the options that were available to Sun/Oracle at the time it created the API packages. Of course, once Sun/Oracle created “java.lang.Math.max,” programmers who want to use that particular package have to call it by that name. But, as the court acknowledged, nothing prevented Google from writing its own declaring code, along with its own implementing code, to achieve the same result. In such circumstances, the chosen expression simply does not merge with the idea being expressed.

    The appeals court then turns its attention to the question of copyrightability of the method names – i.e. the “short words and phrases”. The district court held that Oracle’s nomenclature, conventions, and structure of 7,000 lines of declaring code was not copyrightable because it consisted of several one-line instances of “short words or phrases”. The Appeals court reverses that decision, noting that the combination and compilation of uncopyrightable “short words and phrases” constitutes creative expression that is copyrightable.

    The appeals court also agrees with Oracle that the circuit court erred in declaring the SSO uncopyrightable as a “method of operation”, in that the Lotus decision was not applicable to the case at hand, and did not properly apply the Abstraction-Filtration-Comparison method of determining copyrightability and copyright infringement.

    The appeals court then discusses a rather odd argument by Google that the code they copied was not copyrightable, because it was necessary to achieve interoperability with Java – even though Google deliberately wrote Android so as not to be interoperable with JVM.

    Also importantly: the appeals court rejected Google’s appeal on the basis that software should be protected under patent law rather than under copyright law. The legal precedent set by such an argument, if successful, would be absolutely chilling to software development, and to the free software movement.

    • Thanks for dredging through all that Chip.

      I didn’t read into it in that much depth, but your analysis seems to gel with my understanding of the situation.

    • I see what you’re getting at here Chip, but Java is not PHP, and fundamentally there is a difference in the language that matters here.

      For Java, that “file structure” actually does matter, at the deepest level of the code. That “java.lang.Math.max” you refer to is actually both a file structure inherent in the format and layout of Java code and in the code itself. You cannot actually implement a “java.lang.Math.max” and be compatible without using the file structure of “/java/lang/Math.class” to do it.

      While other languages have a less strict file structure and organizational structure, Java was built from the ground up in a way that the layout of the *.java and *.class files matter to the actual names of namespaces and classes and functions in the language itself. By ruling those copyrightable, the court is saying that the function names and prototypes are essentially copyrightable, because in Java, there is no difference between the two.

      It is not possible to build a compatible version of Java without this inherent file structure and function/object naming interaction. Java is a special case, and by not recognizing that case as special, the court has made an error here. This case is absolutely not a win for “free software” or for anybody else who wants to write their own versions of systems while also maintaining fundamental low level compatibility.

      IMO, that which is absolutely and arguably necessary to create a new work that is compatible with an existing system should not also be copyrightable by the owners of that system. The ability to make compatible works should be preserved and not subject to copyright restrictions.

      • Usually courts handle only the cases presented to them and do not engage in theoretical questions. I do not intend to read the ruling but it was really a no trainer for me that the court decided that an intellectual work created by people can be copyrightable. Now the ball is back to the lower court to decide whether google’s reintroduction of the API falls under fair use (I guess it is not but “fair use” is less clear cut)

        “IMO, that which is absolutely and arguably necessary to create a new work that is compatible with an existing system should not also be copyrightable by the owners of that system. The ability to make compatible works should be preserved and not subject to copyright restrictions.”

        why? Automattic created the Akismet API and wrote the client and server software utilizing it, why should anyone be given by default the advantage of utilizing their client code to communicate with different antispam server? It is not like it is hard to create a new API for a new service.

        • You’re misunderstanding. Code is of course copyrightable. What’s at question here is whether or not a description of that code and possibly the layout or organization of it is also copyrightable.

          The court’s example uses Java’s max() function. It basically looks like max(a, b) where a and b are two numbers. The function returns what the maximum number is. It lives in a place named /java/lang/Math.class and is named java.lang.Math.max().

          Now, is that little description I just wrote copyrightable to the extent that, if you go and implement your own version of it using entirely your own code, but still conforming to what I just stated, then I can sue you for doing so and act to prevent you from doing it?

          The specific implementation is of course protectable by copyright law. No question about it. But if I create some code and then somebody else creates another piece of code designed to *look* like my piece of code and work with other code that was originally designed to be working with my code instead, should I be able to prevent them from doing it?

          For open source projects in general, this matters quite a lot. A significant number of open source projects are written to behave and function like other, closed source, code. The Windows Sharing service is known as SMB (for Simple Message Block). An open source version of this is known as Samba, and it implements the ability for Linux machines to share files with Windows machines, to implement Printer sharing, things like that. Microsoft didn’t create Samba. Microsoft didn’t tell other people how to create Samba. People reverse engineered how Windows did it, then implemented their own code to behave the same way, and thus talk those same protocols. This sort of reverse engineering is commonplace in the open source world.

          You don’t usually get to choose what APIs you use to communicate. You have to interact and be compatible with other people’s code too. Which often means writing code to behave a lot like their own code does, using the same names, and the same types of functions, even though you write the code entirely yourself.

          • I an not a lawyer (although I like to think I understand some aspects more then other people ;) ) and I know the copyright law is not easy to understand as is evident by the fact that the lower court decision was overturned.

            I agree with Chip’s understanding, the Max function by itself is not copyrightable but the Math library might be. It is deciding when does an API stops being a trivial that will be the hard part here. From the way I understand it there was no ruling that the JAVA API is copyrightable, just that it might be and it is the job of the lower court to decide whether the API is not trivial collection of trivial facts and therefor deserve the protection. For Example I would agree that the Math library by itself should not be copyrightable as it is a trivial collection of trivial description of functions.

            “But if I create some code and then somebody else creates another piece of code designed to *look* like my piece of code and work with other code that was originally designed to be working with my code instead, should I be able to prevent them from doing it?”

            Well wordpress.org position (or was it matt’s personal one?) is that you can actually prevent others from replicating the wordpress API. In the big “plugins and themes *have to be* GPL compatible” debate the base assumption is that the only place you can use wordpress API is with the wordpress core library and there might not be any other libraries under other licenses that implement the same API under different license.

            Now, should you be actually able to prevent people from replicating your API? I am not sure what is my position, but in a way it is much easier to assume that every API is copyrightable and let the copyright holders decide how permissive they want to be with it, exactly like it is done with code.

            And even under copyright law there is fair use, Is WINE fair use? I think not as it is usually not that hard to buy a license for windows, but SAMBA might be as you might have devices which talk only SAMBA while the majority of your network is not windows based.

            “You don’t usually get to choose what APIs you use to communicate.”

            I mostly agree when you talk about network protocols (or intercommunication protocols in general) but that is not what the this specific case is about.

            We are creating things in software which it was not possible to do before and this is why the courts have to answer questions that simply were not asked before, and the courts have to interpret old laws in a new settings. It might be that the laws need to be changed to better reflect what people think that is “right” but till then there is no much point in saying that the court was wrong. Best lawyers aided by the best software engineers money can buy were arguing there. The court decision might still be wrong but it was a very informed one, just no point in saying “the court didn’t understand”..

          • @markk5 Clearly you are mistaken in your assumptions somewhere. The fact is that the court very clearly did not understand, since they came to the incorrect conclusions. You cannot actually understand something that is technical in nature and still get the wrong answer. More to the point, this isn’t even a matter of applying old law to new situations, This is a matter of applying old law to old situations. See, this isn’t “new”, by any stretch, the basic principles here have not been any different than they were since the 1960’s. People have been creating work-alikes for a very long time.

            Read the list of amici curiae yourself, and pay special attention to the 32 names at the top of it. If you are a programmer of open source software, you should recognize more than a few of them:
            https://www.eff.org/document/amicus-brief-computer-scientists

  5. 1. I didn’t read the full announcement/TOS change by auttomatic but it sounds like BS.You can’t give up your copiright, you can only license it under a permissive license, and the language used is not legal enough to make any sane lawyer comfortable enough to recommend the reimplementation of auttomatic’s API without getting an explicit permission first.

    2. This has nothing to do with GPL as the case is about the reimplementation of API and not its use.AFAICT oracle didn’t sue google for writing code that uses the API therefor even they probably agree that whatever license an API uses is not relevant to the license of the code which makes use of it. We are still waiting for the court case that will determine if RMS is right and if you have 5 lines of GPL code on your PC then all the software on your PC has to be GPL.

    • You can’t give up your copiright, you can only license it under a permissive license

      You can release things into the public domain. As far as I know, that releases all your rights to copyright. Many governments do this on a regular basis.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: