Tuesday, May 15, 2012

Yes, I believe Platform APIs Should be Protected by Copyright

I am not sure how many takers I have when it comes to the principles espoused in last week’s blog regarding intellectual property protection in a many-to-many world. To respond to some would-be criticisms of these ideas, let me be precise about my thinking.
  1. No, I don’t believe that every.toString() interface should be protected by copyright. I am being very specific when I use the phrase “platform APIs” and by that I mean the entire set of APIs that constitute a platform. It is the platform and its corresponding APIs that I believe deserve copyright protection.

  2. In the case of platform APIs, I believe that the definition of infringement should be narrowly construed to apply only to those instances where a party’s reverse engineering of a platform is motivated by a desire to avoid negotiating with or obtaining a license from the creator / owner of the platform. In the case of Oracle vs. Google, I am persuaded that this was the case.
I’m not convinced by those who would suggest that extending copyright protection in this way would make the use of programming languages unworkable, particularly concepts like inheritance. Nonsense. Every time I install a set of developer tools, including open-source tools, I have to agree to a click-through license agreement. Thus, when programming I am already doing so through a license agreement with the intellectual property creator / owner. And for those intellectual property owners who would seek to use such protections to engage in abusive or monopolistic practices, I remain confident that free market forces would deter such behavior. Nothing destroys a platform’s viability more quickly than engaging in behavior that drives developers away. At a minimum, the situation would be no different than what we experience today when vendors seek to lock customers into their hardware or software platforms.

But what about the traditional distinctions between copyright, which is thought to protect creative expression, and patents, which is thought to protect unique functions or processes? A traditional view would suggest that APIs do not represent creative expression in the same sense as music or literature, and that patent law is more applicable to the functions and process represented by platform APIs. My response is this, that the traditional distinctions between copyright and patent protection are best suited to a world dominated by one-to-many relationships or one-to-many economic exchanges, where there are consistent and regular vertical and hierarchical structures that protect the rights of intellectual property creators (or at a minimum deter would be infringers). But in a world of many-to-many relationships, or a world characterized by many-to-many economic exchanges, the sometimes chaotic forces unleashed by widespread availability of cheap storage, digital distribution, and technical know-how requires a different approach (see this blog post). Dealing with these forces have left intellectual property creators to do things that make little sense and could actually stifle innovation (through patents on things such as one-click shopping). They need better avenues to protect their innovations.

At a minimum, I am deeply troubled by the prospect of individuals copying the APIs of an entire platform, and reverse engineering the implementation of those interfaces, when their primary motive is to avoid obtaining a license from the intellectual property creator / owner. We need a better way to protect the efforts of intellectual property owners while also creating an environment where those creators feel free to innovate. The long-term viability of a dynamic and growing economy depends on it.

1 comment:

  1. This was a well written article, but I disagree with your premise. API's are nothing more than a contracted interface between an application's source code and a library, assembly, and/or platform that implements specific functionality that a third-party developer can chose to use instead of writing the functionality themselves. Copyrighting an API of any type not only limits competition, but it limits innovation.

    As a patent holder, I completely support the protection of intellectual property. But an API interface (i.e. function prototypes and definitions) is not functional without the implementation of functionality behind it. It's the functionality that is important and should be protected.

    Reverse engineering and copying the actual source code behind an API is wrong, both legally and ethically. However, writing "from scratch" a new product that supports an existing API (i.e. interface) so as to facilitate development, migration and/or porting has not only been an acceptable practice for decades, it has led to further innovation, competition, and better software.

    You make an interesting point in your article about the difficulty that would arise by copyrighting API's. I quote:

    "1. No, I don’t believe that every.toString() interface should be protected by copyright. I am being very specific when I use the phrase “platform APIs” and by that I mean the entire set of APIs that constitute a platform. It is the platform and its corresponding APIs that I believe deserve copyright protection."

    The simple fact is that partial API copyright protection would be a requirement if any API copyright protection were to be enforceable. Otherwise, a competing API developer could copy all but one prototype or definition and thus not be subject to any enforcement of the copyright. Another problem you identify with this argument is that of any modification to a competing API's interface. Is a copyright enforceable if a competing API simply imposes a minor change on one or more function names, parameters and/or definitions? For example, would the competing API definition be infringing?

    // Copyrighted API prototype
    void SomeFunction( char* text, int number );

    // Competing API prototype
    int SomeFunction( char* text_value, int numeric_value );

    Due to the differences in parameter names and return types, these are clearly different API definitions. In fact, the competing API prototype might be better (innovative) as it returns a value, thus providing more information than the copyrighted API prototype, which returns no information at all.

    Using your argument, the competing API would not be infringing. However, from the third-party developer's perspective, moving from the copyrighted API to the competing API would require little or no change to their application source code.

    In the the next example, the API's are identical except for the function names.

    // Copyrighted API prototype
    void SomeOtherFunction( char* text, int number );

    // Competing API prototype
    void SomeOtherFunctionEx( char* text, int number );

    Here, the API's are clearly different, and would require changing the application source code to work with the new API interface. As such, the copyright could not be enforced. However, with a simple compiler directive, a third-party developer could make the competing API prototype look exactly like the copyrighted API prototype at compile time, and thus use the competing API with no source code changes.

    #ifdef __compatibility_mode_on__
    # define SomeOtherFunction SomeOtherFunctionEx

    I will agree with you that extending copyright protection to API's might be a good thing in theory, but in reality, they will either be entirely unenforceable or so onerous that they will stifle competition, innovation, and growth.