the gpl is fatally flawed, though the flaws were not obvious until online service became as prominent as they now are. attempts to update the gpl for “the cloud”, like the agpl, only serve to exacerbate the problem. more permissive licenses, such as bsd, mit, and apache, are less troublesome, though still lacking in certain areas, as i will explain.

the original intent of the gpl was to ensure users of software had access to the source so they could inspect it, fix it, and modify it for their needs, irrespective of the desires, or continued existence, of the software vendor. a noble goal motivated by the best of intentions and much excellent software has been produced under the gpl, with linux being the highest profile project.

with the widespread adoption of online services, a weakness in the gpl was exposed: because online services never handed software over to users, they were not obligated to share the source with them. the affero variant of the gpl closes this apparent gap by requiring source disclosure even when the software is provided as a service rather than as object code.

however, the agpl simultaneously makes itself unattractive to service providers who are rightfully concerned about contamination of their proprietary code such that they must release it. this is, in fact, the goal of the gpl and its variants: it acts as a virus to force the release of ever more source. the gpl serves to rigidly control what you can and cannot do with software covered by it, and is thus the license equivalent of digital rights management.

this leads to a related problem. the gpl produces, in practice, a two-tiered structure dividing those who control a software project from those who merely contribute to it. those in the former group are free to create a dual-license: those who want to use the software for non-commercial purposes can do so freely, but those wanting to use the software commercially must pay. the latter group cannot do this, regardless of how much they may have contributed to the project (though, of course, they could create a new project and rewrite all encumbered components). even worse, in a complete subversion of the intent of the gpl, a company can now make open source closed to its users simply by paying for a license. the license intended to protect the rights of users is instead being optimized for the rights of developers.

when the gpl is abused like this, as it is more and more frequently, the most obvious difference between it and the permissive licenses is a matter of who decides who gets paid. under the gpl, that control rests only with the project owner, just like content drm. under a permissive license, anyone can decide.

however, another, more troubling issue looms: content is at least as important as code, but open content licensing, like creative commons, and open source licensing are treated independently. as a result, vendors can adhere to both the letter and the spirit of an open source license, whether the gpl or something more permissive, yet users may have little control over the content managed by the software. as one concrete example, amazon made certain changes to linux for their kindle reader and, as required by the gpl, released those changes. however, the actual kindle application code is closed source and the content users purchase is accessible and transferable as seen fit by amazon or the publishers.

this is the real licensing hole. most users have little interest in source code access for the applications that manage their content, but they have intense interest in access to their content. if i store my personal photos on a photo site and attach all sorts of description and tag information to them, can i easily download them, with all the metadata, when i want? if i purchase books for my electronic book reader, can i easily back them up, transfer them between my devices, and continue to access them even if the company from which i purchased them goes out of business? these applications are empty shells, of no use to anyone, without their content.

the open source community needs to recognize the weaknesses, in practice, of licenses like the gpl and focus attention not on further controlling how people can use code, but, in the spirit of the user freedom, on ensuring access to their content.

this post was greatly improved by input from my reviewers, andrew and coda.

emil makes a very good point about constraints on project owners running off and selling contributed code. this does not invalidate my point that the gpl and its variants are being twisted in favor of developers vs. the original purpose of protecting users. i’ve updated the post to reflect his feedback.

yesterday i explained the dangers of the common misunderstanding of service level agreements as insurance policies. while i mentioned a strategy of using multiple vendors rather than relying on the SLA offered by a single vendor, some more specific details will be useful in understanding and internalizing this approach.

over the past ten years i have participated in or lead negotiations for internet and CDN bandwidth at internap, amazon, and microsoft. at first i invested significant time and effort in defining SLAs, methodology, metrics, and penalties, as is common practice. what eventually became apparent were two things:

1. defining meaningful SLAs for public internet services, as opposed to private telco links, is not generally possible.
2. SLA failure penalties are insufficient compensation for business impact.

from this experience and these realizations i changed my approach significantly. the two facets of the new strategy were, and are:

1. only enter into contracts with as small a traffic commitment as feasible and with no penalties for termination, regardless of cause.
2. engage multiple vendors for all bandwidth services.

availability, which is always the responsibility of the customer, is now actually under the customer’s control, rather than being delegated to a vendor via an SLA. should a vendor fail to deliver the desired service level, even for a short period of time, traffic can be shifted to other vendors until quality improves. should a vendor prove too unreliable to use at all, their services can be terminated and other vendors brought in to replace them.

to make best use of this strategy it is important to have proper software support in place. for example, a single CDN vendor should be used for content on each page served, and the vendor used varied dynamically across requests; mixing multiple CDN vendors on a single page can actually reduce availability. similar traffic engineering can be done for requests to your own web servers using DNS-based global load balancing, though with coarser granularity. similar principles will apply to “the cloud” as the interfaces and functionality in the space are commoditized.

as heinlein said, TANSTAAFL, and high-availability distributed systems are not exceptions. you are responsible for your availability. understand clearly the business value to you of a vendor SLA and be prepared to change your strategy, and put in the technical and contract work required, if it will not meet your business needs.

vijay posted a (better late than never) rebuttal to a post from november last year by joe weinman of at&t. i agree with all the points vijay makes, and want to focus in on a particular area of joe’s article:

(4) SLAs with financial penalties – Not only won’t enterprises accept “Well, after all, it’s still in beta” as an excuse for service outages, they demand meaningful SLAs (service level agreements) with clear metrics for evaluating achievement of those SLAs, backed up by monitoring and management systems, and financial penalties such as credits or refunds if service levels aren’t met. A “free” or low-cost service with questionable delivery quality is about as attractive to a CIO as an offer of free neurosurgery from someone who just skimmed a blog on how to do it in three easy steps.

ah, the mighty service level agreement! the tooth and claw by which the wily customer brings the vendor to heel. get the SLA right and you, the customer, can sit back and relax, safe in the knowledge that should there be an outage, you are covered. your business is protected from harm by the warm, experienced embrace of a big, stable telco. pinch me, i must be dreaming.

vijay refers to SLAs as “an actuarial game”. the situation is rather worse than that. the trouble is that many intelligent people mistake an SLA for an insurance policy. it most definitely is not.

an insurance policy is purchased for a price, often based on actuarial tables, that reflects the risk of the policy being paid out and the size of the pay out. the value of the policy is that it is an actual hedge: in the event of a claim, the holder is compensated for (approximately) the full value lost. the insurance industry is predicated on most policy holders paying far more over the life of their policies than they are paid out, and on there not being catastrophic events that cause simultaneous claims by a large number of policy holders.

a service level agreement does not work this way. an SLA is not a hedge against the business impact of an outage: it is a refund policy. the maximum value of an SLA ‘claim’ is your monthly bill. the cost to your business of an SLA failure is likely to be far higher, but you will not be compensated for that loss. a six hour service outage might cost your small business 10,000 dollars. receiving a 500 dollar service credit is cold comfort.

SLA failures become more common as you move up the stack from the rigid, extremely well-characterized, layer 1 telco sweet spot. outages that impact large sections of your customer base simultaneously are inevitable in large-scale, shared software infrastructure. if SLAs were insurance policies, vendors would quickly be out of business.

given this, the question remains: how do you achieve confidence in the availability of the services on which your business relies? the answer is to use multiple vendors for the same services. this is already common practice in other areas: internet connection multihoming, multiple CDN vendors, multiple ad networks, etc. the cloud does not change this. if you want high availability, you’re going to have to work for it.