Software License Agreements: Types, Terms, and Compliance

Software license agreements govern how software can be used, distributed, and modified. Whether you are selecting a license for software you have built or evaluating the terms of software your business relies on, understanding software licensing is essential for legal compliance and risk management.

This guide explains the major types of software licenses, what a software license agreement should include, and how to evaluate licensing terms before committing to a product. This content is educational and does not constitute legal advice. Consult a qualified attorney for guidance on your specific situation.

What a Software License Agreement Covers

A software license agreement is a legally binding contract between the software rights holder (typically the developer or publisher) and the end user. It defines the scope of permitted use and the conditions attached to that permission.

At its core, every software licence agreement answers these questions:

Who can use the software? Named users, a specific number of seats, an entire organization, or anyone.
How can it be used? Personal use only, commercial use, educational use, or unrestricted.
Can it be modified? Some licenses allow modification and redistribution, while others prohibit any changes to the source code.
Can it be redistributed? Proprietary licenses typically forbid redistribution. Open-source licenses explicitly permit it, sometimes with conditions.
What are the liability terms? Nearly all software licenses include warranty disclaimers and liability caps.
When does the license end? Perpetual licenses last indefinitely. Subscription licenses expire when payments stop. Some licenses can be revoked for violations.

Without a software license document, the default legal framework is copyright law. Under the Berne Convention (which 181 countries have signed), the creator of a work holds exclusive rights automatically. A user who obtains software without a license technically has no legal permission to use it beyond what is implied by the transaction.

Types of Software Licenses

Software licenses fall into several broad categories. Understanding the distinctions is critical when choosing software for your business or selecting a license for your own product.

Proprietary (commercial) licenses

Proprietary licenses restrict users to the specific rights the vendor grants. The source code is not shared, modification is prohibited, and redistribution is forbidden. This is the model used by most commercial software.

Common proprietary license structures:

Per-user/per-seat: Each individual user requires a license. Microsoft 365 and Adobe Creative Cloud use this model.
Per-device: The license is tied to a specific machine rather than a person. Common for embedded software and point-of-sale systems.
Enterprise/site license: A single agreement covers all users within an organization, typically negotiated directly with the vendor.
OEM license: Software is bundled with hardware and cannot be transferred to a different device. Windows licenses sold with laptops are a common example.

Open-source licenses

Open-source licenses grant users the right to use, study, modify, and distribute the software. They fall into two subcategories.

Permissive licenses impose minimal restrictions:

MIT License: Allows virtually any use, including commercial, with only an attribution requirement. One of the most popular licenses on GitHub.
Apache License 2.0: Similar to MIT but includes an explicit patent grant and requires notices of changes to licensed files.
BSD Licenses (2-clause and 3-clause): Allow broad use with attribution. The 3-clause version adds a non-endorsement clause.

Copyleft licenses require derivative works to use the same license:

GNU General Public License (GPL) v3: Permits commercial use and modification but requires that distributed derivative works also be licensed under the GPL and that source code be made available.
GNU Lesser General Public License (LGPL): Allows linking to a library without triggering the copyleft requirement for the entire application. Used frequently for software libraries.
Mozilla Public License (MPL) 2.0: A file-level copyleft. Modified files must remain under the MPL, but you can combine them with proprietary code in a larger project.
GNU Affero General Public License (AGPL): Extends GPL's copyleft to network use. If you modify AGPL software and offer it as a web service, you must release your source code even if you never distribute a binary.

Free software licenses

The term free software license refers to licenses that respect the user's freedom to run, study, modify, and share the software. "Free" refers to freedom, not price. The Free Software Foundation (FSF) maintains a list of licenses that meet this definition.

All copyleft and permissive open-source licenses qualify as free software licenses. However, some free software licenses are not approved by the Open Source Initiative (OSI), and vice versa. For practical purposes, the overlap is nearly complete.

Public domain and creative commons

Public domain (CC0, Unlicense): The creator waives all rights. Anyone can use the software for any purpose with no conditions. SQLite is a notable public-domain project.
Creative Commons licenses: Occasionally used for software documentation or assets but generally not recommended for source code. The CC licenses were designed for creative works and lack provisions for patents and source code distribution.

Key Terms in a Software License Agreement

Whether you are drafting or reviewing a software license agreement, these are the clauses that matter most.

