Copyright of API is recent silent addition in fine prints sometimes with Business Source License, which is intended to crowd fund coding for free. There is quite turbidity in recent time around the abuse of abnormal Business Source License by Rhodecode, previously EyeOS overnight went 100% closed source software after collecting contribution from the community. As there some turbidity with EyeOS, now Business Source License is being added as replacement. Copyright of API is kind of recent news – Google and Oracle, went to Court to fight on Oracle’s patent claims on Google’s Android operating system Java API.
Understand The Complexity Before Understanding The Copyright of API
Whatever the outcome became is not important, the recent facts definitely shows Richard M. Stallman is right about the rigidity for labeling a Software as Free Software with GNU GPL 3.0 Compatible License. For example, Debian allows to install Closed Source software, it is dangerous as the young developers will never realize what he/she pulled from any software repo has complex license. Take that, he/she contributed for debugging or improvement in terms of features without any hope of monetary gain. Suddenly when the software will show the claw, flaw will become apparent. So, Debian if allows to install known Closed Source software, it can create problem for sure – we gave worser examples.
There are blogs which promotes advanced usage of so called “free softwares”, mostly these softwares are from Google and Microsoft. One must download the software, change name and logo, upload to any public code hosting website and notify the original software distributor if they have any problem. For real Free Software, this is allowable but these companies can have abnormal License hidden as text file in some subdirectory. Microsoft Windows is closed source software – but they are clear about being closed source. Author had problem with Opera for a snippet. Opera clearly said, the snippet is their property. So a big lesson is – one must not waste time behind any closed source software (unless paid). Second lesson is, claimed Free Softwares must be tested by downloading and uploading in the way we described. Third part will be discussed here, which the title reads – Copyright of API Means Pushing To Use Cloud Abstraction.
---
Copyright of API Means Pushing To Use Cloud Abstraction
The Google-Oracle Java fight event has a great impact on the entire software industry that often relies on API to make it compatible for some features of competing applications. The opportunity to be part of the companies to extend the right of copyright even on the API would create considerable problems for the competition, which hereafter may be in the position of having to pay in order to be able to integrate the application for software which are developed for in-house usage.
This situation is even more difficult for the cloud world, where the vendor uses the API to ensure that the users can avoid the much-discussed lock-in imposed by some providers, and to allow the customers to transfer their workloads from one cloud to another, in a simple and painless process; if we want to give an easy example.
The copyright on the API could prevent OpenStack to shake hands with the competitor Amazon AWS which creates a bridge between the two clouds; it could lead to a halt in the development of Jumpgate project supported by IBM. In short, the legal issues could cripple a computer science tradition that until now had been consolidated into one area of ‹‹the cloud, where it was important to give users the freedom of choice. For that reason, despite Richard M. Stallman’s red alert on Ubuntu and Cloud; developers contributed, wrote and promoted. Most of these developers either has a service or are hobbyists.
OpenStack is given as example, it is really a Free Software.
In fact, when the customers want to move workloads between different cloud providers, for the sake of policy implementation for disaster recovery and high availability, to handle different workloads on different types of platforms (private and public) it is practically not possible to use 3-4 different providers to build one architecture.
If the API and copyright make everything impossible, we have to look elsewhere, such as the approach via abstraction.
Copyright of API Means Pushing To Use Cloud Abstraction : Business Advantages
The legal dispute between Oracle and Google, in fact, allows to abandon the old method based on API and take advantage of a better approach based on an abstraction layer, which is able to interpret each cloud offering and provide the necessary resources to workloads based on the characteristics of each cloud.
Some cloud management platforms already are taking the advantage of an abstraction layer allowing the individual to decouple workloads from specific cloud infrastructure provider and the individual describing the processes to be executed with universal metadata, designed to indicate the necessity of primitive execution, as the needs in terms of computing, storage, network and security features – it may be considered as generic and applicable on any cloud infrastructure.
At the same time, the approach towards abstraction would allow the individual providers to define the advanced features capable of giving the offer with a competitive advantage over the competition, without the limitations imposed by the API. For the customers, it would preserve the opportunity to move workloads from one cloud to another, even if the first supports the feature that the second does not possess.
In fact, with the different cloud vendor APIs will never be 100 percent compatible, because in order to meet this requirement it would limit the possibility of innovation and competition between each individual provider. With the system abstraction, however, it would be guaranteed to use a specific feature of a vendor which absent in another.
