| |
@@ -7,23 +7,46 @@
|
| |
|
| |
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 https://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses[Free Software Foundation], https://opensource.org/licenses/[OSI] and consultation with Red Hat Legal.
|
| |
+ All software in Fedora must be under licenses in the {fedora-licensing-list}.
|
| |
+ This list is based on the licenses approved by the
|
| |
+ https://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses[Free Software Foundation],
|
| |
+ https://opensource.org/licenses/[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)).
|
| |
+ 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 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 `+%license+`. 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.
|
| |
-
|
| |
- 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.
|
| |
-
|
| |
- However, in situations where upstream is unresponsive, unable, or unwilling to provide proper full license text as part of the source code, and the indicated license requires that the full license text be included, Fedora Packagers must either:
|
| |
-
|
| |
- * 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.
|
| |
+ 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 `+%license+`.
|
| |
+ 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.
|
| |
+
|
| |
+ 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.
|
| |
+
|
| |
+ However, in situations where upstream is unresponsive, unable, or unwilling to provide proper full license text as part of the source code,
|
| |
+ and the indicated license requires that the full license text be included, Fedora Packagers must either:
|
| |
+
|
| |
+ * 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.
|
| |
|
| |
* Choose not to package that software for Fedora.
|
| |
|
| |
- 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.
|
| |
+ 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.
|
| |
|
| |
[#subpackage-licensing]
|
| |
=== Subpackage Licensing
|
| |
@@ -36,23 +59,40 @@
|
| |
|
| |
=== License Clarification
|
| |
|
| |
- 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 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.
|
| |
|
| |
== 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.
|
| |
+ 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.
|
| |
+ The License: field refers to the licenses of the contents of the *_binary_* rpm.
|
| |
+ When in doubt, ask.
|
| |
|
| |
- If a source package generates multiple binary packages, the License: field may differ between them if necessary. This implies that a single spec may have multiple per-subpackage License: tags. Each of those License: tags must comply with all applicable guidelines.
|
| |
+ If a source package generates multiple binary packages, the License: field may differ between them if necessary.
|
| |
+ This implies that a single spec may have multiple per-subpackage License: tags.
|
| |
+ Each of those License: tags must comply with all applicable guidelines.
|
| |
|
| |
=== 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 legal@lists.fedoraproject.org (note that this list is moderated, only members may directly post). If the license is approved, it will be added to the appropriate table.
|
| |
+ 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 legal@lists.fedoraproject.org (note that this list is moderated, only members may directly post).
|
| |
+ If the license is approved, it will be added to the appropriate table.
|
| |
|
| |
=== "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.
|
| |
+ 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
|
| |
|
| |
@@ -60,23 +100,32 @@
|
| |
|
| |
=== 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.
|
| |
+ 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.
|
| |
+ 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.
|
| |
+ 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.
|
| |
+ 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:
|
| |
+ 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+
|
| |
@@ -84,16 +133,21 @@
|
| |
|
| |
=== 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).
|
| |
+ 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:
|
| |
+ 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.
|
| |
+ 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:
|
| |
@@ -126,20 +180,29 @@
|
| |
|
| |
=== 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.
|
| |
+ 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:
|
| |
+ 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.
|
| |
+ 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:
|
| |
+ 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.
|
| |
|
| |
@@ -149,4 +212,8 @@
|
| |
|
| |
== Public Domain
|
| |
|
| |
- Works which are clearly marked as being in the Public Domain, and for which no evidence is known to contradict this statement, are treated in Fedora as being in the Public Domain, on the grounds that the intentions of the original creator are reflected by such a use, even if due to regional issues, it may not have been possible for the original creator to fully abandon all of their their copyrights on the work and place it fully into the Public Domain. If you believe that a work in Fedora which is marked as being in the Public Domain is actually available under a copyright license, please inform us of this fact with details, and we will immediately investigate the claim.
|
| |
+ Works which are clearly marked as being in the Public Domain, and for which no evidence is known to contradict this statement,
|
| |
+ are treated in Fedora as being in the Public Domain, on the grounds that the intentions of the original creator are reflected by such a use, even if due to regional issues,
|
| |
+ it may not have been possible for the original creator to fully abandon all of their their copyrights on the work and place it fully into the Public Domain.
|
| |
+ If you believe that a work in Fedora which is marked as being in the Public Domain is actually available under a copyright license,
|
| |
+ please inform us of this fact with details, and we will immediately investigate the claim.
|
| |
mattdm
commented 2 years ago
See https://asciidoctor.org/docs/asciidoc-recommended-practices/#one-sentence-per-line.
This will make it easier to make PRs against this document in the future and has other advantages.
The first two patches are purely asciidoc source formatting changes and do not change the content or the expected rendered appearance.
The third patch fixes a minor typo discovered when making the other changes.