Grant of rights

This clause defines exactly what the user is permitted to do. It should specify:

Whether the license is exclusive or non-exclusive
Whether it covers one user, multiple users, or an organization
Whether commercial use is permitted
Whether modification and redistribution are allowed
Geographic restrictions, if any

Restrictions and prohibited uses

Common restrictions include:

Reverse engineering, decompiling, or disassembling the software
Removing or altering copyright notices, trademarks, or license headers
Using the software to compete with the vendor
Sublicensing without written permission
Exceeding the licensed number of users, devices, or installations

Intellectual property ownership

The license should clarify that the licensor retains ownership of the software and all associated intellectual property. A license grants permission to use, not ownership. This distinction matters in bankruptcy proceedings, mergers, and IP disputes.

Warranty disclaimers and liability limitations

Nearly all software licenses, both open-source and proprietary, include a warranty disclaimer. The common formulation is "AS IS" without warranties of any kind. Liability is typically capped at the amount the licensee paid for the software, or excluded entirely for indirect, consequential, and incidental damages.

Under the EU Consumer Rights Directive (2011/83/EU) and the Digital Content Directive (2019/770/EU), vendors selling to EU consumers cannot fully disclaim warranties. Digital content, including software, must conform to the contract and be fit for purpose for at least two years from delivery.

Termination

Specify the events that trigger license termination:

Breach of any license term
Non-payment (for subscription or maintenance agreements)
Insolvency of the licensee
Expiration of the license period

Also define what happens after termination: whether the licensee must delete all copies, whether any data can be exported, and whether any refund is owed.

Audit rights

Enterprise software licenses often include a clause granting the vendor the right to audit the licensee's usage. Vendors like Oracle, SAP, and IBM actively enforce audit clauses. Non-compliance discovered during audits can result in back-licensing fees, penalties, and legal action.

Create a comprehensive privacy policy for your website or app. Create yours in minutes with TermsBox.

Generate Now

How to Choose the Right License for Your Software

If you are a developer choosing a license for software you have built, the decision depends on your goals.

If you want maximum adoption

Choose a permissive license (MIT, Apache 2.0, or BSD). These impose the fewest restrictions on downstream users, which encourages adoption in both open-source and commercial projects. Companies are more willing to integrate MIT-licensed code into proprietary products because there is no copyleft obligation.

If you want to keep derivatives open

Choose the GPL or AGPL. The copyleft requirement ensures that anyone who distributes a modified version must also release their source code. The AGPL closes the "SaaS loophole" by extending this requirement to software offered over a network.

If you want to protect a library

The LGPL is designed for libraries. It allows other developers to link against your library in proprietary software without triggering the copyleft for their entire application. This balances openness with adoption.

If you want no restrictions whatsoever

Use CC0 or the Unlicense to place your software in the public domain. This maximizes freedom but provides no protection against others claiming your work as their own (though copyright law still applies in jurisdictions that do not recognize public-domain dedication).

If you are building commercial software

Use a proprietary license. Draft it yourself or work with an attorney. A software license document for commercial distribution should be reviewed by legal counsel, especially if you sell to enterprises, handle personal data, or operate across borders. If your software collects user data, you will also need a privacy policy that complies with laws like the GDPR and CCPA.

Software License Compliance for Businesses

Using software without complying with its license terms creates real legal and financial risk.

Common compliance failures

Exceeding seat counts: Installing per-user software on more devices than the license permits. This is the most common finding in vendor audits.
Ignoring copyleft obligations: Using GPL-licensed code in a proprietary product without releasing source code. The Free Software Foundation has pursued enforcement actions against violators, and the Software Freedom Conservancy actively litigates GPL violations.
Mixing incompatible licenses: Combining code under licenses with conflicting terms. For example, GPL v2-only code cannot be combined with Apache 2.0-licensed code because the patent clause in Apache 2.0 is considered an "additional restriction" under GPL v2.
Using expired or terminated licenses: Continuing to use software after a subscription lapses or after a license has been terminated for breach.
Failing to preserve attribution: Most open-source licenses require copyright notices and license text to be preserved in distributions. Stripping these notices violates the license.

How to manage software license compliance

