A software license is a legal instrument that grants permission to use, copy, modify or distribute a computer program and sets the conditions and restrictions that apply to those acts. In software licensing, the license exists because code is protected by copyright by default: without permission from the rights holder, copying or adapting the program is generally not allowed.
A license does not usually transfer ownership. The author or company keeps the copyright and grants the licensee a defined set of rights, which may be broad and free of charge, as with open source licenses, or narrow and paid, as with most proprietary software agreements.
How a software license works legally
A software license works by turning acts that copyright reserves to the author into permitted acts under stated conditions. Installing a program creates copies in storage and memory, and distributing or modifying it creates further copies and derivative works, so each of these needs a legal basis that the license provides.
Most licenses contain the same core elements: the grant of rights, the scope (number of users, devices or cores, territory and duration), restrictions such as a ban on reverse engineering, obligations such as keeping copyright notices, a warranty disclaimer and a limitation of liability, and rules on termination when the conditions are broken.
Some licenses also contain an explicit patent grant, as the Apache License 2.0 and GPL version 3 do, which protects users against patent claims from contributors. Licenses without such a clause, such as the MIT License, leave the patent question less clearly settled.
| Clause | What it defines | Typical example |
|---|---|---|
| Grant | Which acts are permitted | Use, copy, modify, distribute |
| Scope | Limits on users, devices, time or territory | One license per named user |
| Restrictions | Acts that remain forbidden | No reverse engineering or resale |
| Obligations | Duties of the licensee | Keep notices, share source code |
| Disclaimer and liability | Allocation of risk | Provided as is, liability capped |
| Termination | When the rights end | Automatic on breach of conditions |
Proprietary and open source licenses
Software licenses fall into two broad families. Proprietary licenses keep the source code closed, restrict copying and usually charge a fee, often through an EULA that the user accepts at installation. Open source licenses publish the source code and allow anyone to use, study, modify and redistribute it, subject to conditions.
Open source licenses are further divided into permissive licenses, such as MIT, BSD and Apache 2.0, which require little more than attribution, and copyleft licenses, such as the GPL family, which require that derivative works be released under the same license. The LGPL and the Mozilla Public License are weak copyleft licenses that apply the requirement only to the library or to individual files.
| License family | Source code | Redistribution | Main obligation |
|---|---|---|---|
| Proprietary | Usually closed | Forbidden or tightly controlled | Pay and respect usage limits |
| Permissive | Open | Allowed, including in closed products | Keep copyright and license text |
| Weak copyleft | Open | Allowed with limited sharing duty | Share changes to the licensed part |
| Strong copyleft | Open | Allowed under the same license | Release the whole derivative work |
| Network copyleft | Open | Also triggered by network use | Offer source to remote users |
Freeware is a separate idea: it costs nothing but usually remains proprietary, with no right to modify or redistribute. Price and freedom are independent, so free of charge does not mean open source.
Commercial licensing models
Commercial vendors meter the right to use software in different ways, and the metric often matters more for total cost than the list price. Perpetual licenses grant indefinite use of a version, usually with optional yearly maintenance, while subscriptions grant use only while payments continue.
| Model | Unit of measurement | Where it is common |
|---|---|---|
| Named user | Each identified person | Office and design applications |
| Concurrent user | Simultaneous sessions | Engineering tools with license servers |
| Per device | Each installation or machine | Embedded and point-of-sale software |
| Per core or processor | Compute capacity | Databases and server software |
| Usage-based | Transactions, calls or data volume | Cloud services and APIs |
Enterprises manage these entitlements with software asset management, because vendor audits can reveal underlicensing and lead to back payments. Virtualization and cloud migration are frequent sources of surprise, since a per-core license may count every physical core of a host rather than the virtual cores actually assigned.
Compliance risks and common mistakes
Most license problems arise from ignorance of obligations rather than deliberate infringement. Modern applications include hundreds of third-party packages, and each brings its own license that applies to the final product.
- Mixing incompatible licenses, for example linking GPL-only code into a product distributed under terms that the GPL does not allow.
- Dropping attribution by removing copyright notices or license files that permissive licenses require.
- Assuming public code is free to use: code published without any license remains fully protected by copyright.
- Overlooking network copyleft: the AGPL requires offering source to users of a modified program over a network.
- Exceeding entitlements by installing more copies or using more cores than the agreement covers.
Good practice is to keep a software bill of materials, scan dependencies automatically, record license identifiers such as SPDX expressions, and have legal counsel review unusual terms. Dual licensing, where the same code is offered under copyleft and commercial terms, gives companies a legal route to use copyleft software in closed products.
The short version
When you buy a book, you own the paper copy, but you may not print and sell copies of it. Software is similar. A software license is the permission slip that says what you may do with a program. It tells you whether you can install it, how many times, whether you can change it and whether you can share it.
Some licenses are generous and let anyone use and change the code for free. Others are strict and paid. Following the license is what keeps your use of the software legal.
Where it makes a difference
A startup builds a mobile banking companion app and plans to sell a white-label version to regional banks. Before the first commercial release, the team runs an automated dependency scan and finds about 400 third-party packages, most under MIT, BSD and Apache 2.0, but one PDF rendering library under the AGPL.
Because the app talks to a modified server component that uses that library, the AGPL would require offering the server source code to every bank and its users. The company replaces the library with an Apache-licensed alternative, adds the required notices to an about screen, and stores the scan report with each release. When a bank’s procurement team asks for a license inventory, the startup delivers it the same day and the contract proceeds without delay.