On Fri, Jun 10, 2022 at 10:33:38AM -0400, Neal Gompa wrote: > 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. If you are fundamentally opposed to this change proposal, please remove your name from the owners list. > > 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. This is quite a jump. Please assume good intent. This project has been underway for YEARS now. I noticed internally at Red Hat that across our products and then across Fedora had many overlapping license tracking efforts. Why? Should we not try to combine efforts? The Fedora list had not real process or owner other than spot and I think the project (and downstream consumers of Fedora) will benefit from a documented process and data set owners. spot did a lot of great work to get us here, but we need a better process now and a central set of data. > 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. I do not understand this position. From my point of view, LicenseRef-* syntax is a great part of the SPDX spec to let us accept a license, use it, and then in parallel submit it to SPDX. If SPDX accepts the license, we can make the change in our package(s) and if they don't we can just keep using the LicenseRef-* identifier we created because that's still SPDX spec-compatible. > 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. I do not see it that way. I see it as a way for us to define SPDX spec-compatible license identifiers that are only in our data set and not [yet] accepted in to the upstream SPDX list. Thanks, -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ 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
