Software Licencing Agreements: A Complete Guide

A software licencing agreement is the contract that controls how software is used, distributed, and modified. Whether you are a business purchasing enterprise tools, a developer releasing an application, or a startup choosing between open-source components, understanding software licencing agreements is essential to protecting your interests and staying compliant.

This guide covers what software licencing agreements contain, the different types available, how to draft or evaluate one, and the compliance obligations they create. This content is educational and does not constitute legal advice. Consult a qualified attorney for guidance specific to your situation.

What Is a Software Licencing Agreement

A software licencing agreement is a legal contract between the person or company that owns the software (the licensor) and the party that wants to use it (the licensee). The agreement grants specific rights to the licensee while the licensor retains ownership of the underlying intellectual property.

Software is protected by copyright law under the Berne Convention, which 181 countries have ratified. Without a licencing agreement, the default position is that no one has the right to use, copy, or distribute the software beyond what was explicitly included in the purchase. The licencing agreement is what grants those permissions.

Every software licencing agreement addresses these fundamental points:

• Scope of use: What the licensee is allowed to do with the software (install, run, modify, distribute)
• Authorized users: Whether one person, a specific number of users, or an entire organization may use the software
• Duration: Whether the licence lasts indefinitely (perpetual) or expires after a set term
• Restrictions: Activities that are explicitly prohibited (reverse engineering, sublicensing, competitive use)
• Liability and warranties: What the licensor guarantees and the limits of their financial responsibility
• Termination: The conditions under which the agreement ends and what happens afterward

The specifics vary enormously depending on the type of software, the business model, and the jurisdictions involved.

Types of Software Licencing Agreements

Software licencing agreements fall into several distinct categories, each suited to different business models and distribution strategies.

Proprietary licencing agreements

Proprietary agreements are the most restrictive. The source code remains confidential, modification is prohibited, and redistribution is forbidden. The licensee receives only the rights the vendor explicitly grants.

Common proprietary models include:

• Per-user (per-seat) licences: Each individual user requires a separate licence. This model is standard for productivity software like Microsoft 365 and design tools like Figma.
• Per-device (node-locked) licences: The licence is tied to a specific machine. Common for industrial control systems, embedded applications, and point-of-sale terminals.
• Enterprise (site) licences: A single agreement covers all users within an organization, often negotiated directly with the vendor and including volume pricing.
• Concurrent (floating) licences: A pool of licences is shared across a larger group of users. Anyone can use the software, but only the licensed number of users can access it at the same time.

Open-source licencing agreements

Open-source licencing agreements grant broad rights to use, modify, and redistribute the software. They divide into two main categories:

Permissive licences impose minimal obligations:

1. MIT Licence: The most popular licence on GitHub. Allows any use with one requirement: include the original copyright notice and licence text.
2. Apache Licence 2.0: Similar to MIT but adds an explicit patent grant and requires a NOTICE file and documentation of changes.
3. BSD Licences: The 2-clause BSD allows broad use with attribution. The 3-clause version adds a non-endorsement clause.

Copyleft licences require derivative works to carry the same licence:

1. GNU General Public Licence (GPL) v3: Allows commercial use and modification but requires that distributed derivative works carry the GPL and that source code is made available.
2. GNU Affero General Public Licence (AGPL): Extends the GPL to network use, requiring source code release even for software offered as a web service.
3. Mozilla Public Licence (MPL) 2.0: Applies copyleft at the individual file level. Modified files must remain under MPL, but they can be combined with proprietary code.

SaaS and subscription agreements

Software-as-a-Service agreements differ from traditional software licencing agreements because the user never installs or possesses the software. Instead, they access it remotely over the internet.

SaaS agreements typically cover:

• Access rights and service availability (uptime SLAs)
• Data ownership and portability
• Security obligations and incident response
• Subscription terms, auto-renewal, and cancellation
• Data processing obligations under GDPR Article 28

OEM licencing agreements

