[Fedora-legal-list] Re: License compliance in fedora-review
On Wed, Jan 18, 2023 at 3:12 AM T.C. Hollingsworth wrote: > > On Tue, Jan 3, 2023 at 11:02 AM Richard Fontana wrote: > > Any Fedora community member who has a concern about a license > > compatibility issue involving a specific Fedora package or proposed > > Fedora package is encouraged to raise it (probably most appropriately > > in a Bugzilla bug) and it will be looked at in a context-specific way. > > This context-specific analysis will consider not only architectural > > issues (of the sort referred to by Miroslav) but also the licensing, > > development and political history of the code at issue and general > > relevant FOSS community practices. If it will prove useful we will try > > to document some generalized conclusions in the Fedora license > > documentation. > > Speaking of "political history", there is a lot of talk about the > unintentional incompatibility of (Apache-2.0 AND GPL-2.0) but nothing > about the allegedly intentional incompatibility of (CDDL-1.0 AND > GPL-*). > > Would you really want to reconsider previously thoroughly litigated > matters such as cdrtools or OpenZFS each individually? These are 2 > real-world cases that were probably considered on their own merits but > nevertheless ultimately banned by the documented incompatibility in > the license wiki. While I don't think anyone is seriously proposing > going back to the first one in the year 2022 AD, I can't help but > wonder if the author of the former might have been one motivation for > capturing this information in the first place LOL. And OpenZFS might > reasonably be proposed for inclusion in Fedora now that it is relaxing > its restrictions around third party modules such as Nvidia's driver > and at least one prominent distribution ships it. These are the two cases I was thinking of (does anyone know any others?). Not specific to Fedora, but my impression is that some fans of or contributors to (Open)ZFS will stop at nothing to promote its wider adoption so it wouldn't surprise me to see that one "relitigated". Despite the general doubt I am casting on license compatibility doctrine I actually think the copyleft/copyleft cases have a clearer basis. Anyway, I am not concerned about past decided issues being brought up again if the volume is sufficiently small. On the license approval side I think we say in the documentation that anyone can file an issue arguing that a license approval decision was wrong, so it would be consistent with that policy. > I don't think we need a big old "will it blend?" list, it's not > necessary to consider and document the GPL compatibility of each and > every license on the Fedora allowed list. But I do think there is > merit in a Not Allowed SPDX "AND" Expressions List that is scoped > similarly to the Not Allowed Fedora Licenses List, that is only to > combinations which exist in actual software that has been proposed for > or previously included in Fedora. If you feel that (Apache-2.0 AND > GPL-2.0) doesn't belong on it due to the different history of that > incompatibility that's fantastic, but I would love to hear your > counterexample for how anything with (CDDL-1.0 AND GPL-2.0) could ever > possibly be allowed. :-D Both you and Benson have mentioned SPDX expressions in the context of this topic but I don't think the replacement of Callaway license names with SPDX identifiers changes anything here. I guess the thought may be that the adoption of SPDX expressions would make it easier to check for a license incompatibility programmatically because SPDX expressions are more easily parseable than Callaway license tags. I actually think that increases my concern about Fedora maintaining the "does it blend" guidance. The problem again is the context-dependent nature of the issue. SPDX expressions are not designed to capture the kinds of different contexts we're talking about here. "CDDL-1.0 AND GPL-2.0-only" could refer to a source file, a Fedora package, an executable file, a whole distribution ... any number of things. I suppose you might be suggesting that the CDDL/GPL case is different from the Apache/GPL case because most cases you're likely to encounter are more likely to be problematic. But that seems equivalent to saying that the most likely situation where CDDL/GPL comes up is with OpenZFS. Richard ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On Tue, Jan 3, 2023 at 11:02 AM Richard Fontana wrote: > We did this because in essentially no real-world case > was the information ever used to take any action with respect to an > actual or proposed Fedora package. > [snip] > Any Fedora community member who has a concern about a license > compatibility issue involving a specific Fedora package or proposed > Fedora package is encouraged to raise it (probably most appropriately > in a Bugzilla bug) and it will be looked at in a context-specific way. > This context-specific analysis will consider not only architectural > issues (of the sort referred to by Miroslav) but also the licensing, > development and political history of the code at issue and general > relevant FOSS community practices. If it will prove useful we will try > to document some generalized conclusions in the Fedora license > documentation. Speaking of "political history", there is a lot of talk about the unintentional incompatibility of (Apache-2.0 AND GPL-2.0) but nothing about the allegedly intentional incompatibility of (CDDL-1.0 AND GPL-*). Would you really want to reconsider previously thoroughly litigated matters such as cdrtools or OpenZFS each individually? These are 2 real-world cases that were probably considered on their own merits but nevertheless ultimately banned by the documented incompatibility in the license wiki. While I don't think anyone is seriously proposing going back to the first one in the year 2022 AD, I can't help but wonder if the author of the former might have been one motivation for capturing this information in the first place LOL. And OpenZFS might reasonably be proposed for inclusion in Fedora now that it is relaxing its restrictions around third party modules such as Nvidia's driver and at least one prominent distribution ships it. I don't think we need a big old "will it blend?" list, it's not necessary to consider and document the GPL compatibility of each and every license on the Fedora allowed list. But I do think there is merit in a Not Allowed SPDX "AND" Expressions List that is scoped similarly to the Not Allowed Fedora Licenses List, that is only to combinations which exist in actual software that has been proposed for or previously included in Fedora. If you feel that (Apache-2.0 AND GPL-2.0) doesn't belong on it due to the different history of that incompatibility that's fantastic, but I would love to hear your counterexample for how anything with (CDDL-1.0 AND GPL-2.0) could ever possibly be allowed. :-D ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On Tue, Jan 17, 2023 at 2:08 AM Benson Muite wrote: > > Some developers are aware of this, especially for packages made by > people backed by large corporations. However, for many small projects, > this is more difficult. When good practice has been followed and > license information of included software is available, producing a > warning of possible license incompatibility and asking reviewers to > check it is helpful. The aim should be a best efforts check when > license incompatibilities are known. I could go into so much more detail about this but the fundamental issue is that they are not *known*. Even if we suppose that there is some sort of undisputed truth here, as Jilayne and Miroslav and David have said in different ways, the issue has to be context-dependent if it is going to make sense at all. What we've found over many years is that there are so many contextual reasons why a supposed license incompatibility can't actually be present that it would be wrong to start out with a context-free assumption that a license incompatibility exists at all. Fedora had a confusing but historically-understandable position on this in the past, because it tried to give meaning to and elaborate on this doctrine by classifying approved licenses as GPLv2/GPLv3 (in)compatible, but it also actually found that typically the doctrine wasn't applicable when someone brought it up. This can be seen in the fact that so few packages were kept out of Fedora for license incompatibility-related reasons (offhand I can only think of two over a ~15 year period). So if say 90% of the time an identified GPLv2/Apache-2.0 juxtaposition in a package turns out not to be a demonstrable problem for one or multiple reasons, how should Fedora address the 10% where there is at least some basis for saying there is a problem? I truly believe based on past experience working with Fedora that it *at least* that lopsided. Fedora's treatment of this issue should reflect the marginality of the issue, and that's why I say a good solution is to encourage Fedora contributors to raise license incompatibility issues they think might exist with a specific package in a Fedora Bugzilla bug report and they will be investigated in a context-specific way in due course. > For commonly used > licenses, license compatibilities have likely been determined and > suggestions can be made by software without an offer of support for > legal representation in the case of a law suit should be made. To be clear, this is not at all my concern about having Fedora get overly proscriptive on this topic. Rather, I do not want to slow down Fedora for no good reason. I also want us to continue to actively shape how these licenses are interpreted ourselves (sometimes collaborating with our peer community Linux distributions) rather than rely uncritically on something someone one or more steps removed from Fedora and other Linux distributions may have said about the topic. Richard ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On Mon, Jan 16, 2023 at 02:09:12PM -0500, Neal Gompa wrote: > On Mon, Jan 16, 2023 at 2:04 PM Richard Fontana wrote: > > > > On Mon, Jan 16, 2023 at 2:47 AM Neal Gompa wrote: > > > > > It's fine that SPDX doesn't offer this guidance, but Fedora as a > > > distributor *needs* it. Fedora provided very valuable guidance with > > > its "will-it-blend" chart and offering explicit interpretation. It was > > > useful for both packagers and upstreams to figure out what they can > > > and cannot do. Eliminating that guidance is creating problems now > > > because with the transition to SPDX, you're effectively requiring > > > everyone to re-evaluate all packages for their licensing and document > > > it without any real ability to figure out if it makes any sense > > > anymore. > > > > In my opinion, the default assumption (and I think we should say this > > in documentation) should be that if the licenses are all > > Fedora-allowed, a particular combination of licenses embodied in a > > particular package is okay. If there are specific concerns about some > > combination of Fedora-allowed licenses that package maintainers or > > others want to raise, they can do so and this will be investigated. > > Over the past nearly 15 years, most of them under the previous > > documentation/guidance/process regime, my impression has been that > > such concerns were raised only in very rare cases, typically involving > > a well known upstream issue. > > > > I suspect part of the reason is because Tom Callaway proactively > documented compatibility as part of incorporating licenses. That > eliminated a large portion of the need to ask. Now that the > information is gone, people are asking. :) The big thing that Tom's chart did was assume that license compatibility between two licenses is simply a true or false issue. What Jilayne was saying is that this is not the case and even if a project like Fedora were to provide a similar chart or an opinion on license compatibility, that's all it is--an opinion. Many in Fedora agree with those interpretations, but if an actual legal issue is raised then that information is still just part of the process of figuring out if something wrong has been done. > > The migration to SPDX has been under way now for ~five months and > > Benson's issue is the first time I'm aware of that anyone has brought > > up a license compatibility issue in a Fedora package during that time > > period, FWIW. > > > > I think you've raised an interesting philosophical question, which is > > whether FOSS licensing is supposed to "make sense" beyond the mere > > juxtaposition of the various licenses that apply to some set of > > binaries or source files. I have some preliminary thoughts on this but > > will have to think about it some more. :) > > > > I'd argue that it's supposed to make sense, or otherwise people can't > reasonably use it. Part of the value of a distribution is sorting this > mess out for people. :) That's really the point of the fedora-license-data effort. And a lot of that is simplifying things as much as possible and getting package maintainers and developers out of the business of providing legal interpretations. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On 1/16/23 22:09, Neal Gompa wrote: > On Mon, Jan 16, 2023 at 2:04 PM Richard Fontana wrote: >> >> On Mon, Jan 16, 2023 at 2:47 AM Neal Gompa wrote: >> >>> It's fine that SPDX doesn't offer this guidance, but Fedora as a >>> distributor *needs* it. Fedora provided very valuable guidance with >>> its "will-it-blend" chart and offering explicit interpretation. It was >>> useful for both packagers and upstreams to figure out what they can >>> and cannot do. Eliminating that guidance is creating problems now >>> because with the transition to SPDX, you're effectively requiring >>> everyone to re-evaluate all packages for their licensing and document >>> it without any real ability to figure out if it makes any sense >>> anymore. >> >> In my opinion, the default assumption (and I think we should say this >> in documentation) should be that if the licenses are all >> Fedora-allowed, a particular combination of licenses embodied in a >> particular package is okay. If there are specific concerns about some >> combination of Fedora-allowed licenses that package maintainers or >> others want to raise, they can do so and this will be investigated. >> Over the past nearly 15 years, most of them under the previous >> documentation/guidance/process regime, my impression has been that >> such concerns were raised only in very rare cases, typically involving >> a well known upstream issue. >> > > I suspect part of the reason is because Tom Callaway proactively > documented compatibility as part of incorporating licenses. That > eliminated a large portion of the need to ask. Now that the > information is gone, people are asking. :) > >> The migration to SPDX has been under way now for ~five months and >> Benson's issue is the first time I'm aware of that anyone has brought >> up a license compatibility issue in a Fedora package during that time >> period, FWIW. Some developers are aware of this, especially for packages made by people backed by large corporations. However, for many small projects, this is more difficult. When good practice has been followed and license information of included software is available, producing a warning of possible license incompatibility and asking reviewers to check it is helpful. The aim should be a best efforts check when license incompatibilities are known. >> >> I think you've raised an interesting philosophical question, which is >> whether FOSS licensing is supposed to "make sense" beyond the mere >> juxtaposition of the various licenses that apply to some set of >> binaries or source files. I have some preliminary thoughts on this but >> will have to think about it some more. :) >> > > I'd argue that it's supposed to make sense, or otherwise people can't > reasonably use it. Part of the value of a distribution is sorting this > mess out for people. :) > > Which licenses with SPDX identifiers can be combined is certainly an open research area. It does not make sense to combine all open licenses. This should be clearly stated in the packaging guidelines so that reviewers and packagers know to check this. For commonly used licenses, license compatibilities have likely been determined and suggestions can be made by software without an offer of support for legal representation in the case of a law suit should be made. A clause similar to MIT license: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. on the output of the compatibility check could be added. If one is using software commercially and wants to ensure they are legally compliant, enterprise support is a reasonable way to get legal advice. ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On Mon, Jan 16, 2023 at 2:04 PM Richard Fontana wrote: > > On Mon, Jan 16, 2023 at 2:47 AM Neal Gompa wrote: > > > It's fine that SPDX doesn't offer this guidance, but Fedora as a > > distributor *needs* it. Fedora provided very valuable guidance with > > its "will-it-blend" chart and offering explicit interpretation. It was > > useful for both packagers and upstreams to figure out what they can > > and cannot do. Eliminating that guidance is creating problems now > > because with the transition to SPDX, you're effectively requiring > > everyone to re-evaluate all packages for their licensing and document > > it without any real ability to figure out if it makes any sense > > anymore. > > In my opinion, the default assumption (and I think we should say this > in documentation) should be that if the licenses are all > Fedora-allowed, a particular combination of licenses embodied in a > particular package is okay. If there are specific concerns about some > combination of Fedora-allowed licenses that package maintainers or > others want to raise, they can do so and this will be investigated. > Over the past nearly 15 years, most of them under the previous > documentation/guidance/process regime, my impression has been that > such concerns were raised only in very rare cases, typically involving > a well known upstream issue. > I suspect part of the reason is because Tom Callaway proactively documented compatibility as part of incorporating licenses. That eliminated a large portion of the need to ask. Now that the information is gone, people are asking. :) > The migration to SPDX has been under way now for ~five months and > Benson's issue is the first time I'm aware of that anyone has brought > up a license compatibility issue in a Fedora package during that time > period, FWIW. > > I think you've raised an interesting philosophical question, which is > whether FOSS licensing is supposed to "make sense" beyond the mere > juxtaposition of the various licenses that apply to some set of > binaries or source files. I have some preliminary thoughts on this but > will have to think about it some more. :) > I'd argue that it's supposed to make sense, or otherwise people can't reasonably use it. Part of the value of a distribution is sorting this mess out for people. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On Mon, Jan 16, 2023 at 2:47 AM Neal Gompa wrote: > It's fine that SPDX doesn't offer this guidance, but Fedora as a > distributor *needs* it. Fedora provided very valuable guidance with > its "will-it-blend" chart and offering explicit interpretation. It was > useful for both packagers and upstreams to figure out what they can > and cannot do. Eliminating that guidance is creating problems now > because with the transition to SPDX, you're effectively requiring > everyone to re-evaluate all packages for their licensing and document > it without any real ability to figure out if it makes any sense > anymore. In my opinion, the default assumption (and I think we should say this in documentation) should be that if the licenses are all Fedora-allowed, a particular combination of licenses embodied in a particular package is okay. If there are specific concerns about some combination of Fedora-allowed licenses that package maintainers or others want to raise, they can do so and this will be investigated. Over the past nearly 15 years, most of them under the previous documentation/guidance/process regime, my impression has been that such concerns were raised only in very rare cases, typically involving a well known upstream issue. The migration to SPDX has been under way now for ~five months and Benson's issue is the first time I'm aware of that anyone has brought up a license compatibility issue in a Fedora package during that time period, FWIW. I think you've raised an interesting philosophical question, which is whether FOSS licensing is supposed to "make sense" beyond the mere juxtaposition of the various licenses that apply to some set of binaries or source files. I have some preliminary thoughts on this but will have to think about it some more. :) Richard ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On Mon, Jan 16, 2023 at 1:19 AM Jilayne Lovejoy wrote: > > > Hi Benson, Richard, > > To add a couple thought to this topic, which I see raised in various > venues every so often: > > > On 1/4/23 12:11 AM, Benson Muite wrote: > > Hi Richard, > >> Fedora used to maintain in its old license list an indication of > >> whether a "good" license was GPLv2 and (separately) GPLv3 compatible. > >> We thought this over carefully but decided not to continue this > >> practice in the migration of this data to the fedora-license-data > >> repository. This despite the fact that a lot of careful thought went > >> into those determinations (such that I think the preserved record of > >> those determinations has some significant historical value for GPL > >> interpretation). We did this because in essentially no real-world case > >> was the information ever used to take any action with respect to an > >> actual or proposed Fedora package. > > This data is helpful. Adding this to SPDX would be good, but given the > > number of licenses, it would be most efficient if other interested > > parties also contributed to this. > I can tell you that this kind of thing highly unlikely to be added to > the SPDX project for a couple reasons: > 1) license "compatibility" relies on a legal interpretation at a couple > levels, which is not the perview of the SPDX Project (nor should be) and > can vary as is the nature of legal interpretations in un-tested areas > > 2) determining license "compatibility" relies on context (as mentioned > already a couple times in this thread, I think) - that context (i.e., > how is the software under the various licenses in question being used?) > can vary and it's very hard, if not impossible to capture this fully - > too many variables. > > Most attempts to track license compatibility seems to ignore the > question of context or make broad assumptions about how the software is > used or combined. This results in "answers" that may not be correct > given your specific situation. I actually disagree with both you and Richard on this. :) It's fine that SPDX doesn't offer this guidance, but Fedora as a distributor *needs* it. Fedora provided very valuable guidance with its "will-it-blend" chart and offering explicit interpretation. It was useful for both packagers and upstreams to figure out what they can and cannot do. Eliminating that guidance is creating problems now because with the transition to SPDX, you're effectively requiring everyone to re-evaluate all packages for their licensing and document it without any real ability to figure out if it makes any sense anymore. > >> As for compatibility of arbitrary licenses more generally: If I'm > >> counting correctly, Fedora now has 286 licenses in the simple > >> "allowed" category (corresponding to the old "good [for software]" > >> category) and this is expected to increase substantially with the > >> ongoing migration to use of SPDX identifiers. So it is basically > >> impractical if not impossible to maintain any useful, well-reasoned > >> set of context-free compatibility relationships for each Fedora > >> allowed license with respect to any other arbitrary Fedora allowed > >> license. > agreed. > > For software licenses, probably a simple categorization is reasonable? > > Permissive, weakly protective, strongly protective, network protective > categorization of types of licenses is a bit harder than you'd think. > While it may be somewhat useful in terms of providing generalizations > about compliance, it doesn't really answer the question of license > compatibility. > > Suggestions can then be issued to packagers to check license compliance > > that typically either the most protective license applies, or contents > > with separate licenses are in separate packages. > > > > The Apache 2 and GPL conflict seems well known. There are 1012 packages > > in the repositories with both GPL and Apache licenses: > > $ dnf repoquery --all --info > allpackageinfo.txt > > $ cat allpackageinfo.txt | grep -n "ASL.* GPL" >> GPLonly_AND_APACHE.txt > > $ cat allpackageinfo.txt | grep -n "Apache.* GPL" >> GPLonly_AND_APACHE.txt > > $ cat allpackageinfo.txt | grep -n " GPL.*ASL" >> GPLonly_AND_APACHE.txt > > $ cat allpackageinfo.txt | grep -n " GPL.*Apache" >> GPLonly_AND_APACHE.txt > > $ wc -l GPLonly_AND_APACHE.txt > > > > Need to check that either GPL license is the main one that applies with > > Apache licensed software included in GPL software but no GPL software in > > Apache licensed software or separate Apache and GPL packages are produced: > > https://www.apache.org/licenses/GPL-compatibility.html > to play devil's advocate a bit here: > This conflict is well known because the ASF or the FSF says this, but > does that make it legally true? Who might challenge this in court and > what would that case look like in terms of who would bring such a case > and under what claims? > > Some incompatibilities are more obvious given the specific conditions of > the
[Fedora-legal-list] Re: License compliance in fedora-review
Hi Benson, Richard, To add a couple thought to this topic, which I see raised in various venues every so often: On 1/4/23 12:11 AM, Benson Muite wrote: Hi Richard, Fedora used to maintain in its old license list an indication of whether a "good" license was GPLv2 and (separately) GPLv3 compatible. We thought this over carefully but decided not to continue this practice in the migration of this data to the fedora-license-data repository. This despite the fact that a lot of careful thought went into those determinations (such that I think the preserved record of those determinations has some significant historical value for GPL interpretation). We did this because in essentially no real-world case was the information ever used to take any action with respect to an actual or proposed Fedora package. This data is helpful. Adding this to SPDX would be good, but given the number of licenses, it would be most efficient if other interested parties also contributed to this. I can tell you that this kind of thing highly unlikely to be added to the SPDX project for a couple reasons: 1) license "compatibility" relies on a legal interpretation at a couple levels, which is not the perview of the SPDX Project (nor should be) and can vary as is the nature of legal interpretations in un-tested areas 2) determining license "compatibility" relies on context (as mentioned already a couple times in this thread, I think) - that context (i.e., how is the software under the various licenses in question being used?) can vary and it's very hard, if not impossible to capture this fully - too many variables. Most attempts to track license compatibility seems to ignore the question of context or make broad assumptions about how the software is used or combined. This results in "answers" that may not be correct given your specific situation. As for compatibility of arbitrary licenses more generally: If I'm counting correctly, Fedora now has 286 licenses in the simple "allowed" category (corresponding to the old "good [for software]" category) and this is expected to increase substantially with the ongoing migration to use of SPDX identifiers. So it is basically impractical if not impossible to maintain any useful, well-reasoned set of context-free compatibility relationships for each Fedora allowed license with respect to any other arbitrary Fedora allowed license. agreed. For software licenses, probably a simple categorization is reasonable? Permissive, weakly protective, strongly protective, network protective categorization of types of licenses is a bit harder than you'd think. While it may be somewhat useful in terms of providing generalizations about compliance, it doesn't really answer the question of license compatibility. Suggestions can then be issued to packagers to check license compliance that typically either the most protective license applies, or contents with separate licenses are in separate packages. The Apache 2 and GPL conflict seems well known. There are 1012 packages in the repositories with both GPL and Apache licenses: $ dnf repoquery --all --info > allpackageinfo.txt $ cat allpackageinfo.txt | grep -n "ASL.* GPL" >> GPLonly_AND_APACHE.txt $ cat allpackageinfo.txt | grep -n "Apache.* GPL" >> GPLonly_AND_APACHE.txt $ cat allpackageinfo.txt | grep -n " GPL.*ASL" >> GPLonly_AND_APACHE.txt $ cat allpackageinfo.txt | grep -n " GPL.*Apache" >> GPLonly_AND_APACHE.txt $ wc -l GPLonly_AND_APACHE.txt Need to check that either GPL license is the main one that applies with Apache licensed software included in GPL software but no GPL software in Apache licensed software or separate Apache and GPL packages are produced: https://www.apache.org/licenses/GPL-compatibility.html to play devil's advocate a bit here: This conflict is well known because the ASF or the FSF says this, but does that make it legally true? Who might challenge this in court and what would that case look like in terms of who would bring such a case and under what claims? Some incompatibilities are more obvious given the specific conditions of the licenses that directly conflict in that you cannot comply with both at the same time (e.g., combining GPL or any license that requires the release of source code with code under a license that restricts access to source code) - but those are less likely to be of the kind at issue here given Fedora's broader licensing policy. Other incompatibilities are more based on community ideals or statements from license stewards, which while influential, may not have been tested in court. In that case, how does one decide? (btw, I don't have good answers to these questions :) Maybe there are other well known cases that should be documented and perhaps put in the review tool? Any Fedora community member who has a concern about a license compatibility issue involving a specific Fedora package or proposed Fedora package is encouraged to raise it (probably most appropriately in
[Fedora-legal-list] Re: License compliance in fedora-review
On 1/5/23 19:42, Richard Fontana wrote: > On Wed, Jan 4, 2023 at 3:12 AM Benson Muite > wrote: >> >> Maybe there are other well known cases that should be documented and >> perhaps put in the review tool? > > I would discourage having the review tool attempt to flag license > compatibility issues. My assumption, based on past experience, is that > in the vast majority of cases we would conclude after careful (and > sometimes even quick) analysis that there is no actual issue of > license incompatibility. So I think having this in the review tool > will just add mostly unnecessary friction. With increasing number of licenses, it may be good to start with some automation where incompatibility has been established. Checking for GPL-2.0-only and Apache tags can be automated and a warning given. This would just alert the packager. Checking packages already in Fedora that need corrections/further analysis are below. Can raise issues for these. It is possible to write a short script to check for GPL-2.0-only and Apache license declarations and add this to either rpmlint (co-maintained by SUSE) or the licensechecker. imhex https://src.fedoraproject.org/rpms/imhex/blob/rawhide/f/imhex.spec Apache-2.0 WITH LLVM-exception not just Apache-2.0 zimlib https://src.fedoraproject.org/rpms/zimlib/blob/rawhide/f/zimlib.spec https://github.com/openzim/libzim Seems to have been updated to GPL-2.0-or-later https://github.com/openzim/libzim/issues/30 strawberry https://src.fedoraproject.org/rpms/strawberry/blob/rawhide/f/strawberry.spec https://github.com/strawberrymusicplayer/strawberry Seems to mix licenses in one application, probably needs a check scratch https://src.fedoraproject.org/rpms/scratch/blob/rawhide/f/scratch.spec https://github.com/LLK/Scratch_1.4 Installed as one bundle, should be two separate packages for Scratch and Squeak due to licensing retroarch https://src.fedoraproject.org/rpms/retroarch/blob/rawhide/f/retroarch.spec https://github.com/libretro/RetroArch Installed as one bundle, one file has GPL2 only license, maybe rewritten/relicensed? https://github.com/libretro/RetroArch/blob/master/memory/ngc/ssaram.c qownnotes https://src.fedoraproject.org/rpms/qownnotes/blob/rawhide/f/qownnotes.spec Bundled GPL-2.0-only library and Apache 2.0 patch. One executable. qmc2 https://src.fedoraproject.org/rpms/qmc2/blob/rawhide/f/qmc2.spec Bundled Javascript Apache 2.0 library, should be packaged separately marker https://src.fedoraproject.org/rpms/marker/blob/rawhide/f/marker.spec https://github.com/fabiocolacio/Marker GPL-2.0-only does not seem to apply, mentioned in a Debian packaging file python3-pyopencl https://src.fedoraproject.org/rpms/python-pyopencl/blob/rawhide/f/python-pyopencl.spec Bundled GPL-2.0-only cephes, should be unbundled phpdoc https://src.fedoraproject.org/rpms/phpdoc/blob/f37/f/phpdoc.spec Bundled GPL-2.0-only javascript. Package retired, not available in Rawhide pgadmin4 https://src.fedoraproject.org/rpms/pgadmin4/blob/rawhide/f/pgadmin4.spec https://src.fedoraproject.org/rpms/pgadmin4/blob/rawhide/f/pgadmin4-6.18-vendor-licenses.txt license listing for bundled Javascript seems incorrect netstandard-targeting-pack-2.1 and other dotnet packages https://src.fedoraproject.org/rpms/dotnet6.0/blob/rawhide/f/dotnet6.0.spec https://github.com/dotnet Licensing may need updating. GPL code seems to be used for tests only: https://github.com/dotnet/runtime/issues/55072 Java ( 1.8.0, 11, 17, latest) https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/rawhide/f/java-1.8.0-openjdk.spec#_1414 Assume this has been looked at, since it is a well used package, but maybe a note should be added to the spec file? flameshot https://src.fedoraproject.org/rpms/flameshot/blob/rawhide/f/flameshot.spec Some files probably need relicensing or replacing llvm-test-suite https://src.fedoraproject.org/rpms/llvm-test-suite/blob/rawhide/f/llvm-test-suite.spec Spec indicates review required ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On Wed, Jan 4, 2023 at 3:12 AM Benson Muite wrote: > > The Apache 2 and GPL conflict seems well known. There are 1012 packages > in the repositories with both GPL and Apache licenses: > $ dnf repoquery --all --info > allpackageinfo.txt > $ cat allpackageinfo.txt | grep -n "ASL.* GPL" >> GPLonly_AND_APACHE.txt > $ cat allpackageinfo.txt | grep -n "Apache.* GPL" >> GPLonly_AND_APACHE.txt > $ cat allpackageinfo.txt | grep -n " GPL.*ASL" >> GPLonly_AND_APACHE.txt > $ cat allpackageinfo.txt | grep -n " GPL.*Apache" >> GPLonly_AND_APACHE.txt > $ wc -l GPLonly_AND_APACHE.txt > > Need to check that either GPL license is the main one that applies with > Apache licensed software included in GPL software but no GPL software in > Apache licensed software or separate Apache and GPL packages are produced: > https://www.apache.org/licenses/GPL-compatibility.html > > Maybe there are other well known cases that should be documented and > perhaps put in the review tool? I would discourage having the review tool attempt to flag license compatibility issues. My assumption, based on past experience, is that in the vast majority of cases we would conclude after careful (and sometimes even quick) analysis that there is no actual issue of license incompatibility. So I think having this in the review tool will just add mostly unnecessary friction. Richard ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
Hi Richard, > > Fedora used to maintain in its old license list an indication of > whether a "good" license was GPLv2 and (separately) GPLv3 compatible. > We thought this over carefully but decided not to continue this > practice in the migration of this data to the fedora-license-data > repository. This despite the fact that a lot of careful thought went > into those determinations (such that I think the preserved record of > those determinations has some significant historical value for GPL > interpretation). We did this because in essentially no real-world case > was the information ever used to take any action with respect to an > actual or proposed Fedora package. This data is helpful. Adding this to SPDX would be good, but given the number of licenses, it would be most efficient if other interested parties also contributed to this. > > As for compatibility of arbitrary licenses more generally: If I'm > counting correctly, Fedora now has 286 licenses in the simple > "allowed" category (corresponding to the old "good [for software]" > category) and this is expected to increase substantially with the > ongoing migration to use of SPDX identifiers. So it is basically > impractical if not impossible to maintain any useful, well-reasoned > set of context-free compatibility relationships for each Fedora > allowed license with respect to any other arbitrary Fedora allowed > license. > For software licenses, probably a simple categorization is reasonable? Permissive, weakly protective, strongly protective, network protective Suggestions can then be issued to packagers to check license compliance that typically either the most protective license applies, or contents with separate licenses are in separate packages. The Apache 2 and GPL conflict seems well known. There are 1012 packages in the repositories with both GPL and Apache licenses: $ dnf repoquery --all --info > allpackageinfo.txt $ cat allpackageinfo.txt | grep -n "ASL.* GPL" >> GPLonly_AND_APACHE.txt $ cat allpackageinfo.txt | grep -n "Apache.* GPL" >> GPLonly_AND_APACHE.txt $ cat allpackageinfo.txt | grep -n " GPL.*ASL" >> GPLonly_AND_APACHE.txt $ cat allpackageinfo.txt | grep -n " GPL.*Apache" >> GPLonly_AND_APACHE.txt $ wc -l GPLonly_AND_APACHE.txt Need to check that either GPL license is the main one that applies with Apache licensed software included in GPL software but no GPL software in Apache licensed software or separate Apache and GPL packages are produced: https://www.apache.org/licenses/GPL-compatibility.html Maybe there are other well known cases that should be documented and perhaps put in the review tool? > Any Fedora community member who has a concern about a license > compatibility issue involving a specific Fedora package or proposed > Fedora package is encouraged to raise it (probably most appropriately > in a Bugzilla bug) and it will be looked at in a context-specific way. > This context-specific analysis will consider not only architectural > issues (of the sort referred to by Miroslav) but also the licensing, > development and political history of the code at issue and general > relevant FOSS community practices. If it will prove useful we will try > to document some generalized conclusions in the Fedora license > documentation. > Generalized conclusions/suggestions would be helpful. > Lastly, I would suggest taking past promulgations on the general topic > here by commentators with a fairly enormous grain of salt. > > Richard > ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On Mon, Jan 2, 2023 at 12:45 AM Benson Muite wrote: > > Fedora-review has a license check component that lists license types > available in a package. However, not all licenses are compliant with > each other. A chart indicating which licenses can be included with other > licenses is available at: > https://dwheeler.com/essays/floss-license-slide.html > Would it be possible to create a similar chart for all SPDX identifiers > that can be used in Fedora? This would enable adding such a check to > fedora-review. Hi Benson, Fedora used to maintain in its old license list an indication of whether a "good" license was GPLv2 and (separately) GPLv3 compatible. We thought this over carefully but decided not to continue this practice in the migration of this data to the fedora-license-data repository. This despite the fact that a lot of careful thought went into those determinations (such that I think the preserved record of those determinations has some significant historical value for GPL interpretation). We did this because in essentially no real-world case was the information ever used to take any action with respect to an actual or proposed Fedora package. As for compatibility of arbitrary licenses more generally: If I'm counting correctly, Fedora now has 286 licenses in the simple "allowed" category (corresponding to the old "good [for software]" category) and this is expected to increase substantially with the ongoing migration to use of SPDX identifiers. So it is basically impractical if not impossible to maintain any useful, well-reasoned set of context-free compatibility relationships for each Fedora allowed license with respect to any other arbitrary Fedora allowed license. Any Fedora community member who has a concern about a license compatibility issue involving a specific Fedora package or proposed Fedora package is encouraged to raise it (probably most appropriately in a Bugzilla bug) and it will be looked at in a context-specific way. This context-specific analysis will consider not only architectural issues (of the sort referred to by Miroslav) but also the licensing, development and political history of the code at issue and general relevant FOSS community practices. If it will prove useful we will try to document some generalized conclusions in the Fedora license documentation. Lastly, I would suggest taking past promulgations on the general topic here by commentators with a fairly enormous grain of salt. Richard ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On 1/2/23 12:11, Benson Muite wrote: > On 1/2/23 11:49, Miroslav Suchý wrote: >> Dne 02. 01. 23 v 6:34 Benson Muite napsal(a): >>> available in a package. However, not all licenses are compliant with >>> each other. A chart indicating which licenses can be included with other >>> licenses is available at: >>> https://dwheeler.com/essays/floss-license-slide.html >>> Would it be possible to create a similar chart for all SPDX identifiers >>> that can be used in Fedora? This would enable adding such a check to >>> fedora-review. >> >> IANAL but this can be hardly applied to package. This graph can be >> applied on the same or derived work. But not on the collection of work. >> Which package is. >> >> E.g., I can have a package which contains tools: >> >> /usr/bin/foo >> >> /usr/bin/bar >> >> foo is licensed as LGPLv2.1 and bar is licensed as MPL 1.1. Although >> these two licenses are not compatible, I see no problem to have these >> two separate tools in the same package. And package to have license >> LGPL-2.1-or-later AND MPL 1.1 (or what is the SPDX id). > It is reasonable to have the tools as separate binaries within the same > package. At present, license check will indicate which license > declarations have been made. Having reviewer guidance on license > compatibility would be helpful. A full automatic check maybe difficult, > but warnings would be helpful for reviewers to check licensing and seek > clarification if necessary. As there is an ever growing number of open > source licenses, automating some of this process is helpful. Motivation > for this is a review of a package that contains files under GPL2+, but > intention of developers is to use Apache 2.0. > https://bugzilla.redhat.com/show_bug.cgi?id=2157252 > There is some work on this. In particular the Open Source Automation Development lab [1] publishes a compatibility matrix in Json format. This information is available in a Python library [2], though can also build something specifically for Fedora. Creative commons licenses [3] also have compatibility requirements. 1) https://www.osadl.org/Access-to-raw-data.oss-compliance-raw-data-access.0.html 2) https://github.com/priv-kweihmann/osadl-matrix 3) https://en.wikipedia.org/wiki/License_compatibility#Creative_Commons_license_compatibility ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
On 1/2/23 11:49, Miroslav Suchý wrote: > Dne 02. 01. 23 v 6:34 Benson Muite napsal(a): >> available in a package. However, not all licenses are compliant with >> each other. A chart indicating which licenses can be included with other >> licenses is available at: >> https://dwheeler.com/essays/floss-license-slide.html >> Would it be possible to create a similar chart for all SPDX identifiers >> that can be used in Fedora? This would enable adding such a check to >> fedora-review. > > IANAL but this can be hardly applied to package. This graph can be > applied on the same or derived work. But not on the collection of work. > Which package is. > > E.g., I can have a package which contains tools: > > /usr/bin/foo > > /usr/bin/bar > > foo is licensed as LGPLv2.1 and bar is licensed as MPL 1.1. Although > these two licenses are not compatible, I see no problem to have these > two separate tools in the same package. And package to have license > LGPL-2.1-or-later AND MPL 1.1 (or what is the SPDX id). It is reasonable to have the tools as separate binaries within the same package. At present, license check will indicate which license declarations have been made. Having reviewer guidance on license compatibility would be helpful. A full automatic check maybe difficult, but warnings would be helpful for reviewers to check licensing and seek clarification if necessary. As there is an ever growing number of open source licenses, automating some of this process is helpful. Motivation for this is a review of a package that contains files under GPL2+, but intention of developers is to use Apache 2.0. https://bugzilla.redhat.com/show_bug.cgi?id=2157252 ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora-legal-list] Re: License compliance in fedora-review
Dne 02. 01. 23 v 6:34 Benson Muite napsal(a): available in a package. However, not all licenses are compliant with each other. A chart indicating which licenses can be included with other licenses is available at: https://dwheeler.com/essays/floss-license-slide.html Would it be possible to create a similar chart for all SPDX identifiers that can be used in Fedora? This would enable adding such a check to fedora-review. IANAL but this can be hardly applied to package. This graph can be applied on the same or derived work. But not on the collection of work. Which package is. E.g., I can have a package which contains tools: /usr/bin/foo /usr/bin/bar foo is licensed as LGPLv2.1 and bar is licensed as MPL 1.1. Although these two licenses are not compatible, I see no problem to have these two separate tools in the same package. And package to have license LGPL-2.1-or-later AND MPL 1.1 (or what is the SPDX id). Miroslav ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
