On Tue, Jun 14, 2022 at 11:12 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Tue, Jun 14, 2022 at 11:00 AM David Cantrell <dcantrell@xxxxxxxxxx> 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) <foss@xxxxxx> wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@xxxxxxxxxx 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 <vondruch@xxxxxxxxxx> 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 <ngompa13@xxxxxxxxx> 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. > To elaborate, using SPDX-style identifiers and even working with SPDX itself is something I consider reasonable. However, I *do not* consider it reasonable to make *our* legal process block on someone else's. The only quibble with the Change document I have is this: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1#With_Fedora_abbreviations_we_could_use_and.2C_or.2C_and_parentheses_when_constructing_expressions._Can_we_do_that_with_SPDX.3F SPDX license expression parsers are required to handle all-lowercase "and"/"or"/"with", and I think we should keep doing that for Fedora license math because SPDX identifiers are title case words and that makes it easy for humans to identify discrete clauses. Using all caps makes it annoying to read. The license field is designed to make it easy for people and machines to figure out what the license of a package is, we should not forget humans matter here too. Personally, I don't think we should require full conversion when partial SPDX conversions net us significant benefits too (https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1#Can_we_combine_Fedora_abbreviations_and_SPDX_abbreviations.3F), but I don't feel too strongly about it. Beyond the Change document, there's a whole extra undefined process for how we deal with new licenses and license identifiers. I don't want us waiting on SPDX, and I don't want us using LicenseRef-* if we don't absolutely need to. Aside from the reasons I stated earlier, LicenseRef-* tags can basically never go away because we are not in control of the universe of packages that ship using our packaging guidelines. Since we know what identifiers exist when making a new one, we can designate the identifier ourselves, use it in Fedora, and submit it upstream to SPDX to reconcile it. Fundamentally, I want us to be prepared for the event that SPDX either doesn't exist anymore or is no longer in common use. I signed onto this project principally because I want us to have a proper coherent database of our license policy that our tools can consume that is central to our ecosystem. Whether the identifiers came from SPDX or somewhere else isn't a huge deal to me, but unifying our license identification databases is. That will enable future efforts for mechanizing and automating audits across the entire distribution. SPDX isn't responsible for Fedora, Red Hat and Fedora are. So I want to make sure we are designing this with that value in mind. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
