Re: process for review of licenses

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
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




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Gnome Users]     [KDE Users]

  Powered by Linux