The 'Cloud Computing Bill of Rights': 2010 edition

Here's an updated edition of a post I wrote in August 2008 that outlined a possible Bill of Rights for cloud consumers, vendorsm and governments.

In August of 2008, I wrote a blog post that generated quite a bit of discussion among the cloud-computing and Internet communities of the time. The post described what I felt was a simple "bill of rights" of sorts for the consumers and vendors of cloud-computing services.

Flickr/Thorne Enterprises

Later that month, I posted an update that incorporated feedback from a variety of sources, and added some provisions targeted at governments' relationship with both cloud providers and cloud consumers. That post generated even more discussion, as people from both the technology and legal communities took notice and contributed their thoughts.

Recently, I've been receiving an increasing amount of feedback from folks that the rights outlined in those posts should be updated again to reflect the current cloud-computing market and what we've learned about the effect of technology, culture and law on the use of these services.

Remember that the text is meant simply as an outline for an expected relationship between cloud vendor (and their suppliers, if applicable) and consumer (and their customers, if applicable), and aims at protecting the core interests of both. As regulation and law can have a profound effect on that relationship, expectations of governments' roles and responsibilities are also reflected.

This edition owes special thanks to Gordon Haff and Benjamin Tseng for their input on patent abuse and breach/outage communication protocols, respectively.

In reality, this statement is only worth the disk space it is delivered from, and there are already arguably several violations of key tenets in the market today. But by republishing this post with updates, I hope to keep driving the conversation around what are and are not reasonable expectations on behalf of the various parties participating in the cloud computing economy.

The Cloud Computing Bill of Rights, 2010 edition

In the course of technical history, there exist few critical innovations that forever change the way technical economies operate; forever changing the expectations that customers and vendors have of each other, and the architectures on which both rely for commerce. We, the parties entering into a new era driven by one such innovation--that of network based services, platforms, and applications, known at the writing of this document as "cloud computing"--do hereby avow the following (mostly) inalienable rights:

Article I: Customers Own Their Data

  1. No vendor (or supplier of service to a vendor) shall, in the course of its relationship with any customer, claim ownership of any data uploaded, created, generated, modified, hosted, or in any other way associated with the customer's intellectual property, engineering effort or media creativity. This also includes account-configuration data, customer-generated tags and categories, usage and traffic metrics, and any other form of analytics or metadata collection.

    Customer data is understood to include all data directly maintained by the customer, as well as that of the customer's own customers. It is also understood to include all code and data related to configuring and operating software directly developed by the customer, except for data expressly owned by the underlying infrastructure or platform provided by the vendor.

  2. Vendors shall always provide, at a minimum, API level access to all customer data as described above. This API level access will allow the customer to write software which, when executed against the API, allows access to any customer-maintained data, either in bulk or record-by-record as needed. As standards and protocols are defined that allow for bulk or real-time movement of data between cloud vendors, each vendor will endeavor to implement such technologies, and will not attempt to stall such implementation in an attempt to lock in its customers.

  3. Customers own their data, which in turn means they own responsibility for the data's security and adherence to privacy laws and agreements. As with monitoring and data access APIs, vendors will endeavor to provide customers with the tools and services they need to meet their own customers' expectations. However, customers are responsible for determining a vendor's relevancy to specific requirements, and to provide backstops, auditing, and even indemnification as required by agreements with their own customers.

    Ultimately, however, governments are responsible for the regulatory environments that define the limits of security and privacy laws. As governments can choose any legal requirement that works within the constraints of their own constitutions or doctrines, customers must be aware of what may or may not happen to their data in the jurisdictions in which data resides, is processed or is referenced. As constitutions vary from country to country, it may not even be required for governments to inform customers what specific actions are taken with or against their data. That laws exist that could put their data in jeopardy, however, is the minimum that governments convey to the market.

    Customers (and their customers) must leverage the legislative mechanisms of any jurisdiction of concern to change those parameters.

    In order for enough trust to be built into the online cloud economy, however, governments should endeavor to build a legal framework that respects corporate and individual privacy, and overall data security. While national security is important, governments must be careful not to create an atmosphere in which the customers and vendors of the cloud distrust their ability to securely conduct business within the jurisdiction, either directly or indirectly.

  4. Because regulatory effects weigh so heavily on data usage, security and privacy, and location is key to determining which regulations and laws are in effect, vendors shall, at a minimum, inform customers specifically where their data is housed. A better option would be to provide mechanisms by which users can choose where their data will be stored. Either way, vendors should also endeavor to work with customers to assure that their systems designs do not conflict with known legal or regulatory obstacles. As noted earlier, however, ultimate responsibility for data security and legality remains the responsibility of the customer.

    These rights are assumed to apply to primary, backup, and archived data instances.

