Software licensing sets out what people can and cannot do with software. Though licenses vary significantly, they broadly fall into two categories: a less restrictive "open source" and a more restrictive category that's often called "commercial licensing".
Both types are legally valid, but you may need to prove the user accepted the license.
Here's what you need to know and do.
- 1. What is Software Licensing and Why Do I Need It?
- 2. What Is the Difference Between Open Source and Commercial Licensing?
- 3. Open Source Licenses
- 3.1. Open Source Definition
- 3.2. Open Source Licenses Restrictions and Exemptions
- 3.3. Open Source Enforceability
- 4. Commercial Licenses
- 5. Examples of Software Licenses
- 6. How to Enforce Software Licenses
- 7. Summary
What is Software Licensing and Why Do I Need It?
Normally when you sell a product, you can use documents such as a Terms and Conditions agreement or Terms of Use to cover the important legal points such as the details of the sale and what happens if something goes wrong. This works on the basis that you are transferring ownership of the product: you sell somebody a t-shirt and it's now theirs to own, use and potentially resell.
That doesn't work as neatly with software because you aren't selling something tangible. You may give the user a CD or a download code, but what they are actually paying for is the right to use the software. They don't buy the software (a set of computer code) itself: instead, you still own the rights to it.
This means you can control how the user's right to use the software operates in practice, including restrictions on who can use it, where, in what way and for what purpose. You can even restrict what they can produce with the software. You are also at liberty not to impose a particular restriction.
A good software license sets out these restrictions (or the lack of them) in a clear manner so people can decide if they agree to them before buying, obtaining or using the software.
What Is the Difference Between Open Source and Commercial Licensing?

The precise differences vary between individual licenses, but the most fundamental division is that commercial licenses are primarily about restrictions on use, modification and sharing software. Meanwhile open source is primarily about the absence of such restrictions. In turn that means open source emphasizes people's right to use the software in particular ways.
The difference is not fundamentally about the cost of software. You can sell software with an open source license, though this isn't a common business model; inherently somebody else could take that same software and give it away without charge. Some businesses do make money from selling open source software, for example by including technical support and advice as part of the deal.
You can use terms that fall more into the "commercial licensing" category with free software. In this case, accepting the terms is a condition of being allowed to use the software rather than part of a contract to buy it.
Open Source Licenses
Most open source licenses fall into two board sub-categories:
- Permissive licenses give the most freedom to users. They generally allow unrestricted use, modification and distribution, with minimal requirements or obligations on the user.
- Copyleft licenses have more restrictions. Most commonly they insist anyone who modifies the software can only distribute the new software using the same license as the original.
The key practical difference here is that permissive licenses make it much easier to take software and modify it to create a commercial product. Copyleft means that even with any changes, the software remains open source.
The GNU public license includes an explanation of the copyleft concept:

