How to read a software licence, starting with the grant clause

You did not buy it, and that has consequences

Software is licensed rather than sold, and the distinction is not a drafting affectation. In Vernor v Autodesk the Ninth Circuit held in September 2010 that a user is a licensee rather than an owner where the copyright holder specifies that a licence is granted, significantly restricts transfer, and imposes notable use restrictions. Because the buyer was a licensee, the first sale doctrine did not apply and the second-hand copies could not lawfully be resold.

Europe went the other way. In UsedSoft v Oracle the Court of Justice held in July 2012 that the distribution right is exhausted on the first sale of a copy in the EU, whether the copy arrived on a disc or by download, so genuinely surplus licences can be resold — provided the original holder stops using its own copy. If you operate on both sides of the Atlantic, the same paragraph in the same agreement has different consequences in different territories.

The grant clause, and every word that narrows it

Find the grant. It is usually two sentences, it usually begins "Subject to the terms of this Agreement, Licensor grants Licensee a...", and everything after that comma is a limit. Read it word by word: each adjective is a separate restriction somebody negotiated in, starting with whether the grant is exclusive at all — exclusive vs non-exclusive licence covers what that first word changes.

The metric is the price

Almost every dispute about how much software costs is a dispute about how it is counted. The metrics form a rough ladder from narrowest to broadest, and moving one rung is usually worth more than any discount on offer.

One trap deserves naming separately. Indirect access — where a person or system reads data from the licensed application through an integration, a reporting tool or an API rather than logging in — is treated by several major vendors as consuming a licence. Organisations discover this during an audit, having built an integration that quietly created hundreds of chargeable users. If you plan to integrate anything, put the treatment of indirect and machine access in the agreement in writing, and look at an API licence agreement if the software is being consumed programmatically.

Perpetual, subscription, and what a lapse in maintenance costs

A perpetual licence is a permanent right to use a specified version. A subscription is a right to use the software while you keep paying, ending when you stop. The two are frequently confused because both are usually sold with an annual payment attached — but in one case the annual payment is maintenance and in the other it is the licence itself.

The audit clause is where the money is

Most enterprise agreements let the vendor verify compliance, and for large vendors audit revenue is a planned commercial channel rather than a policing exercise. The clause is negotiable at signature and effectively non-negotiable afterwards. Ask for written notice of 30 to 60 days, no more than one audit in any twelve months, work performed during business hours without unreasonable interference, scope limited to the systems and records needed to verify the specific licensed products, and the vendor bearing its own costs unless a material shortfall — typically 5 per cent or more — is actually found.

Virtualisation, outsourcing and the restrictions nobody reads

The restrictions clause is where old licence metrics meet current infrastructure, and the mismatch is expensive. Four questions to settle in writing rather than by assumption:

• How are virtual environments counted? Vendors differ on whether a licence attaches to the virtual cores allocated or every physical core in a cluster the workload could theoretically move to. That difference can be an order of magnitude.
• Are non-production instances free? Disaster recovery, test, development and training environments are sometimes included, sometimes licensed at a discount, and sometimes fully chargeable.
• Can an outsourcer run it? Many agreements prohibit service bureau use or operation for the benefit of third parties, which can catch a managed service provider running the software on your behalf.
• What happens on a corporate change? Non-transferability plus a change-of-control clause means an acquisition can require the vendor's consent, and consent is a negotiating position.

Escrow, warranties and the indemnity you should want

Three clauses decide what happens when something goes wrong, and only one of them is usually drafted in the customer's favour by default.

Source code escrow matters if the software is critical and the vendor is small. An agent holds a deposit and releases it on defined triggers — insolvency, abandonment of the product, persistent service-level failure. In the US, section 365(n) of the Bankruptcy Code lets a licensee elect to retain its rights when a bankrupt licensor rejects the licence, and that election reaches supplementary agreements such as the escrow. Two cautions: separate licence fees from support fees, since you may have to keep paying whatever is bundled with the licence; and holding source code is not the same as being able to build it. An escrow nobody has verified is a filing cabinet. The escrow agreement clause checklist covers the release triggers worth arguing over.

Warranties are usually thin: the software will perform substantially in accordance with the documentation for 30 or 90 days, and everything else is disclaimed. That is normal and not worth a fight on its own. What is worth checking is the remedy — repair, replace or refund is standard, and a refund limited to fees paid in the last twelve months is a real cap on a multi-year commitment.

The IP indemnity is the clause customers should push hardest on, because it protects against a risk they cannot assess: that the software infringes somebody else's rights. A usable indemnity has the vendor defend the claim, pay the resulting damages, and then either procure the right to keep using the software, modify it so it no longer infringes, or refund. Watch the exclusions — combination with other products, customer modifications, and use outside the documentation are standard carve-outs, and a broadly drafted combination exclusion can swallow the indemnity in any integrated system.

Licence, SaaS and open source are three different animals

They are routinely discussed as if they were variants of one thing, and the clauses that matter are almost entirely different in each.

• A software licence grants rights in a copy you install and run. The risk sits in the metric, the audit and the restrictions.
• A SaaS subscription grants access to a service somebody else runs. There is no copy, so nothing to audit — the risk moves to uptime, data ownership, security and what happens to your data at exit. What to check in a SaaS agreement covers those.
• An open-source licence is a standing grant from the author to the world on fixed terms, with no negotiation and no counterparty to ask. Obligations trigger on distribution rather than on use, which is why they surface late. Open source licences in a commercial product sets out where.

The mistake worth avoiding is applying one mental model to another document — auditing a SaaS deal, or reading a copyleft obligation as if it were negotiable. If you are buying hosted software, the SaaS agreement is the right starting point, not a licence template with the installation clauses deleted.

What to do with the licence you already signed

Most organisations are not signing a new agreement today; they are running under one somebody signed years ago. Two hours on it is unusually good value. Find the grant clause and write down the metric in plain words. Compare it against your actual deployment — not your purchase order. Note the audit notice period and who inside the business would receive the letter. Then check the date nobody has: when maintenance renews, and what you lose if it does not.

The shortfalls that produce large audit findings are almost never deliberate. They are integrations that created users nobody counted, a virtualisation project that changed the core count, contractors given logins, and a test environment that quietly became production. None of those decisions felt like a licensing decision at the time, which is exactly why the grant clause is worth reading before the infrastructure changes rather than after.