I had a few posts on 5-9 availability in the last two years. Today, ZDNet reports that 3Tera is offering 5 9’s. The really positive thing I saw in the article is that 3Tera plans to provide automatic SLA credits in the event of downtime that blows the metric – which, if there’s truly 5-9 availability, shouldn’t take much doing.
I’ll ask the question again that I asked before: Is it worth the cost?
Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics. Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics!
The 400 Track videos include:
SLES 401 – Services Issues 2
SLES 402 – Maintenance and Support 1
SLES 403 – Maintenance and Support 2 (special 1-hour course)
SLES 404 – ASP and SaaS Issues
(500s Tracks are currently in production and will be released shortly!)
Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!
Back in the day, we used to fight for five-nine availability. This meant that you would have access to the product or service 99.999% of the time. (If you’ve not read Wikipedia’s article on the Myth of the Nines, now’s your chance.) Mathematically, this equates to only having 5.26 minutes of downtime a year. Pretty impressive, when you consider how long it takes the average computer to simply reboot.
We would tie the availability requirement to a penalty (aka “financial incentive”). This is a kissing cousin to service and support response/repair times and similar penalties… and it heavily applies to situations where you need steady and consistent access to a particular product.
For ASP/SaaS products, uptime is extremely important, as it not only defines the amount of time you have access to use the product but also is a measure of the service provider’s value/responsibility (you don’t have access to the product to fix it yourself). Until recently, though, network bandwidth wasn’t really available to sustain the offerings and was the scapegoat for much of the argument to reduce or eliminate uptime requirements, even if it was the vendor’s back-end server performance causing the problem(s).
As a result, compromises were made to allow uptime calculations only based on daytime work hours (so downtime at night wouldn’t be counted) for those businesses which didn’t have 24/7 operations. Compromises were also made to allow vendors the ability to challenge a request for credits based on downtime. Of course, compromises are fine so long as you’re not compromising your business model.
Flash-forward almost a decade. Gigoam commented recently about the fact that the current movement towards more cloud-based computing is going to require more attention towards availability. I agree. And I’m a little disappointed that I haven’t yet seen a likewise return of significant uptime commitments.
The bandwidth is here (to understand the difference between then and now, check out this table and compare 10Base-T versus Gigabit Ethernet, almost a 1000x speed difference) and applications are designed to be a little more efficient, too. The result is a resurgence of ASP/SaaS products. There are several that I love, actually. They’re incredibly good products, with good support and they don’t typically have downtime problems. But I’m not seeing uptime guarantees of any significant amount.
To get decent uptime availability commitments from your providers, you need to be in-the-know regarding your own proposed usage and the product offering: Know what the service’s value is to your organization. Know when it must be available and when it can be down. Know about server-loads and peak-usage periods. Know the difference between hot/warm/cold backups and have an understanding of what failover might require.
99.999% availability might never be offered again… but something should be. Make sure you’re asking for an uptime guaranty from your providers. Never forget that the middle name of ASP and the last name of SaaS is service.
When purchasing a million dollar software product with a quarter-million dollar implementation and 18% annual maintenance fee, it’s probably reasonable to guess that the buyer expects to keep the product around for a little while. The fear is that the vendor, however well intentioned, won’t be able to survive in this interesting world of mergers, acquisitions and bankruptcies. So the buyer asks for a little insurance policy known as “source code escrow.”
For those of you who don’t already know, software is developed in a 2-step method. What you install on your computer (the executable) is actually the result of the second step, the object code. It’s machine readable only. The developers code in a human-readable version known as “source code” and go through a process called “compiling” to convert the source into object.
In the event that a future developer would want to modify an application, then, they need the source code to do so. There are some specialized tools (known as decompiliers) to help in the event that you don’t have the source code, but generally speaking, having access to all of the original source files is the easier way to go. And in fact, most license agreements expressly prohibit reverse engineering or decompiling.
But the source code is really the crown jewel of the software company. Giving it to everyone and anyone who asks isn’t a good idea. Recognizing the fear discussed earlier, though, the vendors are sometimes willing to place their code into escrow. Source Code Escrow is a service offered by a variety of organizations (such as GuardIT, Iron Mountain and others), called escrow agents. The vendor can “deposit” copies of the source code and then have an agreement with the Escrow Agent to only release the Source Code to specific recipients in the event of a “Release Condition.”
In theory, if the vendor were to suffer a Release Condition (usually something catastrophic to the vendor’s health, such as bankruptcy), the buyer could send a notice to the Escrow Agent that such a Release Condition has happened. The Escrow Agent, through a contractually-detailed process, confirms the condition and then would release the source code to the buyer.
Through contractual restrictions between the buyer and the vendor, the buyer is normally then allowed to use the source code to maintain their copy of the software. This doesn’t allow the buyer to sell or otherwise divest themselves of the source code – it merely offers the buyer a way to continue to help themselves in the event of a problem with the executable. In some rare cases, the buyer might also have the ability to create derivatives of the source code – new versions of the product, so to speak, but again, this is almost always limited to the buyer’s own use and not for resale to others.
Practically, though, source code escrow is a bit more tricky. First is the source code escrow agreement and the various things that have to be properly defined, such as the Release Conditions and the process by which the Escrow Agent would release the code in the event of one of these conditions. Buyers always want to play a bit more fast and loose than the vendor (for obvious reasons). But for the most part, these issues are resolved in favor of the vendor.
Second, the Escrow Agent doesn’t provide escrow services for free. Some vendors will offer to pay for the service, but most require the buyer to pay the annual costs involved. These are usually relatively nominal – $1500/year or so. But some Escrow Agents charge a small fortune. This cost may be easily forgotten when budgeting – or may be overlooked in later years and the service then lapses.
Third, the quality of the code placed into escrow is important. Most good escrow agreements have stated periods upon which the vendor is supposed to update the code or re-deposit new code. This could be on an annual basis (which is usually fine for software that’s not updated frequently or is less expensive) – but the buyer’s perspective says that they always want the source code equivalent of the most recent released commercially-available product. So there are times where the vendor will have to pay for multiple deposits and will want the buyer to share in that cost. Remember, though, that HUNDREDS (or thousands) of buyers may be beneficiaries of an Escrow Agreement – so buyers generally shouldn’t have to pay for deposits (as one deposit can satisfy all buyers).
Perhaps most important in the escrow discussion, however, is the ability of the buyer to actually make use of what they’ve received in the event of a release. Unless you, as a buyer, have an IT staff that’s educated on the programming language used to write the code in the first place – and have the tools to debug and then compile any changes you were to make, source code access might not do you any good.
In the age of ASPs and SaaS vendors, having source code escrow is seen as a remedy for the problem of not having the executable running at your physical location. But, consider whether you have all of the other back-office requirements needed to effect a product’s use. Having the source code to their product might get you that product – but if that product also requires, for example, a SQL or Oracle backend database, do you also get THOSE products as well? Probably not. So source code won’t help you as much as you would hope.
Overall, then, when considering source code escrow, make sure that:
If the answer to any of those questions is NO, look for other solutions to the possible problem of the vendor shuttering its doors. By way of example, one creative idea I’ve seen is to have the vendor (in an SaaS model), actually host the physical server within the buyer’s IT facilities. The vendor would remotely access the box for maintenance and service, just like they probably would if the box sat in a hosted data center. The only difference is that in the event of trouble with the vendor, the box was sitting in the buyer’s IT shop – readily accessible by the buyer without having to negotiate with an Escrow Agent that a release condition was met.
Anyone have other creative solutions to this problem?
Last week, we discussed Assignment, primarily as it relates to services-type work and the issues that come up in that particular arena. This time, we’ll add additional complexity by dealing with software license assignment.
[Note: the term “assignment” is used with respects to rights and the term “delegate” is used with respects to obligations. I will use the term “assign” or “assignment” through this post for both, but when drafting actual contract language, keep both terms in mind.]
Recall that assignment is the redirection of all or some contractual right(s). Template language in most agreements prevents unilateral assignment, usually requiring the permission of the non-acting party to complete the act. For services-type work, it’s fairly common for subcontractors to do bits and pieces of larger agreements… and prime contractors do have a tendency to disappear sometimes. But when you deal with software assignments, the game changes. A lot.
Assignments with respects to software manifest normally in ASP and SaaS relationships. As discussed in this blog before, a service provider relationship for software works by allowing the service provider to have some sort of right to host the software. In some cases, this is done with assignment language, allowing the licensee to grant a service provider the right to host the software on behalf of the licensee during the ASP relationship. With SaaS vendors, however, this right is part of the license itself, as the vendor is the service provider.
Assignments of all rights, however, get a bit more sticky. Software vendors price and license their products based on the perceived customer value that the software brings to that particular customer. The vendors, however, can’t know this value explicitly, so they guess and create a price they feel is reasonable and one that will be paid by the licensee. Again, as discussed previously, we’ve seen that licensing metrics are used as a way to calculate that value.
A customer who assigns all of their rights to another party can mess up this calculation, especially where site-based or enterprise-type licenses are involved. The problem can most easily be illustrated by imagining a licensee with 1000 employees in a single geographic location obtaining an “enterprise license” to a particular software product. They’re charged a fee, created by the vendor, based on the number of employees at the time of the initial license grant – and based on an estimate of how large the company will grow over time. This wasn’t usually a problem. Until companies began merging like wildfire.
Today, that same 1000 person company could be acquired by a 10,000 person company. If the assignment language isn’t written appropriately with this in mind, the software vendor may have unwittingly granted an enterprise license that is now for 11,000 people rather than 1,000. As a result, language in software licensing is now adjusted by software vendors to remove the ability to assign (and fewer enterprise licensing schemes are used, too).
But customers do sometimes need the relatively-automatic ability to assign a contract as a result of a merger, acquisition or other transfer of ownership of the organization. Most contract boilerplate language allows for this. Software vendors who are granting site or enterprise licenses, however, should continue to remember that this could lead to the example situation above. Therefore, take the time to perhaps create a “carve-out” whereby an assignment due to this type of transfer would convert the license to a set number of users… or to a very specific geographic location. This still allows for the assignment, but doesn’t open the software usage floodgates.
About six months’ ago, the term SaaS (Software as a Service) seemed to spring from nowhere. Everywhere I turned, every company, contract professional and trade association made mention of SaaS as the latest and greatest software “licensing” methodology. As recently as two days ago, my local paper ran an article the other day touting SaaS as the transforming “event” for the next generation. But things really haven’t changed that much and SaaS isn’t exactly new.
When computers were new, users accessed them via dumb terminals – where the operating system and all of the software was stored and ran on a computer apart from the terminal from where it was accessed. Service computing was born. As machines became smaller and faster, users no longer needed to rely on a central computer as they had the power at their fingertips, at their homes.
A few years ago, as the internet became popular and businesses installed very-high-speed connections into their offices, Application Service Providers started offering their software… again in a remote, service-oriented fashion. Every vendor wanted to offer an ASP model. Generally, two types of ASPs were created – one in which a third party hosted the application on behalf of the vendor and provided the access to the customer, and the other where the vendor provided the application AND the hosting.
Bandwidth was an issue, of course. But the fundamental problem for ASPs was always the service itself. Vendors had a difficult time maintaining the service levels (sometimes because of bandwidth, sometimes for other reasons). But the end result was the same… vendors made promises that are very hard to keep in a hosted environment.
SaaS is no different today than it has ever been. It’s not going to alter the software licensing landscape unless and until the vendors who offer ASP/SaaS are able to maintain the service levels. Once they do, it’ll be interesting to see what happens. Until then, traditional software licensing isn’t going anywhere.
LicensingHandbook Archive 