OEM agreements allow software to be pre-installed on hardware or bundled with another product. The licence is tied to the hardware and generally cannot be transferred. These agreements include specific terms about branding, support responsibilities, and quality standards that the OEM must maintain.

Key Clauses in Software Licencing Agreements

Whether you are drafting a software licencing agreement for your own product or reviewing one for software your business will use, these clauses carry the most legal and commercial weight.

Grant of licence

The grant clause is the heart of every software licencing agreement. It must state:

• Whether the licence is exclusive or non-exclusive
• The exact scope of permitted activities (use, copy, modify, distribute)
• The number of authorized users, devices, or installations
• Whether commercial use is allowed
• Any geographic or industry restrictions

Ambiguity in the grant clause is the single most common source of licensing disputes. Be precise. "You may use the software" is insufficient. "You may install and run one copy of the software on a single device for internal business purposes" is clear.

Intellectual property rights

State unambiguously that the licensor retains all intellectual property rights in the software. The licence is a grant of permission, not a transfer of ownership. This clause protects the licensor in acquisitions, bankruptcy proceedings, and IP litigation.

The clause should also address:

• Ownership of modifications or customizations created by the licensee
• Whether the licensee grants the licensor any rights to feedback or suggestions
• Treatment of pre-existing intellectual property that the licensee contributes

Restrictions and prohibited conduct

Most software licencing agreements prohibit:

• Reverse engineering, decompiling, or disassembling the software
• Removing or altering copyright notices, watermarks, or licence headers
• Using the software to build a competing product or service
• Sublicensing, reselling, or transferring the licence without consent
• Exceeding the authorized number of users or installations
• Using the software for unlawful purposes

In the EU, the Software Directive (2009/24/EC, Article 6) permits decompilation for interoperability purposes regardless of contractual restrictions. This right cannot be waived by contract.

Warranty and disclaimer

The standard approach is an "AS IS" disclaimer: no warranties of merchantability, fitness for a particular purpose, or non-infringement. This is nearly universal in both proprietary and open-source software licencing agreements.

However, for consumer-facing software in the EU, the Digital Content Directive (2019/770/EU) establishes minimum conformity requirements. Digital content must conform to the contract, be fit for purpose, and meet reasonable expectations for at least two years. These protections cannot be disclaimed.

For B2B agreements, consider offering a limited warranty (for example, that the software will materially conform to its documentation for 90 days) as a commercial differentiator.

Limitation of liability

Cap total liability at the amount paid for the licence during the preceding 12 months. Exclude all indirect, consequential, incidental, special, and punitive damages. These clauses are standard and generally enforceable in B2B contexts.

Certain liabilities should be carved out from the cap:

• Breaches of confidentiality obligations
• Intellectual property indemnification
• Wilful misconduct or gross negligence
• Data protection violations

Data protection and privacy

If the software collects, processes, or transmits personal data, the licencing agreement should reference a separate privacy policy and, where applicable, a Data Processing Agreement (DPA).

Under GDPR Article 13, the software provider must disclose what personal data is collected, the legal basis for processing, retention periods, and data subject rights. Under CCPA Section 1798.100, California consumers have the right to know what personal information is collected and to request its deletion.

Your software licencing agreement should work alongside a compliant privacy policy to provide full legal coverage. The licence governs usage rights; the privacy policy governs data handling.

Termination and post-termination

Define the triggers for termination:

1. Material breach with or without a cure period (30 days is typical)
2. Non-payment of licence fees
3. Insolvency or dissolution of either party
4. Mutual agreement in writing
5. Expiration of the licence term

Post-termination obligations should include:

• Cessation of all use of the software
• Deletion or return of all copies, including backups
• Written certification of compliance with destruction requirements
• A reasonable data export period (30 to 90 days) if the software stores user data

Drafting Software Licencing Agreements for Your Product

If you are publishing software and need to create a licencing agreement, you can generate a custom EULA as a starting point, and these principles will help you build a solid foundation.

Match the licence to your business model

Your software licencing agreement must align with how you intend to monetize and distribute the software:

