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 <[email protected]> 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ý <[email protected]> > 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? > > 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 <[email protected]> > Red Hat, Inc. | Boston, MA | EST5EDT > _______________________________________________ > legal mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ legal mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
