On 1/12/22 7:37 PM, Richard Fontana wrote:
On Wed, Jan 12, 2022 at 12:22 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> 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@xxxxxxxxxx> 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/LicensingGuidelines/#_multiple_licensing_scenarios
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
_______________________________________________
legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
