Lets not forget another feature of web APIs that makes them loved by the enterprise.
The ability to make use of open source tooling, driving the cost down to zero, without giving anything back, because customers cannot prove what technology stack is being used.
The ability to make use of open source tooling, driving the cost down to zero
Because their employees' time is worthless?
without giving anything back
Isn't this a bit of a red herring? Local forks have a maintenance cost, so there is still an incentive to contribute and improvements back upstream (isn't this why BSD-licence projects do not in fact receive zero contributions from corporate users?). Conversely, posting source tarballs full of unmergeable (whether due to style, quality, or incompatibility) changes doesn't help anyone.
because customers cannot prove what technology stack is being used
This is false. Open/free licenses do not (cannot) restrict use, because they work by allowing things that copyright laws would otherwise forbid (which is why AGPL cannot be considered a True Open/Free License). Whether or not customers can prove or know what stack is being used, is completely irrelevant.
Free licenses always restrict use. You cannot use them without sharing your changes. I don't know what an "Open/free" license is, but if it's your invention, I guess you get to define what a "True" one is.
First, not all free licenses require you to share changes. See, for example, the MIT and BSD licenses. They only require that you preserve the copyright notice, and refrain from suing the original authors.
Second, even the GPL doesn't stop you from using a modified version, just from distributing modified versions without the source code. From the preamble to the GPL "if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received."
The fact that web services don't actually distribute software at all is what inspired the AGPL license in the first place.
Finally, "open/free" refers to the distinction between "open source" licenses as defined by the Open Source Initiative (opensource.org) and "free software" as defined by the Free Software Foundation (fsf.org). As a practical matter, they are similar, but the two organizations have different philosophies.
Free licenses always restrict use. You cannot use them without sharing your changes.
You managed to compress several errors in just two sentences. Free licenses aim to unrestricted use, that's their very reason to be. Search for "software freedoms". You're not forced to share changes, except in very few licences like MPL. Some (not all) free licenses ask you to distribute source for derivative works. Most ask you neither.
Free licenses always restrict use. You cannot use them without sharing your changes.
From section 0 of the GPLv2:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted
That seems to be explicitly not restricting use, yes?
I don't know what an "Open/free" license is
The Open Source and Free Software people tend to use similar (and often the same) licenses, even tho they don't like eachother and can't agree on anything (or rather they only agree until someone points out that they're agreeing, at which point they start nitpicking on their ideological differences).
In practice, this is a non-issue. Aside from drivers (without which you can't run your hardware), you really don't want that code. My years in the Enterprise side taught me that the more upper-management worries about "protecting the IP", the less actual value said IP has.
> because customers cannot prove what technology stack is being used.
Morals aside, this is not typically the case. You can legally run GPL software as a service without contributing back, for example. The AGPL fixes this loophole but as far as I am aware is seldom used. (IANAL etc.)
AGPL isn't exceptionally common, but it's used in a reasonable number of SaaS type niches, where the other common license is "don't release source at all". For example, Launchpad and Gitorious are AGPL, while their main competitor, Github, is closed-source.
Ghostscript is probably the most widely used piece of AGPL software. That one's driven mostly by their dual-licensing strategy (they want proprietary SaaS providers to buy the commercial version of Ghostscript).
One major complication with that for modern web applications is that many don't consider sending javascript to the client as distributing the software (as it is not distributed as a whole) which most putting such software out there under the GPL would assume that the client side code counts as distributing the library to the end user just as much as sending it in a compiled executable would.
I agree completely with the general proposition that APIs are similar to patents in the incentives it creates to open up data (similar to opening up knowledge) while retaining control through the T&Cs (similar to the monopoly granted through patent). The result is also similar in that APIs are spurring a wave of innovation just like we saw in the industrial revolution.
A few points worth bearing in mind:
1) There is no monopoly, so ultimately no API provider can abuse their power without limit
2) This is reinforced by the fact that the API interface itself cannot be patented (though some have tired and disputed it in courts), so one provider can be replaced by another
3) Nevertheless some API providers with strong market power (e.g. Twitter) have trampled on the rights of API consumers (even if they were legally within their rights as described in the T&Cs)
Ultimately it is up to us in the API community to recognize good API practices, and to bring down those API providers who abuse their power.
Was this in English? Maybe that would help explain how the author got so much wrong.
I love API's. I love sharing API's with others. I might have even gone along with the article if it said that API's were the best way to show that you have a technology that isn't patentable and enforce a measure of control over it.
You could write a TOS that says that users of the API can't reverse engineer, compete with for a period of one year, blah, blah, blah.
As such you could rope some companies which would do some "build or buy" research in to using your API and then not being able to not use you after.
I don't really believe that, but I could at minimum not faulted the author for this belief.
This article is just a piece of marketing filled with misinformation and poorly written. Don't take any legal advice from it, and don't take any business advice from it.
I would suggest a change of title. "Open" in title hints at non-proprietary APIs, which doesn't make sense. A better word would be "public" (admittedly not perfect though). Maybe just remove it, like this: "APIs are the new software patents"?
Openness for APIs is about to be Accessible, to be Public, to be Neutral and to be Re-usable without restrictions.
So to be Public is one of the part of to be Open, in my opinion of course.
Some people have made a larger definition about openness http://opendefinition.org/okd/
It is the last one of openness requirements ("Re-usable without restrictions") that bothers me. However I realize that other might understand the title as intended... In other words, I should probably add "YMMV" to my original comment. :)
It was "copyright troll" You can consider it at a API oriented "patent troll".
This proves that some API providers want to keep juridical and commercial protection out of their APIs, as it was a patent.
Have you seen all the recent API Terms of service changes because of competiting business model of 3rd party applications?
Moving beyond the multiple typos, broken English, and weird linebreaks,
which are extremely distracting and majorly detract from the author's
points --
Author's analogy (Prop. APIs == Patents) is completely false.
These juridical and technical restrictions and
business dependance [sic] with specific licensing
defined by ToS are a new kind of patent.
I call bullshit! If anything, APIs are protected by copyright law,
which prevents copying.
Not to mention that a patent is protected by the state (hint: that's
why it's called the United States Patent and Trademark Office),
whereas Terms of Service are contracts between private parties that
are entered into voluntarily.
The basic right of a patent is that of exclusion -- i.e., excluding
others from "practicing" your invention (usually defined as producing,
offering for sale, or importing).
However, if you don't like some company's API, there are perfectly legal
ways to clone the backend service and construct an API that is basically
identical.
If there is a monopoly power on behalf of proprietary APIs, it's created
by market inertia and NOT by a state-granted artificial legal
monopoly.
I'm getting a little sick of non-lawyers getting away with posting
stupid analogies with linkbaity titles. If you want to attack the
patent system, fine. But please, for the love of God, do 10 minutes of
research first.
>there are perfectly legal ways to clone the backend service and construct an API that is basically identical.
>If there is a monopoly power on behalf of proprietary APIs, it's created by market inertia and NOT by a state-granted artificial legal monopoly.
Or it's created by the investment necessary to retool everything to work with a "basically identical" API which cannot be substantially identical. I wonder if they'll be a market for people that come up with synonyms so that companies offering an identical service with entirely different codebase can avoid duplicating copyrighted calls. Maybe we can download shims from torrent sites?
The ability to make use of open source tooling, driving the cost down to zero, without giving anything back, because customers cannot prove what technology stack is being used.