I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad license
Then the result is Good license and the package is allowed to be in Fedora, right?
Miroslav
On Wed, Dec 29, 2021 at 11:21 AM Miroslav Suchý msuchy@redhat.com wrote:
I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad licenseThen the result is Good license and the package is allowed to be in Fedora, right?
Yes. However, apparently we can also declare we're using it under a particular license's terms by removing the declaration of the bad license's identifier.
The precedent for this: https://gitlab.com/redhat/centos-stream/rpms/LibRaw/-/merge_requests/2
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Dec 29, 2021 at 11:22 AM Miroslav Suchý msuchy@redhat.com wrote:
I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad licenseThen the result is Good license and the package is allowed to be in Fedora, right?
So first of all if I change your question to be about the actual underlying license terms of the package as opposed to the representation in the spec file, I believe the answer must be "yes" and there are probably a lot of examples of this in Fedora. (Think of any arbitrary package that says it's under some FOSS license and also says informally that proprietary licenses are also available.)
With the spec file, though, I believe there is an inconsistency in how Fedora deals with this, but this is just a casual impression. On the one hand, there is the common case of traditionally-licensed Perl modules (typically, a dual license involving unversioned GPL and a license identified as the Artistic License 1.0 [which I realize exists in multiple forms, but let's ignore that]). Fedora spec files for such Perl module packages generally say something like "GPL or Artistic", even though Fedora classifies the Artistic License as a "bad" license. I *think* there may be other examples, not involving Perl modules or the Artistic License, where the code is dual licensed under a good license and a bad license and the spec file only gives the good license. The only rationale I could come up with for the difference in approach is that the Artistic License, while "bad" from Fedora's perspective, is generally seen as plausibly-FOSS (it's an OSI-approved license, for one thing).
I think it comes down to whether Fedora wants to have spec files that say, for example, "GPL or Proprietary" much as it has spec files that say "GPL or Artistic".
Richard
On Wed, Dec 29, 2021 at 11:46:44AM -0500, Richard Fontana wrote:
On Wed, Dec 29, 2021 at 11:22 AM Miroslav Suchý msuchy@redhat.com wrote:
I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad licenseThen the result is Good license and the package is allowed to be in Fedora, right?
So first of all if I change your question to be about the actual underlying license terms of the package as opposed to the representation in the spec file, I believe the answer must be "yes" and there are probably a lot of examples of this in Fedora. (Think of any arbitrary package that says it's under some FOSS license and also says informally that proprietary licenses are also available.)
With the spec file, though, I believe there is an inconsistency in how Fedora deals with this, but this is just a casual impression. On the one hand, there is the common case of traditionally-licensed Perl modules (typically, a dual license involving unversioned GPL and a license identified as the Artistic License 1.0 [which I realize exists in multiple forms, but let's ignore that]). Fedora spec files for such Perl module packages generally say something like "GPL or Artistic", even though Fedora classifies the Artistic License as a "bad" license. I *think* there may be other examples, not involving Perl modules or the Artistic License, where the code is dual licensed under a good license and a bad license and the spec file only gives the good license. The only rationale I could come up with for the difference in approach is that the Artistic License, while "bad" from Fedora's perspective, is generally seen as plausibly-FOSS (it's an OSI-approved license, for one thing).
I think it comes down to whether Fedora wants to have spec files that say, for example, "GPL or Proprietary" much as it has spec files that say "GPL or Artistic".
It's true there is inconsistency regarding the License tag in the spec file. As the package maintainer and as part of the Fedora project, I would prefer that the License tag in the spec reflect the license terms that we are distributing the built package against. So in the case of Perl modules that are generally GPL or Artistic, the Fedora project is really redistributing them under the terms of the GPL only, right?
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
So many licenses, so many questions....
For historical context, we went from "Perl" as the license tag, to the more accurate "GPL+ or Artistic". Then, when we determined after Jacobsen v. Katzer that Artistic was both unsafe and possibly not open source, I audited Fedora and removed any Artistic 1 only code that could not be relicensed upstream to the "same as perl" license (GPL+ or Artistic) or any other FOSS license (mostly Artistic 2.0). In that effort, I discovered that a notable number of upstream perl maintainers were unhappy with us describing their packages as "GPL+" only, insisting that even if Fedora didn't use the Artistic 1.0 license, they wanted it included.
Since I had many more pressing battles to fight, I left the perl modules with the technically correct (but functionally inconsistent) licensing tag. As we move to the new licensing syntax, I would say there is no reason to permit this ancient corner case.
~spot
On Tue, Jan 4, 2022 at 11:27 AM David Cantrell dcantrell@redhat.com wrote:
On Wed, Dec 29, 2021 at 11:46:44AM -0500, Richard Fontana wrote:
On Wed, Dec 29, 2021 at 11:22 AM Miroslav Suchý msuchy@redhat.com
wrote:
I want to clarify one thing I am working on. When I have this string in
License tag in spec:
Good License or Bad licenseThen the result is Good license and the package is allowed to be in
Fedora, right?
So first of all if I change your question to be about the actual underlying license terms of the package as opposed to the representation in the spec file, I believe the answer must be "yes" and there are probably a lot of examples of this in Fedora. (Think of any arbitrary package that says it's under some FOSS license and also says informally that proprietary licenses are also available.)
With the spec file, though, I believe there is an inconsistency in how Fedora deals with this, but this is just a casual impression. On the one hand, there is the common case of traditionally-licensed Perl modules (typically, a dual license involving unversioned GPL and a license identified as the Artistic License 1.0 [which I realize exists in multiple forms, but let's ignore that]). Fedora spec files for such Perl module packages generally say something like "GPL or Artistic", even though Fedora classifies the Artistic License as a "bad" license. I *think* there may be other examples, not involving Perl modules or the Artistic License, where the code is dual licensed under a good license and a bad license and the spec file only gives the good license. The only rationale I could come up with for the difference in approach is that the Artistic License, while "bad" from Fedora's perspective, is generally seen as plausibly-FOSS (it's an OSI-approved license, for one thing).
I think it comes down to whether Fedora wants to have spec files that say, for example, "GPL or Proprietary" much as it has spec files that say "GPL or Artistic".
It's true there is inconsistency regarding the License tag in the spec file. As the package maintainer and as part of the Fedora project, I would prefer that the License tag in the spec reflect the license terms that we are distributing the built package against. So in the case of Perl modules that are generally GPL or Artistic, the Fedora project is really redistributing them under the terms of the GPL only, right?
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
So many licenses, so many questions....
-- David Cantrell dcantrell@redhat.com Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ 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
On Tue, Jan 4, 2022 at 4:49 PM Tom Callaway spotrh@gmail.com wrote:
For historical context, we went from "Perl" as the license tag, to the more accurate "GPL+ or Artistic". Then, when we determined after Jacobsen v. Katzer that Artistic was both unsafe and possibly not open source, I audited Fedora and removed any Artistic 1 only code that could not be relicensed upstream to the "same as perl" license (GPL+ or Artistic) or any other FOSS license (mostly Artistic 2.0). In that effort, I discovered that a notable number of upstream perl maintainers were unhappy with us describing their packages as "GPL+" only, insisting that even if Fedora didn't use the Artistic 1.0 license, they wanted it included.
Since I had many more pressing battles to fight, I left the perl modules with the technically correct (but functionally inconsistent) licensing tag. As we move to the new licensing syntax, I would say there is no reason to permit this ancient corner case.
I always assumed that you had classified Artistic 1.0 as nonfree because that had been the FSF's position since time immemorial. Historically, the FSF had what many (including me), who, in the past, looked favorably on the FSF as a license policymaking entity, assumed to be a reasonably well-thought-out set of objections to the Artistic License, which I think came down to "the license is a bit of a joke and is too confusingly drafted", and indeed that has become a principle in reviewing licenses under consideration in Fedora in later times. Personally, I would admit that I never bothered to analyze the Artistic License 1.0 that closely and was inclined to accept the FSF's condemnation even though it implicitly clashed with the views of certain other organizations active in developing policies around FOSS licensing. If instead it had to do with Jacobsen v. Katzer, that might warrant reconsideration.
Richard
~spot
On Tue, Jan 4, 2022 at 11:27 AM David Cantrell dcantrell@redhat.com wrote:
On Wed, Dec 29, 2021 at 11:46:44AM -0500, Richard Fontana wrote:
On Wed, Dec 29, 2021 at 11:22 AM Miroslav Suchý msuchy@redhat.com wrote:
I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad licenseThen the result is Good license and the package is allowed to be in Fedora, right?
So first of all if I change your question to be about the actual underlying license terms of the package as opposed to the representation in the spec file, I believe the answer must be "yes" and there are probably a lot of examples of this in Fedora. (Think of any arbitrary package that says it's under some FOSS license and also says informally that proprietary licenses are also available.)
With the spec file, though, I believe there is an inconsistency in how Fedora deals with this, but this is just a casual impression. On the one hand, there is the common case of traditionally-licensed Perl modules (typically, a dual license involving unversioned GPL and a license identified as the Artistic License 1.0 [which I realize exists in multiple forms, but let's ignore that]). Fedora spec files for such Perl module packages generally say something like "GPL or Artistic", even though Fedora classifies the Artistic License as a "bad" license. I *think* there may be other examples, not involving Perl modules or the Artistic License, where the code is dual licensed under a good license and a bad license and the spec file only gives the good license. The only rationale I could come up with for the difference in approach is that the Artistic License, while "bad" from Fedora's perspective, is generally seen as plausibly-FOSS (it's an OSI-approved license, for one thing).
I think it comes down to whether Fedora wants to have spec files that say, for example, "GPL or Proprietary" much as it has spec files that say "GPL or Artistic".
It's true there is inconsistency regarding the License tag in the spec file. As the package maintainer and as part of the Fedora project, I would prefer that the License tag in the spec reflect the license terms that we are distributing the built package against. So in the case of Perl modules that are generally GPL or Artistic, the Fedora project is really redistributing them under the terms of the GPL only, right?
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
So many licenses, so many questions....
-- David Cantrell dcantrell@redhat.com Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ 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
On 1/4/22 9:27 AM, David Cantrell wrote:
On Wed, Dec 29, 2021 at 11:46:44AM -0500, Richard Fontana wrote:
On Wed, Dec 29, 2021 at 11:22 AM Miroslav Suchý msuchy@redhat.com wrote:
I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad license
Then the result is Good license and the package is allowed to be in Fedora, right?
So first of all if I change your question to be about the actual underlying license terms of the package as opposed to the representation in the spec file, I believe the answer must be "yes" and there are probably a lot of examples of this in Fedora. (Think of any arbitrary package that says it's under some FOSS license and also says informally that proprietary licenses are also available.)
With the spec file, though, I believe there is an inconsistency in how Fedora deals with this, but this is just a casual impression. On the one hand, there is the common case of traditionally-licensed Perl modules (typically, a dual license involving unversioned GPL and a license identified as the Artistic License 1.0 [which I realize exists in multiple forms, but let's ignore that]). Fedora spec files for such Perl module packages generally say something like "GPL or Artistic", even though Fedora classifies the Artistic License as a "bad" license. I *think* there may be other examples, not involving Perl modules or the Artistic License, where the code is dual licensed under a good license and a bad license and the spec file only gives the good license. The only rationale I could come up with for the difference in approach is that the Artistic License, while "bad" from Fedora's perspective, is generally seen as plausibly-FOSS (it's an OSI-approved license, for one thing).
I think it comes down to whether Fedora wants to have spec files that say, for example, "GPL or Proprietary" much as it has spec files that say "GPL or Artistic".
It's true there is inconsistency regarding the License tag in the spec file. As the package maintainer and as part of the Fedora project, I would prefer that the License tag in the spec reflect the license terms that we are distributing the built package against. So in the case of Perl modules that are generally GPL or Artistic, the Fedora project is really redistributing them under the terms of the GPL only, right?
I think the answer to the inconsistency here is to set a policy relating to disjunctive licensed packages and then document that in the packaging guidelines. This would provide clarity for both package maintainers as well as downstream recipients. My recommendation would be that in the case where (random example):
The package license upstream is: AGPL-3.0-or-later OR SSPL-1.0
and where Fedora would not allow SSPL-1.0, then the License field in the spec file would simply indicate:
AGPL-3.0-or-later
If one really wants to be thorough and there is some kind of comment field in the Spec file (I think I've seen this?), then one could note something along the lines of "This package is licensed upstream as AGPL-3.0-or-later OR SSPL-1.0"
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
So many licenses, so many questions....
:)
Jilayne
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I sort of agree.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
The only reason why "GPL+ or Artistic" (or, presumably in SPDX notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used by Fedora is that Artistic-1.0 is "bad" from Fedora's perspective and Fedora has a policy of not distributing code in packages under "bad" licenses. Or else we should revisit that classification of Artistic-1.0, or else document that there is a special exception for Perl modules because Perl module developers upstream objected to the use of merely 'GPL" in the spec file license tag. (I don't really like that last possibility.)
Otherwise, if the disjunctive license expression involves two licenses Fedora considers "good", then I agree with Jilayne, the choice should be passed on -- even if there is some argument that it *can't* be (which would mainly be for license compatibility reasons, I guess). That has in fact been the practice in Fedora, and in all the projects and products developed by Red Hat that I'm aware of. At Red Hat we've even explained this to the occasional customer who asks us which license of a FOSS-dual-licensed package, or file, we are shipping under.
I am aware anecdotally that there are other companies that do the opposite: they are careful to somehow ceremonially or otherwise "pick" one of the licenses in the disjunct. It is important to note that this is *not* what is done upstream, i.e. by upstream projects using other projects' FOSS code, except in extremely rare cases, and I see Fedora, as well as Red Hat, as perpetuating that general upstream FOSS community practice of passing on FOSS license choices without further analysis. One reason for this is that it's generally never clear which of the licenses ought to be selected or would be preferable, if one had to make a choice. The result is more complex license identifier expressions in package metadata, but I think there the complexity is justified.
What it actually *means* for an intermediary to distribute upstream code under the upstream choice of licenses, with conditions that might simultaneously apply to that intermediary on either side of the disjunct, I'm not entirely sure, but in all normal practical scenarios it never really matters -- which is another reason for the "pass the choice on" practice. I'd rather copy the practices of upstream community projects than the practices of GPL-phobic companies downstream, basically.
Richard
On Wed, Jan 5, 2022 at 1:31 AM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I sort of agree.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
The only reason why "GPL+ or Artistic" (or, presumably in SPDX notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used by Fedora is that Artistic-1.0 is "bad" from Fedora's perspective and Fedora has a policy of not distributing code in packages under "bad" licenses. Or else we should revisit that classification of Artistic-1.0, or else document that there is a special exception for Perl modules because Perl module developers upstream objected to the use of merely 'GPL" in the spec file license tag. (I don't really like that last possibility.)
Otherwise, if the disjunctive license expression involves two licenses Fedora considers "good", then I agree with Jilayne, the choice should be passed on -- even if there is some argument that it *can't* be (which would mainly be for license compatibility reasons, I guess). That has in fact been the practice in Fedora, and in all the projects and products developed by Red Hat that I'm aware of. At Red Hat we've even explained this to the occasional customer who asks us which license of a FOSS-dual-licensed package, or file, we are shipping under.
I am aware anecdotally that there are other companies that do the opposite: they are careful to somehow ceremonially or otherwise "pick" one of the licenses in the disjunct. It is important to note that this is *not* what is done upstream, i.e. by upstream projects using other projects' FOSS code, except in extremely rare cases, and I see Fedora, as well as Red Hat, as perpetuating that general upstream FOSS community practice of passing on FOSS license choices without further analysis. One reason for this is that it's generally never clear which of the licenses ought to be selected or would be preferable, if one had to make a choice. The result is more complex license identifier expressions in package metadata, but I think there the complexity is justified.
What it actually *means* for an intermediary to distribute upstream code under the upstream choice of licenses, with conditions that might simultaneously apply to that intermediary on either side of the disjunct, I'm not entirely sure, but in all normal practical scenarios it never really matters -- which is another reason for the "pass the choice on" practice. I'd rather copy the practices of upstream community projects than the practices of GPL-phobic companies downstream, basically.
With my upstream hat, I greatly prefer that Fedora *not* make decisions about the licenses. I even kind of prefer what Fedora does today with Perl modules (that is, document both "good" and "bad" licenses). With my Fedora contributor "hat" on (lol), I'd prefer to strip "bad" licenses since we never want to allow that choice of license combinations. I know some think that documenting "bad" licenses means we give permission to use under those terms (that's not even *close* to what that means, but meh). With my downstream consumer hat on, I worry that Fedora making decisions on licenses might lead to weird effects for me when working with other things. I'd prefer Fedora to stay out of picking licenses for packages and allow "runtime evaluation" of license combinations instead.
All of this to say, I agree with Richard that we should more or less keep the status quo.
Dne 05. 01. 22 v 11:16 Neal Gompa napsal(a):
On Wed, Jan 5, 2022 at 1:31 AM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I sort of agree.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
The only reason why "GPL+ or Artistic" (or, presumably in SPDX notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used by Fedora is that Artistic-1.0 is "bad" from Fedora's perspective and Fedora has a policy of not distributing code in packages under "bad" licenses. Or else we should revisit that classification of Artistic-1.0, or else document that there is a special exception for Perl modules because Perl module developers upstream objected to the use of merely 'GPL" in the spec file license tag. (I don't really like that last possibility.)
Otherwise, if the disjunctive license expression involves two licenses Fedora considers "good", then I agree with Jilayne, the choice should be passed on -- even if there is some argument that it *can't* be (which would mainly be for license compatibility reasons, I guess). That has in fact been the practice in Fedora, and in all the projects and products developed by Red Hat that I'm aware of. At Red Hat we've even explained this to the occasional customer who asks us which license of a FOSS-dual-licensed package, or file, we are shipping under.
I am aware anecdotally that there are other companies that do the opposite: they are careful to somehow ceremonially or otherwise "pick" one of the licenses in the disjunct. It is important to note that this is *not* what is done upstream, i.e. by upstream projects using other projects' FOSS code, except in extremely rare cases, and I see Fedora, as well as Red Hat, as perpetuating that general upstream FOSS community practice of passing on FOSS license choices without further analysis. One reason for this is that it's generally never clear which of the licenses ought to be selected or would be preferable, if one had to make a choice. The result is more complex license identifier expressions in package metadata, but I think there the complexity is justified.
What it actually *means* for an intermediary to distribute upstream code under the upstream choice of licenses, with conditions that might simultaneously apply to that intermediary on either side of the disjunct, I'm not entirely sure, but in all normal practical scenarios it never really matters -- which is another reason for the "pass the choice on" practice. I'd rather copy the practices of upstream community projects than the practices of GPL-phobic companies downstream, basically.
With my upstream hat, I greatly prefer that Fedora *not* make decisions about the licenses. I even kind of prefer what Fedora does today with Perl modules (that is, document both "good" and "bad" licenses). With my Fedora contributor "hat" on (lol), I'd prefer to strip "bad" licenses since we never want to allow that choice of license combinations. I know some think that documenting "bad" licenses means we give permission to use under those terms (that's not even *close* to what that means, but meh). With my downstream consumer hat on, I worry that Fedora making decisions on licenses might lead to weird effects for me when working with other things. I'd prefer Fedora to stay out of picking licenses for packages and allow "runtime evaluation" of license combinations instead.
All of this to say, I agree with Richard that we should more or less keep the status quo.
Why the license tag couldn't be something like:
License: upstream(GPL+ or Artistic) and fedora(GPL+)
There could even be macro based e.g. on Mirek's tool to reduce the upstream license set to Fedora license set:
%{license:GPL+ or Artistic}
because as a packager, I'd be much happier if I can just list the upstream licenses and don't bother what is effective Fedora license.
Vít
On Wed, Jan 05, 2022 at 12:39:50PM +0100, Vít Ondruch wrote:
Dne 05. 01. 22 v 11:16 Neal Gompa napsal(a):
On Wed, Jan 5, 2022 at 1:31 AM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I sort of agree.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
The only reason why "GPL+ or Artistic" (or, presumably in SPDX notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used by Fedora is that Artistic-1.0 is "bad" from Fedora's perspective and Fedora has a policy of not distributing code in packages under "bad" licenses. Or else we should revisit that classification of Artistic-1.0, or else document that there is a special exception for Perl modules because Perl module developers upstream objected to the use of merely 'GPL" in the spec file license tag. (I don't really like that last possibility.)
Otherwise, if the disjunctive license expression involves two licenses Fedora considers "good", then I agree with Jilayne, the choice should be passed on -- even if there is some argument that it *can't* be (which would mainly be for license compatibility reasons, I guess). That has in fact been the practice in Fedora, and in all the projects and products developed by Red Hat that I'm aware of. At Red Hat we've even explained this to the occasional customer who asks us which license of a FOSS-dual-licensed package, or file, we are shipping under.
I am aware anecdotally that there are other companies that do the opposite: they are careful to somehow ceremonially or otherwise "pick" one of the licenses in the disjunct. It is important to note that this is *not* what is done upstream, i.e. by upstream projects using other projects' FOSS code, except in extremely rare cases, and I see Fedora, as well as Red Hat, as perpetuating that general upstream FOSS community practice of passing on FOSS license choices without further analysis. One reason for this is that it's generally never clear which of the licenses ought to be selected or would be preferable, if one had to make a choice. The result is more complex license identifier expressions in package metadata, but I think there the complexity is justified.
What it actually *means* for an intermediary to distribute upstream code under the upstream choice of licenses, with conditions that might simultaneously apply to that intermediary on either side of the disjunct, I'm not entirely sure, but in all normal practical scenarios it never really matters -- which is another reason for the "pass the choice on" practice. I'd rather copy the practices of upstream community projects than the practices of GPL-phobic companies downstream, basically.
With my upstream hat, I greatly prefer that Fedora *not* make decisions about the licenses. I even kind of prefer what Fedora does today with Perl modules (that is, document both "good" and "bad" licenses). With my Fedora contributor "hat" on (lol), I'd prefer to strip "bad" licenses since we never want to allow that choice of license combinations. I know some think that documenting "bad" licenses means we give permission to use under those terms (that's not even *close* to what that means, but meh). With my downstream consumer hat on, I worry that Fedora making decisions on licenses might lead to weird effects for me when working with other things. I'd prefer Fedora to stay out of picking licenses for packages and allow "runtime evaluation" of license combinations instead.
All of this to say, I agree with Richard that we should more or less keep the status quo.
Why the license tag couldn't be something like:
License: upstream(GPL+ or Artistic) and fedora(GPL+)
There could even be macro based e.g. on Mirek's tool to reduce the upstream license set to Fedora license set:
%{license:GPL+ or Artistic}
because as a packager, I'd be much happier if I can just list the upstream licenses and don't bother what is effective Fedora license.
I don't think using a macro for the License tag is a good idea because it risks changing it to something invalid at each rebuild of the package. In the case of mass rebuilds and other builds that the maintainer may not do correctly, we risk introducing invalid values in the License tag.
Also, packages relicense from time to time, some more than others (e.g., Qt). It's best that we capture this as static data in the spec file tied to the version of the software being packaged.
Dne 05. 01. 22 v 19:52 David Cantrell napsal(a):
On Wed, Jan 05, 2022 at 12:39:50PM +0100, Vít Ondruch wrote:
Dne 05. 01. 22 v 11:16 Neal Gompa napsal(a):
On Wed, Jan 5, 2022 at 1:31 AM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I sort of agree.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
The only reason why "GPL+ or Artistic" (or, presumably in SPDX notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used by Fedora is that Artistic-1.0 is "bad" from Fedora's perspective and Fedora has a policy of not distributing code in packages under "bad" licenses. Or else we should revisit that classification of Artistic-1.0, or else document that there is a special exception for Perl modules because Perl module developers upstream objected to the use of merely 'GPL" in the spec file license tag. (I don't really like that last possibility.)
Otherwise, if the disjunctive license expression involves two licenses Fedora considers "good", then I agree with Jilayne, the choice should be passed on -- even if there is some argument that it *can't* be (which would mainly be for license compatibility reasons, I guess). That has in fact been the practice in Fedora, and in all the projects and products developed by Red Hat that I'm aware of. At Red Hat we've even explained this to the occasional customer who asks us which license of a FOSS-dual-licensed package, or file, we are shipping under.
I am aware anecdotally that there are other companies that do the opposite: they are careful to somehow ceremonially or otherwise "pick" one of the licenses in the disjunct. It is important to note that this is *not* what is done upstream, i.e. by upstream projects using other projects' FOSS code, except in extremely rare cases, and I see Fedora, as well as Red Hat, as perpetuating that general upstream FOSS community practice of passing on FOSS license choices without further analysis. One reason for this is that it's generally never clear which of the licenses ought to be selected or would be preferable, if one had to make a choice. The result is more complex license identifier expressions in package metadata, but I think there the complexity is justified.
What it actually *means* for an intermediary to distribute upstream code under the upstream choice of licenses, with conditions that might simultaneously apply to that intermediary on either side of the disjunct, I'm not entirely sure, but in all normal practical scenarios it never really matters -- which is another reason for the "pass the choice on" practice. I'd rather copy the practices of upstream community projects than the practices of GPL-phobic companies downstream, basically.
With my upstream hat, I greatly prefer that Fedora *not* make decisions about the licenses. I even kind of prefer what Fedora does today with Perl modules (that is, document both "good" and "bad" licenses). With my Fedora contributor "hat" on (lol), I'd prefer to strip "bad" licenses since we never want to allow that choice of license combinations. I know some think that documenting "bad" licenses means we give permission to use under those terms (that's not even *close* to what that means, but meh). With my downstream consumer hat on, I worry that Fedora making decisions on licenses might lead to weird effects for me when working with other things. I'd prefer Fedora to stay out of picking licenses for packages and allow "runtime evaluation" of license combinations instead.
All of this to say, I agree with Richard that we should more or less keep the status quo.
Why the license tag couldn't be something like:
License: upstream(GPL+ or Artistic) and fedora(GPL+)
There could even be macro based e.g. on Mirek's tool to reduce the upstream license set to Fedora license set:
%{license:GPL+ or Artistic}
because as a packager, I'd be much happier if I can just list the upstream licenses and don't bother what is effective Fedora license.
I don't think using a macro for the License tag is a good idea because it risks changing it to something invalid at each rebuild of the package.
Nowadays, we don't even know the License tag is broken, so if it was change by macro from something broken to something broken differently, it can be worse.
But I actually see this as and opportunity for improvement. E.g. if I specified just `Artistic` license, the build would fail right away. If I specified `GPL+ or Artistic`, it would pass. If I specified `foo or Artistic`, it would also pass.
In the case of mass rebuilds and other builds that the maintainer may not do correctly, we risk introducing invalid values in the License tag.
We are constantly in the risk of this. If the tool should produce broken results, then fix and another mass rebuild would fix them.
Also, packages relicense from time to time, some more than others (e.g., Qt). It's best that we capture this as static data in the spec file tied to the version of the software being packaged.
I am not sure what is the difference to current state. Packages relicense and we are changing (or forget to change) the License tag all the time. The macro won't change it, because there must be the licenses specified the same way as for the current tag.
Vít
On Wed, Jan 05, 2022 at 05:16:41AM -0500, Neal Gompa wrote:
On Wed, Jan 5, 2022 at 1:31 AM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I sort of agree.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
The only reason why "GPL+ or Artistic" (or, presumably in SPDX notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used by Fedora is that Artistic-1.0 is "bad" from Fedora's perspective and Fedora has a policy of not distributing code in packages under "bad" licenses. Or else we should revisit that classification of Artistic-1.0, or else document that there is a special exception for Perl modules because Perl module developers upstream objected to the use of merely 'GPL" in the spec file license tag. (I don't really like that last possibility.)
Otherwise, if the disjunctive license expression involves two licenses Fedora considers "good", then I agree with Jilayne, the choice should be passed on -- even if there is some argument that it *can't* be (which would mainly be for license compatibility reasons, I guess). That has in fact been the practice in Fedora, and in all the projects and products developed by Red Hat that I'm aware of. At Red Hat we've even explained this to the occasional customer who asks us which license of a FOSS-dual-licensed package, or file, we are shipping under.
I am aware anecdotally that there are other companies that do the opposite: they are careful to somehow ceremonially or otherwise "pick" one of the licenses in the disjunct. It is important to note that this is *not* what is done upstream, i.e. by upstream projects using other projects' FOSS code, except in extremely rare cases, and I see Fedora, as well as Red Hat, as perpetuating that general upstream FOSS community practice of passing on FOSS license choices without further analysis. One reason for this is that it's generally never clear which of the licenses ought to be selected or would be preferable, if one had to make a choice. The result is more complex license identifier expressions in package metadata, but I think there the complexity is justified.
What it actually *means* for an intermediary to distribute upstream code under the upstream choice of licenses, with conditions that might simultaneously apply to that intermediary on either side of the disjunct, I'm not entirely sure, but in all normal practical scenarios it never really matters -- which is another reason for the "pass the choice on" practice. I'd rather copy the practices of upstream community projects than the practices of GPL-phobic companies downstream, basically.
With my upstream hat, I greatly prefer that Fedora *not* make decisions about the licenses. I even kind of prefer what Fedora does today with Perl modules (that is, document both "good" and "bad" licenses). With my Fedora contributor "hat" on (lol), I'd prefer to strip "bad" licenses since we never want to allow that choice of license combinations. I know some think that documenting "bad" licenses means we give permission to use under those terms (that's not even *close* to what that means, but meh). With my downstream consumer
Out of curiosity, what do you think listing forbidden licenses means in a Fedora package?
(I ask this too because when asking other people, I get slightly different answers and I think this is something we need clarified in the Packaging Guidelines and the forthcoming Fedora Legal Guidelines.)
hat on, I worry that Fedora making decisions on licenses might lead to weird effects for me when working with other things. I'd prefer Fedora to stay out of picking licenses for packages and allow "runtime evaluation" of license combinations instead.
All of this to say, I agree with Richard that we should more or less keep the status quo.
On Wed, Jan 05, 2022 at 01:30:42AM -0500, Richard Fontana wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I sort of agree.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
The only reason why "GPL+ or Artistic" (or, presumably in SPDX notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used by Fedora is that Artistic-1.0 is "bad" from Fedora's perspective and Fedora has a policy of not distributing code in packages under "bad" licenses. Or else we should revisit that classification of Artistic-1.0, or else document that there is a special exception for Perl modules because Perl module developers upstream objected to the use of merely 'GPL" in the spec file license tag. (I don't really like that last possibility.)
Otherwise, if the disjunctive license expression involves two licenses Fedora considers "good", then I agree with Jilayne, the choice should be passed on -- even if there is some argument that it *can't* be (which would mainly be for license compatibility reasons, I guess). That has in fact been the practice in Fedora, and in all the projects and products developed by Red Hat that I'm aware of. At Red Hat we've even explained this to the occasional customer who asks us which license of a FOSS-dual-licensed package, or file, we are shipping under.
I am aware anecdotally that there are other companies that do the opposite: they are careful to somehow ceremonially or otherwise "pick" one of the licenses in the disjunct. It is important to note that this is *not* what is done upstream, i.e. by upstream projects using other projects' FOSS code, except in extremely rare cases, and I see Fedora, as well as Red Hat, as perpetuating that general upstream FOSS community practice of passing on FOSS license choices without further analysis. One reason for this is that it's generally never clear which of the licenses ought to be selected or would be preferable, if one had to make a choice. The result is more complex license identifier expressions in package metadata, but I think there the complexity is justified.
What it actually *means* for an intermediary to distribute upstream code under the upstream choice of licenses, with conditions that might simultaneously apply to that intermediary on either side of the disjunct, I'm not entirely sure, but in all normal practical scenarios it never really matters -- which is another reason for the "pass the choice on" practice. I'd rather copy the practices of upstream community projects than the practices of GPL-phobic companies downstream, basically.
My main concern is that if Fedora maintains a list of forbidden licenses, then in the case of a dual-licensed project (e.g., a Perl module) presenting a good license and a bad license, Fedora is using that project under the good license. Which would mean the terms of redistribution to the user are under what we have chosen as the good license.
But in cases where we don't have that decision to make, the package should represent the entire complement of licenses for that project. I don't want to suggest we start selecting licenses for multi licensed projects--except in cases where one or more of the choices are one of our forbidden licenses.
Given the nature of "good or bad" case, should we considering a packaging policy that requires a README.Fedora file included with the %license definition in the spec file to indicate that Fedora is using this package under the terms of the 'good' license but in this directory you will find all of the licenses from the upstream project? The packager would write this file to clarify things.
On 1/4/22 11:30 PM, Richard Fontana wrote:
On Wed, Jan 5, 2022 at 12:06 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
The only reason why "GPL+ or Artistic" (or, presumably in SPDX notation, "GPL-1.0-or-later OR Artistic-1.0") shouldn't be used by Fedora is that Artistic-1.0 is "bad" from Fedora's perspective and Fedora has a policy of not distributing code in packages under "bad" licenses. Or else we should revisit that classification of Artistic-1.0, or else document that there is a special exception for Perl modules because Perl module developers upstream objected to the use of merely 'GPL" in the spec file license tag. (I don't really like that last possibility.)
+1 to revisiting the policy of the classification of Artistic-1.0 as "bad"
Otherwise, if the disjunctive license expression involves two licenses Fedora considers "good", then I agree with Jilayne, the choice should be passed on -- even if there is some argument that it *can't* be (which would mainly be for license compatibility reasons, I guess). That has in fact been the practice in Fedora, and in all the projects and products developed by Red Hat that I'm aware of. At Red Hat we've even explained this to the occasional customer who asks us which license of a FOSS-dual-licensed package, or file, we are shipping under.
I am aware anecdotally that there are other companies that do the opposite: they are careful to somehow ceremonially or otherwise "pick" one of the licenses in the disjunct. It is important to note that this is *not* what is done upstream, i.e. by upstream projects using other projects' FOSS code, except in extremely rare cases, and I see Fedora, as well as Red Hat, as perpetuating that general upstream FOSS community practice of passing on FOSS license choices without further analysis. One reason for this is that it's generally never clear which of the licenses ought to be selected or would be preferable, if one had to make a choice. The result is more complex license identifier expressions in package metadata, but I think there the complexity is justified.
By way of example re: other companies and picking one of the licenses (for anyone interested) - a couple scenarios I've seen where it might matter: you are a company that does not have an all-products-are-open-source policy, or your open source project wants to make sure its incorporated licenses are all compatible (in theory and practically). Say you have an open source project that is licensed under: GPL-2.0-or-later OR MIT
a) you want to incorporate this into your proprietary product, but your policy does not allow using any GPL code - then you will want to clarify that your distribution is under MIT.
b) You also may choose MIT even if you don't have a policy against GPL for the simple reason the MIT is "easier" to comply with.
b) you want to incorporate this into your open source project which is under Apache-2.0 - you choose MIT because of the FSF alleged incompatibility between Apache-2.0 and GPL-*
c) you have other code you are combining this with that is under GPL-3.0-only - so you choose GPL-3.0-only (because another choice here you had from upstream was GPL-2.0-or-later) because it's easier to comply with one/the same license for all your code and GPL-3.0 has better/more modern source code provision options
So, it matters to some, but I can't see any of these scenarios really applying here for Fedora (with the exception of the already stated Perl issue)
What it actually *means* for an intermediary to distribute upstream code under the upstream choice of licenses, with conditions that might simultaneously apply to that intermediary on either side of the disjunct, I'm not entirely sure, but in all normal practical scenarios it never really matters -- which is another reason for the "pass the choice on" practice. I'd rather copy the practices of upstream community projects than the practices of GPL-phobic companies downstream, basically.
I agree that it never really matters in all practical scenarios *when you are providing source code anyway*, as is our case here. It's more of an issue when you are distributing code in binary form only. Fortunately, that is not our ship :)
Jilayne
On Tue, Jan 04, 2022 at 09:05:59PM -0800, Jilayne Lovejoy wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
On Wed, Dec 29, 2021 at 11:46:44AM -0500, Richard Fontana wrote:
On Wed, Dec 29, 2021 at 11:22 AM Miroslav Suchý msuchy@redhat.com wrote:
I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad license
Then the result is Good license and the package is allowed to be in Fedora, right?
So first of all if I change your question to be about the actual underlying license terms of the package as opposed to the representation in the spec file, I believe the answer must be "yes" and there are probably a lot of examples of this in Fedora. (Think of any arbitrary package that says it's under some FOSS license and also says informally that proprietary licenses are also available.)
With the spec file, though, I believe there is an inconsistency in how Fedora deals with this, but this is just a casual impression. On the one hand, there is the common case of traditionally-licensed Perl modules (typically, a dual license involving unversioned GPL and a license identified as the Artistic License 1.0 [which I realize exists in multiple forms, but let's ignore that]). Fedora spec files for such Perl module packages generally say something like "GPL or Artistic", even though Fedora classifies the Artistic License as a "bad" license. I *think* there may be other examples, not involving Perl modules or the Artistic License, where the code is dual licensed under a good license and a bad license and the spec file only gives the good license. The only rationale I could come up with for the difference in approach is that the Artistic License, while "bad" from Fedora's perspective, is generally seen as plausibly-FOSS (it's an OSI-approved license, for one thing).
I think it comes down to whether Fedora wants to have spec files that say, for example, "GPL or Proprietary" much as it has spec files that say "GPL or Artistic".
It's true there is inconsistency regarding the License tag in the spec file. As the package maintainer and as part of the Fedora project, I would prefer that the License tag in the spec reflect the license terms that we are distributing the built package against. So in the case of Perl modules that are generally GPL or Artistic, the Fedora project is really redistributing them under the terms of the GPL only, right?
I think the answer to the inconsistency here is to set a policy relating to disjunctive licensed packages and then document that in the packaging guidelines. This would provide clarity for both package maintainers as well as downstream recipients. My recommendation would be that in the case where (random example):
The package license upstream is: AGPL-3.0-or-later OR SSPL-1.0
and where Fedora would not allow SSPL-1.0, then the License field in the spec file would simply indicate:
AGPL-3.0-or-later
If one really wants to be thorough and there is some kind of comment field in the Spec file (I think I've seen this?), then one could note something along the lines of "This package is licensed upstream as AGPL-3.0-or-later OR SSPL-1.0"
Yes, this is what I was thinking. And as Richard noted in a later followup, this has been the standard we've followed for a while--but I don't think we've actually written it down formally. We should do that.
Does it follow that we [Fedora] take an open source project that is dual licensed and use the license that is acceptable in our project and redistribute under those terms? Is that even a thing one can do? Given the "or" usage, my assumption is yes. The author is giving the downstream user the choice of using that work under the terms of the GPL or the terms of the Artistic license. In the case of Fedora, we've deemed Artistic undesirable which means our use of the modules is technically under the terms of the GPL.
Correct.
For me, I would prefer to see this reflected in the License tags in spec files so we can see how we're integrating components in to Fedora. If we note a license that we can't use or that we are not using, it makes it harder to see at a glance _what_ terms actually apply to that component. And that makes it harder for other packagers looking for license-compatible dependencies.
Agreed.
I realize this is yet another work project and also that I may be incorrect regarding what we can and can't do with regard to dual-licensed projects. If we are unable to say "we're using the Perl modules under the terms of the GPL" and exclude the Artistic license, then really the "or" boolean doesn't apply and it's really always "and".
I think you mean that there would not be a need for the "OR" operator in Fedora, but there are open source projects that may be licensed under a choice of two "good" Fedora licenses, in which case, it would make sense to simply pass downstream the choice of both, I would think.
Right, sorry for the confusion. What you said is actually what I meant.
So many licenses, so many questions....
:)
Jilayne
On 1/5/22 10:42 AM, David Cantrell wrote:
On Tue, Jan 04, 2022 at 09:05:59PM -0800, Jilayne Lovejoy wrote:
On 1/4/22 9:27 AM, David Cantrell wrote:
On Wed, Dec 29, 2021 at 11:46:44AM -0500, Richard Fontana wrote:
On Wed, Dec 29, 2021 at 11:22 AM Miroslav Suchý msuchy@redhat.com wrote:
I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad license
Then the result is Good license and the package is allowed to be in Fedora, right?
So first of all if I change your question to be about the actual underlying license terms of the package as opposed to the representation in the spec file, I believe the answer must be "yes" and there are probably a lot of examples of this in Fedora. (Think of any arbitrary package that says it's under some FOSS license and also says informally that proprietary licenses are also available.)
With the spec file, though, I believe there is an inconsistency in how Fedora deals with this, but this is just a casual impression. On the one hand, there is the common case of traditionally-licensed Perl modules (typically, a dual license involving unversioned GPL and a license identified as the Artistic License 1.0 [which I realize exists in multiple forms, but let's ignore that]). Fedora spec files for such Perl module packages generally say something like "GPL or Artistic", even though Fedora classifies the Artistic License as a "bad" license. I *think* there may be other examples, not involving Perl modules or the Artistic License, where the code is dual licensed under a good license and a bad license and the spec file only gives the good license. The only rationale I could come up with for the difference in approach is that the Artistic License, while "bad" from Fedora's perspective, is generally seen as plausibly-FOSS (it's an OSI-approved license, for one thing).
I think it comes down to whether Fedora wants to have spec files that say, for example, "GPL or Proprietary" much as it has spec files that say "GPL or Artistic".
It's true there is inconsistency regarding the License tag in the spec file. As the package maintainer and as part of the Fedora project, I would prefer that the License tag in the spec reflect the license terms that we are distributing the built package against. So in the case of Perl modules that are generally GPL or Artistic, the Fedora project is really redistributing them under the terms of the GPL only, right?
I think the answer to the inconsistency here is to set a policy relating to disjunctive licensed packages and then document that in the packaging guidelines. This would provide clarity for both package maintainers as well as downstream recipients. My recommendation would be that in the case where (random example):
The package license upstream is: AGPL-3.0-or-later OR SSPL-1.0
and where Fedora would not allow SSPL-1.0, then the License field in the spec file would simply indicate:
AGPL-3.0-or-later
If one really wants to be thorough and there is some kind of comment field in the Spec file (I think I've seen this?), then one could note something along the lines of "This package is licensed upstream as AGPL-3.0-or-later OR SSPL-1.0"
Yes, this is what I was thinking. And as Richard noted in a later followup, this has been the standard we've followed for a while--but I don't think we've actually written it down formally. We should do that.
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "*If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License:field must reflect this by using "OR" as a separator. " and *add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later "
How does that work in terms of making the guidelines for this case more explicit?
Jilayne
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. " and add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later
I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons:
First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.)
Second, and I think this is possibly the most important reason, in probably most cases of upstream Good License OR Bad License, the Bad license won't be in the SPDX list. What if the Bad license does not have a standard SPDX identifier -- would we want the packager to use a LicenseRef (after having gone to the trouble of verifying that the Bad license isn't on the SPDX list via the matching criterion)? The examples we've been talking about here - the "GPL or Artistic" classic case, or the "AGPL-3.0 OR SSPL-1.0" hypothetical -- are atypical because (certain versions of ) the Artistic License 1.0 are represented in the SPDX list as is SSPL version 1.0. If not LicenseRef, we surely wouldn't want to have the packager make up some arbitrary identifier (thus encouraging non-conformant SPDX-style license expression syntax). For example, we wouldn't want to have # Upstream license is GPL-2.0-or-later OR Proprietary. And certainly we wouldn't want to encourage the packager to waste time submitting a Bad license (already rejected by Fedora) to SPDX -- in most cases it likely wouldn't even meet SPDX inclusion criteria.
Third, I am not seeing why the information about a non-carried-over upstream dual license is valuable (to mandate or even encourage). At best I'd say it's sometimes *interesting* information, but not worth having the packager use LicenseRef or departing from SPDX expression syntax or whatever (see previous comment). If the only reason left is to avoid offending Perl modules maintainers upstream, that's limited to the special case of Perl modules and I don't think that's a good enough reason :) I'm also somewhat concerned about generalizing the principle here (meaning, either we have inconsistent guidelines or we make even more work for the packager). Consider upstream packages that have source files stripped from the source tarball because the license is "bad", or for which source files under a "good" license are not reflected in the binary RPM.
Richard
On Wed, Jan 12, 2022 at 12:17 AM Richard Fontana rfontana@redhat.com wrote:
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. " and add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later
I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons:
First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.)
Second, and I think this is possibly the most important reason, in probably most cases of upstream Good License OR Bad License, the Bad license won't be in the SPDX list. What if the Bad license does not have a standard SPDX identifier -- would we want the packager to use a LicenseRef (after having gone to the trouble of verifying that the Bad license isn't on the SPDX list via the matching criterion)? The examples we've been talking about here - the "GPL or Artistic" classic case, or the "AGPL-3.0 OR SSPL-1.0" hypothetical -- are atypical because (certain versions of ) the Artistic License 1.0 are represented in the SPDX list as is SSPL version 1.0. If not LicenseRef, we surely wouldn't want to have the packager make up some arbitrary identifier (thus encouraging non-conformant SPDX-style license expression syntax). For example, we wouldn't want to have # Upstream license is GPL-2.0-or-later OR Proprietary. And certainly we wouldn't want to encourage the packager to waste time submitting a Bad license (already rejected by Fedora) to SPDX -- in most cases it likely wouldn't even meet SPDX inclusion criteria.
Third, I am not seeing why the information about a non-carried-over upstream dual license is valuable (to mandate or even encourage). At best I'd say it's sometimes *interesting* information, but not worth having the packager use LicenseRef or departing from SPDX expression syntax or whatever (see previous comment). If the only reason left is to avoid offending Perl modules maintainers upstream, that's limited to the special case of Perl modules and I don't think that's a good enough reason :) I'm also somewhat concerned about generalizing the principle here (meaning, either we have inconsistent guidelines or we make even more work for the packager). Consider upstream packages that have source files stripped from the source tarball because the license is "bad", or for which source files under a "good" license are not reflected in the binary RPM.
Forgot to add: while I think situations where you can't (conveniently) use SPDX expressions will predominate in these cases, I also think that these situations are going to be relatively uncommon -- certainly outside the Perl case (which goes away if we decide the (?) Artistic License 1.0 is "good" which I think is reasonably possible at this point). So I think that also suggests not making this a requirement.
If the goal is to document the packager's judgment process, then there are a lot of other things the packager might be expected to comment on, depending on what philosophy of license description (if any) we want to specifically adopt. So we might end up with a requirement for comments in most cases, which is probably not going to be popular.
Richard
I think a few things got lost in translation - let me clarify. I also just went back and read this entire thread again, as I was only trying to reflect the things stated as either status quo (to then explicitly document) or clarification on things where there is sort of a status quo but may be some inconsistency (to take away inconsistency or questions for package maintainers). :)
On 1/11/22 9:17 PM, Richard Fontana wrote:
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. "
Note - this is a slight amendment to the current guidelines under the Dual Licensing section to explicitly state that if both licenses are "good" to pass along the choice which it seemed everyone on the thread agreed should be the case and is the common practice.
and add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Note - the Multiple Licensing Scenarios - https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... in the packaging guidelines requires a comment for these scenarios and gives some examples. So, I thought it would be consistent to use a similar approach in the "Good or Bad" dual licensing section and copied one of the examples of how to comment.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later
I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons:
See comment above
First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.)
I did not mean to imply that SPDX identifiers had to be used in the comment whatsoever, so we can simply change the example to something like the following (which would be consistent with other examples in the Multiple Licensing Scenarios examples):
# The upstream package license is: Affero General Public License v3 or later or Server Side Public License License: AGPL-3.0-or-later
or we could add another example like:
# The upstream package license is: GNU General Public License v2 or later or a commercial license License: GPL-2.0-or-later
I think we could also add the word "known" to the guideline so it reads:
"If your package is licensed under a _known_ choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice."
Point being that the package maintainer doesn't need to research the upstream licensing scenario deeply, but where it's known or obvious, then notate that for clarity.
Does that help?
Other posts on the mailing thread suggested a more complex notation in the actual License field, but that seems to risk breaking some checks or something (see David's response) and then runs into the problem you expressed re: using SPDX identifiers in the License: field. But if it's merely a comment, it's more flexible and yet the info if there for anyone who cares downstream or is wondering why the License field reflects just the one license and not the choice. Documenting this explicitly also sets expectations downstream as well that Fedora is not going to pass along the option to redistribute a package under a license considered "bad" by Fedora.
Jilayne
On Wed, Jan 12, 2022 at 12:22 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
I think a few things got lost in translation - let me clarify. I also just went back and read this entire thread again, as I was only trying to reflect the things stated as either status quo (to then explicitly document) or clarification on things where there is sort of a status quo but may be some inconsistency (to take away inconsistency or questions for package maintainers). :)
On 1/11/22 9:17 PM, Richard Fontana wrote:
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. "
Note - this is a slight amendment to the current guidelines under the Dual Licensing section to explicitly state that if both licenses are "good" to pass along the choice which it seemed everyone on the thread agreed should be the case and is the common practice.
and add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Note - the Multiple Licensing Scenarios - https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... in the packaging guidelines requires a comment for these scenarios and gives some examples. So, I thought it would be consistent to use a similar approach in the "Good or Bad" dual licensing section and copied one of the examples of how to comment.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later
I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons:
See comment above
First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.)
I did not mean to imply that SPDX identifiers had to be used in the comment whatsoever, so we can simply change the example to something like the following (which would be consistent with other examples in the Multiple Licensing Scenarios examples):
# The upstream package license is: Affero General Public License v3 or later or Server Side Public License License: AGPL-3.0-or-later
or we could add another example like:
# The upstream package license is: GNU General Public License v2 or later or a commercial license License: GPL-2.0-or-later
OK, so as to these examples -- I don't like the AGPL|SSPL one because it's not realistic (I don't believe it is known to have occurred in the real world, unlike the GPL|Artistic cases and so forth).
For the other example: If you change "commercial license" to "proprietary license" (there's a long history of semi-justifiable objections to the term "commercial license" as an antonym to open source/free software license in FOSS), the problem here is that it too is not necessarily a real world case of the sort we're talking about here. It is pretty common for purportedly-single-licensor GPL projects to say informally something like "If you find the GPL problematic, you can write to me for an alternative commercial [yes, they might say commercial] license". But historically Fedora has just paid no attention to that sort of statement for licensing purposes -- it's just background noise. (More worrisome might be such a statement coupled with a reinterpretation of the GPL, e.g. "If you want to use this project commercially, contact me for alternative licensing options". But this doesn't go to the problem of license description in the spec file at all, but rather whether the license is "really" the GPL.)
What we don't usually see is a project repository where you have LICENSE.GPL and LICENSE.PROPRIETARY, in a context suggesting that the operative terms are a disjunctive dual license consisting of the two. I believe this is sufficiently uncommon that we shouldn't worry about this case.
To put it another way, I can't think of any real-world disjunctive dual license involving a (likely) "bad" license other than the Perl module case (where of course it is really common). If it's so unusual, why should the guidelines address it at all? Or if the only likely example is the Perl one, then the guidelines should only use the Perl (GPL/Artistic) example.
I think we could also add the word "known" to the guideline so it reads:
"If your package is licensed under a _known_ choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice."
So thinking more about this, I think if we say anything about this, it should be specific to the Perl case, until someone encounters a counterexample.
We could say:
" If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only. This is highly uncommon in Fedora packages apart from the case of Perl modules dual licensed under the GPL and the Artistic License 1.0. In that case you must pick the appropriate identifier for the GPL side (which in Perl modules will typically map to SPDX "GPL-1.0-or-later"). You are encouraged to include a comment memorializing this, for example: # Upstream project is dual licensed GPL | Artistic 1.0 " (I can explain why I don't think SPDX identifiers should be used in the example comment.)
However, I don't see why we should go to all this trouble if it is reasonably likely that in the one case where this problem is known to occur it might go away by revisiting Fedora's classification of the Artistic License 1.0 (in its various forms) as "bad".
Other posts on the mailing thread suggested a more complex notation in the actual License field, but that seems to risk breaking some checks or something (see David's response) and then runs into the problem you expressed re: using SPDX identifiers in the License: field. But if it's merely a comment, it's more flexible and yet the info if there for anyone who cares downstream or is wondering why the License field reflects just the one license and not the choice.
One thing that bothers me is, this is creating a new requirement that didn't exist before. It didn't exist in the Perl module case because Perl modules got "special treatment".
The question is, who cares downstream? I don't think this matters to Red Hat, to take one Fedora downstream. I would be interested in knowing whether there are Fedora community members (including folks who might be at Red Hat) who would like there to be a requirement that spec files document probably-rare (outside of the Perl module case) situations where, by application of Fedora policy, an upstream dual license disjunct is not selected. If anyone is really that interested they should be analyzing the source code.
The source code of these packages will in most cases I can imagine still have all the information about the upstream dual license. For example, under the new rule, a Fedora Perl module package might have "License: GPL-1.0-or-later OR Artistic-1.0", but the source tarball in the source RPM, at least, will have a copy of the Artistic license or source file license notices that state the dual license or however the dual license is indicated upstream (let's ignore the actual common usage of the horrible "Licensed under the same terms as Perl itself"). So to the really curious person no information is lost. I don't think anyone has ever suggested that the "bad" license in these cases should be stripped out.
Documenting this explicitly also sets expectations downstream as well that Fedora is not going to pass along the option to redistribute a package under a license considered "bad" by Fedora.
We're already basically saying this -- even today, the only thing that is confusing is the "special treatment" given to Perl modules. It just doesn't seem important enough to mandate a new requirement. I just think these guidelines need to spring from and relate to real world scenarios.
I forget whether I said this in this thread, but if we require documentation for this case, why don't we require it for all cases in which the packager makes some simplification or reduction in complexity of the license expression. I am not sure we want to mandate that, though we might want to encourage it. My impression is very few spec files today contain comments of that sort.
Richard
With my packagers hat on, I'd like this to be as simple as me (or some scanner) going through the code and listing all the licenses which are then put into `License` tag. The rest can handle automation, e.g. are these licenses good and in right combination, what is effective Fedora license. I am not sure why I, as a packager, should be involved in decision if Artistic should be listed somewhere or not.
BTW reducing the license list or identifying good/bad licenses is much easier task then identifying the licenses in the source code. If we mostly trust the scanners today, then we should leave the remaining decisions to automation as well, because these are much simpler task then license identification.
Vít
Dne 13. 01. 22 v 4:37 Richard Fontana napsal(a):
On Wed, Jan 12, 2022 at 12:22 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
I think a few things got lost in translation - let me clarify. I also just went back and read this entire thread again, as I was only trying to reflect the things stated as either status quo (to then explicitly document) or clarification on things where there is sort of a status quo but may be some inconsistency (to take away inconsistency or questions for package maintainers). :)
On 1/11/22 9:17 PM, Richard Fontana wrote:
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. "
Note - this is a slight amendment to the current guidelines under the Dual Licensing section to explicitly state that if both licenses are "good" to pass along the choice which it seemed everyone on the thread agreed should be the case and is the common practice.
and add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Note - the Multiple Licensing Scenarios - https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... in the packaging guidelines requires a comment for these scenarios and gives some examples. So, I thought it would be consistent to use a similar approach in the "Good or Bad" dual licensing section and copied one of the examples of how to comment.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later
I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons:
See comment above
First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.)
I did not mean to imply that SPDX identifiers had to be used in the comment whatsoever, so we can simply change the example to something like the following (which would be consistent with other examples in the Multiple Licensing Scenarios examples):
# The upstream package license is: Affero General Public License v3 or later or Server Side Public License License: AGPL-3.0-or-later
or we could add another example like:
# The upstream package license is: GNU General Public License v2 or later or a commercial license License: GPL-2.0-or-later
OK, so as to these examples -- I don't like the AGPL|SSPL one because it's not realistic (I don't believe it is known to have occurred in the real world, unlike the GPL|Artistic cases and so forth).
For the other example: If you change "commercial license" to "proprietary license" (there's a long history of semi-justifiable objections to the term "commercial license" as an antonym to open source/free software license in FOSS), the problem here is that it too is not necessarily a real world case of the sort we're talking about here. It is pretty common for purportedly-single-licensor GPL projects to say informally something like "If you find the GPL problematic, you can write to me for an alternative commercial [yes, they might say commercial] license". But historically Fedora has just paid no attention to that sort of statement for licensing purposes -- it's just background noise. (More worrisome might be such a statement coupled with a reinterpretation of the GPL, e.g. "If you want to use this project commercially, contact me for alternative licensing options". But this doesn't go to the problem of license description in the spec file at all, but rather whether the license is "really" the GPL.)
What we don't usually see is a project repository where you have LICENSE.GPL and LICENSE.PROPRIETARY, in a context suggesting that the operative terms are a disjunctive dual license consisting of the two. I believe this is sufficiently uncommon that we shouldn't worry about this case.
To put it another way, I can't think of any real-world disjunctive dual license involving a (likely) "bad" license other than the Perl module case (where of course it is really common). If it's so unusual, why should the guidelines address it at all? Or if the only likely example is the Perl one, then the guidelines should only use the Perl (GPL/Artistic) example.
I think we could also add the word "known" to the guideline so it reads:
"If your package is licensed under a _known_ choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice."
So thinking more about this, I think if we say anything about this, it should be specific to the Perl case, until someone encounters a counterexample.
We could say:
" If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only. This is highly uncommon in Fedora packages apart from the case of Perl modules dual licensed under the GPL and the Artistic License 1.0. In that case you must pick the appropriate identifier for the GPL side (which in Perl modules will typically map to SPDX "GPL-1.0-or-later"). You are encouraged to include a comment memorializing this, for example: # Upstream project is dual licensed GPL | Artistic 1.0 " (I can explain why I don't think SPDX identifiers should be used in the example comment.)
However, I don't see why we should go to all this trouble if it is reasonably likely that in the one case where this problem is known to occur it might go away by revisiting Fedora's classification of the Artistic License 1.0 (in its various forms) as "bad".
Other posts on the mailing thread suggested a more complex notation in the actual License field, but that seems to risk breaking some checks or something (see David's response) and then runs into the problem you expressed re: using SPDX identifiers in the License: field. But if it's merely a comment, it's more flexible and yet the info if there for anyone who cares downstream or is wondering why the License field reflects just the one license and not the choice.
One thing that bothers me is, this is creating a new requirement that didn't exist before. It didn't exist in the Perl module case because Perl modules got "special treatment".
The question is, who cares downstream? I don't think this matters to Red Hat, to take one Fedora downstream. I would be interested in knowing whether there are Fedora community members (including folks who might be at Red Hat) who would like there to be a requirement that spec files document probably-rare (outside of the Perl module case) situations where, by application of Fedora policy, an upstream dual license disjunct is not selected. If anyone is really that interested they should be analyzing the source code.
The source code of these packages will in most cases I can imagine still have all the information about the upstream dual license. For example, under the new rule, a Fedora Perl module package might have "License: GPL-1.0-or-later OR Artistic-1.0", but the source tarball in the source RPM, at least, will have a copy of the Artistic license or source file license notices that state the dual license or however the dual license is indicated upstream (let's ignore the actual common usage of the horrible "Licensed under the same terms as Perl itself"). So to the really curious person no information is lost. I don't think anyone has ever suggested that the "bad" license in these cases should be stripped out.
Documenting this explicitly also sets expectations downstream as well that Fedora is not going to pass along the option to redistribute a package under a license considered "bad" by Fedora.
We're already basically saying this -- even today, the only thing that is confusing is the "special treatment" given to Perl modules. It just doesn't seem important enough to mandate a new requirement. I just think these guidelines need to spring from and relate to real world scenarios.
I forget whether I said this in this thread, but if we require documentation for this case, why don't we require it for all cases in which the packager makes some simplification or reduction in complexity of the license expression. I am not sure we want to mandate that, though we might want to encourage it. My impression is very few spec files today contain comments of that sort.
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
On Thu, Jan 13, 2022 at 8:56 AM Vít Ondruch vondruch@redhat.com wrote:
With my packagers hat on, I'd like this to be as simple as me (or some scanner) going through the code and listing all the licenses which are then put into `License` tag. The rest can handle automation, e.g. are these licenses good and in right combination, what is effective Fedora license. I am not sure why I, as a packager, should be involved in decision if Artistic should be listed somewhere or not.
BTW reducing the license list or identifying good/bad licenses is much easier task then identifying the licenses in the source code. If we mostly trust the scanners today, then we should leave the remaining decisions to automation as well, because these are much simpler task then license identification.
This is a very important issue which I think we need to tackle somehow. Jilayne has started this in her pull request by including a section providing guidance on how to determine the license applicable to a package, but I think this is sufficiently difficult and complex and contentious that I believe it should be addressed in a separate document which will require a lot of work to develop. Part of this is figuring out what we want the identifiers to signify and how much deviation from reality we want to tolerate. We really ought to start out figuring out this question and only then develop practical guidelines around it.
For example, existing Fedora guidance indicates that the License: tag should reflect the license of the appropriate binary (a very interesting convention which I've often thought is beneficial), which among other things implies that merely scanning source code will sometimes give "incorrect" results even if the scanner is somehow perfect.
Do we trust scanning tools? There are some tools (FOSS of course) I have some relatively decent confidence in as far as scanners go (ScanCode and FOSSology) although the only one I really ever used directly was ScanCode. Even ScanCode gets lots of things wrong, has spurious or unhelpful results, etc., and doesn't necessarily produce something easily translatable or representable as a compact SPDX expression. ScanCode is also not great at detecting bespoke likely-non-FOSS license texts.
We certainly could adopt a rule that the License: tag should be an SPDX expression representation of the "output of ScanCode" (configured in some particular way, say), despite the resultant inclusion of inaccurate or misleading information. (Inside Red Hat, we thought about this in a non-Fedora context.) We could dispense with the rules that make this difficult (such as the "binary license" rule). The resulting license tags would look a lot ... stranger than the ones Fedora has today, and would be in some ways less meaningful, but maybe that's okay. But I don't think even if we did this it would remove the need for the packager to do some level of analysis. How much analysis is desirable is a big question. Minimizing burdens on people doing packaging has to be an important consideration no matter where we end up.
Richard
Vít
Dne 13. 01. 22 v 4:37 Richard Fontana napsal(a):
On Wed, Jan 12, 2022 at 12:22 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
I think a few things got lost in translation - let me clarify. I also just went back and read this entire thread again, as I was only trying to reflect the things stated as either status quo (to then explicitly document) or clarification on things where there is sort of a status quo but may be some inconsistency (to take away inconsistency or questions for package maintainers). :)
On 1/11/22 9:17 PM, Richard Fontana wrote:
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. "
Note - this is a slight amendment to the current guidelines under the Dual Licensing section to explicitly state that if both licenses are "good" to pass along the choice which it seemed everyone on the thread agreed should be the case and is the common practice.
and add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Note - the Multiple Licensing Scenarios - https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... in the packaging guidelines requires a comment for these scenarios and gives some examples. So, I thought it would be consistent to use a similar approach in the "Good or Bad" dual licensing section and copied one of the examples of how to comment.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later
I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons:
See comment above
First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.)
I did not mean to imply that SPDX identifiers had to be used in the comment whatsoever, so we can simply change the example to something like the following (which would be consistent with other examples in the Multiple Licensing Scenarios examples):
# The upstream package license is: Affero General Public License v3 or later or Server Side Public License License: AGPL-3.0-or-later
or we could add another example like:
# The upstream package license is: GNU General Public License v2 or later or a commercial license License: GPL-2.0-or-later
OK, so as to these examples -- I don't like the AGPL|SSPL one because it's not realistic (I don't believe it is known to have occurred in the real world, unlike the GPL|Artistic cases and so forth).
For the other example: If you change "commercial license" to "proprietary license" (there's a long history of semi-justifiable objections to the term "commercial license" as an antonym to open source/free software license in FOSS), the problem here is that it too is not necessarily a real world case of the sort we're talking about here. It is pretty common for purportedly-single-licensor GPL projects to say informally something like "If you find the GPL problematic, you can write to me for an alternative commercial [yes, they might say commercial] license". But historically Fedora has just paid no attention to that sort of statement for licensing purposes -- it's just background noise. (More worrisome might be such a statement coupled with a reinterpretation of the GPL, e.g. "If you want to use this project commercially, contact me for alternative licensing options". But this doesn't go to the problem of license description in the spec file at all, but rather whether the license is "really" the GPL.)
What we don't usually see is a project repository where you have LICENSE.GPL and LICENSE.PROPRIETARY, in a context suggesting that the operative terms are a disjunctive dual license consisting of the two. I believe this is sufficiently uncommon that we shouldn't worry about this case.
To put it another way, I can't think of any real-world disjunctive dual license involving a (likely) "bad" license other than the Perl module case (where of course it is really common). If it's so unusual, why should the guidelines address it at all? Or if the only likely example is the Perl one, then the guidelines should only use the Perl (GPL/Artistic) example.
I think we could also add the word "known" to the guideline so it reads:
"If your package is licensed under a _known_ choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice."
So thinking more about this, I think if we say anything about this, it should be specific to the Perl case, until someone encounters a counterexample.
We could say:
" If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only. This is highly uncommon in Fedora packages apart from the case of Perl modules dual licensed under the GPL and the Artistic License 1.0. In that case you must pick the appropriate identifier for the GPL side (which in Perl modules will typically map to SPDX "GPL-1.0-or-later"). You are encouraged to include a comment memorializing this, for example: # Upstream project is dual licensed GPL | Artistic 1.0 " (I can explain why I don't think SPDX identifiers should be used in the example comment.)
However, I don't see why we should go to all this trouble if it is reasonably likely that in the one case where this problem is known to occur it might go away by revisiting Fedora's classification of the Artistic License 1.0 (in its various forms) as "bad".
Other posts on the mailing thread suggested a more complex notation in the actual License field, but that seems to risk breaking some checks or something (see David's response) and then runs into the problem you expressed re: using SPDX identifiers in the License: field. But if it's merely a comment, it's more flexible and yet the info if there for anyone who cares downstream or is wondering why the License field reflects just the one license and not the choice.
One thing that bothers me is, this is creating a new requirement that didn't exist before. It didn't exist in the Perl module case because Perl modules got "special treatment".
The question is, who cares downstream? I don't think this matters to Red Hat, to take one Fedora downstream. I would be interested in knowing whether there are Fedora community members (including folks who might be at Red Hat) who would like there to be a requirement that spec files document probably-rare (outside of the Perl module case) situations where, by application of Fedora policy, an upstream dual license disjunct is not selected. If anyone is really that interested they should be analyzing the source code.
The source code of these packages will in most cases I can imagine still have all the information about the upstream dual license. For example, under the new rule, a Fedora Perl module package might have "License: GPL-1.0-or-later OR Artistic-1.0", but the source tarball in the source RPM, at least, will have a copy of the Artistic license or source file license notices that state the dual license or however the dual license is indicated upstream (let's ignore the actual common usage of the horrible "Licensed under the same terms as Perl itself"). So to the really curious person no information is lost. I don't think anyone has ever suggested that the "bad" license in these cases should be stripped out.
Documenting this explicitly also sets expectations downstream as well that Fedora is not going to pass along the option to redistribute a package under a license considered "bad" by Fedora.
We're already basically saying this -- even today, the only thing that is confusing is the "special treatment" given to Perl modules. It just doesn't seem important enough to mandate a new requirement. I just think these guidelines need to spring from and relate to real world scenarios.
I forget whether I said this in this thread, but if we require documentation for this case, why don't we require it for all cases in which the packager makes some simplification or reduction in complexity of the license expression. I am not sure we want to mandate that, though we might want to encourage it. My impression is very few spec files today contain comments of that sort.
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
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
--
On 1/13/22 2:59 PM, Richard Fontana wrote:
On Thu, Jan 13, 2022 at 8:56 AM Vít Ondruch vondruch@redhat.com wrote:
With my packagers hat on, I'd like this to be as simple as me (or some scanner) going through the code and listing all the licenses which are then put into `License` tag. The rest can handle automation, e.g. are these licenses good and in right combination, what is effective Fedora license. I am not sure why I, as a packager, should be involved in decision if Artistic should be listed somewhere or not.
so, are you saying you'd like to use a license scanner (e.g., ScanCode or FOSSology) to scan a proposed new package for Fedora and then have those results checked against the "good" list and then generate the License tag? This sounds like something that would require some additional tooling to be written to take the FOSSology results and compare them against the Fedora-license data, right?
BTW reducing the license list or identifying good/bad licenses is much easier task then identifying the licenses in the source code. If we mostly trust the scanners today, then we should leave the remaining decisions to automation as well, because these are much simpler task then license identification.
This is a very important issue which I think we need to tackle somehow. Jilayne has started this in her pull request by including a section providing guidance on how to determine the license applicable to a package,
My start to this was a bit less sophisticated than what I think Vit is intending. I was merely trying to address a more manual situation where, for example: package maintainer looks at LICENSE file for package, license text *looks* like BSD-3-Clause, but instead of trusting a visual inspection, the package maintainer could use - for example, the SPDX license-diff to see if the license actually matched something on the SPDX License List and then that info could be used to search the Fedora Good licenses.
I think (see above) that Vit is suggesting a more thorough and advance analysis.
but I think this is sufficiently difficult and complex and contentious that I believe it should be addressed in a separate document which will require a lot of work to develop.
yes, will move it out of the PR once we have the new location to put it. Then we can iterate from there, as needed.
Part of this is figuring out what we want the identifiers to signify and how much deviation from reality we want to tolerate. We really ought to start out figuring out this question and only then develop practical guidelines around it.
For example, existing Fedora guidance indicates that the License: tag should reflect the license of the appropriate binary (a very interesting convention which I've often thought is beneficial), which among other things implies that merely scanning source code will sometimes give "incorrect" results even if the scanner is somehow perfect.
The Fedora policy of license-reflects-binary is indeed a monkey wrench in using a license scanner to scan the source code. Would it be possible to change the question or analysis instead to: the License: tag should reflect the license for the code (whatever format, source or binary) that is actually distributed in Fedora. ??
Do we trust scanning tools? There are some tools (FOSS of course) I have some relatively decent confidence in as far as scanners go (ScanCode and FOSSology) although the only one I really ever used directly was ScanCode. Even ScanCode gets lots of things wrong, has spurious or unhelpful results, etc., and doesn't necessarily produce something easily translatable or representable as a compact SPDX expression. ScanCode is also not great at detecting bespoke likely-non-FOSS license texts.
I have not really used ScanCode and have more familiarity (even if a bit outdated) with FOSSology. It is true that many scanner results require some amount of "reconciliation" as I call it - that is, manually inspecting results that are ambiguous in some way. Often, there is an easily human-identifiable "answer", but it still requires some looking. That being said, if some/most package maintainers are actually looking at all the files in a more manual way, using a scanner would be a big improvement over that. FOSSology, and I believe ScanCode both have the capability to output scan results in various formats, including an SPDX document. This is not necessary for Fedora or the spec file, but... there is an SPDX specification field that sort of corresponds to the data that is used for the License: field in the spec file. https://spdx.github.io/spdx-spec/package-information/#714-all-licenses-infor... Only issue is that the All-License-Information-from-files-field does not differentiate on license expressions (disjunctive, conjunctive) so it's just a flat list. Hmmm...
We certainly could adopt a rule that the License: tag should be an SPDX expression representation of the "output of ScanCode" (configured in some particular way, say), despite the resultant inclusion of inaccurate or misleading information. (Inside Red Hat, we thought about this in a non-Fedora context.) We could dispense with the rules that make this difficult (such as the "binary license" rule). The resulting license tags would look a lot ... stranger than the ones Fedora has today, and would be in some ways less meaningful, but maybe that's okay. But I don't think even if we did this it would remove the need for the packager to do some level of analysis. How much analysis is desirable is a big question. Minimizing burdens on people doing packaging has to be an important consideration no matter where we end up.
Agreed.
To answer the question as to how much analysis and the burdens - I'd be interested to hear examples of how and to what extent package maintainers are doing this analysis currently? I imagine it being a wide range of answers, but I really don't have any idea. Maybe we could set up a poll?
Jilayne
Richard
Vít
Dne 13. 01. 22 v 4:37 Richard Fontana napsal(a):
On Wed, Jan 12, 2022 at 12:22 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
I think a few things got lost in translation - let me clarify. I also just went back and read this entire thread again, as I was only trying to reflect the things stated as either status quo (to then explicitly document) or clarification on things where there is sort of a status quo but may be some inconsistency (to take away inconsistency or questions for package maintainers). :)
On 1/11/22 9:17 PM, Richard Fontana wrote:
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. "
Note - this is a slight amendment to the current guidelines under the Dual Licensing section to explicitly state that if both licenses are "good" to pass along the choice which it seemed everyone on the thread agreed should be the case and is the common practice.
and add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Note - the Multiple Licensing Scenarios - https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... in the packaging guidelines requires a comment for these scenarios and gives some examples. So, I thought it would be consistent to use a similar approach in the "Good or Bad" dual licensing section and copied one of the examples of how to comment.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later
I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons:
See comment above
First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.)
I did not mean to imply that SPDX identifiers had to be used in the comment whatsoever, so we can simply change the example to something like the following (which would be consistent with other examples in the Multiple Licensing Scenarios examples):
# The upstream package license is: Affero General Public License v3 or later or Server Side Public License License: AGPL-3.0-or-later
or we could add another example like:
# The upstream package license is: GNU General Public License v2 or later or a commercial license License: GPL-2.0-or-later
OK, so as to these examples -- I don't like the AGPL|SSPL one because it's not realistic (I don't believe it is known to have occurred in the real world, unlike the GPL|Artistic cases and so forth).
For the other example: If you change "commercial license" to "proprietary license" (there's a long history of semi-justifiable objections to the term "commercial license" as an antonym to open source/free software license in FOSS), the problem here is that it too is not necessarily a real world case of the sort we're talking about here. It is pretty common for purportedly-single-licensor GPL projects to say informally something like "If you find the GPL problematic, you can write to me for an alternative commercial [yes, they might say commercial] license". But historically Fedora has just paid no attention to that sort of statement for licensing purposes -- it's just background noise. (More worrisome might be such a statement coupled with a reinterpretation of the GPL, e.g. "If you want to use this project commercially, contact me for alternative licensing options". But this doesn't go to the problem of license description in the spec file at all, but rather whether the license is "really" the GPL.)
What we don't usually see is a project repository where you have LICENSE.GPL and LICENSE.PROPRIETARY, in a context suggesting that the operative terms are a disjunctive dual license consisting of the two. I believe this is sufficiently uncommon that we shouldn't worry about this case.
To put it another way, I can't think of any real-world disjunctive dual license involving a (likely) "bad" license other than the Perl module case (where of course it is really common). If it's so unusual, why should the guidelines address it at all? Or if the only likely example is the Perl one, then the guidelines should only use the Perl (GPL/Artistic) example.
I think we could also add the word "known" to the guideline so it reads:
"If your package is licensed under a _known_ choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice."
So thinking more about this, I think if we say anything about this, it should be specific to the Perl case, until someone encounters a counterexample.
We could say:
" If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only. This is highly uncommon in Fedora packages apart from the case of Perl modules dual licensed under the GPL and the Artistic License 1.0. In that case you must pick the appropriate identifier for the GPL side (which in Perl modules will typically map to SPDX "GPL-1.0-or-later"). You are encouraged to include a comment memorializing this, for example: # Upstream project is dual licensed GPL | Artistic 1.0 " (I can explain why I don't think SPDX identifiers should be used in the example comment.)
However, I don't see why we should go to all this trouble if it is reasonably likely that in the one case where this problem is known to occur it might go away by revisiting Fedora's classification of the Artistic License 1.0 (in its various forms) as "bad".
Other posts on the mailing thread suggested a more complex notation in the actual License field, but that seems to risk breaking some checks or something (see David's response) and then runs into the problem you expressed re: using SPDX identifiers in the License: field. But if it's merely a comment, it's more flexible and yet the info if there for anyone who cares downstream or is wondering why the License field reflects just the one license and not the choice.
One thing that bothers me is, this is creating a new requirement that didn't exist before. It didn't exist in the Perl module case because Perl modules got "special treatment".
The question is, who cares downstream? I don't think this matters to Red Hat, to take one Fedora downstream. I would be interested in knowing whether there are Fedora community members (including folks who might be at Red Hat) who would like there to be a requirement that spec files document probably-rare (outside of the Perl module case) situations where, by application of Fedora policy, an upstream dual license disjunct is not selected. If anyone is really that interested they should be analyzing the source code.
The source code of these packages will in most cases I can imagine still have all the information about the upstream dual license. For example, under the new rule, a Fedora Perl module package might have "License: GPL-1.0-or-later OR Artistic-1.0", but the source tarball in the source RPM, at least, will have a copy of the Artistic license or source file license notices that state the dual license or however the dual license is indicated upstream (let's ignore the actual common usage of the horrible "Licensed under the same terms as Perl itself"). So to the really curious person no information is lost. I don't think anyone has ever suggested that the "bad" license in these cases should be stripped out.
Documenting this explicitly also sets expectations downstream as well that Fedora is not going to pass along the option to redistribute a package under a license considered "bad" by Fedora.
We're already basically saying this -- even today, the only thing that is confusing is the "special treatment" given to Perl modules. It just doesn't seem important enough to mandate a new requirement. I just think these guidelines need to spring from and relate to real world scenarios.
I forget whether I said this in this thread, but if we require documentation for this case, why don't we require it for all cases in which the packager makes some simplification or reduction in complexity of the license expression. I am not sure we want to mandate that, though we might want to encourage it. My impression is very few spec files today contain comments of that sort.
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
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
-- _______________________________________________ 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
On Tue, Jan 18, 2022 at 10:42 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Part of this is figuring out what we want the identifiers to signify and how much deviation from reality we want to tolerate. We really ought to start out figuring out this question and only then develop practical guidelines around it.
For example, existing Fedora guidance indicates that the License: tag should reflect the license of the appropriate binary (a very interesting convention which I've often thought is beneficial), which among other things implies that merely scanning source code will sometimes give "incorrect" results even if the scanner is somehow perfect.
The Fedora policy of license-reflects-binary is indeed a monkey wrench in using a license scanner to scan the source code. Would it be possible to change the question or analysis instead to: the License: tag should reflect the license for the code (whatever format, source or binary) that is actually distributed in Fedora. ??
To be clear, Fedora has "binary RPMs" and corresponding "source RPMs". The binary RPM, the thing you install on your system so that you can run some executable or library or whatever, is built from the source code that ends up being packaged in the source RPM. The binary RPM doesn't necessarily contain any object code, though usually it does, and might have source files. So that's one thing. I think the policy doesn't refer to binary (object) code per se but rather attempting to describe the licensing of all the code distributed in a binary/installable RPM, which implies some extra degree of legal analysis you wouldn't need to undertake if you are just looking at, say, a source repository or the equivalent in a package format. Fedora distributes both things (though normally when you install a package you are not also getting a copy of the source RPM).
A couple of issues here:
One is that the corresponding source tarball will (depending on the technology) very often have files under a larger set of licenses than what's in the binary. The upshot is that lots of packages in Fedora that might just say "MIT" today (and let's assume for sake of argument that Callaway™ MIT is SPDX MIT in all these cases) would have to say something like "MIT AND GPL-2.0-or-later AND GPL-2.0-or-later WITH Autoconf-exception-2.0 AND FSFAP AND FSFULLR". That's certainly going to be in the set of stuff FOSSology and ScanCode will tell you are there. So one question is whether it is useful to have that rather complex SPDX expression, particularly if some of it concerns stuff that the user will never have on their system anyway. And these are cases where we can say the software is normally thought of as being "not GPL".
The other thing is that the binary rule means that you can have spec files that have different License: tags for different subpackages. A common case in Linux distros is to have a (source) package associated with multiple binary packages that might be under different licenses (based on analysis of compilation of the binaries), so for example one subpackage might be built from GPL version 2 code and another might be built from LGPL version 2.1 code. And that distinction might actually be useful for some users. (In reality, though, I think the fidelity to this approach to license description varies widely across Fedora packages, which might signify that it's actually too complex to be consistently workable.) If you switch to a pure source code-oriented license description standard, you necessarily lose that type of information, since the LGPL library and the GPL daemon or utility or whatever are built from the same source code, which will be a mix of GPL and LGPL. So you'd end up with a single License tag, say "GPL-2.0-or-later AND LGPL-2.1-or-later" (or, actually, "GPL-2.0-or-later AND LGPL-2.1-or-later AND GPL-2.0-or-later WITH Autoconf-exception-2.0 ..." etc.) instead of two License tags, where the main package might be GPL-2.0-or-later and the library subpackage might be LGPL-2.1-or-later.
(BTW I am not a Fedora packager nor do I play one on TV so I welcome any corrections to misstatements in the above. :-)
I have not really used ScanCode and have more familiarity (even if a bit outdated) with FOSSology. It is true that many scanner results require some amount of "reconciliation" as I call it - that is, manually inspecting results that are ambiguous in some way. Often, there is an easily human-identifiable "answer", but it still requires some looking. That being said, if some/most package maintainers are actually looking at all the files in a more manual way, using a scanner would be a big improvement over that. FOSSology, and I believe ScanCode both have the capability to output scan results in various formats, including an SPDX document.
A dilemma here is that using scanners, at least the kind that give the best results, is kind of a burden. It is worth bearing in mind that scanners, including the open source ones, have been developed mainly for internal use by specialized personnel within companies and the use of scanners by open source projects is pretty limited. I don't think we can expect Fedora packagers to try to get a FOSSology instance running and to figure out how to use it once they do (basing this on personal experience). Even ScanCode might be a bit challenging to work with. Simpler tools however might give suboptimal results. I can imagine Fedora running a scanner-as-a-service (do any other community distros do this?) -- maybe even something like an instance of ClearlyDefined -- but that is probably farfetched.
Richard
Dne 19. 01. 22 v 4:42 Jilayne Lovejoy napsal(a):
On 1/13/22 2:59 PM, Richard Fontana wrote:
On Thu, Jan 13, 2022 at 8:56 AM Vít Ondruch vondruch@redhat.com wrote:
With my packagers hat on, I'd like this to be as simple as me (or some scanner) going through the code and listing all the licenses which are then put into `License` tag. The rest can handle automation, e.g. are these licenses good and in right combination, what is effective Fedora license. I am not sure why I, as a packager, should be involved in decision if Artistic should be listed somewhere or not.
so, are you saying you'd like to use a license scanner (e.g., ScanCode or FOSSology) to scan a proposed new package for Fedora and then have those results checked against the "good" list and then generate the License tag? This sounds like something that would require some additional tooling to be written to take the FOSSology results and compare them against the Fedora-license data, right?
All I wanted to say is that determining SW license is not always easy for packager. For my packages, I typically check for the licenses in following places:
1) Metadata
2) License files
3) Readme
4) License scanner (typically licensecheck, because it is easy a straight forward).
5) Skimming through the code.
This should give me reasonable list of licenses. This is the nontrivial part.
But from here, it should be quite easy to proceed with some tool. Therefore if I put something fishy into license tag, the build would not be allowed to proceed.
For a packager, if Artistic is allowed/listed or not, it should not be any concern as long as the build passes. Or is there SSPL listed and build fails, then the package should be finally concerned why it fails.
IOW, at this stage, we should not discuss if Artistic should be listed in `License` tag or not. If it was Ok up to day, then it will be Ok for foreseeable future, with SPDX identifiers or not. Should it be reassessed? Probably, but not sooner prior we can validate the `License` tag content.
Vít
On 1/12/22 7:37 PM, Richard Fontana wrote:
On Wed, Jan 12, 2022 at 12:22 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
I think a few things got lost in translation - let me clarify. I also just went back and read this entire thread again, as I was only trying to reflect the things stated as either status quo (to then explicitly document) or clarification on things where there is sort of a status quo but may be some inconsistency (to take away inconsistency or questions for package maintainers). :)
On 1/11/22 9:17 PM, Richard Fontana wrote:
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142
In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. "
Note - this is a slight amendment to the current guidelines under the Dual Licensing section to explicitly state that if both licenses are "good" to pass along the choice which it seemed everyone on the thread agreed should be the case and is the common practice.
and add the following to the Dual Licensing section:
"If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice.
Note - the Multiple Licensing Scenarios - https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... in the packaging guidelines requires a comment for these scenarios and gives some examples. So, I thought it would be consistent to use a similar approach in the "Good or Bad" dual licensing section and copied one of the examples of how to comment.
Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows:
# The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 License: AGPL-3.0-or-later
I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons:
See comment above
First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.)
I did not mean to imply that SPDX identifiers had to be used in the comment whatsoever, so we can simply change the example to something like the following (which would be consistent with other examples in the Multiple Licensing Scenarios examples):
# The upstream package license is: Affero General Public License v3 or later or Server Side Public License License: AGPL-3.0-or-later
or we could add another example like:
# The upstream package license is: GNU General Public License v2 or later or a commercial license License: GPL-2.0-or-later
OK, so as to these examples -- I don't like the AGPL|SSPL one because it's not realistic (I don't believe it is known to have occurred in the real world, unlike the GPL|Artistic cases and so forth).
For the other example: If you change "commercial license" to "proprietary license" (there's a long history of semi-justifiable objections to the term "commercial license" as an antonym to open source/free software license in FOSS),
we can use whatever example and wording makes sense. It is just an illustrative example akin to the similar documentation in that section.
the problem here is that it too is not necessarily a real world case of the sort we're talking about here. It is pretty common for purportedly-single-licensor GPL projects to say informally something like "If you find the GPL problematic, you can write to me for an alternative commercial [yes, they might say commercial] license". But historically Fedora has just paid no attention to that sort of statement for licensing purposes -- it's just background noise. (More worrisome might be such a statement coupled with a reinterpretation of the GPL, e.g. "If you want to use this project commercially, contact me for alternative licensing options". But this doesn't go to the problem of license description in the spec file at all, but rather whether the license is "really" the GPL.)
What we don't usually see is a project repository where you have LICENSE.GPL and LICENSE.PROPRIETARY, in a context suggesting that the operative terms are a disjunctive dual license consisting of the two. I believe this is sufficiently uncommon that we shouldn't worry about this case.
To put it another way, I can't think of any real-world disjunctive dual license involving a (likely) "bad" license other than the Perl module case (where of course it is really common). If it's so unusual, why should the guidelines address it at all? Or if the only likely example is the Perl one, then the guidelines should only use the Perl (GPL/Artistic) example.
well, as Miroslav began this thread asking about the scenario of having a Good or Bad license (and didn't seem to indicate it was specifically the Perl example - I assumed Fedora packagers are coming across such scenarios.
I think we could also add the word "known" to the guideline so it reads:
"If your package is licensed under a _known_ choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice."
So thinking more about this, I think if we say anything about this, it should be specific to the Perl case, until someone encounters a counterexample.
on the other hand... if we are contemplating re-reviewing the categorization of the (various versions of ) Artistic License (which I support) then perhaps we simplify what you have below to:
We could say:
" If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only. You are encouraged to include a comment memorializing this, for example: # Upstream project is dual licensed GPL | Artistic 1.0 " (I can explain why I don't think SPDX identifiers should be used in the example comment.)
you don't need to explain that - I get it and I never intended that they should be used there (if someone wanted to where it worked, fine, but generally I think of a comment as being more "human readable" in any case. It is the License: field that needs to be machine parsable.)
However, I don't see why we should go to all this trouble if it is reasonably likely that in the one case where this problem is known to occur it might go away by revisiting Fedora's classification of the Artistic License 1.0 (in its various forms) as "bad".
It was a question on this mailing list that started this thread and there was some support to documenting the answer to the question. At a minimum, stating explicitly that where one has a "Good or Good" - the License: field should capture that and if it's "Good or Bad" the License field should include only the Good license. That seemed to be common practice by all I could deduce from the entire thread. I can't see how at least capturing that is controversial?
Jilayne
On Thu, Jan 13, 2022 at 6:00 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
well, as Miroslav began this thread asking about the scenario of having a Good or Bad license (and didn't seem to indicate it was specifically the Perl example - I assumed Fedora packagers are coming across such scenarios.
I guess I don't really know for sure. My intuition is that it's not going to be common because while disjunctive dual (and triple, etc.) licenses are common in FOSS projects usually all the licenses are clearly FOSS. In the Fedora context I don't think I know of a good|bad example other than the GPL/Artistic cases. A team at Red Hat has been using ScanCode to scan RHEL packages and I see the results of these; I think there may have been one or two "good|bad" cases outside the Perl module cases. So I think it's probably really rare.
(Conjunctive multiple licenses -- "Good AND Bad" -- is going to be a much more common situation.)
However, I don't see why we should go to all this trouble if it is reasonably likely that in the one case where this problem is known to occur it might go away by revisiting Fedora's classification of the Artistic License 1.0 (in its various forms) as "bad".
It was a question on this mailing list that started this thread and there was some support to documenting the answer to the question. At a minimum, stating explicitly that where one has a "Good or Good" - the License: field should capture that and if it's "Good or Bad" the License field should include only the Good license. That seemed to be common practice by all I could deduce from the entire thread. I can't see how at least capturing that is controversial?
I totally agree with the suggestion that "Good or Bad" should be represented in the license tag as just "Good". Sorry if it seemed I was saying otherwise. The only thing I'm really objecting to is imposing a new commenting requirement that didn't exist before (I think especially if the triggering event is going to be really uncommon).
Richard
-
On 1/13/22 3:33 PM, Richard Fontana wrote:
On Thu, Jan 13, 2022 at 6:00 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
well, as Miroslav began this thread asking about the scenario of having a Good or Bad license (and didn't seem to indicate it was specifically the Perl example - I assumed Fedora packagers are coming across such scenarios.
I guess I don't really know for sure. My intuition is that it's not going to be common because while disjunctive dual (and triple, etc.) licenses are common in FOSS projects usually all the licenses are clearly FOSS. In the Fedora context I don't think I know of a good|bad example other than the GPL/Artistic cases. A team at Red Hat has been using ScanCode to scan RHEL packages and I see the results of these; I think there may have been one or two "good|bad" cases outside the Perl module cases. So I think it's probably really rare.
Fair enough. I was hoping Miroslav might enlighten us with the context of what prompted his question to begin with, but at this point our banter may have bored everyone else to tears ;-p
(Conjunctive multiple licenses -- "Good AND Bad" -- is going to be a much more common situation.)
However, I don't see why we should go to all this trouble if it is reasonably likely that in the one case where this problem is known to occur it might go away by revisiting Fedora's classification of the Artistic License 1.0 (in its various forms) as "bad".
It was a question on this mailing list that started this thread and there was some support to documenting the answer to the question. At a minimum, stating explicitly that where one has a "Good or Good" - the License: field should capture that and if it's "Good or Bad" the License field should include only the Good license. That seemed to be common practice by all I could deduce from the entire thread. I can't see how at least capturing that is controversial?
I totally agree with the suggestion that "Good or Bad" should be represented in the license tag as just "Good". Sorry if it seemed I was saying otherwise. The only thing I'm really objecting to is imposing a new commenting requirement that didn't exist before (I think especially if the triggering event is going to be really uncommon).
Gotcha. Here's where I think we've ended up in terms of proposing some revised text for the package guidelines, let me know if you agree and would be good to get some package maintainers input as well!
*** Dual Licensing Scenarios If your package is licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. Note that this only applies when the contents of the package are actually under a dual license, and not when the package contains items under multiple, distinct, and independent licenses.
Example: Package libfoo is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later. The package spec must have:
License: MPL-1.1 OR GPL-2.0-or-later
If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only. You are encouraged to include a comment memorializing the upstream licensing choice.
***
I took out the example altogether. At this point, I'm thinking it's not really necessary?
Jilayne
On Thu, Jan 13, 2022 at 10:24 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Gotcha. Here's where I think we've ended up in terms of proposing some revised text for the package guidelines, let me know if you agree and would be good to get some package maintainers input as well!
Dual Licensing Scenarios If your package is licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. Note that this only applies when the contents of the package are actually under a dual license, and not when the package contains items under multiple, distinct, and independent licenses.
Example: Package libfoo is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later. The package spec must have:
License: MPL-1.1 OR GPL-2.0-or-later
If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only. You are encouraged to include a comment memorializing the upstream licensing choice.
I took out the example altogether. At this point, I'm thinking it's not really necessary?
I think this looks OK, without the good|bad example. But agreed that it would be good to get feedback from people actually involved in Fedora packaging. For example, I wonder if this statement is hard to understand for people not sufficiently steeped in FOSS licensing:
"Note that this only applies when the contents of the package are actually under a dual license, and not when the package contains items under multiple, distinct, and independent licenses."
In many cases (I'm guessing more typically) a notated dual license will be part of a larger expression (i.e. the dual license will cover only a part of the code that makes up the package). I don't know if it's important to say anything about that. I'd ultimately like to see (maybe in some other document) some real world examples (involving real Fedora packages!) to illustrate the kinds of general guidelines being given here.
Richard
On 1/13/22 8:16 PM, Richard Fontana wrote:
On Thu, Jan 13, 2022 at 10:24 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Gotcha. Here's where I think we've ended up in terms of proposing some revised text for the package guidelines, let me know if you agree and would be good to get some package maintainers input as well!
Dual Licensing Scenarios If your package is licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. Note that this only applies when the contents of the package are actually under a dual license, and not when the package contains items under multiple, distinct, and independent licenses.
Example: Package libfoo is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later. The package spec must have:
License: MPL-1.1 OR GPL-2.0-or-later
If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only. You are encouraged to include a comment memorializing the upstream licensing choice.
I took out the example altogether. At this point, I'm thinking it's not really necessary?
I think this looks OK, without the good|bad example. But agreed that it would be good to get feedback from people actually involved in Fedora packaging. For example, I wonder if this statement is hard to understand for people not sufficiently steeped in FOSS licensing:
"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."
That sentence has been there all along and the next section is "Multiple Licensing Scenarios" see https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
I thought about adding a parenthetical of "see further info below" but since it's the very next section, that seemed maybe too obvious.
In many cases (I'm guessing more typically) a notated dual license will be part of a larger expression (i.e. the dual license will cover only a part of the code that makes up the package). I don't know if it's important to say anything about that. I'd ultimately like to see (maybe in some other document) some real world examples (involving real Fedora packages!) to illustrate the kinds of general guidelines being given here.
There is also the section on "Combined Dual and Multiple Licensing Scenario" and some examples. (realizing that I now know all these sections maybe a bit too well, which may be the result of trying to edit stuff in the Pagure GUI text editor - not that I'm inviting a tangent discussion on that topic! But it does require a certain amount of "attention")
;) Jilayne
Dne 14. 01. 22 v 4:24 Jilayne Lovejoy napsal(a):
On 1/13/22 3:33 PM, Richard Fontana wrote:
On Thu, Jan 13, 2022 at 6:00 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
well, as Miroslav began this thread asking about the scenario of having a Good or Bad license (and didn't seem to indicate it was specifically the Perl example - I assumed Fedora packagers are coming across such scenarios.
I guess I don't really know for sure. My intuition is that it's not going to be common because while disjunctive dual (and triple, etc.) licenses are common in FOSS projects usually all the licenses are clearly FOSS. In the Fedora context I don't think I know of a good|bad example other than the GPL/Artistic cases. A team at Red Hat has been using ScanCode to scan RHEL packages and I see the results of these; I think there may have been one or two "good|bad" cases outside the Perl module cases. So I think it's probably really rare.
Fair enough. I was hoping Miroslav might enlighten us with the context of what prompted his question to begin with, but at this point our banter may have bored everyone else to tears ;-p
(Conjunctive multiple licenses -- "Good AND Bad" -- is going to be a much more common situation.)
However, I don't see why we should go to all this trouble if it is reasonably likely that in the one case where this problem is known to occur it might go away by revisiting Fedora's classification of the Artistic License 1.0 (in its various forms) as "bad".
It was a question on this mailing list that started this thread and there was some support to documenting the answer to the question. At a minimum, stating explicitly that where one has a "Good or Good" - the License: field should capture that and if it's "Good or Bad" the License field should include only the Good license. That seemed to be common practice by all I could deduce from the entire thread. I can't see how at least capturing that is controversial?
I totally agree with the suggestion that "Good or Bad" should be represented in the license tag as just "Good". Sorry if it seemed I was saying otherwise. The only thing I'm really objecting to is imposing a new commenting requirement that didn't exist before (I think especially if the triggering event is going to be really uncommon).
Gotcha. Here's where I think we've ended up in terms of proposing some revised text for the package guidelines, let me know if you agree and would be good to get some package maintainers input as well!
Dual Licensing Scenarios If your package is licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. Note that this only applies when the contents of the package are actually under a dual license, and not when the package contains items under multiple, distinct, and independent licenses.
Example: Package libfoo is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later. The package spec must have:
License: MPL-1.1 OR GPL-2.0-or-later
If your package is licensed under a known choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only.
I'd suggest 'License: field *should* reflect the "good" license only.', because listing the bad license is still fine, isn't it? The intent is just to discourage that. Practical difference would be that if it is "must", the package review should be blocked until the issue is fixed, whereas "should" allows to just point the issue out and move on. At least this is my general perception how the guidelines are implemented in practice.
Vít
You are encouraged to include a comment memorializing the upstream licensing choice.
I took out the example altogether. At this point, I'm thinking it's not really necessary?
Jilayne _______________________________________________ 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 14. 01. 22 v 0:00 Jilayne Lovejoy napsal(a):
To put it another way, I can't think of any real-world disjunctive dual license involving a (likely) "bad" license other than the Perl module case (where of course it is really common). If it's so unusual, why should the guidelines address it at all? Or if the only likely example is the Perl one, then the guidelines should only use the Perl (GPL/Artistic) example.
well, as Miroslav began this thread asking about the scenario of having a Good or Bad license (and didn't seem to indicate it was specifically the Perl example - I assumed Fedora packagers are coming across such scenarios
Nope. From me this was completely theoretical question. Just to make the algorithm complete.
The full scan of all spec does not found any such case.
Miroslav
On 1/14/22 2:02 PM, Miroslav Suchý wrote:
Dne 14. 01. 22 v 0:00 Jilayne Lovejoy napsal(a):
To put it another way, I can't think of any real-world disjunctive dual license involving a (likely) "bad" license other than the Perl module case (where of course it is really common). If it's so unusual, why should the guidelines address it at all? Or if the only likely example is the Perl one, then the guidelines should only use the Perl (GPL/Artistic) example.
well, as Miroslav began this thread asking about the scenario of having a Good or Bad license (and didn't seem to indicate it was specifically the Perl example - I assumed Fedora packagers are coming across such scenarios
Nope. From me this was completely theoretical question. Just to make the algorithm complete.
The full scan of all spec does not found any such case.
ha! well, lesson learned - I should have not assumed and began with this question...
Miroslav
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
-
David Cantrell -
Jilayne Lovejoy -
Miroslav Suchý -
Neal Gompa -
Richard Fontana -
Tom Callaway -
Vitaly Zaitsev -
Vít Ondruch