
No Copyrights on APIs: Help Us Make The Case - apievangelist
https://www.eff.org/deeplinks/2012/11/no-copyrights-apis-help-us-make-case
======
josephlord
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
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
This is correct, doing away with API copyright all together is only solution.

~~~
josephlord
'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?

------
LyleKop
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.

------
spullara
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.

~~~
chc
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
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
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.

~~~
josephlord
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
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?

~~~
josephlord
What Google did is an interesting example but at least jbri's comment referred
to breaking functionality if you changed it at all so it needed to be copied.

Oracle did make the point that Google didn't copy enough for compatibility and
Write Once Run Anywhere effectively forking their entire ecosystem/platform
without a license. It has killed Java on mobile (although maybe it would have
happened anyway and maybe it is a good thing with Oracle running the show). I
think that if the participants in the case hadn't been the most hated and
loved companies in tech many people might have had a different view of the
case.

There are a number of other reasons for copying an API than compatibility.

1) Its an efficient (lazy?) way to get to a well designed API without you
having to do multiple rounds of iterative design as users hammer on it over
several years.

2) Existing documentation can be used. [Documentation, tutorials StackOverflow
answers].

3) Users are already familiar with it.

It seems to me that Google did a pretty vicious embrace, extend, extinguish on
mobile Java and they may still be the better custodians of the platform but
I'm not sure the behaviour is actually acceptable in general. They took
maximum benefit from Sun's efforts to create a platform and a community and
give the absolute minimum back. Just imagine if it was Microsoft (or even
Apple) in the Google roll and old Sun (rather than Oracle) in the Oracle roll
- would you still feel the same about the case?

Now does this mean I want to be locked into a provider unable to find an
alternative implementer of a required library - absolutely not. But that is a
factor to consider when adopting a platform/library as a cost to be weighed
against the benefits. I always like an exit option or accept significant risk
if I don't have one. Obviously API developers could offer permissive licenses
to the API even if the library itself is closed source as a way to reassure
customers and gain business. I'm not sure law is required OR desirable in this
area.

~~~
AnthonyMouse
>There are a number of other reasons for copying an API than compatibility.

All three of the ones you listed are just advantages of compatibility. You
don't get any of them exactly to the extent that you aren't compatible.

>Just imagine if it was Microsoft (or even Apple) in the Google roll and old
Sun (rather than Oracle) in the Oracle roll - would you still feel the same
about the case?

Sure. Because the problem you're implying would occur is completely different
to the question of copyright over APIs. People object to Microsoft's EEE
because it's anticompetitive -- if it's to be illegal then it should be as an
antitrust violation, not a copyright violation. Which is why many people don't
object to what Google has done -- they're not using it as lock in. It's open
source and you can port their VM to whatever platform you like and run all the
same user code. The only reason you can't run all the Android apps on an
iPhone is that _Apple_ doesn't allow it. I believe RIM actually offered it as
a feature for about five minutes before they realized they also used Oracle
Java(TM) and were too busy going out of business to be fighting with Oracle
over license terms.

Moreover, it's bad policy to allow copying when the implementation is
perfectly compatible but not when it isn't. It says to the small developer
that they can't just patch Kerberos to do the thing they need to talk to
Microsoft software, they have to reimplement all of Active Directory. And if
the implementation adds anything useful then it's not compliant and they're
infringing copyright. Ditto if there are any bugs or the reimplementation
lacks bugs present in the original.

API forks are not inherently evil. Making them copyright violations makes them
inherently prohibited. Better to prohibit the things that actually are evil,
like EEE for anticompetitive purposes.

~~~
josephlord
> All three of the ones you listed are just advantages of compatibility. You
> don't get any of them exactly to the extent that you aren't compatible.

But you are definitely getting beyond it being a pure functional issue. Lots
of other things can also be made easier without copyright.

Competition law may prevent the worse abuses but I expect not all and it can
be terribly slow.

> API forks are not inherently evil. Making them copyright violations makes
> them inherently prohibited. Better to prohibit the things that actually are
> evil, like EEE for anticompetitive purposes.

Copyright in general is not a matter of inherent evil but a balance of rights.
I also agree that forks are not always a bad thing but they could be permitted
by the copyright holders (if API's are copyright).

The benefit of copyright is incentive for investment and creation. I have
general issues about current copyright duration and the limits on
circumvention and fair use/dealing but I'm still not convinced about the
general benefit of non copyrightability of API's.

As I said the lack of a relatively permissive license over the API would put
me off using it unless I had another exit strategy (easier for a simple
library than for a massive framework like Java but the investment is smaller
in creating a simple library).

~~~
AnthonyMouse
>But you are definitely getting beyond it being a pure functional issue.

How so? Creating a compatible piece of software is _functionally impossible_
without using the same API, because that's what the API is. You can't do it.
The fact that compatibility has a lot of advantages doesn't change the nature
of that functional necessity.

>Copyright in general is not a matter of inherent evil but a balance of
rights.

Of course, but that's the point. You weigh the evil against the good. If
someone creates a thing and is a good steward of it then they have a first to
market advantage over competitors in addition to the implementation copyright,
so as long as they're being good stewards and only collecting their creation
costs plus a fair profit, they'll have the market all to themselves because
prospective competitors will see that they can't profitably do any better as
against the need to spend the resources to create another implementation. Only
when a copyright holder is allowing the market to decay or imposing
unreasonable restrictions or pricing on users will there be a sufficient
incentive for others to enter the market, and why in that case does it make
any sense to give the copyright holder the power to prohibit such competition?

>I also agree that forks are not always a bad thing but they could be
permitted by the copyright holders (if API's are copyright).

The problem is that in almost all cases the copyright holder wouldn't allow it
-- a full reimplementation fork is only necessary when the existing maintainer
is doing such a sour job of it that you think you can justify the enormous
reduplication of effort necessary to compete with them, and in that case why
would they sanction a competitor?

~~~
josephlord
The items like people's knowledge and documentation are not purely functional.

You might be a good steward but with high prices due to the education costs
you take on teaching the API to others. Someone can piggy back on your work,
charge a lower price and never do their own further design work.

You can compete without copying the API, just design your own or use an open
source one. Yes it would be hard for people to switch libraries when they have
existing code but it is possible to rewrite the client software.

It is allowed by many copyright holders. Virtually all open source software
and a number of other commercial platforms particularly when the API has been
designed or released by or to an industry consortium.

I see it as a perfectly valid reason not to choose a platform with a closed
API and while I feel sorry for those that are locked to one theynreallynshould
have considered it at the start. I still don't see it as an essential issued.

I've enjoyed this conversation but I suspect no one is watching apart from us
so while I wanted to answer your questions so as not to be rude and ignore
them I plan not to post again on this thread.

------
mehdim
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-...](http://apijoy.tumblr.com/post/34350096121/twitter-api-teams-
message-to-developers)

?

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
_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>

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

------
icholy
this would be a stepping stone to copyrighting design patterns ... _shrug_

