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@xxxxxxxxxx> 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 ;-pGotcha. 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!(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).*** Dual Licensing ScenariosIf 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-laterIf 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxxFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
