If you derive a program component from a GNU General Public License (GPL) software package, you are obligated to publish your software under the same GPL license. However, if the program is a combination of GNU Lesser General Public License (LGPL) code and your own work, you are allowed to distribute the result under a new, potentially proprietary license. You would have the same options if you derived your software from a Berkeley Software Distribution (BSD)-licensed package.

Although GPL, LGPL, and BSD are all free software licenses, they envisage very different types of use. To illustrate the fundamental differences in more detail, software licenses can be broken down into different categories.

Outside of the open source world, proprietary software licenses are the norm, and they rarely follow a standard. Besides the widespread commercial licenses, this category also includes shareware and freeware.

Categorical

Free and open source software licenses are defined by the Free Software Foundation (FSF) [1] and the Open Source Initiative (OSI) [2]. A distinction can essentially be made between copyleft, permissive, and public domain licenses.

Copyleft licenses [3] oblige the licensee to publish any adaptations of the software (derivatives) under the same license as the original work. This type of license, also known as a reciprocal license, is intended to prevent restrictions on the use of the software. The best-known copyleft license is undoubtedly the GPL; its copyleft is considered to be very strict, whereas that of the Mozilla Public License (MPL) is viewed as quite permissive. Because the licensors themselves are not bound by their own copyleft, they can publish new versions under a proprietary license or allow third parties to do the same, which is referred to as multiple licensing.

Copyleft licenses can quickly lead to incompatibilities if software is distributed along with software subject to other free licenses. For example, the three-clause BSD license is incompatible with the GPL, whereas the European Union Public License (EUPL) [4] is an interoperable reciprocal license that is compatible with most other open reciprocal licenses. The compatible license obligations take precedence if they conflict with the obligations arising from the EUPL [5].

Permissive open source licenses allow broader reuse than copyleft licenses. Derivations and copies of the source code can be distributed under conditions that have fundamentally different characteristics than the original license. The best-known examples of permissive open source licenses are the MIT and BSD licenses.

Finally, the public domain licenses transfer the copyright to the general public. The Unlicense [6] was created to mark software as public domain.

Beyond Software

Some open source software licenses can also be used for non-software works. In fact, they are often the best choice, especially if the works in question are edited as source code and versioned.

In contrast, the popular Creative Commons licenses are explicitly not intended for software [7], but for data, media, and documentation. The Open Knowledge Foundation [8] formulated the Open Data Commons licenses [9] for data and databases. Table 1 compares the non-software license variants, which now also include those for open source hardware [10].

As mentioned earlier, you are only free to choose the license for your programs if you have not derived your work from other software or combined it with other software. License compatibility for derived or combined works made up of your own software and external code that is subject to an open source license is shown in Figure 1.

Figure 1: Overview of the compatibility of derived software licenses [12]. CC0 "No Rights Reserved" [11]

Various methods, including manual and software-based approaches, can be used to discover the license for derived or combined works. The manual method applies if the project is hosted on GitHub: The license is either stated in the license file or can be found in the license/ directory. To discover more, check the project repository to see if you can find a license there. If not, the next step is to look at the notes in the README file. Licenses can also be identified by software tools such as Liccheck [13] and REUSE [14].

Liccheck

Liccheck is interesting for anyone who uses Python in their projects – either directly or as a package dependency. One of the fixed components of every Python package is a file named requirements.txt, where the programmer specifies which other Python packages the current package needs to run. Liccheck looks for licenses of the packages listed in this file and displays any license conflicts it detects.

You first need to define a strategy that Liccheck will use to carry out its check; that is, which licenses should Liccheck consider to be in violation and which not? The more precise this definition, the more accurate the results of the check. Listing 1 shows how Liccheck is called and the results of the analysis for the Python cryptography module [15].

$ 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