Packaging:LicensingGuidelines

Licensing Guidelines

Author: Tom 'spot' Callaway
Revision: 0.05
Initial Draft: Thursday August 2, 2007
Last Revised: Monday March 31, 2008

Fedora Licensing

The goal of the Fedora Project is to work with the Linux community to create a complete, general purpose operating system exclusively from Free and Open Source software.

All software in Fedora must be under licenses in the Fedora licensing list . This list is based on the licenses approved by the Free Software Foundation , OSI and consultation with Red Hat Legal.

If code is multiple licensed, and at least one of the licenses is approved for Fedora, that code can be included in Fedora under the approved license(s) (but only under the terms of the approved license(s)).

License Text

If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package, must be included as documentation.

License: field

Every Fedora package must contain a License: entry. Maintainers should be aware that the contents of the License: field are understood to not be legally binding (only the source code itself is), but maintainers must make every possible effort to be accurate when filling the License: field.

The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask.

Valid License Short Names

The License: field must be filled with the appropriate license Short License identifier(s) from the "Good License" tables on the Fedora Licensing page. If your license does not appear in the tables, it needs to be sent to fedora-legal-list@redhat.com (note that this list is moderated, only members may directly post). If the license is approved, it will be added to the appropriate table.

License Text

If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake.

"Distributable"

In the past, Fedora (and Red Hat Linux) packages have used "Distributable" in the License: field. In virtually all of these cases, this was not correct. Fedora no longer permits packages to use "Distributable" as a valid License. If your package contains content which is freely redistributable without restrictions, but does not contain any license other than explicit permission from the content owner/creator, then that package can use "Freely redistributable without restriction" as its License: identifier.

Firmware

The License: field for any firmware that disallows modification should be set to: "Redistributable, no modification permitted".

Versioned licenses

Some licenses include the version as part of the Short License Identifier. This is only done when multiple versions of the license differ in significant ways (e.g. one revision is GPLv2 incompatible, while a later version is not). Be careful to ensure that you use the correct Short License Identifier, as shown in the tables on the Fedora Licensing page.

"or later version" licenses

Some licenses state that either the current version of the license or later versions may be used. It is important to note when a license states this. When a license has an "or later version" clause, we note that by appending a + to the Short License Identifier. Please note that there are already special Short License Identifiers for GPLv2+ and LGPLv2+, there is no need to append an additional + for those cases.

GPL and LGPL

Since compatibility of code and library linking is especially complex with GPL and LGPL, Fedora packages can no longer simply use "GPL" or "LGPL" in the License: field. Please refer to the Fedora Licensing page for the acceptable identifiers, and be careful to ensure that you select the correct one.

Dual Licensing Scenarios

If your package is dual licensed (or triple licensed, etc.), the spec must reflect this by using "or" as a separator. Note that this only applies when the contents of the package are actually under a dual license, and not when the package contains items under multiple, distinct, and independent licenses.

Example:

Package libfoo is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later. The package spec must have:

License: MPLv1.1 or GPLv2+

Multiple Licensing Scenarios

If your package contains files which are under multiple, distinct, and independent licenses, then the spec must reflect this by using "and" as a separator. Fedora maintainers are highly encouraged to avoid this scenario whenever reasonably possible, by dividing files into subpackages (subpackages can each have their own License: field).

Example: Package bar-utils contains some files under the Python License, some other files under the GNU Lesser General Public License v2 or later, and one file under the BSD License (no advertising). The package spec must have:

License: Python and LGPLv2+ and BSD

In addition, the package must contain a comment explaining the multiple licensing breakdown. The actual implementation of this is left to the maintainer. Some suggested implementations include

• A comment right above the License: field:

License: GPLv2+ and BSD

• Including a file as %doc which contains the licensing breakdown for the packaged files, then using:

# For a breakdown of the licensing, see PACKAGE-LICENSING 

• Noting the license above the appropriate %files section:

%files
%defattr(-,root,root,-)
%doc Changes
%{_bindir}/cobra-util
%{_bindir}/viper-util
%{_bindir}/gnu-util
%{_bindir}/rms-util
%{_bindir}/berkeley-util

Combined Dual and Multiple Licensing Scenario

If you are unlucky enough that your package possesses items multiple, distinct, and independent licenses...AND some of those items are dual licensed, you must note the dual licensed items by wrapping them with parenthesis (). Otherwise, the guidelines for Dual and Multiple Licensing apply.

Example: Package baz-utils contains some files under the Python License, some other files under the GNU Lesser General Public License v2 or later, one file under the BSD License, no advertising, and one file which is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later. The package spec must have:

License: Python and LGPLv2+ and BSD and (MPLv1.1 or GPLv2+)

Since this is a multiple licensing scenario, the package must contain a comment explaining the multiple licensing breakdown. The actual implementation of this is left to the maintainer.

Mixed Source Licensing Scenario

