Software license agreement template

Why license scope is tied to a countable metric

The grant needs a metric. "For internal business purposes" describes a purpose, not a scope, and leaves both parties without a way to establish whether use is within the license.

The common metrics each suit different products. Named users work where individuals log in and the population is stable. Concurrent users suit software used intermittently by a larger group. Per-device, per-CPU or per-core licensing suits infrastructure software, though core-based metrics have become contentious as processors have grown. Per-instance or per-environment licensing suits deployed applications, and normally says whether development, test, staging and disaster recovery instances count.

Whichever you use, define it carefully. "User" normally says whether it means a person, a login credential or a device, whether contractors and affiliates are included, and whether a named user license can be reassigned when someone leaves. Those definitional details are exactly what audits turn on.

Then state the permitted environment: production only or also non-production, which sites or countries, whether affiliates may use it, and whether processing data on behalf of third parties — service bureau use — is permitted. Cloud deployment of on-premise-licensed software is worth addressing explicitly, because vendor positions on running licensed software in a third-party cloud vary widely.

• Pick a metric that can actually be counted and audited
• Define "user", including contractors, affiliates and reassignment
• Say whether non-production environments consume licenses
• Address cloud deployment and service bureau use explicitly

How IP indemnities are usually structured

An IP infringement indemnity is the most important protection a licensee gets, because a successful third-party claim can stop them using software their business depends on. Many indemnities only cover half the problem.

The defense obligation — the vendor will defend and pay damages and costs — is the part everyone includes. The part that is often missing is what happens if the claim succeeds and an injunction issues. A licensee that has been defended and is still unable to use the software has not been made whole.

The standard remedy ladder is: the vendor procures the right for the licensee to continue using the software; or replaces or modifies it so it no longer infringes while remaining materially equivalent in function; or, failing both, refunds the fees. Watch how the refund is calculated. A refund of fees paid in the last twelve months is worth little against a seven-figure perpetual license; straight-line depreciation over three to five years is the more balanced position.

Check the exclusions too. Indemnities routinely exclude claims arising from modifications by the licensee, combination with other products, use outside the documentation, and continued use after notice of infringement. Those are reasonable in principle but the combination exclusion can be drafted so broadly that it swallows the indemnity for any software used alongside anything else.

The components nobody mentioned

Nearly all commercial software contains open source. That is not a problem in itself, but it becomes one when the licenses attached to those components impose obligations the licensee never anticipated.

Open source licenses fall loosely into two camps. Some ask for little beyond attribution. Others are written so that obligations travel onward with the code, and those are the ones businesses get caught by — the trigger is usually distributing something built on top rather than simply running it, and for some licenses even making it available over a network counts.

The protections are straightforward to ask for. Require a written open source bill of materials listing every component and its license. Get a warranty that no copyleft-licensed component is incorporated in a way that would subject the licensee's own code to source disclosure obligations. And extend the IP indemnity to cover open source license compliance claims, which vendor forms frequently exclude.

That is why goHeather asks what you are doing with the software. Running it internally is usually a small question. Embedding it in something you ship to customers is worth real attention before the deal closes, and it is a conversation with a technology attorney rather than something software can settle for you.

Audit rights, escrow, and what happens if the vendor disappears

Software audits are a commercial reality and, for some vendors, a revenue line. An unrestricted audit right — at any time, without notice, with unlimited frequency — is disruptive and is routinely deployed as leverage in a renewal negotiation.

The standard negotiated position limits audits to once in any twelve-month period, on thirty days' written notice, during normal business hours, subject to the licensee's site security and confidentiality requirements, and conducted either by the vendor or an independent auditor bound by confidentiality. Add a cure period: if underuse or overuse is found, the licensee has a stated period to true up by purchasing the shortfall at standard discounted rates rather than at list price with penalties. And make audit costs the vendor's unless a material discrepancy — typically 5% or more — is discovered.

Business continuity is the other side of the same question. For software a business genuinely depends on, source code escrow deposits the code with a third party for release on defined triggers: the vendor's insolvency, cessation of business, or failure to meet support obligations. Escrow is only useful if it works, which means requiring deposit verification, build instructions, documentation of third-party dependencies and periodic updates. A release of code nobody can compile is a false comfort, and it is the most common outcome of an unverified escrow arrangement.