A Software Lawyer’s Thoughts on Forrester’s Enterprise Software Licensee Bill of Rights?
December 2, 2010
From the perspective of a software company, I thought my views would be helpful regarding the Forrester Software ‘Licensee’ Bill of Rights. Any company looking for a venture capital investment or growth capital should take a read. In case you missed it, this actually came out in 2009 (I actually missed it, so don’t worry if you did too).
I am ok with most of it (see all the yellow highlights), but what I highlighted in red I don’t (or don’t understand).
1) Choose Any Implementation Partner. While this sounds good, there may be valid reasons why a software company does not want just anyone implementing their software (you know, training, expertise, know-how, confidentiality, competitive issues, etc.).
2) Pay for Actual Usage. While this also sounds good, I think software companies should be free to determine their pricing models (plus reporting on actual usage would be really complicated/hard). Remember that more flexibility may equate to a higher price for the software (yes, price and terms are linked).
3) Licensee Free to Share Modifications. Because most software is not provided in source code, this is not even an issue, but if it were, I can understand why a software vendor would not want this to happen (e.g. they probably want to capitalize on the market for extensions to their software).
4) Freely Transfer Software (regardless of site/hardware). Again, this should be up to the vendor to determine as part of their pricing model/strategy. Remember, it is all about price (more flexibility may cost more than a customer wants to pay for that license).
5) Speak Freely About It. The argument here is that software is treated as the confidential information of the software company, and so why should the customer be free to discuss these kinds of things.
6) Ensure License Equivalency. I am not sure what this is (and nothing came up in a Google search), so I am at a loss on this one. Sorry.
7) Unbundling of Support and Maintenance. Nice idea, but I think that should be up to the software company to decide, as they can/should determine their revenue model/strategy.
8) Support from a Third Party. Sounds great on first blush, but here’s the practical reality: How can a third-party support someone else’s code (bug fixes, upgrades, new versions, etc. . . no source code access)? It just does not work (quite frankly I am amazed anyone tried it); I am open to someone proving me wrong though. Ask SAP about it, as a court just ordered them to pay $1.3 Billion in damages for trying to do just that through a company they bought for $10 million.
9) Define Functionality Replacement. I am not sure I understand this, but if the vendor is retiring a product it would be nice/good to tell your customer what key functionality they would need in a replacement (if that is what they mean by this. . . not sure?).
10) Resell Software. This I don’t get, because most commercial software is not transferable. Vendors don’t want to create a secondary market for their products (consumer software vendors usually allow it, though). I think they should be free to restrict this.
Just some thoughts (biased, no doubt) from a software lawyer who also works as a venture capital advisor to the OpenView portfolio of expansion stage companies.
Related Articles.
Intro to these BOR by Forrester in 2007.