2016-07-26 3:54 GMT+02:00 Richard Fontana <rfontana@xxxxxxxxxx>: > On Mon, Jul 25, 2016 at 01:31:58PM -0400, Tom Callaway wrote: >> I've been working on and off with SPDX to ensure that there is as >> minimal as possible deviation between our two lists. >> >> If we did want to move forward with this, we'd need to figure out how to >> resolve the inconsistencies with BSD/MIT between Fedora and SPDX. >> Additionally, since pretty much every single package would need to be >> touched for this change (as well as every package awaiting review), this >> would not be a small effort, and I am _not_ volunteering to undertake it >> alone, as I do not have the time. >> >> I tend be of the opinion that the work involved vastly outweighs the >> benefit, but if others disagree (and are willing to volunteer their time >> to work on this), I could be convinced. > > The main problem is exemplified by the BSD/MIT case, but it's not > limited to that. We have a number of instances where a Fedora license > tag refers to a set of things that are (usefully, I increasingly > believe) treated as multiple licenses in the SPDX universe. BSD and > MIT are just the extremes. I.e. it's not just a case of conceptually > equivalent standards that just happen to use different tokens for > things. > > Would it be possible to gradually evolve towards the SPDX system, say > on a voluntary basis (by package maintainer), making use of the > existing RPM license field? For example, say some Fedora package foo > today has "License: LGPLv2+" and let's further say that the code is > clearly licensed under LGPL version 2.1 or later. Could we move to a > voluntary system where the foo package maintainer can opt to change > that to "License: LGPLv2+ (SPDX: LGPL-2.1+)"? Or does that not even > make sense? > > Richard We can add custom tags, but we should probably do it progressively with automated warnings as Vit suggested. As for problematic conversions like BSD/MIT, we should just retrieve the list of the packages and have them fixed manually by volunteers after review. _______________________________________________ legal mailing list legal@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/legal@xxxxxxxxxxxxxxxxxxxxxxx