Article II: Vendors and Customers Jointly Own System Service Levels

  1. Vendors own, and shall do everything in their power to meet service level targets committed to with any given customer. All required effort and expense necessary to meet those explicit service levels will be spent freely and without additional expense to the customer. While the specific legally binding contracts or business agreements will spell out these requirements, it is noted here that these service level agreements are entered into expressly to protect both the customer's and vendor's business interests, and all decisions by the vendor will take both parties equally into account.

    Where no explicit service level agreement exists with a customer, the vendor will endeavor to meet any expressed service level targets provided in marketing literature or the like. At no time will it be acceptable for a vendor to declare a high level of service at a base price, only to later indicate that this level of service is only available at a higher premium price.

    It is perfectly acceptable, however, for vendors to expressly sell a higher level of service at a higher price, as long as they make that clear at all points where a customer may evaluate or purchase the service.

  2. Ultimately, though, customers own their service level commitments to their own internal or external customers, and customers understand that it is their responsibility to take into account possible failures by each vendor that they do business with.

    Customers relying on a single vendor to meet their own service level commitments enter into an implicit agreement to tie their own service level commitments to the vendor's, and to live and die by the vendor's own infrastructure reliability. Those customers who take their own commitments seriously will seek to build or obtain independent monitoring, failure recovery, and disaster recovery systems.

    If a vendor recommends specific architectures or procedures in order to achieve specific service levels, it will be the customer's responsibility to adhere to them. Failure to do so means liability for service failures rests with the customer, not the vendor.

  3. Where customer/vendor system integration is necessary, the vendors must offer options for monitoring the viability of that integration at as many architectural levels as required to allow customers to meet their own service level commitments. Where standards exist for such monitoring, the vendor will implement those standards in a timely and complete fashion. The vendor should not underestimate the importance of this monitoring to the customer's own business commitments.

    A bare minimum form of this monitoring would be timely and thorough communication of events such as security breaches, service outages or degredations, and pricing changes.

  4. Under no circumstances will vendors terminate customer accounts for political statements, inappropriate language, statements or content related to sexuality or other taboo subjects, religious commentary, or statements critical of the vendor's service, with exceptions for specific laws, e.g. hate speech, where they apply.

Article III: Vendors Own Their Interfaces
  1. Vendors are under no obligation to provide "open" or "standard" interfaces, other than as described above for data access and monitoring. APIs for modifying user experience, frameworks for building extensions, or even complete applications for the vendor platform, or other such technologies can be developed however the vendor sees fit. If a vendor chooses to require developers to write applications in a custom programming language with esoteric data storage algorithms and heavily piracy protected execution systems, so be it.

    If it seems that this completely abdicates the customer's power in the business relationship, this is not so. As the "cloud" is a marketplace of technology infrastructures, platforms, and applications, customers exercise their power by choosing where to spend their hard-earned money. A decision to select a platform vendor that locks you into proprietary programming libraries or execution containers, for instance, is a choice to support such programming lock-in. On the other hand, insistence on portable virtual machine formats or programming frameworks will drive the market towards a true commodity compute capacity model.

    The key reason for giving vendors such power is to maximize innovation. By restricting how technology gets developed or released, the market risks restricting the ways in which technologists can innovate. History shows that eventually the "open" market catches up to most innovations (or bypasses them altogether), and the pace at which this happens is greatly accelerated by open-source software. Nonetheless, forcing innovation through open source or any other single method runs the risk of weakening capitalist entrepreneurial risk taking.

  2. The customer, however, has the right to use any method legally possible to extend, replicate, leverage or better any given vendor technology. If a vendor provides a proprietary API for virtual machine management in their cloud, customers (aka "the community" in this case) have every right to experiment with "home grown" implementations of alternative technologies using that same API. This is also true for replicating cloud platform functionality, or even complete applications--though, again, the right only extends to legal means.

    This provision does NOT protect customers from illegal use of patented or trademarked technologies, but vendors and third parties should be aware that demanding royalties for defacto standard technologies will only result in other, more open technologies taking the defacto role. With the advent of several open-source projects to decouple client code from proprietary interfaces, it is unlikely to be tremendously expensive for customers to replace cloud interfaces if forced to do so.

    Possibly the best thing cloud vendors can do to extend their community, and encourage innovation on their platform from community members is to open their platform as much as possible. By making themselves the "reference platform" for their respective market space, an open vendor creates a petrie dish of sorts for cultivating differentiating features and successes on their platform. Protective proprietary vendors are on their own.

These three articles serve as the baseline for customer, vendor and, as necessary, government relationships in the new network-based computing marketplace. No claim is made that this document is complete, or final. These articles may be changed or extended at any time, and additional articles can be declared, whether in response to new technologies or business models, or simply to reflect the business reality of the marketplace. It is also a community document, and others are encouraged to bend and shape it in their own venues.

Older versions

Cloud Computing Bill of Rights, v 0.1

Cloud Computing Bill of Rights, v 0.2

About the author

    James Urquhart is a field technologist with almost 20 years of experience in distributed-systems development and deployment, focusing on service-oriented architectures, cloud computing, and virtualization. James is a market strategist for cloud computing at Cisco Systems and an adviser to EnStratus, though the opinions expressed here are strictly his own. He is a member of the CNET Blog Network and is not an employee of CNET.

     

    ARTICLE DISCUSSION

    Conversation powered by Livefyre

    Don't Miss
    Hot Products
    Trending on CNET

    Hot on CNET

    The Next Big Thing

    Consoles go wide and far beyond gaming with power and realism.