On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana <rfontana@xxxxxxxxxx> wrote: > > "Blocking on the SPDX-legal team" is the one aspect of this process > that I am somewhat worried about, and I think it might be something > unprecedented for Fedora, so it's important that people can get behind > that as an experiment. Also I went back and looked at Jilayne's > original email in this thread and I'm not sure that this was an > obvious feature of the proposal. So it's important to understand: > under this proposal, Fedora package submitters will have to wait for > an external project to make a decision, for some unspecified amount of > time, and I'm not even sure if we can say what that time period might > be based on past experience because this relationship is going to be > new for SPDX as well as for Fedora. > > Probably worth keeping in mind, though, that new licenses in new > packages are *probably* going to be a relatively uncommon event, > assuming that we don't primarily use the new package process as the > means of transitioning existing approved Callaway license symbols to > SPDX-conformant identifiers. > So, this is where I will disagree here, sadly. Transitioning from the Fedora/Callaway system (which allows license families to be given the same designator) to the SPDX system (which does not) means that we will have the sad duty of having to generate identifiers for licenses that don't deserve them. 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 don't know how much delay Fedora packagers can tolerate or how fast > SPDX-legal can be. I would assume this is something new for SPDX too > -- the first time an external consumer of SPDX identifiers is > dependent on SPDX-legal acting somewhat fast. I believe we talked > (maybe this was on the spdx-legal list) about defining an SPDX-legal > decision as being the merging of a pull request at > github.com/spdx/license-list-XML, not on a formal release of a new > license list by SPDX (which I think we can agree would be unacceptable > for Fedora). > > 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). > This problem is the principal reason why I don't think Debian will ever fully adopt SPDX identifiers in the same way openSUSE did, and why I don't think it'd be a good idea for us to do so either. We may be adopting SPDX-style identifiers, but we aren't going to rely on their data set for our systems. That's why David Cantrell is making a new one for us. Clearly the wind is blowing for us to make life easier for lawyers and harder for packagers, but that doesn't mean I want to give up *too* much ground on that front. And I've made it clear in the past and I'll reiterate again: LicenseRef-* identifiers should *not* be used except in the absolute worst circumstances. Those tags indicate three things: 1. A lack of agency 2. A lack of coherence 3. A lack of agreement Fedora, when identifying acceptable licenses, should not have those problems. -- 真実はいつも一つ！/ 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
