Re: Boolean logic in license

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 ;-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@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

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

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Gnome Users]     [KDE Users]

  Powered by Linux