Greetings,
As part of some ongoing efforts to improve information relating to Fedora licensing and licensing policy, we want to provide better documentation around the various license approval categories for Fedora, as currently set forth here: https://fedoraproject.org/wiki/Licensing:Main but which probably will live in the future on docs.fedoraproject.org.
Here's a rough draft which I wanted to publish here for review. Feedback/criticisms/suggestions welcome.
Side note: This preserves Tom Callaway's historical usage of "good" to mean "Fedora-approved", but I have mixed feelings about this terminology.
1. Licenses for Code
“Code” means software code, any other functional material whose principal purpose is to control or facilitate the building of packages, such as an RPM spec file, and other kinds of material that the Fedora Council has classified as "code" rather than "content", but does not include font files.
[Comment: This annoyingly and confusingly does not line up with definitions in the FPCA, but Fedora should get rid of the FPCA anyway]
A license for code is “good” if the Fedora Project determines that the license is a free/libre//open source license.
[Not sure if it's helpful to add the following:]
In making this determination, Fedora historically relied primarily on the Free Software Definition as maintained and interpreted by the Free Software Foundation, but out of necessity Fedora passed judgment on many licenses never addressed by the FSF and, in the process, built up an informal body of interpretation and policymaking (admittedly, mostly undocumented) that went far beyond what the FSF had done. Fedora has also sometimes considered the decisions of other community Linux distributions and other important efforts to define and apply FLOSS norms, most notably the OSI’s Open Source Definition. In a small number of cases, Fedora has disagreed with decisions of the FSF and OSI regarding whether particular licenses are FLOSS.
2. Licenses for Documentation
Any license that is good for code is also good for documentation.
In addition, Fedora may designate a license as good for documentation if (a) the license meets the standards for good licenses for code, (b) the license is designed primarily for technical documentation or otherwise has a history of substantial use in free software communities for documentation, and (c) the license is not commonly or normally used for code.
[Comment: this feels unsatisfactory to me, for multiple reasons, but I think it does accurately represent the historical Fedora policy.]
3. Licenses for Content
“Content” means any material that is not code, documentation, fonts or binary firmware.
Any license that is good for code is also good for content.
In addition, Fedora may designate a license as good for content if it restricts or prohibits modification but otherwise meets the standards for good licenses for code.
4. Licenses for Fonts
Any license that is good for code is also good for fonts.
In addition, Fedora may designate a license as good for fonts if it contains a nominal prohibition on resale or distribution in isolation but otherwise meets the standards for good licenses for code.
5. Licenses for Binary Firmware
Some applications, drivers, and hardware require binary-only firmware to boot Fedora or function properly. Fedora permits inclusion of these files if they meet certain requirements [currently set forth at: https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware but the non-license part of this needs to move somewhere else ].
Any license that is good for code is also good for binary firmware.
In addition, Fedora may designate a particular firmware license as good for firmware if the terms in the license that would not be acceptable in a good code license are limited to the following:
* Requirements 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
* Requirements that the redistributor to pass on or impose conditions on users that are no more restrictive than those authorized by Fedora itself with respect to firmware licenses
* Prohibitions on modification, reverse engineering, disassembly or decompilation
* Requirements that use be in conjunction with the hardware associated with the firmware license
Richard
This is really helpful, Richard!
A few thoughts inline below.
Thanks, Jilayne
On 2/7/22 9:52 PM, Richard Fontana wrote:
Greetings,
As part of some ongoing efforts to improve information relating to Fedora licensing and licensing policy, we want to provide better documentation around the various license approval categories for Fedora, as currently set forth here: https://fedoraproject.org/wiki/Licensing:Main but which probably will live in the future on docs.fedoraproject.org.
Here's a rough draft which I wanted to publish here for review. Feedback/criticisms/suggestions welcome.
Side note: This preserves Tom Callaway's historical usage of "good" to mean "Fedora-approved", but I have mixed feelings about this terminology.
- Licenses for Code
“Code” means software code, any other functional material whose principal purpose is to control or facilitate the building of packages, such as an RPM spec file, and other kinds of material that the Fedora Council has classified as "code" rather than "content", but does not include font files.
[Comment: This annoyingly and confusingly does not line up with definitions in the FPCA, but Fedora should get rid of the FPCA anyway]
sounds like a potential other thread ;)
A license for code is “good” if the Fedora Project determines that the license is a free/libre//open source license.
maybe a bit more here on the criteria for this determination?
You have a statement for each category below like, "Any license that is good for code is also good for documentation." maybe add here something similar like, "Any license that is good for code is good to be used for anything included in Fedora" (now I maybe see your point about "good" - it makes the sentence a bit odd)
[Not sure if it's helpful to add the following:]
In making this determination, Fedora historically relied primarily on the Free Software Definition as maintained and interpreted by the Free Software Foundation, but out of necessity Fedora passed judgment on many licenses never addressed by the FSF and, in the process, built up an informal body of interpretation and policymaking (admittedly, mostly undocumented) that went far beyond what the FSF had done. Fedora has also sometimes considered the decisions of other community Linux distributions and other important efforts to define and apply FLOSS norms, most notably the OSI’s Open Source Definition. In a small number of cases, Fedora has disagreed with decisions of the FSF and OSI regarding whether particular licenses are FLOSS.
I think this is interesting background, but maybe better for a section on history or background, or at the bottom of the page, so it doesn't distract from the key info here?
- Licenses for Documentation
Any license that is good for code is also good for documentation.
In addition, Fedora may designate a license as good for documentation if (a) the license meets the standards for good licenses for code, (b) the license is designed primarily for technical documentation or otherwise has a history of substantial use in free software communities for documentation, and (c) the license is not commonly or normally used for code.
[Comment: this feels unsatisfactory to me, for multiple reasons, but I think it does accurately represent the historical Fedora policy.]
If a good license for documentation meets the same criteria as for code, then do we even need this category or differentiation? Where does it matter for a package maintainer or user of Fedora to know that a license is good-for-documentation (as opposed to simply "good")?
- Licenses for Content
“Content” means any material that is not code, documentation, fonts or binary firmware.
Any license that is good for code is also good for content.
should we add something like, "any license that is good for content is only good for content"?
In addition, Fedora may designate a license as good for content if it restricts or prohibits modification but otherwise meets the standards for good licenses for code.
- Licenses for Fonts
Any license that is good for code is also good for fonts.
same comment as for content
In addition, Fedora may designate a license as good for fonts if it contains a nominal prohibition on resale or distribution in isolation but otherwise meets the standards for good licenses for code.
- Licenses for Binary Firmware
Some applications, drivers, and hardware require binary-only firmware to boot Fedora or function properly. Fedora permits inclusion of these files if they meet certain requirements [currently set forth at: https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware but the non-license part of this needs to move somewhere else ].
Any license that is good for code is also good for binary firmware.
In addition, Fedora may designate a particular firmware license as good for firmware if the terms in the license that would not be acceptable in a good code license are limited to the following:
- Requirements 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
- Requirements that the redistributor to pass on or impose conditions
on users that are no more restrictive than those authorized by Fedora itself with respect to firmware licenses
- Prohibitions on modification, reverse engineering, disassembly or
decompilation
- Requirements that use be in conjunction with the hardware associated
with the firmware license
maybe there should be a final category:
6. bad licenses Any license that does not meet any of the above criteria. A bad license my not be used in Fedora.
Richard _______________________________________________ legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
Dne 08. 02. 22 v 5:52 Richard Fontana napsal(a):
Greetings,
As part of some ongoing efforts to improve information relating to Fedora licensing and licensing policy, we want to provide better documentation around the various license approval categories for Fedora, as currently set forth here: https://fedoraproject.org/wiki/Licensing:Main but which probably will live in the future on docs.fedoraproject.org.
Here's a rough draft which I wanted to publish here for review. Feedback/criticisms/suggestions welcome.
Side note: This preserves Tom Callaway's historical usage of "good" to mean "Fedora-approved", but I have mixed feelings about this terminology.
- Licenses for Code
“Code” means software code, any other functional material whose principal purpose is to control or facilitate the building of packages, such as an RPM spec file, and other kinds of material that the Fedora Council has classified as "code" rather than "content", but does not include font files.
[Comment: This annoyingly and confusingly does not line up with definitions in the FPCA, but Fedora should get rid of the FPCA anyway]
A license for code is “good” if the Fedora Project determines that the license is a free/libre//open source license.
[Not sure if it's helpful to add the following:]
Yes, I like the following paragraph.
Other than that IANAL and I am not sure what will be precisely relation to the Licensing:Main, I like this draft.
Vít
In making this determination, Fedora historically relied primarily on the Free Software Definition as maintained and interpreted by the Free Software Foundation, but out of necessity Fedora passed judgment on many licenses never addressed by the FSF and, in the process, built up an informal body of interpretation and policymaking (admittedly, mostly undocumented) that went far beyond what the FSF had done. Fedora has also sometimes considered the decisions of other community Linux distributions and other important efforts to define and apply FLOSS norms, most notably the OSI’s Open Source Definition. In a small number of cases, Fedora has disagreed with decisions of the FSF and OSI regarding whether particular licenses are FLOSS.
- Licenses for Documentation
Any license that is good for code is also good for documentation.
In addition, Fedora may designate a license as good for documentation if (a) the license meets the standards for good licenses for code, (b) the license is designed primarily for technical documentation or otherwise has a history of substantial use in free software communities for documentation, and (c) the license is not commonly or normally used for code.
[Comment: this feels unsatisfactory to me, for multiple reasons, but I think it does accurately represent the historical Fedora policy.]
- Licenses for Content
“Content” means any material that is not code, documentation, fonts or binary firmware.
Any license that is good for code is also good for content.
In addition, Fedora may designate a license as good for content if it restricts or prohibits modification but otherwise meets the standards for good licenses for code.
- Licenses for Fonts
Any license that is good for code is also good for fonts.
In addition, Fedora may designate a license as good for fonts if it contains a nominal prohibition on resale or distribution in isolation but otherwise meets the standards for good licenses for code.
- Licenses for Binary Firmware
Some applications, drivers, and hardware require binary-only firmware to boot Fedora or function properly. Fedora permits inclusion of these files if they meet certain requirements [currently set forth at: https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware but the non-license part of this needs to move somewhere else ].
Any license that is good for code is also good for binary firmware.
In addition, Fedora may designate a particular firmware license as good for firmware if the terms in the license that would not be acceptable in a good code license are limited to the following:
- Requirements 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
- Requirements that the redistributor to pass on or impose conditions
on users that are no more restrictive than those authorized by Fedora itself with respect to firmware licenses
- Prohibitions on modification, reverse engineering, disassembly or
decompilation
- Requirements that use be in conjunction with the hardware associated
with the firmware license
Richard _______________________________________________ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Dne 08. 02. 22 v 5:52 Richard Fontana napsal(a):
Greetings,
As part of some ongoing efforts to improve information relating to Fedora licensing and licensing policy, we want to provide better documentation around the various license approval categories for Fedora, as currently set forth here:
The document sometimes uses uncommon words. Maybe common in jargon, but hard to process for non-English native speaker (maintainer)
E.g.,
* Requirements that the redistributor to pass on or impose conditions on users
* if it contains a nominal prohibition on resale or distribution in isolation
If this is meant as guidelines for maintainers I would like to see simplified English here.
Miroslav
On Wed, Feb 9, 2022 at 5:17 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 08. 02. 22 v 5:52 Richard Fontana napsal(a):
Greetings,
As part of some ongoing efforts to improve information relating to Fedora licensing and licensing policy, we want to provide better documentation around the various license approval categories for Fedora, as currently set forth here:
The document sometimes uses uncommon words. Maybe common in jargon, but hard to process for non-English native speaker (maintainer)
E.g.,
Requirements that the redistributor to pass on or impose conditions on users
if it contains a nominal prohibition on resale or distribution in isolation
If this is meant as guidelines for maintainers I would like to see simplified English here.
Thank you! That is definitely not jargon (other than my own personal jargon maybe), so I'll attempt some rephrasing or further elaboration there and in the document generally.
Richard
I'm working on the draft documentation that will contain the explanation of Fedora license approval criteria by category. I'm rewriting the explanation of the "allowed for documentation" category in a significant enough way that I think I ought to post it here:
Fedora may designate a license as allowed for documentation if the license: (a) contains terms no more restrictive than the terms of any of the licenses that Fedora treated as "good licenses" for documentation as of 1 July 2020; (b) is designed primarily for technical documentation or otherwise has a history of substantial use in free software communities for documentation, and (c) is not commonly or normally used for code.
Explanation:
Basically, (a) is what's different: the description is no longer asserting that these licenses "generally" meet the standards for code, because I feel that isn't really a defensible statement (and the use of "generally" feels sort of squishy). I am not sure all of the existing "good" documentation licenses would meet Fedora's present-day standards for libre licensing (that is, I am not sure Fedora would really find a hypothetical use of such a license for code to be acceptable) -- but I also don't propose revisiting the past approval of those licenses, most of which were, I believe, approved by Fedora many years ago. Rather than have Fedora imply that, say, the various versions of the GFDL are truly free/libre, I would rather say that the boundaries of the category are set by what Fedora decided in the past. The July 1, 2020 date is not arbitrary; it is (I think) approximately the time at which Tom Callaway stopped acting in his longstanding Fedora Legal role.
An alternative and possibly better, but similar, approach would be to analyze all of the existing good documentation licenses and note any kinds of arguably non-libre terms in them (for example, the invariant sections terms of the GFDL), and then develop a set of criteria based on that analysis. However that would be a lot of work and I don't feel I have the time to devote to that. :-) That alternative approach would then resemble how the firmware license criteria are defined.
Of course to assess whether a new documentation is acceptable under the draft standard above you'd have to at least informally review all the existing good (or, ~now, allowed) documentation licenses, so in a sense this is just putting off work that would have to be done eventually.
Richard
On Mon, Feb 7, 2022 at 11:52 PM Richard Fontana rfontana@redhat.com wrote:
Greetings,
As part of some ongoing efforts to improve information relating to Fedora licensing and licensing policy, we want to provide better documentation around the various license approval categories for Fedora, as currently set forth here: https://fedoraproject.org/wiki/Licensing:Main but which probably will live in the future on docs.fedoraproject.org.
Here's a rough draft which I wanted to publish here for review. Feedback/criticisms/suggestions welcome.
Side note: This preserves Tom Callaway's historical usage of "good" to mean "Fedora-approved", but I have mixed feelings about this terminology.
- Licenses for Code
“Code” means software code, any other functional material whose principal purpose is to control or facilitate the building of packages, such as an RPM spec file, and other kinds of material that the Fedora Council has classified as "code" rather than "content", but does not include font files.
[Comment: This annoyingly and confusingly does not line up with definitions in the FPCA, but Fedora should get rid of the FPCA anyway]
A license for code is “good” if the Fedora Project determines that the license is a free/libre//open source license.
[Not sure if it's helpful to add the following:]
In making this determination, Fedora historically relied primarily on the Free Software Definition as maintained and interpreted by the Free Software Foundation, but out of necessity Fedora passed judgment on many licenses never addressed by the FSF and, in the process, built up an informal body of interpretation and policymaking (admittedly, mostly undocumented) that went far beyond what the FSF had done. Fedora has also sometimes considered the decisions of other community Linux distributions and other important efforts to define and apply FLOSS norms, most notably the OSI’s Open Source Definition. In a small number of cases, Fedora has disagreed with decisions of the FSF and OSI regarding whether particular licenses are FLOSS.
- Licenses for Documentation
Any license that is good for code is also good for documentation.
In addition, Fedora may designate a license as good for documentation if (a) the license meets the standards for good licenses for code, (b) the license is designed primarily for technical documentation or otherwise has a history of substantial use in free software communities for documentation, and (c) the license is not commonly or normally used for code.
[Comment: this feels unsatisfactory to me, for multiple reasons, but I think it does accurately represent the historical Fedora policy.]
- Licenses for Content
“Content” means any material that is not code, documentation, fonts or binary firmware.
Any license that is good for code is also good for content.
In addition, Fedora may designate a license as good for content if it restricts or prohibits modification but otherwise meets the standards for good licenses for code.
- Licenses for Fonts
Any license that is good for code is also good for fonts.
In addition, Fedora may designate a license as good for fonts if it contains a nominal prohibition on resale or distribution in isolation but otherwise meets the standards for good licenses for code.
- Licenses for Binary Firmware
Some applications, drivers, and hardware require binary-only firmware to boot Fedora or function properly. Fedora permits inclusion of these files if they meet certain requirements [currently set forth at: https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware but the non-license part of this needs to move somewhere else ].
Any license that is good for code is also good for binary firmware.
In addition, Fedora may designate a particular firmware license as good for firmware if the terms in the license that would not be acceptable in a good code license are limited to the following:
- Requirements 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
- Requirements that the redistributor to pass on or impose conditions
on users that are no more restrictive than those authorized by Fedora itself with respect to firmware licenses
- Prohibitions on modification, reverse engineering, disassembly or
decompilation
- Requirements that use be in conjunction with the hardware associated
with the firmware license
Richard
After some further work and deliberation, I think we should take the following approach to defining what is an allowed license for documentation:
Fedora may designate a license as allowed for documentation if it meets the criteria for allowed licenses and it is specifically designed for documentation.
In addition, Fedora classifies the following licenses as allowed for documentation:
* The Creative Commons Attribution 4.0 International Public License and the Creative Commons Attribution-ShareAlike 4.0 International Public License, and the predecessor versions of these licenses
* The Open Publication License v1.0, provided that no Section VI "license options" are elected
* The GNU Free Documentation License version 2.1 and its predecessor versions
Basically, the legacy list of "good" Fedora documentation licenses consists of (a) licenses that are pretty much FOSS-normative but happen to be designed for documentation, and (b) the specific licenses listed (CC BY, CC BY-SA, OPL, GFDL) which all contain at least a few (or, in the case of GFDL, many) provisions that I think it is hard to argue are consistent with FOSS licensing norms. I thought about trying to abstract the kinds of non-FOSS provisions in those licenses into general categories, but it's kind of pointless. We can assume that there won't be any future licenses with these kinds of provisions other than successor versions of those licenses. Attempting to abstract the various unique provisions in the GFDL is especially challenging. We also really don't want to encourage people to create new licenses for documentation that resemble these licenses. So I think it's just best to mention this small set explicitly.
Richard
On Sat, Jul 16, 2022 at 11:35 PM Richard Fontana rfontana@redhat.com wrote:
I'm working on the draft documentation that will contain the explanation of Fedora license approval criteria by category. I'm rewriting the explanation of the "allowed for documentation" category in a significant enough way that I think I ought to post it here:
Fedora may designate a license as allowed for documentation if the license: (a) contains terms no more restrictive than the terms of any of the licenses that Fedora treated as "good licenses" for documentation as of 1 July 2020; (b) is designed primarily for technical documentation or otherwise has a history of substantial use in free software communities for documentation, and (c) is not commonly or normally used for code.
Explanation:
Basically, (a) is what's different: the description is no longer asserting that these licenses "generally" meet the standards for code, because I feel that isn't really a defensible statement (and the use of "generally" feels sort of squishy). I am not sure all of the existing "good" documentation licenses would meet Fedora's present-day standards for libre licensing (that is, I am not sure Fedora would really find a hypothetical use of such a license for code to be acceptable) -- but I also don't propose revisiting the past approval of those licenses, most of which were, I believe, approved by Fedora many years ago. Rather than have Fedora imply that, say, the various versions of the GFDL are truly free/libre, I would rather say that the boundaries of the category are set by what Fedora decided in the past. The July 1, 2020 date is not arbitrary; it is (I think) approximately the time at which Tom Callaway stopped acting in his longstanding Fedora Legal role.
An alternative and possibly better, but similar, approach would be to analyze all of the existing good documentation licenses and note any kinds of arguably non-libre terms in them (for example, the invariant sections terms of the GFDL), and then develop a set of criteria based on that analysis. However that would be a lot of work and I don't feel I have the time to devote to that. :-) That alternative approach would then resemble how the firmware license criteria are defined.
Of course to assess whether a new documentation is acceptable under the draft standard above you'd have to at least informally review all the existing good (or, ~now, allowed) documentation licenses, so in a sense this is just putting off work that would have to be done eventually.
Richard
On Mon, Feb 7, 2022 at 11:52 PM Richard Fontana rfontana@redhat.com wrote:
Greetings,
As part of some ongoing efforts to improve information relating to Fedora licensing and licensing policy, we want to provide better documentation around the various license approval categories for Fedora, as currently set forth here: https://fedoraproject.org/wiki/Licensing:Main but which probably will live in the future on docs.fedoraproject.org.
Here's a rough draft which I wanted to publish here for review. Feedback/criticisms/suggestions welcome.
Side note: This preserves Tom Callaway's historical usage of "good" to mean "Fedora-approved", but I have mixed feelings about this terminology.
- Licenses for Code
“Code” means software code, any other functional material whose principal purpose is to control or facilitate the building of packages, such as an RPM spec file, and other kinds of material that the Fedora Council has classified as "code" rather than "content", but does not include font files.
[Comment: This annoyingly and confusingly does not line up with definitions in the FPCA, but Fedora should get rid of the FPCA anyway]
A license for code is “good” if the Fedora Project determines that the license is a free/libre//open source license.
[Not sure if it's helpful to add the following:]
In making this determination, Fedora historically relied primarily on the Free Software Definition as maintained and interpreted by the Free Software Foundation, but out of necessity Fedora passed judgment on many licenses never addressed by the FSF and, in the process, built up an informal body of interpretation and policymaking (admittedly, mostly undocumented) that went far beyond what the FSF had done. Fedora has also sometimes considered the decisions of other community Linux distributions and other important efforts to define and apply FLOSS norms, most notably the OSI’s Open Source Definition. In a small number of cases, Fedora has disagreed with decisions of the FSF and OSI regarding whether particular licenses are FLOSS.
- Licenses for Documentation
Any license that is good for code is also good for documentation.
In addition, Fedora may designate a license as good for documentation if (a) the license meets the standards for good licenses for code, (b) the license is designed primarily for technical documentation or otherwise has a history of substantial use in free software communities for documentation, and (c) the license is not commonly or normally used for code.
[Comment: this feels unsatisfactory to me, for multiple reasons, but I think it does accurately represent the historical Fedora policy.]
- Licenses for Content
“Content” means any material that is not code, documentation, fonts or binary firmware.
Any license that is good for code is also good for content.
In addition, Fedora may designate a license as good for content if it restricts or prohibits modification but otherwise meets the standards for good licenses for code.
- Licenses for Fonts
Any license that is good for code is also good for fonts.
In addition, Fedora may designate a license as good for fonts if it contains a nominal prohibition on resale or distribution in isolation but otherwise meets the standards for good licenses for code.
- Licenses for Binary Firmware
Some applications, drivers, and hardware require binary-only firmware to boot Fedora or function properly. Fedora permits inclusion of these files if they meet certain requirements [currently set forth at: https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware but the non-license part of this needs to move somewhere else ].
Any license that is good for code is also good for binary firmware.
In addition, Fedora may designate a particular firmware license as good for firmware if the terms in the license that would not be acceptable in a good code license are limited to the following:
- Requirements 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
- Requirements that the redistributor to pass on or impose conditions
on users that are no more restrictive than those authorized by Fedora itself with respect to firmware licenses
- Prohibitions on modification, reverse engineering, disassembly or
decompilation
- Requirements that use be in conjunction with the hardware associated
with the firmware license
Richard
-
Jilayne Lovejoy -
Miroslav Suchý -
Richard Fontana -
Vít Ondruch