4 ms·

No Copyrights on APIs: Help Us Make The Case

135 points by apievangelist 14y ago

spullara 14y ago
Honestly if something is silly as several musical notes can be copyrighted, I don't see how you could argue something as complicated and full of creative work as an API can't be. Instead, I think we need something more like the reverse-engineering or parody laws. Allow them to be reimplemented as long as it is clearly called out that they are not the original creative work of the reimplementing party. It would lead to effectively the same thing and would give the original creator credit.
- baddox 14y ago
  To be fair, some of us don't think musical notes should be copyrighted either. Or maybe it's just me.
- chc 14y ago
  That isn't how the "fair use" defense for satire (not parody!) works, nor is that the purpose of it. And it is unclear that an API is full of creative work in the sense of what copyright covers. JK Rowling could have written the Harry Potter books in the first person and still told the same story, but she chose not to. Books are full of all sorts of choies like that. But if you change an API, it is no longer the same API and no longer capable of interacting with a program that implements the original API. There is no room for creativity, because differences are functional. Copyright doesn't cover function — that's what patents are for. This isn't to say that APIs can't be well designed or poorly designed — just that insofar as they are mere information about how you interact with a system, they are not copyrightable. Information is not copyrightable.
  - josephlord 14y ago
    I have some sympathy for this argument although in what way does this argument that the creative expression in API design is functional and therefore uncopyrightable not actually apply to all software? I'm not sure that leads us to a good place as that would only leave patents to protect software.
    - jbri 14y ago
      If you change the API design in any way, it no longer fulfills its purpose - interoperating with other software that uses that API. Hence, API design is functional. However, you can change the design of a piece of software (for example, a user interface) while having it still be able to fulfill its purpose. So in the general case, software design is not necessarily strictly functional.
      - mehdim 14y ago
        Some thoughts between facts, compilation and original work of authorship http://en.wikibooks.org/wiki/US_Copyright_Law/Copyrightable_Works http://en.wikibooks.org/wiki/US_Copyright_Law/Copyrightable_... Does a orignal list of URLs is copyrightable? If you follow the copyritht , yes. But an other URL compilation of the same API which would be a kind of "list" (alphabetical for example) would not... In all cases, if original URLs lists are copyrightable, Google results too are under copyright, because they are sorted by pagerank, which is an orginal way to sort links...
      - josephlord 14y ago
        I up voted both you an AnthonyMouse for good clarifying comments that move the debate forward. Do you think it is then legitimate to partially copy an API making sufficient changes for it to be largely incompatible (certainly not a drop in replacement)? In this scenario the functional element is lost in the copy but not the creative element.
        AnthonyMouse 14y ago
        I assume you're referring to what Google did, i.e. implementing a subset of the API but not the whole thing. But in that case I wouldn't agree that the functional element is lost. It continues to exist exactly to the extent that they copied the API -- the functions they copied are compatible. Any code using those functions will compile against both. (Incidentally, it feels like a very strange argument for Oracle to say that the problem with what Google did is that they didn't copy enough.) I suppose you could argue that it's theoretically possible to copy the creative elements from an API while specifically setting out to break all compatibility, but it's hard to say what that would even look like. You can't break compatibility without changing the function signatures, but if you change substantially all of the function signatures then it's arguably a completely independent API. More importantly, it seems like this would be more of a theoretical problem than one seen in practice -- the only practical reason to copy an API is to achieve partial or complete compatibility. Can you provide any example of an API being copied for reasons other than achieving compatibility?
  - chc 14y ago
    Just so as not to misinform: I did a quick edit before running out the door, and the bit I added about satire and parody, I got backwards. That should have read "parody (but not satire!)". I think it would show how very specific the idea is, but I don't want to spread misinformation. Just an FYI.
icholy 14y ago
this would be a stepping stone to copyrighting design patterns ... shrug
josephlord 14y ago
I don't buy the SAMBA example in the original article. As I understand it they reverse engineered the API/protocol from the on the wire network traffic. This would to me make it not a case of literal copying and therefore not infringing a copyright in the API (if it exists). The equivalent for a general API would be avoiding the documentation and the actual API files (headers etc.) and developing an alternative implementation from examples of client code and the behaviour observed of the library when tested with inputs. This may be the answer, allow APIs to be copyrighted (in general - some may be too trivial to be copyrightable where there are limited sensible approaches) but allow the reverse engineering of behaviour. Of course it would be possible to grant licenses to the the API and it may be sensible to consider the flexibility of the API license when choosing to use a library, webservice or framework and the difficulty of transferring away from it to an alternative supplier.
- nitrogen 14y ago
  It's much less ambiguous to exclude APIs from copyright. Otherwise, you'll have endless battles trying to prove that someone really did have access to the API documentation, or some derivative work thereof. Or, someone will argue that reverse engineering an API should not be permitted. On the flip side, API copyrights could be rendered moot by simply reverse engineering everything, which isn't really that hard.
  - WhaleCormbit 14y ago
    This is correct, doing away with API copyright all together is only solution.
    - josephlord 14y ago
      'only solution' that is a very absolute response, is there not even room for discussion? I would have downvoted you if I could and I have upvoted comments I don't agree with in this thread that added depth and thought to the discussion. Secondly exactly what is it a solution to? Have you considered any possible costs or downsides to the proposal?
  - 14y ago
LyleKop 14y ago
I thought APIs had been established as non-copyrightable by numerous precedents, e.g. Lotus v. Borland, Apple v. Microsoft. Why do we need to go through this again? The US Copyright Law Chapter 12 provides for reverse engineering, for the purpose of interoperability. So that would seem to negate any defense of copyright of an API, whose sole purpose is interoperability.
mehdim 14y ago
Any creative content or writing can be copyrightable. But in the case of Oracle vs Google, the end of the case was that an API is just no more than a list of rules and URLs, nothing "creative". And a list is not copyrightable. Think to the Yellow Pages for examples. No Copyright on name, address and numbers (hopefully) , because no specific form or shape to these writings. The case is to define if design an API is more than listing URLs. I don't think so, and the Judge Alsup of Oracle vs Google who was developer too, said the same thing. But API providers will try to not accept this. Do you remeber Twitter's message to developers http://apijoy.tumblr.com/post/34350096121/twitter-api-teams-message-to-developers http://apijoy.tumblr.com/post/34350096121/twitter-api-teams-... ? IFTTT, Zapier, Webshell.io, Webscript.io, Elasctic.io, Apiary.io, Opalang.org, Rules.io etc...we have something to bring to api@eff.org
dmpayton 14y ago
2. Reimplementation of an API, where the resulting software benefitted the original API creator, perhaps by increasing the creator’s user base or otherwise benefitted the developer community. Would this cover a language-specific wrapper around an HTTP API? For example, I wrote a Python library for the iHackerNews API[0]. Would something like that count as a reimplementation for the purposes of their request? [0] https://github.com/dmpayton/python-ihackernews https://github.com/dmpayton/python-ihackernews
njyx 14y ago
Some thoughts on why a legal precedent probably isn't enough: http://www.3scale.net/2012/11/the-case-against-api-copyright-and-the-need-for-an-interface-commons/ http://www.3scale.net/2012/11/the-case-against-api-copyright...

135 points by apievangelist 14y ago

Honestly if something is silly as several musical notes can be copyrighted, I don't see how you could argue something as complicated and full of creative work as an API can't be. Instead, I think we need something more like the reverse-engineering or parody laws. Allow them to be reimplemented as long as it is clearly called out that they are not the original creative work of the reimplementing party. It would lead to effectively the same thing and would give the original creator credit.

baddox 14y ago
To be fair, some of us don't think musical notes should be copyrighted either. Or maybe it's just me.
chc 14y ago
That isn't how the "fair use" defense for satire (not parody!) works, nor is that the purpose of it. And it is unclear that an API is full of creative work in the sense of what copyright covers. JK Rowling could have written the Harry Potter books in the first person and still told the same story, but she chose not to. Books are full of all sorts of choies like that. But if you change an API, it is no longer the same API and no longer capable of interacting with a program that implements the original API. There is no room for creativity, because differences are functional. Copyright doesn't cover function — that's what patents are for. This isn't to say that APIs can't be well designed or poorly designed — just that insofar as they are mere information about how you interact with a system, they are not copyrightable. Information is not copyrightable.
- josephlord 14y ago
  I have some sympathy for this argument although in what way does this argument that the creative expression in API design is functional and therefore uncopyrightable not actually apply to all software? I'm not sure that leads us to a good place as that would only leave patents to protect software.
  - jbri 14y ago
    If you change the API design in any way, it no longer fulfills its purpose - interoperating with other software that uses that API. Hence, API design is functional. However, you can change the design of a piece of software (for example, a user interface) while having it still be able to fulfill its purpose. So in the general case, software design is not necessarily strictly functional.
    - mehdim 14y ago
      Some thoughts between facts, compilation and original work of authorship http://en.wikibooks.org/wiki/US_Copyright_Law/Copyrightable_Works http://en.wikibooks.org/wiki/US_Copyright_Law/Copyrightable_... Does a orignal list of URLs is copyrightable? If you follow the copyritht , yes. But an other URL compilation of the same API which would be a kind of "list" (alphabetical for example) would not... In all cases, if original URLs lists are copyrightable, Google results too are under copyright, because they are sorted by pagerank, which is an orginal way to sort links...
    - josephlord 14y ago
      I up voted both you an AnthonyMouse for good clarifying comments that move the debate forward. Do you think it is then legitimate to partially copy an API making sufficient changes for it to be largely incompatible (certainly not a drop in replacement)? In this scenario the functional element is lost in the copy but not the creative element.
      - AnthonyMouse 14y ago
        I assume you're referring to what Google did, i.e. implementing a subset of the API but not the whole thing. But in that case I wouldn't agree that the functional element is lost. It continues to exist exactly to the extent that they copied the API -- the functions they copied are compatible. Any code using those functions will compile against both. (Incidentally, it feels like a very strange argument for Oracle to say that the problem with what Google did is that they didn't copy enough.) I suppose you could argue that it's theoretically possible to copy the creative elements from an API while specifically setting out to break all compatibility, but it's hard to say what that would even look like. You can't break compatibility without changing the function signatures, but if you change substantially all of the function signatures then it's arguably a completely independent API. More importantly, it seems like this would be more of a theoretical problem than one seen in practice -- the only practical reason to copy an API is to achieve partial or complete compatibility. Can you provide any example of an API being copied for reasons other than achieving compatibility?
- chc 14y ago
  Just so as not to misinform: I did a quick edit before running out the door, and the bit I added about satire and parody, I got backwards. That should have read "parody (but not satire!)". I think it would show how very specific the idea is, but I don't want to spread misinformation. Just an FYI.

icholy 14y ago

this would be a stepping stone to copyrighting design patterns ... shrug

josephlord 14y ago

I don't buy the SAMBA example in the original article. As I understand it they reverse engineered the API/protocol from the on the wire network traffic. This would to me make it not a case of literal copying and therefore not infringing a copyright in the API (if it exists). The equivalent for a general API would be avoiding the documentation and the actual API files (headers etc.) and developing an alternative implementation from examples of client code and the behaviour observed of the library when tested with inputs. This may be the answer, allow APIs to be copyrighted (in general - some may be too trivial to be copyrightable where there are limited sensible approaches) but allow the reverse engineering of behaviour. Of course it would be possible to grant licenses to the the API and it may be sensible to consider the flexibility of the API license when choosing to use a library, webservice or framework and the difficulty of transferring away from it to an alternative supplier.

nitrogen 14y ago
It's much less ambiguous to exclude APIs from copyright. Otherwise, you'll have endless battles trying to prove that someone really did have access to the API documentation, or some derivative work thereof. Or, someone will argue that reverse engineering an API should not be permitted. On the flip side, API copyrights could be rendered moot by simply reverse engineering everything, which isn't really that hard.
- WhaleCormbit 14y ago
  This is correct, doing away with API copyright all together is only solution.
  - josephlord 14y ago
    'only solution' that is a very absolute response, is there not even room for discussion? I would have downvoted you if I could and I have upvoted comments I don't agree with in this thread that added depth and thought to the discussion. Secondly exactly what is it a solution to? Have you considered any possible costs or downsides to the proposal?
- 14y ago

LyleKop 14y ago

I thought APIs had been established as non-copyrightable by numerous precedents, e.g. Lotus v. Borland, Apple v. Microsoft. Why do we need to go through this again? The US Copyright Law Chapter 12 provides for reverse engineering, for the purpose of interoperability. So that would seem to negate any defense of copyright of an API, whose sole purpose is interoperability.

mehdim 14y ago

Any creative content or writing can be copyrightable. But in the case of Oracle vs Google, the end of the case was that an API is just no more than a list of rules and URLs, nothing "creative". And a list is not copyrightable. Think to the Yellow Pages for examples. No Copyright on name, address and numbers (hopefully) , because no specific form or shape to these writings. The case is to define if design an API is more than listing URLs. I don't think so, and the Judge Alsup of Oracle vs Google who was developer too, said the same thing. But API providers will try to not accept this. Do you remeber Twitter's message to developers http://apijoy.tumblr.com/post/34350096121/twitter-api-teams-message-to-developers http://apijoy.tumblr.com/post/34350096121/twitter-api-teams-... ? IFTTT, Zapier, Webshell.io, Webscript.io, Elasctic.io, Apiary.io, Opalang.org, Rules.io etc...we have something to bring to api@eff.org

dmpayton 14y ago

2. Reimplementation of an API, where the resulting software benefitted the original API creator, perhaps by increasing the creator’s user base or otherwise benefitted the developer community. Would this cover a language-specific wrapper around an HTTP API? For example, I wrote a Python library for the iHackerNews API[0]. Would something like that count as a reimplementation for the purposes of their request? [0] https://github.com/dmpayton/python-ihackernews https://github.com/dmpayton/python-ihackernews

njyx 14y ago

Some thoughts on why a legal precedent probably isn't enough: http://www.3scale.net/2012/11/the-case-against-api-copyright-and-the-need-for-an-interface-commons/ http://www.3scale.net/2012/11/the-case-against-api-copyright...