In some cases, it is possible for a binary to be generated from multiple source files with compatible, but differing licenses. Thus, the binary file would actually have simultaneous dual licensing (an AND, as opposed to an OR). For example, it is possible that a binary is generated from a source file licensed as BSD with advertising, and another source file licensed as QPL (which specifies that modifications must be shipped as patches). In this scenario, we'd wrap the list of licenses for that binary with parenthesis, example:

Package spot-utils contains some files under the Python License, but one of the files is generated from a BSD with advertising source file and a QPL source file.

License: Python and (BSD with advertising and QPL)

Software Types

There are some specific software types worth mentioning from a licensing/legal perspective.

Shareware

Shareware applications are not Open Source code, and are not acceptable for Fedora.

However, it is worth noting that some non-executable content exists that is required to make Open Source applications functional. An example of this would be open sourced game engines, such as Doom, Heretic, and Descent. These game engines come with freely distributable shareware gamedata files.

In this case, the gamedata files can be packaged and included in Fedora, as long as the files meet the requirements for binary firmware .

Patented Software

If a package contains code covered by known patents, then you should seek a written patent grant (and include that grant inside the package) before submitting it for Fedora. This is especially important for GPL/LGPL licensed packages, because of the following clause (from GPLv2):

For example, if a patent license would not permit royalty-free redistribution
of the Program by all those who receive copies directly or indirectly through you,
then the only way you could satisfy both it and this License would be to refrain
entirely from distribution of the Program.

It isn't safe to assume that the patent holder permits royalty-free redistribution, you need to get it in writing.

Emulators

Some emulators (applications which emulate another platform) are not permitted for inclusion in Fedora. These rules will help you determine if an emulator is acceptable for Fedora.

• Emulators which depend on firmware or ROM files to function may not be included in Fedora, unless the copyright holder(s) for the firmware/ROM files give clear permission for the firmware/ROM files to be distributed (either under a Fedora permissible license or under the Fedora firmware exception criteria). Note: This only covers the situation where an emulator will not run at all without firmware/ROM files. For example, emulators that compile and run, but ship with no game ROMs are not covered by this rule.

• Emulators must not ship with any ROM files (e.g. games) unless those ROM files are available under a Fedora permissible license and have been built from source code in the Fedora buildsystem.

• Emulators must not point to any third-party sites which provide firmware or ROM files that are distributed without the clear and explicit permission of their copyright holders.

• All other Fedora licensing and packaging rules apply to emulators.

QEMU ROMs

Whenever possible, ROMS implementing BIOS or Firmware for QEMU system targets must be built from source on the intended architecture. However, in many situations, this is not practical or possible. As a special exception for those situations where it is not practical or possible, prebuilt binary ROMS implementing BIOS or Firmware for QEMU system targets may be included in Fedora Packages, as long as the corresponding source code is also included in the Source RPM package.

Binary Firmware

Some applications, drivers, and hardware require binary-only firmware to boot Fedora or function properly. Fedora permits inclusion of these files as long as they meet the following requirements:

Requirements:

• The files are non-executable within the Fedora OS context (note: this means that the files cannot run on their own, not that they are just chmod -x)
• The files are not libraries, within the Fedora OS context.
• The files are standalone, not embedded in executable or library code (within the Fedora OS context).
• The files must be necessary for the functionality of open source code being included in Fedora OR to enable Fedora to boot on a specific device, where no other reliable and supported mechanisms exist.
• The files are available under an acceptable firmware license, which is included with the files in the packaging.

The Fedora Project considers a firmware license acceptable if:

• it allows some form of royalty-free use, subject to restrictions that the Fedora Project has determined are acceptable for firmware licenses (see below), and
• it does not restrict redistribution in ways that would make a software license unacceptable under Fedora licensing guidelines, except by:
  1. requiring that the firmware be redistributed only as incorporated in the redistributor's product (or as a maintenance update for existing end users of the redistributor's product), possibly limited further to those products of the redistributor that support or contain the hardware associated with the licensed firmware; and
  2. requiring the redistributor to pass on or impose conditions on users that are no more restrictive than those authorized by this Fedora firmware licensing policy.

A non-exhaustive list of restrictions on use that Fedora considers acceptable for firmware licenses are:

1. any restrictions that are found in software licenses that are acceptable for Fedora;
2. prohibitions on modification;
3. prohibitions on reverse engineering, disassembly or decompilation;
4. restricting use to use in conjunction with the hardware associated with the firmware license.

If you are unsure whether or not your files meet these requirements, ask on fedora-devel-list, and we will examine them for you.

The License tag for any firmware that disallows modification must be set to: "Redistributable, no modification permitted"

Firmware packages must be named <foo>-firmware, where <foo> is the driver or other hardware component that the firmware is for. In cases of firmware used to boot Fedora on a device, <foo> must be the type of device(s) that the firmware is intended for (e.g. raspberrypi).