No Copyrights on APIs: Help Us Make The Case
eff.org
eff.org
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.
On the flip side, API copyrights could be rendered moot by simply reverse engineering everything, which isn't really that hard.
Secondly exactly what is it a solution to?
Have you considered any possible costs or downsides to the proposal?
Whether it is or isn't hard will depend on the size and scale of the API that you are trying to recreate. It is probably hard enough that it would normally be easier to create your own API except where you were doing it to create an alternative platform for existing code.
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.
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.
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.
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...
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.
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?
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.
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.
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).
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?
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.
What distinguishes an API is that it is by definition the unambiguous formal specification of the implementation's function. A function can only be used if the provider and user of the interface agree. Once one side is established, it removes all opportunity for creativity from the other. If the library provides "sort(container&, iterator start, iterator end)" then that's how the user has to call it; you have no choice. And if the user code calls it that way then every library implementation must implement it that way.
APIs are in a bit of a curious situation in that making them can be a creative activity but then the act of specifying them makes the specification functional. But if you think about it, it isn't really all that novel. It happens anywhere you have an interface between functional components of anything -- you can make the interface decorative, but you can't use that to exclude competitors from the market, because by incorporating what would otherwise be decoration as a necessary part of the interface, you make it inherently functional. You can't exclude competitors from making screw drivers compatible with your screws (or screws compatible with your screw drivers) just by using an arbitrary new screw head and then trying to claim copyright over it. (Naturally utility patents are a different animal.)
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-...
?
IFTTT, Zapier, Webshell.io, Webscript.io, Elasctic.io, Apiary.io, Opalang.org, Rules.io etc...we have something to bring to api@eff.org
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?