Open Source Definition
"Open Source" doesn't have a legal definition, but a leading industry organization called the Open Source Initiative says the term should only be used if the licence meets 10 conditions:
- There's no restriction on selling or giving away the software.
- The source code is accessible.
- People can modify the software to produce a new variant.
- The source code must always be available, but the author can insist anyone who makes changes releases them as a patch file to add to the original source code. (The idea here is to make it easy to tell which changes/developments were made by the original author and which variants have been developed independently by other users.)
- The license can't discriminate against a person or group.
- The license can't discriminate against using the software for a particular purpose.
- Any rights to use the software must automatically pass on to new users if the software is redistributed.
- The rights can't be bundled up to only cover a particular software distribution (eg a package of programs) rather than applying to an individual program.
- The license can't put restrictions on other software that is distributed alongside the licensed software.
- The license must be "technology-neutral". For example, it can't only apply to downloads and exclude distribution on CD.
Open Source Licenses Restrictions and Exemptions
Open source does not cover public domain software. This is software which no longer has any copyright protection, either because the original author has waived their copyright, or because the necessary time has elapsed under the relevant copyright laws. As the software no longer has copyright protection, licensing it is no longer meaningful.
Open source doesn't cover a category known as "source available". This is where the author has made the source code available (for example to help the software development community or to promote research) but wants to retain and enforce their full rights over the software. This means they impose restrictions on use beyond simply requiring a similar license for any derivatives or modifications.
Open source only covers licensing and thus copyright. It doesn't apply to trademarks. This means somebody could release software under an open source license and use a trademarked name for the program or application. Other people would have the rights to modify and distribute the software, but would not be allowed to call it by the trademarked name.
Open Source Enforceability
Until well into the 21st century, it was not legally clear how an open source contract could be enforced. One theory was that although a software developer could pursue somebody for breach of contract if they violated the license, they could not pursue them for breach of copyright in the software itself.
That theory was initially backed in a case called Jacobsen vs Katzer. However, a higher court reversed the verdict and established a clear precedent. Violating an open source license means the rights granted by a software developer no longer apply. In turn, using the software in certain ways (such as modifying or distributing it) becomes a violation of copyright.
The result is that courts can and will enforce an open source license as a way to protect the software developer's copyright. This is the case even though the main purpose of open source is to relax restrictions.
Commercial Licenses
Commercial software licenses tend to start from the perspective that the user only has rights explicitly granted by the software developer. They are most commonly used on software that's sold or leased, but this doesn't have to be the case. Some people use the term "proprietary license" to cover this type of license, including when it's used for free software.
The term "commercial licensing" can also cause confusion in another context. In this case it is used to describe a license for software where the user is allowed to use the software for commercial purposes. This contrasts with "non-commercial licensing" which only gives people permission for personal use of the software.
As you can see, simply relying on the name of a particular software license type can cause confusion. (Some people use the terms in different ways to how we've described them here.) This means the terms of the license must be clear about the precise rights and restrictions it involves.
Most commercial licenses vary mainly on what they cover. This could include the number of users, the number of devices, and the time period the license covers. This will often depend on whether the software has a one-off cost or an ongoing subscription fee.
Steam's license clearly explains what rights it gives users:

Commercial licenses don't have to be excessively formal or use complex language. Microsoft's licence for Minecraft is particularly clear:

Examples of Software Licenses

With both open source and commercial licenses, you can use existing licenses (adding in the relevant details) or write your own. Many developers will use an existing open source license, with common examples including:
- MIT License: Arguably the least restrictive "permissive" license. In effect it only requires that you acknowledge the original copyright holder (ie the software developer) and include a warranty disclaimer (meaning the software developer doesn't accept responsibility for any problems the software causes.)
- Apache 2.0: This is similar to the MIT License but includes a license for using a patented technology.
- BSD: This is similar to the MIT License but says you can't use the author or software developer's name to endorse or promote anything you make using the software (including variants of the software itself.)
- GNU: This is arguably the best known "copyleft" license. It broadly says any software that derives from the licensed software must also carry the same license.
- Mozilla Public License: This is somewhere in between GNU and the various permissive licenses. It means you can use the licensed software as part of a wider commercial product. You can then put a commercial license on your new product, as long as the components from the original software remain open source.
Here's how the MIT license emphasizes its lack of restrictions:

Mozilla explains how its license lets software developers ("contributors") address their intellectual property rights:

With commercial licenses, it's less common to use a standard wording. That's mainly because the specific rights you grant and restrictions you impose will vary significantly, as will the specific details of you and your software. As having unique licenses drafted can be expensive, one option is to use a generator or similar service which uses established wording with a defined legal meaning but uses these clauses as building blocks for a customized license.
Frontier's license includes specific restrictions which might not be found in a more generic video game license:

Similarly, the software license for Microsoft Security Essentials includes details specific to the product and the varying user base:

Whatever wording you use, the license document is commonly called an End User License Agreement or EULA.
How to Enforce Software Licenses

Both open source and commercial software licenses are legally enforceable as long as you can prove the user agreed to them. You can make it a mandatory requirement to agree to the license before somebody uses the software.
The best ways to do this depend on the nature of the product and how much certainty you need so that you can prove the user agreed to the software. The weakest option is to simply state somewhere that using the software constitutes agreeing to the software license.
The problem is that the user could claim they never saw this statement. Even if you can persuade a court otherwise, this could cause a lengthy and costly legal debate.
A better option is to specifically require the user to consent to the agreement, for example through a digital signature or tickbox. This could be before they download or order the software, before they install it on a device, or before they use it for the first time.
For maximum certainty, you can use an approach called clickwrap (previously known as shrink-wrap with physical software such as boxed CDs). This approach means setting up the technology so that it is physically impossible to use the software without consenting to the license agreement.
Whatever method you use, the two most important points are that you can show the user made a meaningful decision to consent to the agreement, and that they had a fair opportunity to read the agreement first. This means the best option is a clear request for consent that includes a link to the EULA, with the user giving a positive and unambiguous signal of consent. This could include a clearly marked tick-box or toggle; never have these pre-ticked or set to consent by default.
The Malwarebytes installation tool requires the user to confirm they accept the EULA. It's perfect for somebody using a mouse, though "Accept" is pre-selected for somebody who confirms by pressing the Enter key.

The Bleachbit installation tool goes a step further: it's physically impossible to install the software without confirming acceptance of the license agreement, which is clearly accessible.

Summary
Software licenses set out rights and restrictions on how somebody can use software. 'Open source' licenses are more about putting limited restrictions on the user, while 'commercial' licenses are more about the user only having explicitly granted rights.
Despite the name, 'commercial' licenses aren't restricted to paid software. In some scenarios terms like 'proprietary' software may be more appropriate. Whatever you call software, the key is that license terms are clear.
Open source software often uses an existing, standard model license. With commercial software it's usually safer to use a custom-written license that fits your specific needs.
Whatever type of license you use, be certain you can prove the user made an informed decision to accept it before using the software.