On Thu, Aug 31, 2023 at 05:13:10PM -0600, Jilayne Lovejoy wrote: > > > On 8/31/23 2:39 AM, Daniel P. Berrangé wrote: > > On Thu, Aug 24, 2023 at 02:52:21PM -0400, Richard Fontana wrote: > > > Some of the complaints that have surfaced since the migration from the > > > Callaway system to SPDX seem to be, at root, an aesthetic distaste for > > > complex license expressions in RPM license metadata. This may explain > > > why some favor application of "effective license" analysis. I suspect > > > there is also a sort of psychological desire to hide the underlying > > > licensing complexity that characterizes many packages. > > Lets take the proposed change to the kernel spec: > > > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2648/diffs#b49eece2a4839c357a77beb23d8760ff33be48cc > > > > as an example of "complex license expressions" for which > > there is likely an aesthetic distaste. Each distinct > > SPDX-License-Identifier tag expession, is combined such > > that we end up with: > > While the majority of files in the kernel are "GPL-2.0-only", > > a number of files are offered under a choice of licenses (OR). > > Even if 99% of files were simply GPL-2.0-only, it only takes > > a handful of files being offered under a choice, to result in > > an enourmous SPDX expression like the one above. In the above > > example, at a bare minimum it would only take 30 files, out > > of the kernel's 80,000 to have distinct licence choices to > > cause the existance the above expression. > That's an interesting point, but I'm not sure how we could justify some kind > of an exception in such a case I'm not suggesting an exception for the kernel, as this also applies to other large projects to some degress. Rather I'm suggestnig a change to the Fedora License: field guidelines to say that the expression should be simplied by not including "OR" clauses, only "AND", such that we don't repeat the same SPDX identifier over & over again with different combinatorial expansions. > > While this is an accurate reflection of the range of distinct > > file license choices, I'm not convinced that this approach is > > especially beneficial to Fedora users. > well, it's not really just about Fedora users - besides the benefit > downstream, I think there is some benefit to what Fedora is doing in a > broader, example-setting, ecosystem sense. I guess part of this feeling > comes from my thinking that any desire or attempt to obscure the license > complexity is not a good thing and potentially creates more work or issues - > reflecting the reality, to me, sets a good precedent I'd say that the License field is inherantly "obscuring" the complexity because it is trying to condense the reality of disparate licensing across 10's of 1000's of files into a single line of text. I don't feel my proposal to simplify the SPDX expressions is a major difference in that respect. If not "obscuring the license complexity" is the benchmark, then I think our solution is very weak compared to Debian's approach of having the "copyright" file report the distinct licenses along with information about what files they found each license in. > > What purpose does it serve to list "MPL-1.1 OR GPL-2.0-only" > > and "MIT OR LGPL-2.1-only", etc if only perhaps < 1% of files > > carry this choice and we're not telling the user which 1% of > > files it applies to ? > they can run a license scanner and create an SPDX document that shows the > file level license info to determine this. And that report will be far more > complex and lengthy than what you came up with above ;) > In that way, what you have above is a useful "summary" and accurate > reflection of the big picture If we're pointing people in the direction of using a license scanner when they want the gory details, then I'd say that it is even more compelling to drop the combinatorial expansion of SPDX identifiers, and simply have a flat list of SPDX identifiers found. > > The previous effective license analysis addressed this problem, > > such that everything reduced down to "GPLv2 and Redistributable" > > I don't want to suggest going back to effective analysis as I > > think that was overly simplified, but perhaps we can finese > > what we're doing today. > > > > ie tather than trying to maintain the full list of choices, can > > we eliminate all the OR clauses, such that we present just a > > flat list of each distinct SPDX license name that is found. > > IOW, the above kernel SPDX expression would be > > > > License: Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND BSD-3-Clause-Clear AND CDDL-1.0 AND copyleft-next-0.3.1 AND GPL-1.0-or-later AND GPL-1.0-or-later-WITH-Linux-syscall-note AND GPL-2.0-only AND GPL-2.0-only-WITH-Linux-syscall-note AND GPL-2.0-or-later AND GPL-2.0-or-later-WITH-GCC-exception-2.0 AND GPL-2.0-or-later-WITH-Linux-syscall-note AND ISC AND LGPL-2.0-or-later AND LGPL-2.0-or-later-WITH-Linux-syscall-note AND LGPL-2.1-only AND LGPL-2.1-only-WITH-Linux-syscall-note AND LGPL-2.1-or-later AND LGPL-2.1-or-later-WITH-Linux-syscall-note AND Linux-OpenIB AND MIT AND MPL-1.1 AND Redistributable, no modification permitted AND X11 AND Zlib > > > but then this would be an exception to our original policy? and how would we > articulate that? I'm not sure why this is really any "better" than your > original - it's just shorter and truncated. I wouldn't call it an exception, I'd say this should be the Fedora standard. Shorter is indeed better because it is far easier for humans to read when it is more concise, especially so because once the expression is flattened, the SPDX identifiers could be alphabetically orered as in this example above. IMHO, there's a world of diference in readability between this shorter example, and the current kernel proposed SPDX expression. > oh, and we should take a look at the "Redistributable, no modification > permitted" ones... that is likely the firmware licenses that were never > captured Yes, that looks dubious - I added a comment on the latest kernel MR saying that this needs replacing by actual SPDX identifiers for whatever files it was supposed to apply to. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
