"I'd always rather err on the side of openness. But there's a difference between optimum and maximum openness, and fixing that boundary is a judgment call. The art of leadership is knowing how much information you're going to pass on -- to keep people motivated and to be as honest, as upfront, as you can. But, boy, there really are limits to that."
Two current trends in software development are the open source paradigm and the notion of software as a service. The combination of these has lead to the concept of open APIs and mashups. Since late 2005, there has been a rapid proliferation of applications, referred to as mashups, that combine data and services provided by third parties through open APIs with data sources owned by users. Open APIs give users access to the data or services of an information technology (IT) platform. A well-known example is the Google Maps API which generates maps for a given location, whose output can be combined with other data and services into mashups.
Combining services and data from multiple sources raises several issues related to intellectual rights in mashups. However, the concept of mashups is currently in a nascent stage, and service and data providers often underestimate the relevance of these issues. In this paper we give an overview of open API licensing and provide examples from current open APIs. We then briefly discuss licensing of open APIs.
Objectives of an Open API License
The objectives of an open API license are similar to the objectives of a software license. These objectives can be summarized as follows:
- To define the extent to which the API can be used without constituting an infringement.
- To have a remedy against the con- sumer for complaints which do not constitute an infringement of copy- rights.
- To limit the liability of API providers in case of failure of the API.
Anatomy of an Open API License
In this section we describe the anatomy of an open API license. We do not claim that the given anatomy is complete as it is almost impossible to generalize all the terms of a license. Furthermore, this article is not intended as a substitute for legal advice and we highly recommend service providers and service consumers to obtain appropriate legal counsel to make use of licenses for their open APIs.
- Subject: the subject of the license relates to the definition of the open API being licensed. It defines some related information about the open API and may include a unique identification code for the API, name, and other relevant information.
- Scope of Rights: the following rights in an open API allowing extraction and re-utilization of the whole or a substantial part of services and data:
- usage: indicates a set of methods in which the service and data can be consumed
- reuse: indicates a set of operations in which the service and data, or portions of it, can be re-utilised
- transfer: indicates a set of procedures in which the rights over the service and data can be used
The scope of rights of an open API license reflect what can be done with the open API. For example, the clauses of the Google Maps API terms include the following:
"If you develop a Maps API Implementation for use by other users, you must:
- Attribution: copyright law refers to attribution as the requirement to acknowledge or credit the author of a work which is used or appears in another work. Attribution signifies a decent sign of respect to acknowledge the creator.
Flickr requires the following attribution terms:
"You shall place the following notice prominently on your application: "This product uses the Flickr API but is not endorsed or certified by Flickr.""
- Non-Commercial use: commercial uses and non-commercial uses are differentiated by Flickr as follows:
"Flickr is committed to free and open access to our APIs for commercial and non-commercial purposes. However, providing the APIs does have real costs for Flickr. For uses of Flickr APIs over a certain rate or for certain types of commercial applications, Flickr reserves the rightto charge fees for future use of or access to the Flickr APIs."
- Information Rights: the rights over the data created or modified by an open API based on the input from consumers is owned by the consumers. However, API providers can transfer such information to third parties.
These are some of the clauses defining information rights provided by the Google Friend Connect APIs:
"You agree that Google may transfer and disclose to third parties personally identifiable information about you for the purpose of approving and enabling your use of the Services, including to third parties that reside in jurisdictions with less restrictive data laws than your own.
Google may share non-personally-identifiable information about you, including Web site URLs, site-specific statistics, and similar information collected by Google, with advertisers, business partners, sponsors, and other third parties. In addition, you grant Google the right to access, index and cache your Web sites, or any portion thereof, including by automated means including Web spiders or crawlers."
- Financial Terms: often, open APIs are charged on a pay-per-use or transaction base. This transaction-based model allows API providers to charge for each use, as the license defines the term "use." The use of the API can be continuously recorded and monitored by service management systems. This model of pricing is quite similar to charging for utilities like electricity and water.
Subscription is an alternative financial model that allows consumers to purchase the open API based services for a fixed term, during which time they automatically receive full support from service providers including any upgrades or feature enhancements.
This is a subset of the clauses of the financial terms of Amazon web services:
"In consideration of your use of any of the Paid Services, you agree to pay applicable fees for Paid Services in the amounts set forth on the respective Service detail pages on the AWS Website (including any minimum subscription fees). You are responsible for any fees assessed by Amazon Payments for transactions that you submit to the Payment Service using Amazon FPS. Fees for any new Service or new Service feature will be effective upon posting by us on the AWS Website for the applicable Service."
- Warranty: in general, an open API is licensed by the licensor "as is" and without any warranty of any kind, either express or implied, whether of title, of accuracy, of the presence or absence of errors, of fitness for purpose, or otherwise.
These are the some of the warranty clauses of the Google Maps API:
"YOU EXPRESSLY UNDERSTAND AND AGREE THAT YOUR USE OF THE SERVICE AND THE CONTENT IS AT YOUR SOLE RISK AND THAT THE SERVICE AND THE CONTENT ARE PROVIDED "AS IS" AND "AS AVAILABLE."
ANY CONTENT OBTAINED THROUGH THE USE OF THE GOOGLE SERVICES IS DONE AT YOUR OWN DISCRETION AND RISK AND YOU WILL BE SOLELY RESPONSIBLE FOR ANY DAMAGE TO YOUR COMPUTER SYSTEM OR OTHER DEVICE, LOSS OF DATA, OR ANY OTHER DAMAGE OR INJURY THAT RESULTS FROM THE DOWNLOAD OR USE OF ANY SUCH CONTENT."
- Limitation of Liability: limitation of liability clauses limit the liability of the licensor and the licensee under the license agreement. Under this clause, both parties disclaim liability for unforeseeable damages, such as network errors or hosting server problems, or indirect damages. Limitation of liability clauses often include a ceiling for monetary liability.
The limitation of liability clause of Flickr is as follows:
"FLICKR SHALL NOT, UNDER ANY CIRCUMSTANCES, BE LIABLE TO YOU FOR ANY INDIRECT, INCIDENTAL, CONSEQUENTIAL, SPECIAL OR EXEMPLARY DAMAGES ARISING OUT OF OR IN CONNECTION WITH USE OF THE FLICKR APIS, WHETHER BASED ON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE, PRODUCT LIABILITY OR OTHERWISE), OR ANY OTHER PECUNIARY LOSS, WHETHER OR NOT FLICKR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. UNDER NO CIRCUMSTANCES SHALL FLICKR BE LIABLE TO YOU FOR ANY AMOUNT."
Conclusion and Future
Licenses for open APIs reflect the differences between traditional software and web services as they govern the execution, reuse and composition of services and data exposed by third-party systems. It is common for API providers to offer some of their APIs for free and others for pay. A provider can even use separate terms for the same API by offering different licenses for high-end and low-end versions of the service provided by the API. The common ways for a provider to impose constraints on the execution of a service include limiting requests, results, and quality.
In the future, we believe that more open APIs will begin to be licensed using open source licenses. While the source code of the interface of an open API is always available, open sourcing an open API makes the source code of the API implementation available in addition to the source of its interface. In this case, users would be able to modify an API, or derive new APIs from an open API. However, in order to avoid license forking, providers would like to prevent the new open API from being licensed differently from the parent API. In this way, the value added by the changes can be returned to the community of users of the parent API. At present, very few open APIs fit the description of being open sourced. One example is WikiDot, a wiki service with an open API that is licensed under the GNU Affero General Public License. We expect more open APIs to be available under an open source license in the near future.
Analyzing Software Licenses in Open Architecture Software Systems