On Wed, Feb 9, 2022 at 11:27 AM Richard Fontana <[email protected]> wrote: > > On Wed, Feb 9, 2022 at 11:14 AM Jilayne Lovejoy <[email protected]> wrote: > > > > > > > > On 2/9/22 9:08 AM, Richard Fontana wrote: > > > On Wed, Feb 9, 2022 at 10:53 AM Florian Weimer <[email protected]> wrote: > > >> * Serge Guelton: > > >> > > >>> the LLVM project has moved to an Apache Software License 2.0 with > > >>> exception > > >>> license, referenced as https://releases.llvm.org/10.0.0/LICENSE.TXT > > >>> > > >>> Some more details are available here: > > >>> > > >>> > > >>> https://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework > > >>> > > >>> Does it make sense to have it listed in > > >>> https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses and the > > >>> associated short name be compatible with, say, rpmdiff? > > >> Isn't our position that the relicensing has not happened yet, that the > > >> SPDX identifiers in the sources are incorrect, and that the project > > >> still distributes the sources under the old LLVM license (called “NCSA” > > >> in the Fedora framework)? > > > Separately from that issue, I am aware of one unresolved (for my team > > > at Red Hat) longstanding objection to some aspects of the language of > > > the LLVM exception (raised by at least one person outside of Red Hat). > > > I wouldn't want to classify the exception as "good" without reaching > > > some sort of resolution on that issue. > > > > > > Richard > > > > just saw this after I wrote my email. That's interesting and a bit > > surprising - I'd be curious to hear more about what the objection is > > (and especially since I know LLVM got a lot of feedback when they were > > drafting it!) > > I think they got a lot of feedback from a somewhat narrow part of the > universe that didn't include historically non-LLVM-oriented community > members. > > To be clear, my position would be that even if the exception embodies > some horrible drafting problem it does not mean LLVM, conceptualized > as being "Apache-2.0" (-only, as it were) or "Apache-2.0 AND NCSA" or > whatever is problematic for Fedora. It sort of goes to the issue of > how important it is to make sure the license metadata incorporates the > details of all exceptions given that normally exceptions are > structured as additional permissions (though sometimes "exceptions" > are additional restrictions and historically some of those have been > problematic). Not so long ago (before we were engaged in the current > iteration of looking into having Fedora migrate from Callaway > Notation™ to SPDX identifiers) I suggested that Fedora abandon all > efforts to track exceptions as being ultimately a waste of time, but I > have a feeling you would disagree with that view. :-) >
From a practical perspective, the only two exceptions that matter for Fedora are: * GPL compatibility exceptions * OpenSSL compatibility exceptions With OpenSSL 3.0, we can basically say goodbye to the second one, and only worry about the first. All other exceptions are basically fluff. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ legal mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
