A software licence defines what a business may do with software it does not own. It can govern who may use the product, where it may run, whether it may be modified, how it can be transferred and what happens when the agreement ends.
Licence risk is not confined to legal wording. It can affect budgets, supplier changes, acquisitions, system recovery and the ability to continue operating a business process.
Identify the licensing layers
A business application rarely has one licence. It may combine:
- a SaaS subscription;
- custom code created for the organisation;
- supplier-owned modules;
- open-source libraries;
- commercial database, reporting or document components;
- cloud services charged by usage;
- fonts, images, data sets or APIs with separate terms.
Maintain a register that records the component, supplier, licence, renewal date, cost basis, permitted use and exit implications.
Recognise the main commercial models
| Model | What to check |
|---|---|
| User or seat licence | Named versus concurrent users, inactive accounts, contractors and minimum commitments. |
| Organisation or site licence | Which legal entities, locations or domains are covered. |
| Usage-based service | Transactions, storage, messages, API calls, overage rates and spend controls. |
| Perpetual licence | Whether support, security updates and future versions require continuing fees. |
| Subscription licence | Renewal, price changes, suspension, termination and data retrieval. |
| Embedded or OEM licence | Whether the component may be included in a product supplied to customers. |
Understand open-source obligations
Open-source does not mean “no conditions”. Each package is supplied under a licence. Permissive licences commonly allow broad use subject to notices and attribution. Other licences may impose wider obligations when software is distributed or combined in particular ways.
Do not rely on a generic statement that the system “uses open source”. Ask for:
- a software component list;
- the licence for each component;
- the version in use;
- known security and maintenance status;
- any notices or source-disclosure obligations relevant to the intended use.
Specialist review may be needed where a product will be distributed, licensed to customers or built around components with reciprocal terms.
Separate ownership from permission to use
Owning custom code and licensing a component are different legal and operational positions. The business may own the bespoke workflow code while relying on a commercial PDF library under an annual licence. If the library licence ends, ownership of the surrounding code does not preserve that function.
Similarly, access to a supplier's repository does not grant permission to reuse supplier-owned modules outside the agreed system.
Check transfer and change scenarios
Licence terms should be reviewed against realistic business events:
- moving hosting to another provider;
- appointing a replacement support supplier;
- selling the business or transferring the application to another group company;
- launching the system in another country;
- allowing customers, partners or contractors to use it;
- turning an internal tool into a commercial product;
- ending the supplier relationship.
A licence adequate for one internal department may not cover a future SaaS product.
Look beyond the headline price
Licence cost may change with users, data volume, transactions, environments or features. Include:
- production, test and disaster-recovery environments;
- administrators and service accounts;
- minimum terms and annual uplifts;
- implementation or migration charges;
- premium support;
- export, termination or transition assistance;
- replacement cost if the component becomes unsuitable.
Define who manages compliance
Someone should own the licence register, renewals and usage checks. Development teams may introduce packages, while finance sees invoices and operations controls accounts. Without a named owner, the organisation may pay for unused licences or discover restrictions during an urgent migration.
Supplier questions
- Which parts of the proposed system are licensed rather than owned?
- Which licences are held by the supplier and which must be held by the customer?
- Can the licence be transferred to another support or hosting provider?
- What happens to operation and data access if fees are disputed or the contract ends?
- Are test, staging and recovery environments covered?
- Which open-source obligations affect the intended use?
- What replacement options exist for critical proprietary components?
Create a licence register
Ask for a component and licence register before final acceptance. Review it against current use and foreseeable changes, then record the person responsible for renewals and compliance. Where rights are central to the value of the system, obtain specialist contractual and intellectual-property advice.