On 6/10/22 1:52 PM, Justin W. Flory
(he/him) wrote:
Hi all,
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@redhat.com 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.
Thanks for saying this! The same can be said of the SPDX community.
I can also say that having observed various adoptions of SPDX
license ids or use of the SPDX License List over the years, the most
successful results have come with collaboration between the relevant
communities. Where a community has gone off and done their own thing
using various aspects of SPDX (as they have every right to do) -
usually misses the benefit of more informed implementation. So, that
is why I feel so strongly around cross-collaboration. :)
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@redhat.com> 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… ;-)
FWIW - SPDX-legal used to use email, very similar to Fedora-legal,
for our license review process. Once a license was approved, one
person had to update the "data" (at that time held in a .txt file
and spreadsheet... the horror!). We eventually moved to Github and
started using issues. Considering the SPDX-legal community is not
necessarily day-to-day Github (or other repo) users, this was a big
lift! For awhile, people still used email and we just made an issue
for them. Anyway, point being, I'd think the Fedora community is
probably way more Gitlab savvy and this transition would be an
easier shift. But if someone still sent an email to fedora-legal,
it's also easy enough for anyone to make an issue and then reply on
email to follow there. I'd guess there will be a transition period
where this may happen as people become aware of the new process.
On Friday, June 10th, 2022 at 10:33, Neal Gompa <ngompa13@gmail.com> 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.
_______________________________________________
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure