A Software Lawyer’s Take on Forrester’s Software Licensee Bill of Rights.
As a software lawyer that represents software and SAAS companies, I thought my perspective on the Forrester Software Licensee Bill of Rights may be useful to you (this is something that may come up during your customer software negotiations). In case you missed it, this report actual came out in 2009, but you know, I missed it too.
Most of it I am ok with (see all the yellow highlights), but what I have highlighted in red I don’t (or don’t understand).
(1) Choose Any Implementation Partner. While this sounds good on its face, 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 sounds good too, I think software companies should be free to determine their pricing models (plus reporting on actual usage would be really complicated/hard). Remember, that if the license is more restrictive the price for the license should/will be lower.
(3) Licensee Free to Share Modifications. As 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. derivative works/extensions to their software could create other software products that the vendor would instead like to capitalize on . . . seems fair to me).
(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 (flexibility that does not add real value may cost more than a customer wants to pay for).
(5) Speak Freely About It. The argument here is often software is treated as the confidential information of the software company, and so why should the customer be free 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.
(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. Some companies do unbundle (e.g. Microsoft Windows) and others don’t (most commercial software products).
(8) Third Party Support. Great on first blush, but the practical reality is how can a third-party support someone else code (bug fixes, upgrades, new versions, etc. . . no source code access)? It just does not work (quite frankly I am amazed anyone tried it) . . . but maybe someone can prove me wrong. 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 yes 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).
(10) Resell Software. This I don’t get, as most commercial software is not transferable, as 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.
So why do you need to know about this? I bet these issues will come up at some point during your software negotiations with your customers, so you should figure out your stance/response to these issues. I hope this helps!
Some other people commented on this too.
Deal Architect’s Point of View
Legal Disclaimer:
This is for informational and educational purposes only, and does not constitute legal advice. Contact your attorney for legal advice, which should be provided after review of the facts and applicable law.