English Finnish
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).
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.
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
In cases where the licensing is unclear, it may be necessary to contact the copyright holders to confirm the licensing of code or content. In those situations, it is _always_ preferred to ask upstream to resolve the licensing confusion by documenting the licensing and releasing an updated tarball. However, this is not always possible to achieve. In such cases, it is acceptable to receive confirmation of licensing via email. A copy of the email, containing full headers, must be included as a source file (marked as %license) in the package. This file is considered part of the license text.
In cases where the upstream has chosen a license that requires that a copy of the license text be distributed along with the binaries and/or source code, but does not provide a copy of the license text (in the source tree, or in some rare cases, anywhere), the packager should do their best to point out this confusion to upstream. This sometimes occurs when an upstream project's only reference to a license is in a README (where they simply say "licensed under the FOO license"), on their website, or when they simply do not check a copy of the license into their Source tree. Common licenses that require including their texts with all derivative works include ASL 2.0, EPL, BSD and MIT. Packagers should point out to upstream that by not including a proper full license text, they are making it difficult or impossible for anyone to comply with their desired license terms.
Include a copy of what they believe the license text is intended to be, as part of the Fedora package in `+%license+`, in order to remain in compliance. It is worth noting that this may place some additional risk on the packager, however, Fedora believes that this risk is minimized by the fact that if the upstream disagrees with what we have distributed as the full license text, they can easily remedy this by making full license text available in the source code. Packagers who choose to do this should ensure that they have exhausted all attempts to work with upstream to include the license text as part of the source code, or at least, to confirm the full license text explicitly with the upstream, as this minimizes the risk on the packager. Packagers should also take copies of license texts from reliable and canonical sources (such as the Fedora Software Licenses page, the FSF licenses page, or the OSI license list), whenever possible.
Including a file as `+%license+` which contains the licensing breakdown for the packaged files, then using:
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:
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.
It is important to reiterate that in situations where the indicated license does not imply a requirement that the license be distributed along with the source/binaries, Fedora packagers are NOT required to manually include the full license text when it is absent from the source code, but are still encouraged to point out this issue to upstream and encourage them to remedy it.
License Clarification
License: field
License: MPLv1.1 or GPLv2+
License: Python and (BSD with advertising and QPL)
License: Python and LGPLv2+ and BSD
License: Python and LGPLv2+ and BSD and (MPLv1.1 or GPLv2+)
License Text
Licensing Guidelines
Mixed Source Licensing Scenario
Multiple Licensing Scenarios