Forrester’s Software Licensee Bill of Rights.

A Software Lawyer’s Take on Forrester’s Software Licensee Bill of Rights.

Short answer: Forrester’s “Software Licensee Bill of Rights” is a buyer wish list, and several items collide with a vendor’s legitimate right to set its own pricing and licensing model. Know your stance on each one, because these arguments show up in customer negotiations.

As a software lawyer who represents software and SaaS companies, I thought my perspective on the Forrester Software Licensee Bill of Rights may be useful to you, because it tends to come up during customer software negotiations. The report came out in 2009, but you know, I missed it too.

Most of it I am OK with. A few items, though, run straight into a vendor’s right to design its own model.

The Ten Rights, From a Vendor’s Side.

(1) Choose Any Implementation Partner. Sounds good, but there may be valid reasons a vendor does not want just anyone implementing its software: training, expertise, confidentiality, and competitive issues.
(2) Pay for Actual Usage. Also appealing, but vendors should be free to set their pricing models, and usage reporting is complicated. Remember, a more restrictive license should cost less.
(3) Licensee Free to Share Modifications. Since most software ships without source code, this rarely comes up. Where it does, a vendor reasonably objects, because derivative works could become products it would rather build itself.
(4) Freely Transfer Software (regardless of site or hardware). This should be part of the vendor’s pricing model. Flexibility that does not add real value can cost more than a customer wants to pay. (See transferring software in a reorganization.)
(5) Speak Freely About It. Software is often the vendor’s confidential information, so there is a real question about how freely a customer should discuss it.
(6) Ensure License Equivalency. I am not sure what this means, and nothing turned up when I searched, so I am at a loss here.
(7) Unbundling of Support and Maintenance. A nice idea, but it should be the vendor’s call as part of its revenue model. Some unbundle (for example, Microsoft Windows) and others do not.
(8) Third-Party Support. Great on first blush, but how does a third party support someone else’s code, with bug fixes and upgrades, without source-code access? Ask SAP, which a court ordered to pay $1.3 billion in damages for trying to do exactly that through a company it bought for $10 million.
(9) Define Functionality Replacement. If a vendor is retiring a product, yes, it is good practice to tell customers what key functionality they would need in a replacement.
(10) Resell Software. This one I do not get. Most commercial software is non-transferable because vendors do not want a secondary market (consumer software often allows it). They should be free to restrict it.

Many of these are reasonable asks, but several of them, flex-down pricing, audit penalties, and source-code access, shift real economic value, so price them rather than concede them. Figure out your stance on each before you are at the table. For the broader playbook, see why education drives software negotiations and 6 Tips When Your Customer Insists on Their Form Agreement.

How Others Reacted.

Vinnie Mirchandani, a former Gartner analyst who wrote the Deal Architect blog (now offline), argued the Forrester list did not go far enough and proposed his own additions across the deal lifecycle. During selection: more self-service product information, customized proposals instead of boilerplate, and making proposal responses part of the contract. During implementation: a wide choice of implementation resources, published customer-satisfaction data on services partners, and periodic certification of partner staff. On usage and pricing: pay-for-usage with the ability to flex license counts up and down each quarter, agreed definitions of processing units before multi-core or virtualized changes, vendor penalties when audits find little or no non-compliance, and two years of term protection after either side goes through a change in control. On support: tiered options including a basic tier limited to bug fixes and regulatory updates, published support metrics, and a real third-party support ecosystem. The throughline was transparency before signature. My vendor-side reaction is the same as for the Forrester list: many are reasonable asks, but the ones that move economic value should be priced, not conceded.

Frequently Asked Questions.

Is the Forrester Bill of Rights binding on vendors? No. It is an analyst’s buyer-side wish list, not law. It matters because customers cite it in negotiations, so you want a considered position on each item.

Which items should a vendor resist? The ones that shift real economic value, like pay-for-usage with flex-down, audit penalties, free transfer, and third-party support requiring source access. Price them rather than give them away.

Why is third-party support so risky to grant? Because supporting code usually requires source access, and getting that wrong is costly. SAP paid a $1.3 billion judgment over a third-party support model gone wrong.

I hope this helps.

Disclaimer:

This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.