• One-time purchase: Use a perpetual licence with clear version and support boundaries
• Subscription model: Use a term licence that references the subscription agreement for billing and renewal terms
• Freemium: Use tiered licencing with separate grants of rights for free and paid features
• Open-source with commercial options: Use a dual-licensing model (open-source licence for community use, proprietary licence for commercial use without copyleft obligations)

Address the full legal stack

A software licencing agreement is one part of a broader legal framework. For a complete setup, you also need:

• A privacy policy if you collect any user data
• Terms of service if you operate a web-based platform
• A cookie policy if your software or website uses cookies or tracking technologies
• A DPA if you process personal data on behalf of your customers (GDPR Article 28)

Plan for updates and version control

Software evolves, and so should the licencing agreement. Establish a process for:

• Versioning the agreement with clear effective dates
• Notifying licensees of material changes (email notification at least 30 days before changes take effect is best practice)
• Obtaining consent for changes to core terms (continued use after notice constitutes acceptance for minor changes; affirmative consent for material changes)
• Archiving previous versions for reference

Software Licencing Agreements and Compliance

Non-compliance with software licencing agreements creates real financial and legal risk. Building a compliance program is essential for any business that uses or distributes software.

Vendor audit risk

Enterprise software vendors actively audit their customers' licence compliance. Oracle, SAP, IBM, and Microsoft all maintain dedicated compliance teams. Audit clauses in their software licencing agreements grant them the right to inspect your usage records, typically with 30 days' notice.

Common audit findings include:

• More installations than licences purchased
• Use of higher-tier features than the licence permits
• Unauthorized deployment to virtual machines or cloud instances
• Expired maintenance agreements for software still in production use

Back-licensing fees from failed audits frequently run into the millions. Prevention is far cheaper than remediation.

Building an internal compliance program

Effective compliance requires ongoing discipline:

• Maintain a software asset inventory: Track every application in use, its licence type, seat count, expiration date, and renewal terms. Update the inventory whenever software is adopted, retired, or upgraded.
• Use automated discovery tools: Products like Flexera, Snow Software, and ServiceNow SAM scan your environment to identify installed software and compare it against your licence entitlements.
• Establish an approval workflow: Require procurement or IT approval before anyone installs new software or adds open-source dependencies. This prevents untracked licences from accumulating.
• Conduct quarterly reviews: Internal audits are cheaper than vendor audits. Review your software inventory quarterly, reconcile it against purchase records, and address any discrepancies before a vendor finds them.
• Train your team: Employees who understand licencing basics are less likely to create compliance problems. Annual training on software usage policies costs little and prevents expensive mistakes.

Open-source compliance

Open-source software licencing agreements impose their own compliance requirements. The most common failures are:

1. Missing attribution: Most open-source licences require preserving copyright notices and licence text. Stripping them violates the licence.
2. Copyleft violations: Incorporating GPL-licensed code into proprietary software without releasing source code. The Software Freedom Conservancy and Free Software Foundation pursue enforcement.
3. Licence incompatibility: Combining components with conflicting licence terms. For example, GPL v2-only code cannot be combined with Apache 2.0 code because the Apache patent clause is considered an "additional restriction" under GPL v2.
4. Undocumented dependencies: Using open-source libraries without tracking them, which makes compliance verification impossible during due diligence or audits.

Use tools like FOSSA, Snyk, or Black Duck to scan your codebase automatically for open-source components and flag potential licence conflicts.

Software Licencing Agreements for SaaS Products

SaaS products require a different approach to software licencing agreements because the user accesses the software remotely rather than installing it.

Key differences from traditional licences

Traditional software licencing agreements focus on installation, copying, and distribution rights. SaaS agreements focus on:

• Access rights: The right to access and use the service via the internet, not to possess a copy
• Service levels: Uptime guarantees, response times for support, and compensation for outages
• Data handling: Where data is stored, how it is protected, who can access it, and what happens to it when the subscription ends
• Availability: The provider's obligation to maintain the service and the consequences of discontinuation

Data portability and lock-in

