.. SPDX-FileCopyrightText: 2020 Veit Schiele
..
.. SPDX-License-Identifier: BSD-3-Clause
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.
.. seealso::
* `The Whys and Hows of Licensing Scientific Code
`_
* `A Quick Guide to Software Licensing for the Scientist-Programmer
`_
* Karl Fogel: `Producing Open Source Software `_
* `Forschungsdaten veröffentlichen
`_
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 :abbr:`GPL (GNU General Public License)` 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 :abbr:`GPL (GNU General Public License)`.
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, :abbr:`etc. (et cetera)`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`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 `_
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:
* `Datenlizenz Deutschland – Namensnennung – Version 2.0
`_
* `Datenlizenz Deutschland – Zero – Version 2.0
`_
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
`_.
.. seealso::
* `Font Licensing `_
`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
.. seealso::
* `Certified Open Source Hardware Projects
`_
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:
.. figure:: software-license-compatiblity.svg
:alt: 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
:file:`requirement.txt` file, for example:
.. code-block:: console
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`` or ``LICENSE.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 :file:`/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 :file:`/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
.. code-block:: rst
|License|
.. |License| image:: https://img.shields.io/github/license/veit/python4datascience.svg
:target: https://github.com/cusyio/Python4DataScience/blob/main/LICENSE
|License|
.. |License| image:: https://img.shields.io/github/license/veit/python4datascience.svg
:target: https://github.com/cusyio/Python4DataScience/blob/main/LICENSE
.. _standard_format_licensing:
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:
.. code-block::
# SPDX-FileCopyrightText: [year] [copyright holder] <[email address]>
#
# SPDX-License-Identifier: [identifier]
Check conformity
----------------
.. _reuse:
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:
.. code-block:: console
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:
.. figure:: reuse-compliant.svg
:alt: REUSE-compliant Badge
.. _reuse-in-gitlab-ci:
CI workflow
:::::::::::
You can easily integrate REUSE into your continuous integration workflow:
.. tab:: Pre-commit
You can automatically run ``reuse lint`` as a :doc:`pre-commit hook
` on every commit by adding the following to your
:file:`.pre-commit-config.yaml`:
.. code-block:: yaml
repos:
- repo: https://github.com/fsfe/reuse-tool
rev: v2.1.0
hooks:
- id: reuse
.. tab:: GitLab
Add the following to the :file:`.gitlab-ci.yml` file:
.. code-block:: yaml
reuse:
image:
name: fsfe/reuse:latest
entrypoint: [""]
script:
- reuse lint
.. tab:: GitHub
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 :file:`workflow .yml` file:
.. code-block:: yaml
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
::::::::::::
.. _open_chain:
`ISO/IEC 5230/OpenChain `_
recommends :ref:`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.
.. seealso::
* `OpenChain project `_
* `OpenChain Self Certification
`_
* `Reference-Material
`_
`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.
.. figure:: clearly-defined.png
:alt: Screenshot of the ClearlyDefined website with cryptography example
`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
.. seealso::
* `GitHub Action for ORT
`_
* `ORT for GitLab `_
`licensechecker `_
A command line tool that scans installation directories for licences.
Python package metadata
-----------------------
With :pep:`658` the :file:`METADATA` file from distributions becomes available
in the :pep:`503` repository API on :term:`PyPI`. This allows the metadata of
:doc:`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
:samp:`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
`_.
.. seealso::
* :pep:`639` – Improving License Clarity with Better Package Metadata
* :pep:`621` – Storing project metadata in pyproject.toml
* :pep:`643` – Metadata for Package Source Distributions