Monthly Archives: March 2009

Software Licensing Handbook Reviewed by H. Ward Classen

I am honored to present a review of the Software Licensing Handbook by H. Ward Classen, author of A Practical Guide to Software Licensing for Licensees and Licensors.  Thanks to Ward for his time and energy on creating such a comprehensive evaluation!

Jeffrey Gordon’s Software Licensing Handbook is one of those rare reference resources where the reader only wishes they had come across it earlier.  The Software Licensing Handbook is a comprehensive resource addressing all of the material potential issues a practitioner may confront in a software licensing transaction.  It guides the reader from preparing for the RFP/RFI process to identify prospective vendors until the successful vendor has completed its contractual obligations.

The book begins with a detailed overview of the different intellectual property rights utilized to protect software: patents, copyrights, trademarks and trade secrets.  Mr. Gordon’s explanation allows the reader to understand the basis and means for software protection and thus the foundation for software licensing itself.  By providing a succinct overview of intellectual property law, he permits the reader to conceptualize reason for and the importance of each clause in a software license.  The subsequent text delves into a comprehensive explanation of almost every issue that may arise during the course a software negotiation, including defining the services to be rendered, tax liability, indemnification, source code escrow and most importantly, how to successfully negotiate a software license.  Perhaps the most valuable aspect of his book is Mr. Gordon’s advice on how to negotiate a software license.  Mr. Gordon is an expert in negotiation and it clearly shows.  He interspaces throughout the book negotiating positions from both the licensor’s and licensee’s perspective. His tried and true advice provides invaluable insights that benefit all parties to a transaction.

Mr. Gordon also examines many of the issues related to alternative licensing transactions such as ASP licenses and click-through and shrink-wrap licenses as well as open source licenses.  As open source software assumes greater importance in the world of software licensing, it is imperative that both licensors and licensees understand the risks and benefits of utilizing open source software   Too often parties fail to realize the inherent risks of utilizing viral licenses. This brief but comprehensive discussion provides the reader a fundamental working knowledge of the relevant issues related to open source licenses.

The book explores many aspects of software licensing that are rarely addressed in other books including the RFP process, software audits and the importance of establishing severity levels for maintenance and support agreements.  Each of these issues is critical to a successful licensing transaction but yet many practitioners fail to grasp their importance.  By utilizing an RFP process, a customer is able to compare and contrast the abilities of several vendors and usually obtain better terms and pricing through a competitive process.  Software audits allow the licensor to confirm the licensee’s compliance with the terms of the license grant.  Audit language must be carefully drafted to protect the licensor’s interests while limiting the licensor’s ability to conduct overly broad audits of the licensee’s business at the licensee’s expense.   Similarly, it is in both parties interests to negotiate well defined severity levels for the provision of support and maintenance services to avoid potential disputes.

Not only does Mr. Gordon address the issues involved in software licensing, he provides the reader with a solid foundation for negotiating peripheral agreements when purchasing computer hardware and working with value added resellers (VARs).  While some readers will not interact with VARs or purchase hardware on a day to day basis, his discussion is not superfluous as every practitioner should have an understanding of the interrelationship among vendors providing an integrated software system to ensure the customer receives a vibrant, fully functional system.

Mr. Gordon also includes a chapter on contract management.  Many practitioners falsely believe the contract ends with the acceptance of the software.  This misconception often contributes to the software failing to meet the licensee’s long term goals.  Many software projects continue for many years after the software’s initial installation, emphasizing the need for both the licensor and licensee to manage the contracting process well after installation and acceptance.  Mr. Gordon’s eloquent discussion also incorporates the importance of managing the deliverables, service levels and guiding the contract toward completion.  Finally, the Software Licensing Handbook contains an excellent glossary of important words and phrases often found in software licenses as well as a list of resources the reader can access for further information.  These features are often overlooked by many other authors but yet they provide invaluable assistance to the reader.

Perhaps the book’s only weakness is its lack of a comprehensive model software license form to illustrate Mr. Gordon’s excellent discussion.  A model form would reinforce the reader’s understanding of Mr. Gordon’s points and help them visualize the issue being discussed.  Given the large number of forms available in form books and over the internet, this is not a material flaw but one that would serve as a welcome addition for the reader.

In short, the Software Licensing Handbook is a valuable resource that every individual who negotiates software licenses and technology agreements should own.

Internal Business Purposes

How many licenses to your core database software do you own?  I ask about this specific type of license because database software is typically expensive (relatively speaking) and customers license an exact quantity of licenses required based on actual use.  In other words, if you need 5 database servers (or instances), you pay for 5 licenses.

Of course, it’s never that simple.  Because your IT department usually also wants a development server for each database instance.  This makes sense – development should be done separately from production (you wouldn’t want some experiment in design to bring down your production server).  Oh, and what about testing?  This is the middle-of-the-road between development and production… where something that your developers believe is ready for production goes to receive significant QA attention.  That’s yet another set of databases.

So, now we’re talking about 15 licenses: 5 production + 5 QA/test + 5 development.  If 5 were expensive, imagine what 15 could become.

Database software developers understand this dilemma.  They know that if you’re really making use of their products, whatever you have in production has to be supported by nearly as many dev/test environments.  Back in the day, this was usually a pretty simple situation – you asked for, and usually received, “free” dev/test licenses.  I say “free” because they were never really free, they just didn’t separately price them.  You paid for them then, just as you pay for them now.  The difference is that the cost was built into the production licenses back then because the hardware wasn’t strong enough to support some of the tricks that can now be used to run multiple databases within a single hardware environment.  Once the hardware was strong enough (about 8 years ago), savvy licensees didn’t actually need 5+5+5 … they could find ways to do 5 + 3 + 2 or some other combination in something other than a 1:1 relationship.

The net result is that these same savvy licensees started asking for discounts on the initial 5 production licenses because they knew they were no longer needing the triple-play effort of that single license.  Instead, they argued, they only needed a few “extra” licenses (now really for free) because it was understood that to make use of the product, you needed these extra environments.  They just didn’t need them in the same quantities as before, so it had the appearance of being less of a freebie than before.

Software vendors reacted in the best way they could – through changes in language.  The phrase “internal busines purposes” became the expected response.  “Yes”, the vendors said, “you can have a few extra licenses – but only for internal business purposes.”  The meaning wasn’t always clear, of course, but the intent was to say that the licenses you purchased were the ones that could see the light of day (be used by regular users, etc), but that the extra licenses were only for back-room development and testing.  You were signing a license agreement confirming that you wouldn’t take these fully-functional licenses and put them into production.

No problem.

Until ASP/SaaS offerings came along.  Now you have databases that are serving data to the world 24/7/365.  Licensees still need dev/test environments… but these are now potentially available online, too.  And, in rare cases, serve as the backup production environment in the event that the usual production environment goes down.

Has this really created a problem?  No.  The case remains that licensees should have frank and honest conversations with their vendors about how they intend to use the products rather than try to sneak some form of unintended or unexplained use by the vendor.  If licensees want “free” licenses for dev/test, they should expect to see (and respect) “internal business purposes” language.  And they should discuss the possibility of needing to put a dev/test server into production in the event of a disaster.

Lastly, licensees should also remember that such licenses are never free.  Whether you have a line-item cost that shows you paying full-price, partial-price or no-price, the cost is still baked into the deal in some way.  However, one key advantage to calling out the pricing specifically for dev/test environments is the ability to get them excluded from maintenance costs – as there should be no need to pay for maintenance on a dev/test box needed to provide support for a production server.