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(a)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