Rick Chapman Praises the Software Licensing Handbook

The just introduced Software Licensing Handbook is an invaluable guide to one of the software’s industry’s most maddening and, at times, controversial topics, software licensing. Since the introduction of the end user legal agreement (EULA) in the late 1970s, software companies have struggled to negotiate successfully the web of various rules and regulations that govern copyright, trademark, patent, and trade secrets. At 216 pages, this handbook is a compact and succinct guide to when you’ll haggle over software license terms and conditions and how to do it well.  Of particular interest is the book’s scenario-driven approach. In most the chapters, a common point of contention between the software licensor and licensee is described, followed by an outline of the issues that underlie the topic and suggested negotiating points for both sides. This is the type of book any software senior executive should keep close to his/her desktop for immediate reference when needed. Highly recommended (and in some cases, critical). Available online at: http://www.licensinghandbook.com.

Rick Chapman

Soft*Letter Volume 23, #2 (1/31/2007)

Advertisement

Software as a Service

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.

Now Available on Amazon/Borders!

After a long introduction, the Software Licensing Handbookis now globally available at Amazon, Borders and any book store near you by title or ISBN: 978-1430305842. However, I can’t promise you’ll get the lulu.com price via the links from this page. Thank you again to everyone who has supported me in this process!

Warranty vs Maintenance

A few years ago, it was very common to find one year warranties on products and maintenance and/or support programs that would pick up where these warranties would leave off. As a result, most IT folks still understand Maintenance to be a paid-for version of a Warranty. Unfortunately, vendors do not see it the same way, leading to one of the most contentious parts of a contract negotiation.

As defined, a warranty is a guaranty that the product will work in a certain manner for a certain period of time. The “certain manner” is usually as specified in the product’s manual and the “certain period of time” is now substantially less than a year. Maintenance (and/or Support) Programs are then sold to the customer as a way to offer a longer-term availability in the even that the product has functionality problems. Why the difference?

Warranties are sometimes mandated by state and/or federal laws and regulations. You will usually note this not by the warranty itself, but by the warranty exclusions listed that the vendor is disclaiming. Beyond that, warranties were once a way to promise to the customer that the product would work “forever” as stated in the manual. In an age when a particular version of software is obsolete soon after it’s released, “forever” is much shorter in the eyes of the software vendor.

Coupled with this is the fact that many customers not only want to make sure that their product works as advertised (which is reasonable) for the time that they use the product, but that they also want access to each new version/release of the product (which may be unreasonable, given the advances in the technology). Software vendors handled this by creating a division between the warranty and the maintenance/support concepts.

So now we’re left with a more traditional definition of warranty – a small window of time in which a customer can receive help for a dysfunctional product, along with certain limited guarantees that last for the entire duration of use (such as a guaranty of ownership in the underlying intellectual property). Support (as opposed to maintenance) is then also defined by its dictionary definition – help provided after the expiration of the warranty period. Support plans do cost the software vendor to provide, from technicians to replacement parts, 800 numbers and all the other infrastructure items necessary to be available when the customer calls. These plans also range from the basic, 8a-5p M-F plans, to the 24x7x365 “we’re there when you need us” plans, along with every conceivable variant.

Maintenance, as opposed to Support, is the added benefit of being able to receive updates, upgrades or product revisions as they come out. In essence, Maintenance is a fee paid to the vendor that contributes to the R&D of new products. Software development, contrary to popular belief, is a very demanding and time-consuming process. Quality Assurance testing alone can take months of tedious operation by skilled users/developers without a guaranty of ever actually finding every product problem (bug). As stated above, this is one major reason why vendors do not want to just give new products to their customers for free. Add revenue recognition issues into the mix, and it becomes even more complex to provide a contractually open-ended arrangement.

The costs involved in each of the three concepts (warranty, maintenance and support) can be substantial. Vendors interested in their own long-term survival can’t reasonably provide perpetual free maintenance or support. In an attempt to provide customers with software packages that meet their different customers’ needs, vendors do not usually require all of their customers to buy maintenance and support. That way, customers who do not need/want maintenance or support, don’t have to pay for it.

At the end of the day, this is the best way to satisfy the most number of customers, even if it causes some interesting negotiations.