On Thu, Jan 13, 2022 at 10:24 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> wrote: > > 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. > 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? I think this looks OK, without the good|bad example. But agreed that it would be good to get feedback from people actually involved in Fedora packaging. For example, I wonder if this statement is hard to understand for people not sufficiently steeped in FOSS licensing: "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." In many cases (I'm guessing more typically) a notated dual license will be part of a larger expression (i.e. the dual license will cover only a part of the code that makes up the package). I don't know if it's important to say anything about that. I'd ultimately like to see (maybe in some other document) some real world examples (involving real Fedora packages!) to illustrate the kinds of general guidelines being given here. Richard _______________________________________________ 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