A software license sets the rules for using software – whether you can view and modify the code, distribute it, and the conditions under which you can use it.
This post covers the essentials: user rights, license categories, combining licenses, license headers, license files, multi-licensing, relicensing, forks, and our licensing strategy.
User rights
Refers to the specific permissions granted to anyone using the software. There are four main rights:
- View the code
- Modify the code
- Distribute the code
- Usage
View the code
The right to access and read the source code.
Modify the code
The right to access and modify the source code.
Distribute the code
The right to share copies of the software, subject to the license conditions, eg via download, online access, or physical media. 'Sharing' means providing the actual software – either the source code or compiled binaries – not images or video demonstrations of the software.
Usage
The rules defining how, where, and under what conditions end users can use the software. Usage restrictions apply only to proprietary and source-available licenses, not to open source licenses.
Typical restrictions include scope (eg personal, commercial, educational), limits on the number of devices or users, geographic restrictions, no reverse engineering, and constraints on the deployment model (eg SaaS, PaaS, or on-premises).
Other rights
Other rights may include access to support, warranties, the ability to transfer the software, access to documentation, the right to grant usage rights to others, and additional permissions.
License categories
There are three license categories: open source, source-available, and proprietary. First up, open source.
Open source
Refers to software whose source code is publicly available and licensed under terms that permit use, modification, and redistribution. View a list of open source licenses. These licenses are typically categorised as either permissive or copyleft.
Permissive
A permissive license places minimal restrictions on how the software can be used, modified, and redistributed. Examples include: MIT license, Apache License 2.0, and the BSD 3-Clause License.
Copyleft
A copyleft license requires derivative works to be distributed under the same license terms as the original software. Examples include: GPL 3.0 License, AGPL 3.0 License, and the LGPL 3.0 License.
Distribution
Both permissive and copyleft licenses require retaining the original license and copyright notice. Permissive licenses allow modifications to use any open source, source-available, or proprietary license.
Source-available
Source-available licenses (SALs) allow users to view the source code, but modification depends on the license. SALs allow redistribution, but only if the license's usage restrictions, such as prohibiting commercial use, are followed.
Source-available licenses let developers share source code while retaining control over how it's used and distributed. Examples licenses include: BSL, SSPL, and the Elastic License.
Relicensing option
A SAL could allow the software to be relicensed – commonly to an open source license – after a set period, eg three to seven years.
Proprietary
Proprietary licenses do not allow access to or modification of the source code. Software is typically delivered in binary form, and may impose usage, distribution, and commercial restrictions as defined by the license.
EULA
Most proprietary software is distributed under an End-User License Agreement (EULA) – a legal contract that defines how the software may be used, installed, copied, and redistributed.
Typically, users must agree to the terms during the installation process before using the software.
License information
If proprietary software incorporates open source or source-available code, the copyright and license terms of that code must be preserved. This is done by including a license or notice file in the software distribution, and/or displaying license information in the software UI.
Combining licenses
A codebase can contain: a) One license across the entire codebase, b) Mixed licenses across different files, and c) Mixed licenses within a single file.
License headers
In a mixed-license codebase, every file must include a license header specifying its license. If a file contains code under multiple licenses, each section should have its own license header. For example:
/*
Copyright © 2026 Your Company
Created: 05 January 2026
Previous license: BUSL-1.1
SPDX-License-Identifier: MIT
*/
// MIT code here
Automation
Source-available and proprietary licenses can switch to a new license after a set a time. Headers can be updated automatically based on the file's age.
License files
A license file contains the full text of a license. Include one license text file for each type of license used in your project.
License files are stored in the root folder, either as a single LICENSE.txt file for the entire codebase, or in a LICENSES/ folder containing one file per license type, eg MIT.txt, BUSL-1.1.txt, PROPRIETARY.txt. You could use Markdown (.md) instead of text files.
Multi-licensing
The practice of releasing the same code under multiple licenses, giving users the option to choose between, for example, an open source license and a proprietary license.
Relicensing
Copyright owners may relicense their code at any time, but they cannot revoke or alter the license for code that has already been released.
Forks
A fork is a copy of a codebase that is developed independently from the original project, allowing changes to proceed on a separate path while retaining the original license terms.
Forks are permitted for open source projects, and if allowed by the license, for source-available projects. To prevent forks, use a source-available license with redistribution restrictions or a proprietary license.
Our licensing strategy
This project uses the MIT license. We do not expect to relicense any part of the code under a source-available license, but the option is kept open. The for-profit company uses proprietary licenses.