legal November 2023

legal@lists.fedoraproject.org

11 participants
14 discussions

Fwd: SPDX Statistics - Kristallnacht edition
by Miroslav Suchý 10 Nov '23

10 Nov '23

-------- Přeposlaná zpráva -------- Předmět: SPDX Statistics - Kristallnacht edition Datum: Fri, 10 Nov 2023 07:21:16 +0100 Od: Miroslav Suchý <msuchy(a)redhat.com> Společnost: Red Hat Czech, s.r.o. Komu: Development discussions related to Fedora <devel(a)lists.fedoraproject.org> Hot news: Robert-Andre Mauchin packaged python-spdx-tools for Fedora. For scancode-toolkit - all dependencies are finally reviewed and present in Fedora, scancode-toolkit is in the middle of review. Big thanks to Robert and everybody who did the package reviews. The process of adding the licenses on list is very slow recently as the lawyers does not have too much free time before the end of the year. Now lets dive into numbers: Two weeks ago we had: > * 23282 spec files in Fedora > > * 29750license tags in all spec files > > * 12512 tags have not been converted to SPDX yet > > * 5677tags can be trivially converted using `license-fedora2spdx` > > * Progress: 57.94% ░░░░░█████ 100% > > ELN subset: > > 437 out of 3013 packages are not converted yet (progress 85%) > Today we have: * 23365 spec files in Fedora * 29583license tags in all spec files * 12255 tags have not been converted to SPDX yet * 5577tags can be trivially converted using `license-fedora2spdx` * Progress: 58.95% ░░░░░█████ 100% ELN subset: 623 out of 3969 packages are not converted yet (progress 84%) Graph with the burndown chart: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807r… The list of packages needed to be converted is here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f… List by package maintainers is here https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f… List of packages from ELN subset that needs to be converted: https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt New version of fedora-license-data has been released. With 2 new licenses (plus bunch of public domain declarations). 19 licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B… Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. New projection when we will be finished is 2024-09-19. Pure linear approximation. If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license tag matches SPDX formula, you can put your package on ignore list https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt Either pull-request or direct email to me is fine. Very impractical tip of the day: A compendium of absurd, funny, and downright bad licenses: https://github.com/ErikMcClure/bad-licenses/ Why Kristallnachte edition? On today's date at 1938, was i Kristallnacht (Night of Broken Glass) - a pogrom against Jews in Germany. It was first step where every other step was worse than the previous one. It was basicaly a first step that lead to holocaust. https://en.wikipedia.org/wiki/Kristallnacht#Kristallnacht_as_a_turning_point Do you hesitate how to proceed with the migration? Please follow https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ Miroslav

1 0

How to handle GFDL/GFDL-1.3-no-invariants-or-later
by Mark Wielaard 06 Nov '23

06 Nov '23

Hi, There is a man page in one of my packages that is distributed under the GFDL. This used to be a valid (documentation) license. But recently rpminspect (as run in bodhi) flags it as invalid, both the old-style tag GFDL (in f39) and the new-style tag GFDL-1.3-no-invariants-or-later (in rawhide): https://bodhi.fedoraproject.org/updates/FEDORA-2023-70de8a8207 https://artifacts.dev.testing-farm.io/ca605c04-706a-4124-b73b-bb97d57c2b98/ BAD Unapproved license in elfutils-0.190-1.fc39.src: GFDL Not Waivable https://bodhi.fedoraproject.org/updates/FEDORA-2023-d4cc1aa93d https://artifacts.dev.testing-farm.io/d3a446b9-ad10-40da-8fbc-526331385be0/ BAD Unapproved license in elfutils-0.190-2.fc40.src: GFDL-1.3-no-invariants-or-later Not Waivable license-validate-20-1.fc38 did allow these licenses: $ license-validate -v --old "GFDL" Approved license $ license-validate -v "GFDL-1.3-no-invariants-or-later" Approved license Thanks, Mark

3 2

python-dateutil SPDX license -- some code is Apache-2.0 and all code is BSD-3-Clause
by Miro Hrončok 05 Nov '23

05 Nov '23

Hello, I wanted to send a pull request to the python-dateutil package to change: License: BSD-3-Clause and Apache-2.0 To: License: BSD-3-Clause AND Apache-2.0 However, the comment above the License tag made me curious: # According to the LICENSE file: # - BSD License applies to all code, even that also covered by ASL 2.0 # - ASL 2.0 applies to all contributions after 2017-12-01, The license file: https://github.com/dateutil/dateutil/blob/2.8.2/LICENSE tl;dr: > ...snip Apache-2.0... > > The above license applies to all contributions after 2017-12-01, as well as > all contributions that have been re-licensed (see AUTHORS file for the list of > contributors who have re-licensed their code). > > ...snip BSD-3-Clause... > > The above BSD License Applies to all code, even that also covered by Apache 2.0. In other words. There is a subset of the code which is covered by Apache-2.0 and *at the same time* all of the code is covered by BSD-3-Clause. Is that an OR case? Should the license tag be: License: (Apache-2.0 AND BSD-3-Clause) OR BSD-3-Clause (We can either pick BSD-3-Clause for everything OR a combination of both.) Or should it be: License: (Apache-2.0 OR BSD-3-Clause) AND BSD-3-Clause (Some code is BSD-3-Clause and for the rest we can pick either one of them.) Or is it an AND case (the code is covered by both license "together" (whatever that means)? In that case, should it be: License: (Apache-2.0 AND BSD-3-Clause) AND BSD-3-Clause Or is the current license tag more or less correct: License: Apache-2.0 AND BSD-3-Clause ? Thanks -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 5

CC0 license of dlmalloc in sgx-sdk package review
by Daniel P. Berrangé 02 Nov '23

02 Nov '23

Hi Legal The 'sgx-sdk' package is currently open for review with a view to adding to Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2085444 One of the last stumbling blocks is that it includes a copy of the "dlmalloc" code under the CC0 license, which is now a forbidden code license for packages being newly added to Fedora. The authors of sgx-sdk have contacted the original author of dlmalloc, and he apparently suggested that since CC0 is a public domain license, they can just add a second license header of their choosing to the source files and Fedora can then ignore the orignial CC0 license. This smells fishy to me, as I can't come with rationale for why adding a second "BSD" license header to the source file and justify Fedora ignoring the original CC0. The original code would still explicitly not have a patent grant, and an extra license doesn't seem to alter that fact. It was pointed out that this approach has already been taken by OpenJDK, where they took CC0 code and added a GPL-v2-only header: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java… OpenJDK though would be grandfathered in, since it existed in Fedora before CC0 was forbidden, so I'm not sure that can be relied on as a precedent. I am not a lawyer, so I want an expert opinion on this suggestion that adding a 2nd license header allows Fedora to ignore the original CC0 license. If it is true, then it would appear to make the whole exercise of banning CC0 effectively pointless. I had also suggested downgrading to an older version of dlmalloc which had the CC Public Domain license, rather than CC0, but the sgx-sdk maintainers rejected that as they're concerned it has security relevant flaws. 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 :|

3 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal November 2023