SaaS licencing agreements should address data portability clearly:

• The licensee owns their data at all times
• Data can be exported in standard formats (CSV, JSON, API access) at any time
• After termination, data remains available for export for a defined period (30 to 90 days)
• After the export period, data is securely deleted

These provisions protect the licensee from vendor lock-in and ensure compliance with GDPR Article 20, which grants data subjects the right to receive their personal data in a portable format.

Multi-tenancy and security

SaaS platforms typically serve multiple customers from shared infrastructure. The software licencing agreement should address:

• Data isolation between tenants
• Encryption standards (at rest and in transit)
• Access controls and authentication requirements
• Incident response and breach notification timelines (GDPR Article 33 requires notification within 72 hours)
• Penetration testing and security audit rights

International Considerations for Software Licencing Agreements

Software licencing agreements that cross borders must account for varying legal frameworks.

EU-specific requirements

The EU provides strong protections for software licensees:

• The Software Directive (2009/24/EC) allows decompilation for interoperability and backs up of software regardless of licence terms
• The Digital Content Directive (2019/770/EU) establishes minimum conformity requirements for consumer digital products
• GDPR imposes strict obligations on data processing, cross-border transfers, and breach notification
• The UsedSoft v. Oracle ruling (C-128/11) established that perpetual software licences can be resold within the EU

US-specific considerations

In the US, software licencing agreements are governed primarily by state contract law, with federal copyright law (17 U.S.C.) providing the IP framework:

• Click-wrap agreements (requiring affirmative consent) are generally enforceable
• Browse-wrap agreements (consent by continued use) face more legal scrutiny
• CCPA and state privacy laws impose data handling obligations
• The Uniform Computer Information Transactions Act (UCITA) was intended to standardize software licensing law but has been adopted by only two states (Virginia and Maryland)

Governing law and dispute resolution

Include a governing law clause that specifies which jurisdiction's law applies. For international agreements, consider:

• Arbitration clauses as an alternative to litigation (faster, potentially less expensive, and the New York Convention makes arbitration awards enforceable in 172 countries)
• Forum selection clauses that specify where disputes will be resolved
• Whether separate licence terms are needed for different regions to comply with local consumer protection laws

A compliance platform like TermsBox can help you generate the supporting legal documents, including privacy policies and cookie policies, that your software licencing agreement references but does not replace.

Frequently Asked Questions

What is a software licencing agreement?

A software licencing agreement is a legally binding contract between the software owner (licensor) and the user (licensee) that defines how the software may be used, distributed, and modified. It covers the scope of permitted use, number of authorized users or installations, restrictions, warranty terms, liability limitations, and termination conditions. Every piece of commercial and open-source software operates under some form of licencing agreement.

What are the main types of software licencing agreements?

The main types are proprietary licences (per-user, per-device, enterprise, concurrent), open-source licences (permissive like MIT and Apache 2.0, and copyleft like GPL and AGPL), SaaS agreements (subscription-based access), and OEM licences (bundled with hardware). Each type grants different rights and imposes different obligations on the licensee.

Is a software licencing agreement legally enforceable?

Yes, software licencing agreements are generally enforceable as contracts in most jurisdictions. In the US, courts have upheld both negotiated agreements and click-wrap or browse-wrap licences, though browse-wrap terms face more scrutiny. In the EU, the Software Directive (2009/24/EC) provides a legal framework for software licensing. Enforceability depends on factors like mutual assent, consideration, and whether the terms are unconscionable or conflict with mandatory consumer protection laws.

What happens if you breach a software licencing agreement?

Breaching a software licencing agreement can result in licence termination, copyright infringement claims, and financial penalties. Under US copyright law (17 U.S.C. Section 504), statutory damages for willful infringement can reach $150,000 per work. Enterprise vendors like Oracle, SAP, and Microsoft conduct licence audits, and non-compliance findings frequently result in back-licensing fees running into millions of dollars. In the EU, Directive 2004/48/EC provides additional enforcement mechanisms including injunctions and seizure of infringing copies.