On Fri, Jun 10, 2022 at 04:32:10PM -0400, Neal Gompa wrote: > On Fri, Jun 10, 2022 at 3:52 PM Justin W. Flory (he/him) <[email protected]> wrote: > > > > Hi all, > > > > > > > On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana [email protected] wrote: > > > > > > > > Jilayne, I think we can be confident that SPDX-legal will be efficient > > > enough as long as you are involved in leading it and also are involved > > > on the Fedora side, but it would be reasonable for Fedora community > > > members to wonder what will happen if one or both of those > > > involvements were to ever change. Maybe we should think about a backup > > > plan (like, if some version of the SPDX namespace proposal is adopted, > > > making use of that if SPDX-legal is not responsive by a certain time, > > > or using LicenseRef- to create SPDX-conformant identifiers that can be > > > altered later on to SPDX-adopted identifiers as needed). > > > > > > > > > The Fedora Community has a good reputation for collaboration across > > communities. Given the close connection to the SPDX Legal team via > > Jilayne's role as a maintainer, I think it is worth giving it a go with a > > clear flag to the community as trialing a new process. > > > > A contingency plan for when things don't go ideally is a way to build > > efficacy into the process. It is a reason why a contingency plan is > > included in the Fedora Change Proposal template. There should also be a > > scheduled window to retrospect on the process and identify what is working > > well and what is not. If this is submitted as a Fedora 37 Change, then > > perhaps targeting a retrospective in Fedora 39 or 40. > > > > > > > On Friday, June 10th, 2022 at 09:44, Vít Ondruch <[email protected]> > > > wrote: > > > > > > Maybe I wonder (similarly to you) what would be purpose of this ML, if > > > all discussion happens in some issue tracker. > > > > > > > > > Maybe for people like me who are plugged into too many issue trackers as it > > is. :-) Although a tag for #legal on discussion.fp.o could be nice… ;-) > > > > > > > On Friday, June 10th, 2022 at 10:33, Neal Gompa <[email protected]> > > > wrote: > > > > > > Tom's system had one very important property that SPDX lacks: human > > > coherence. SPDX is inherently verbose and forces specificity where > > > none is necessary in practice, which means that even minute variations > > > in licenses (and we all know that BSD and MIT variants are a dime a > > > dozen) now need new identifiers. > > > > > > > > > I understand this. It adds low-value labor to the packaging workflow for > > every package to require a perfectly accurate identifier. There is also > > significant labor in transitioning not only existing identifiers, but also > > habits of existing packagers to support this change. > > > > But instead of identifiers, shouldn't this be solved at the level of > > process and software? I see a strong case for maintaining simplicity for > > packagers, but I also do not see a strong case against supporting SPDX > > identifiers in some capacity. These were two ideas I had, but I don't have > > a deep RPM development background to back them: > > > > 1. A subset of identifiers as "super identifiers" that support license > > families under commonly-understood terms. Packagers are encouraged to use > > more verbose identifiers, but super identifiers are also permitted. Super > > identifiers are understood to be intentionally unspecific as license > > families. > > > > 2. Creating a Fedora-specific license identifier that indicates a new > > license is acknowledged by Fedora Legal, but it does not have an assigned > > SPDX identifier or it is under review. For the purpose of identifiers, this > > could be a prefix like "FE-" combined with a super identifier (above) that > > represents a known license family. I think this supports packagers in > > getting quick answers for identifiers to use in packages, while enabling a > > Fedora Legal/SPDX Legal discussion to pan out. If/when a SPDX identifier is > > created for a new license, the Fedora-specific license identifier can be > > aliased to the new SPDX identifier. > > > > I'm not sure how viable these ideas are in the RPM end of things, but I am > > pulling from my experience as a packager and also O.S. legal enthusiast in > > other places. I believe this approach better balances the scale of manual > > packager labor to using a common set of identifiers to aid in legal support > > for Fedora. > > In my ideal world, we would not explicitly "switch to SPDX", but > instead replace 1:1 identifiers with SPDX ones. We'd keep our license > math and conventions, but identifiers would be remapped where it made > sense. The more specific SPDX identifiers for various MIT and BSD > variants would be acceptable, but not required. > > SPDX would essentially be an advisor for us, rather than a dependency. > That's what Debian did, more or less. > > As for "FE-", I'd rather not make that prefix exist more than it > already has to. We also don't need it, since we would have our own > license list, with identifiers and the will-it-blend(tm) chart. Again, > the only reason to do weird prefixes is if we needed to maintain > coherence across multiple indexes. We don't, so that's not an issue.
I read this as you are opposed to the SPDX change proposal as written, in which case I ask that you remove your name from the change owners list. -- David Cantrell <[email protected]> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ 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