Maintain a software inventory: Track every piece of software your organization uses, the license type, the number of seats or instances, and renewal dates.
Use license scanning tools: Tools like FOSSA, Black Duck, and Snyk automatically scan your codebase for open-source dependencies and flag license conflicts.
Establish an approval process: Require developers to get approval before introducing new open-source dependencies, especially those with copyleft licenses.
Document everything: Keep records of all license purchases, agreements, and correspondence with vendors. These records are essential during audits.
Review regularly: Conduct an internal license audit at least annually. Software inventories change as employees install new tools, developers add dependencies, and vendors change their licensing terms.

Software Licensing and Data Privacy

Software and licensing intersect with data privacy in several important ways.

Data processing by licensed software

Many software products collect telemetry, usage data, or crash reports. The license agreement should disclose this, but it often appears in a separate privacy policy or data processing agreement. Under Article 13 of the GDPR, the software vendor must inform users about what data is collected, why, and how it is processed.

When evaluating business software, check whether the vendor provides a Data Processing Agreement (DPA). Under GDPR Article 28, if the software vendor processes personal data on your behalf, a DPA is legally required. The DPA should specify the types of data processed, the purpose, security measures, sub-processor lists, and breach notification procedures.

SaaS and cloud software considerations

Cloud-based software raises additional licensing and privacy questions:

Data location: Where is your data stored? GDPR Chapter V restricts transfers of personal data outside the EU/EEA unless adequate safeguards are in place.
Data portability: Can you export your data if you leave the service? A good license agreement guarantees a data export period after termination.
Service continuity: What happens to your data if the vendor goes bankrupt or discontinues the product? Look for escrow arrangements or open-data commitments.

If your website uses third-party software that sets cookies or processes visitor data, you need to disclose that in your own privacy and cookie policies. A compliance platform like TermsBox can scan your site to identify these third-party tools and help you generate accurate privacy policies and cookie policies that reflect what your site actually does.

Open-Source License Obligations by Type

This reference table summarizes the key obligations for the most common open-source licenses.

Permissive licenses (MIT, BSD, Apache 2.0)

Include the original copyright notice and license text in distributions
Apache 2.0: include a NOTICE file if one exists in the original project
Apache 2.0: state changes made to licensed files
No requirement to release source code of derivative works
Commercial use, modification, and redistribution all permitted

Weak copyleft (LGPL, MPL 2.0)

Modified files must be released under the same license
LGPL: if you only link to the library (without modifying it), your application code can remain proprietary
MPL 2.0: copyleft applies at the file level, not the project level
Must provide source code for the licensed component upon request

Strong copyleft (GPL v2, GPL v3, AGPL)

Any distributed derivative work must be licensed under the same GPL version (or a compatible one)
Source code of the entire combined work must be made available
GPL v3: includes an explicit patent grant and anti-tivoization provisions
AGPL: network use triggers the source code disclosure requirement, even without traditional distribution
Commercial use is permitted, but the copyleft obligations apply

Frequently Asked Questions

What is a software license agreement?

A software license agreement is a legal contract between the software developer (or rights holder) and the end user that defines how the software may be used. It specifies permissions (installation, copying, modification), restrictions (redistribution, reverse engineering), liability limitations, and termination conditions. Without one, default copyright law applies, which generally prohibits any use beyond what the purchaser explicitly received.

What is the difference between a software license and a software subscription?

A software license grants permission to use the software, typically perpetually after a one-time payment. A software subscription grants access for a recurring fee (monthly or annual) and usually revokes access when payments stop. Many modern SaaS products use subscriptions, while traditional desktop software historically used perpetual licenses. Some vendors offer both models.

Can I use free software for commercial purposes?

It depends on the specific license. Permissive licenses like MIT and BSD explicitly allow commercial use with minimal restrictions. The GPL also permits commercial use but requires you to release your source code if you distribute a modified version. Public domain and CC0-licensed software has no restrictions at all. Always read the full license text before using any free software in a commercial product.

What happens if I violate a software license agreement?

Consequences range from license termination (losing the right to use the software) to legal action for copyright infringement. Under US copyright law (17 U.S.C. Section 504), statutory damages for willful infringement can reach $150,000 per work infringed. In the EU, Directive 2004/48/EC provides for injunctions, damages, and seizure of infringing copies. Many vendors send cease-and-desist letters before pursuing litigation.