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.


This does not constitute legal advice. If in doubt, contact a lawyer or the legal department of your company.

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.

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


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.


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.


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.


Designs for open source hardware are covered by the CERN Open Hardware licences:




weakly reciprocal


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:

Software licence compatibility

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']
          cffi << cryptography
    cryptography (41.0.3): ['Apache Software', 'BSD']
    pycparser (2.21): ['BSD']
          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.


On GitHub you can have an open source license created in your repository.

  1. Go to the main page of your repository.

  2. Click on Create new file and then enter LICENSE or as the file name.

  3. Then you can click on Choose a license template.

  4. Now you can select the open source license that is suitable for your repository.

  5. You will now be asked for additional information if the selected license requires this.

  6. 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 generate a license badge for you, which you can include in your README file, for example


.. |License| image::


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 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

The following files have no copyright and licensing information:
* .gitattributes
* vectors/cryptography_vectors/x509/wosign-bc-invalid.pem
* vectors/pyproject.toml

The following files have no licensing information:
* docs/_ext/
* src/cryptography/


* 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:

REUSE-compliant 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:

- repo:
  rev: v2.1.0
  - id: reuse

Add the following to the .gitlab-ci.yml file:

    name: fsfe/reuse:latest
    entrypoint: [""]
    - 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]

    runs-on: ubuntu-latest
    - uses: actions/checkout@v3
    - name: REUSE Compliance Check
      uses: fsfe/reuse-action@v2


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.


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).


compares two codebase scans to detect significant changes.


collects and displays information about the licensing and copyright situation of a software project.

Screenshot of the ClearlyDefined website with cryptography example

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


A command line tool that scans installation directories for licences.

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.

See also

  • PEP 639 – Improving License Clarity with Better Package Metadata

  • PEP 621 – Storing project metadata in pyproject.toml

  • PEP 643 – Metadata for Package Source Distributions