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.