Releases of Liability as Part of Licensing Deals – How Hard to Push?
Software publishers know that the vast majority of their customers are, to varying degrees, out of compliance with the terms of license agreements governing their use of the publishers’ software products. Especially in larger enterprises, managing and maintaining a company’s license position is a daunting and maybe even impractical task, especially given the increasingly complex architectures utilized in today’s IT environments and the correspondingly complex licensing metrics that go along with them. The choice often comes down to increased licensing exposure due to lax monitoring or the lost productivity that may arise from systems that are centrally managed by IT teams with insufficient resources. Companies may have every intention of running compliant shops, but day-to-day demands of business operations may thwart those good intentions. Given that, it makes sense for businesses to look for other alternatives to help mitigate their exposure.
In most cases, companies wield no greater leverage to obtain favorable licensing terms than they do when they are contemplating significant license purchases, and one of the most important uses of that leverage to consider when negotiating a licensing deal is requesting a release of liability associated with past software usage. The purpose of the release is to “wipe the slate clean” with respect to the compliance state, so that the company does not have to worry about an audit resulting in fees or penalties for past, inadvertent non-compliance. We regularly advise our clients to push for releases as part of every large expenditure associated with licensing or periodic support renewals. However, there are limitations and even risks associated with that approach.
First, the typical software publisher usually will respond by saying that it simply will not consider a release – it may not know what products the company has deployed on its computers, so it would have no way to determine the value of the requested release. That is not an invalid concern, and it means that the licensee company will need to be flexible and creative in how it approaches the issue, with options that may include:
- A release in favor of a limited-scope audit or future reporting obligations not otherwise required in the license agreement
- Limiting the scope of the release to claims associated with quantities of products deployed (and not to other matters like commercial hosting or unauthorized duplication of the publisher’s products for profit)
- In lieu of a true release, restricting the scope of future audits to only those periods following the date of the licensing transaction being contemplated
In addition, it is important to keep in mind that requesting a release can lead to potentially awkward questions from the publisher during negotiations. The first reaction may be: “What do you have to hide?” Worse, if negotiations break down, a company that previously requested a release is nearly guaranteed to receive an audit notice letter from the publisher in the very near future. Therefore, it is important to be delicate in introducing the concept to the publisher’s sales team and, in most cases, to do so early in the negotiations process. Make it clear that the release request is part of the company’s standard procurement procedures and represents an effort to obtain greater value from IT expenditures.
Other requests during the negotiations process – such as audit forbearance or modified use rights – may also be critical to a licensee, however the release always should be at or near the top of the list of requirements.