Me and my friend had been arguing about an matter comparable to this! Now I realize that I had been appropriate. lol! Many thanks to the data you article….

It was when I analyzed its data.”

“which you would know if you hadn’t lied through your teeth and been too lazy to do any fact checking at all.”

In any case you are free to download the files from FLOSSmole yourself and contradict our findings. Since no one has done that I assume everyone else is either too lazy or they found that our data was correct

Of the 45,000 projects cataloged by the site-the-was-freshmeat, about 25,000 are GPL family and 1700 are BSD-revised, the highest showing BSD license. Phhht.

I guess some corporate droids will never get why most programmers prefer copyleft.

JL

I wrote a long response at LinuxInsider.
http://www.ectnews.com/perl/board/mboard.pl?board=lnitalkback&thread=5891&id=5896&display=1

In brief, allowing all comers to USE an proprietary API, implemented by proprietary code, does not make the API ‘open’ in any meaningful sense.

Please allow me to suggest that you’re on the scent of a meaningful trend, of which OpenStack is the prime exemplar: that (truly) open APIs are necessary, IN ADDITION TO open source implementations.

Historically, the two have been divorced. Formal standards bodies cared exclusively about APIs, not about implementations. Open source projects cared exclusively about implementations, not about APIs. But now, market forces are putting pressure on open source projects to expose consistent, stable APIs as “first class citizens,” right along with the implementation code.

Therefore, I encourage you to resist the temptation to use the phrase “open API” to describe “proprietary APIs for accessing proprietary implementations of proprietary services.” Instead, I encourage you to call them what they are: “proprietary APIs.” Save the phrase “open APIs” for APIs that are openly designed, openly governed, and implemented via open source.

Fair enough?

Thanks!

Jim Plamondon
Director, Developer Relations
Rackspace

JL

APIs are probably not covered by copyright, the law is still being worked out, so in that sense they are all “open”, although documentation may be copyrighted which can make writing and documenting your implementations harder if the copyright owners make a fuss (see Google v Oracle over JVM API).

Utility arises from having multiple implementations of the same API. It makes it possible to run the same applications on AIX as GNU/Linux creating a market and competition in the OS market.

The problem with closed source implementations behind an API comes when they don’t do what you want, or the implementers aren’t going in the direction you want, or they simply don’t fix a specific bug. If all the implementations are closed you are then at an impasse. Particularly troublesome if the supplier(s) has(have) some reason not to support you, such as they are in competition.

If at least one implementation is free software (note not Open Source, because that might not convey sufficient rights) you avoid the impasse.

However APIs controlled by a single implementer are rife with the usual traps of proprietary software.

I wrote a server side implementation of the Google Gadgets API, and was able to run a selection of third party Google gadgets from my own webserver without any contact with Google. The day I finished it (it didn’t take long) Google released the next version of the Google Gadget specification, extending it way beyond what we would have time to implement. So whilst the implementation was great for the old style gadgets you end up chasing someone else’s tail if you want to support all gadgets.

Of course the route to avoiding this chasing is always to adhere to APIs for which there is a free software implementation. And if you are doing that, using the free software implementation guarantees you won’t extend your application to use newer aspects of the API, and that you won’t accidentally lock yourself out of a free software implementation. At that point it is both “free enough” and you will be able to take action to keep it all working should you need to.