On Tue, Jun 14, 2022 at 11:00 AM David Cantrell <[email protected]> wrote: > > 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. >
I am not opposed to changing to SPDX identifiers, but there's a world of difference between that and basically saying that we are not in control of our license process. Switching to SPDX identifiers and the SPDX identifier scheme has a ton of consequences, and we need to actually be cognizant and account for them. I'm bringing this up all the time because I've seen it go wrong before and I don't want it to go wrong here now. -- 真実はいつも一つ！/ 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
