Licensing¶
In order for others to use your software, it should have one or more licences that describe the terms of use. Otherwise, it is likely to be protected by copyright. Authors are those who have originally contributed to the software. If software is to be licensed, the consent of all those who can claim authorship is required.
Note
This does not constitute legal advice. If in doubt, contact a lawyer or the legal department of your company.
See also
Proprietary software licenses¶
Proprietary software licenses are rarely standardised; they can be commercial, shareware, or freeware.
Free and open source software licenses¶
They are defined by the Free Software Foundation (FSF) and the Open Source Initiative (OSI). A distinction can essentially be made between copyleft, permissive and public domain licenses.
Copyleft or reciprocal licences¶
Copyleft licences oblige the licensees to place any adaptation of the software (so-called derivatives) under the licence of the original work. This is intended to prevent restrictions on the use of the software. The best-known copyleft licence is the GPL (GNU General Public License). The copyleft of the GPL is considered very strong, while that of the Mozilla Public License is considered very weak.
Since the licensors are not bound by their own copyleft, they can also publish new versions under a proprietary license or allow third parties to do so (multiple licensing).
Copyleft licenses can quickly lead to incompatibilities with free licenses without copyleft. For example, the 3 Clause BSD license is incompatible with the
However, copyleft licences can quickly create incompatibilities when distributed together with software under other free licences. For example, the 3-Clause BSD licence is incompatible with the GPL.
The EUPL, on the other hand, is a reciprocal licence that is at least compatible and interoperable with most other open reciprocal licences: the compatible licence obligations take precedence if they conflict with the obligations arising from the EUPL.
Permissive open source licenses¶
Permissive open source licenses allow broader reuse than copyleft licenses. Derivatives and copies of the source code can be distributed under conditions that have fundamentally different properties than those of the original license. The best known examples of such licenses are MIT and BSD.
Public domain licenses¶
With public domain licences, the copyrights are transferred to the general public. The WTFPL was created to mark the public domain of software.
Non-software licences¶
Open source software licences can also be used for works that are not software. They are often also the best choice, especially if the works in question are edited and versioned as source code.
Data, media, etc.¶
CC0 1.0, CC BY 4.0 and CC BY-SA 4.0 are open licences used for non-software material, from datasets to videos. However, they are not recommended for software.
Tip
The DEAL consortium recommends the CC BY licence for Open Access publications, see also Why CC BY is the Best Choice for Open Access Publishing.
The Open Knowledge Foundation has also published a set of Open Data Commons licences for data/databases:
- Open Data Commons Open Database License (ODbL) v1.0
Attribution and sharing under equal terms.
- Open Data Commons Attribution License (ODC-By) v1.0
Attribution.
- Open Data Commons Public Domain Dedication and License (PDDL) v1.0
The PDDL places the data in the public domain and waives all rights.
GovData has submitted the Data Licence Germany in two variants:
When using the Community Data License Agreement – Permissive, Version 2.0 the copyright notices must be retained.
Another possible licence for artistic works is the Free Art License 1.3.
Documentation¶
Any open source software licence or open media licence also applies to software documentation. If you use different licences for your software and its documentation, you should make sure that the source code examples in the documentation are also licensed under the software licence. In addition to the Creative Commons licences mentioned above, the following licences are available specifically for free documentation.
- GNU Free Documentation License (FDL)
Copyleft licence for documentation to be used for all GNU manuals. Its applicability is limited to textual works (books).
- FreeBSD Documentation License
Permissive documentation licence with copyleft, compatible with the GNU FDL.
- Open Publication License, Version 1.0
Free documentation licence with copyleft, provided none of the licence options in Section VI of the licence are used. In any case, it is incompatible with the GNU FDL.
Fonts¶
- SIL Open Font License 1.1
Font licence that can be freely used in other works.
- GNU General Public License 3
It can also be used for fonts, but it may only be included in documents with the font exception.
See also
- LaTeX ec fonts
Free European Computer Modern and Text Companion fonts commonly used with Latex.
- Arphic Public License
Free licence with copyleft.
- IPA Font license
Free licence with copyleft, but derived values may not use or contain the name of the original.
Hardware¶
Designs for open source hardware are covered by the CERN Open Hardware licences:
- CERN-OHL-P-2.0
permissive
- CERN-OHL-W-2.0
weakly reciprocal
- CERN-OHL-S-2.0
strongly reciprocal
Choosing a suitable license¶
Overviews of possible licenses can be found in the SPDX License List or OSI Open Source Licenses by Category. When choosing suitable licences, the websites Choose an open source license and Comparison of free and open-source software licenses will help you.
If you want to achieve the widest possible distribution of your package, for example, MIT or BSD versions are a good choice. The Apache licence protects you better from from patent infringement, but it is not compatible with the GPL v2.
Check dependencies¶
In addition, you should look at what licences those packages have that you depend on and should be compatible with:
Licence compatibility for derivative works or combined works of own code and external code licensed under an open source licence (from Licence compatibility, following The Rise of Open Source Licensing p. 119).¶
To analyse licences, you can look at license compatibility.
With liccheck
you can check Python packages and their dependencies with a
requirement.txt
file, for example:
liccheck -s liccheck.ini -r requirements.txt gathering licenses... 3 packages and dependencies. check unknown packages... 3 packages. cffi (1.15.1): ['MIT'] dependency: cffi << cryptography cryptography (41.0.3): ['Apache Software', 'BSD'] dependency: cryptography pycparser (2.21): ['BSD'] dependency: pycparser << cffi << cryptography
Furthermore, it can also be useful to publish a package under several licences. An example of this is cryptography/LICENSE:
This software is made available under the terms of either of the licenses found in LICENSE.APACHE or LICENSE.BSD. Contributions to cryptography are made under the terms of both these licenses.
The code used in the OpenSSL locking callback and OS random engine is derived from the same in CPython, and is licensed under the terms of the PSF License Agreement.
GitHub¶
On GitHub you can have an open source license created in your repository.
Go to the main page of your repository.
Click on Create new file and then enter
LICENSE
orLICENSE.md
as the file name.Then you can click on Choose a license template.
Now you can select the open source license that is suitable for your repository.
You will now be asked for additional information if the selected license requires this.
After you have given a commit message, for example
Add license
, you can click on Commit new file.
If you’ve already added a /LICENSE
file to your repository, GitHub uses
licensee to compare the file with a
short list of open source licenses. If
GitHub can’t detect your repository’s license, it might contain multiple
licenses or be too complex. Then consider whether you can simplify the license,
for example by outsourcing complexity to the /README
file.
Conversely, you can also search for repositories with specific licenses or license families on GitHub. You can get an overview of the license keywords in Searching GitHub by license type.
Finally, you can have Shields.io generate a license
badge for you, which you can include in your README
file, for example
|License|
.. |License| image:: https://img.shields.io/github/license/veit/python4datascience.svg
:target: https://github.com/cusyio/Python4DataScience/blob/main/LICENSE
Standard format for licensing¶
SPDX stands for Software Package Data Exchange and defines a standardised method for the exchange of copyright and licensing information between projects and people. You can choose the appropriate SPDX identifiers from the SPDX License List and then add to the header of your licence files:
# SPDX-FileCopyrightText: [year] [copyright holder] <[email address]>
#
# SPDX-License-Identifier: [identifier]
Check conformity¶
REUSE¶
REUSE was initiated by the Free Software Foundation Europe (FSFE) to facilitate the licensing of free software projects. The REUSE tool checks licenses and supports you in compliance with the license, for example:
reuse lint
# MISSING COPYRIGHT AND LICENSING INFORMATION
The following files have no copyright and licensing information:
* .gitattributes
* .github/ISSUE_TEMPLATE/openssl-release.md
...
* vectors/cryptography_vectors/x509/wosign-bc-invalid.pem
* vectors/pyproject.toml
The following files have no licensing information:
* docs/_ext/linkcode_res.py
* src/cryptography/__about__.py
# SUMMARY
* Bad licenses: 0
* Deprecated licenses: 0
* Licenses without file extension: 0
* Missing licenses: 0
* Unused licenses: 0
* Used licenses: 0
* Read errors: 0
* files with copyright information: 2 / 2806
* files with license information: 0 / 2806
Unfortunately, your project is not compliant with version 3.0 of the REUSE Specification :-(
With the REUSE API you can also generate a dynamic compliance badge:
CI workflow¶
You can easily integrate REUSE into your continuous integration workflow:
You can automatically run reuse lint
as a pre-commit hook on every commit by adding the following to your
.pre-commit-config.yaml
:
repos:
- repo: https://github.com/fsfe/reuse-tool
rev: v2.1.0
hooks:
- id: reuse
Add the following to the .gitlab-ci.yml
file:
reuse:
image:
name: fsfe/reuse:latest
entrypoint: [""]
script:
- reuse lint
On GitHub you can integrate the REUSE action into your workflow with the
GitHub Action REUSE Compliance Check, for
example, by adding the following to your workflow .yml
file:
name: REUSE Compliance Check
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: REUSE Compliance Check
uses: fsfe/reuse-action@v2
Alternatives¶
- ISO/IEC 5230/OpenChain
recommends REUSE as a component to improve license and copyright clarity, but sets higher requirements to achieve full compliance.
It is based on OpenChain Specification 2.1 and is an international standard on software supply chains, simplified procurement, and open source license compliance.
- ScanCode
offers a range of tools and applications for scanning software codebases and packages to determine the origin and licence (provenance) of open source software (and other third-party software).
- DeltaCode
compares two codebase scans to detect significant changes.
- ClearlyDefined
collects and displays information about the licensing and copyright situation of a software project.
- FOSSology
is a free software compliance toolkit that stores information in a database with license, copyright, and export scanners.
- OSS Review Toolkit (ORT)
is a toolkit for automating and orchestrating FOSS policies, allowing you to manage your (open source) software dependencies. It
generates OWASP CycloneDX, SPDX Software Bill of Materials (SBOM) or custom FOSS attribution documentation for your software project
automates your FOSS policy to check your software project and its dependencies for licensing, security vulnerabilities, source code and technical standards
create a source code archive for your software project and its dependencies to comply with specific licenses
correct package metadata or license findings yourself
See also
- licensechecker
A command line tool that scans installation directories for licences.
See also
Python package metadata¶
With PEP 658 the METADATA
file from distributions becomes available
in the PEP 503 repository API on PyPI. This allows the metadata of
distribution packages to be analysed
without having to download the whole package.
In Python packages there are other fields where licence information is stored, such as the core metadata specifications, which are also limited. This leads not only to problems for authors to specify the correct licence, but also to problems when re-packaging for various Linux distributions.
Currently, although some common cases are covered and the licence classification
can also be extended, there are some popular classifications such as
License :: OSI Approved :: BSD License
that will be abolished. However,
this means that backwards compatibility is no longer guaranteed and the packages
have to be relicensed. At least you have a way to check your trove
classifications with trove-classifiers.