legal September 2023

legal@lists.fedoraproject.org

13 participants
15 discussions

Fwd: SPDX Statistics - Marco Polo edition
by Miroslav Suchý 18 Sep '23

18 Sep '23

-------- Přeposlaná zpráva -------- Předmět: SPDX Statistics - Marco Polo edition Datum: Fri, 15 Sep 2023 07:38:26 +0200 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> Two weeks ago we had: > * 23128 spec files in Fedora > > * 29572license tags in all spec files > > * 16519 tags have not been converted to SPDX yet > > * 6059tags can be trivially converted using `license-fedora2spdx` > > * Progress: 44.14% ░░░░██████ 100% > > ELN subset: > > 825 out of 2479 packages are not converted yet > Today we have: * 23143 spec files in Fedora * 29600license tags in all spec files * 16169 tags have not been converted to SPDX yet * 5903tags can be trivially converted using `license-fedora2spdx` * Progress: 45.35% ░░░░██████ 100% ELN subset: 603 out of 2986 packages are not converted yet 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 17 new licenses (plus bunch of public domain declarations). 31 licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data). Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. New projection when we will be finished is 2025-01-30 (we are slowing down. Again. :( ). 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. Why Marco Polo edition? On today's date at 1254, an Italian merchant Marco Polo was born. He traveled to Asia (today's China). It took him 4 years to get there, 3 years to get back. And he stayed 17 years there. He wrote a book Millione about this travel. That made him famous and even nowadays is great insight about Asia of that time. https://en.wikipedia.org/wiki/Marco_Polo https://en.wikipedia.org/wiki/The_Travels_of_Marco_Polo Do you hesitate how to proceed with the migration? Please follow https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ Miroslav

2 1

msv (xsdlib) licensing review
by Marián Konček 08 Sep '23

08 Sep '23

As part of the jaxb 4.0.2 -> 4.0.3 update, part of this package is needed for its code generation. Therefore, I would like to package it in Fedora. This package has complex licensing which is why I am asking for a review. Note that I only need the "xsdlib" subdirectory. I only need a stripped-down version of this package as if by downloading: https://github.com/xmlark/msv/archive/refs/tags/msv-2022.7.tar.gz and running (inside the msv-msv-2022.7 directory): find . -mindepth 1 -maxdepth 1 -type d ! -name 'xsdlib' -exec rm -rf {} + rm -rf xsdlib/src/main/resources rm -rf xsdlib/src/test grep -l -r --ignore-case 'proprietary' | xargs rm -v Most problematic license files are: copyright.txt and license.txt in https://github.com/xmlark/msv/tree/main/docs/xsdlib. To my knowledge, all files that remained use explicit BSD-3-Clause or Apache-1.1. Question is whether we could have removed the copyright.txt and license.txt files in the first place. Current upstream: https://github.com/xmlark/msv Previous package in Fedora (used different source repository): https://koji.fedoraproject.org/koji/packageinfo?packageID=2576 Previous bug related to licensing: https://bugzilla.redhat.com/show_bug.cgi?id=87684 Also grep --ignore-case for "proprietary" "confidential", "nuclear". -- Marián Konček

2 5

Simplification of package license expressions involving dual licenses
by Richard Fontana 07 Sep '23

07 Sep '23

Fedora legal docs currently say: "If your package is built from files under multiple distinct licenses, and some files are licensed under a choice of two (or more) licenses, then the License: field must include the appropriate OR and AND expressions.... The license expression must reflect the disjunctive license choice even if one or both of the license identifiers in the OR expression also appear separately in the composite license expression." I am coming around to the view that we can revise the last sentence there: For an SPDX expression involving licenses foo and bar, foo AND bar AND (foo OR bar) can acceptably be "reduced" to foo AND bar since both elements of the OR-expression are separately atomic elements of the larger AND expression. In insisting on preservation of all dual licenses (involving Fedora-allowed licenses that is), we were following what I understood to be the Callaway tradition. However, this is not entirely clear; see for example: https://web.archive.org/web/20190801152043/https://fedoraproject.org/wiki/P… As far as I can tell, the scenario we're talking about wasn't explicitly addressed in the old guidelines. The other part of this is that insisting on preservation of dual licenses was making an important cultural or political point. To understand this, you need to understand that some companies consuming open source have a silly practice of taking steps to explicitly select one of the licenses. As you might expect this usually happens when one of the licenses is in the *GPL family. A related phenomenon involves taking GPLv2-or-later code "as" GPLv2-only. Apart from being sort of ridiculous, this practice conflicts with the usual practice in upstream open source of passing through all disjunctive licenses. So by *not* doing this, Fedora was expressing a sort of solidarity with normal open source development and distancing itself from the practices of those companies. Since in the (foo AND bar AND (foo OR bar)) -> (foo AND bar) case the simplified expression has all of the elements that were in the dual license, I think the simplification is still in the spirit of the old rule. We would not be removing any of the license symbols on either side of the dual license; we are just hiding the fact that there was a dual license. If anyone thinks this would be a bad, or good, change to make let me know. It probably wouldn't affect too many packages and wouldn't do a whole lot to make their license tags that much shorter. I don't feel too strongly about it but I am trying to think of ways we could make SPDX expressions a little simpler without abandoning all integrity. Note that adoption of this approach this would not be an assertion that (foo AND bar AND (foo OR bar)) is *equivalent* to (foo AND bar). Richard

1 0

Making no-conditions identifiers optional in the License: field
by Richard Fontana 04 Sep '23

04 Sep '23

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. I do think that the current approach can be criticized as being overly pedantic, and perhaps also internally contradictory (some of Florian's recent comments get at the various ways in which we are being contradictory). We have a still-undocumented rule that what I call "true public domain" should not be reflected in the License: field (unless it would otherwise be empty), yet we have carefully attempted to collect nonstandard public domain dedication statements and cover those by `LicenseRef-Fedora-Public-Domain`. We have been using a similar approach with `LicenseRef-Fedora-UltraPermissive`. These basically replace Callaway system names "Public domain" (though this was sometimes used for "true public domain") and "Freely redistributable without restrictions", respectively. I think it can reasonably be argued that there is little point in including `LicenseRef-Fedora-Public-Domain` and `LicenseRef-Fedora-UltraPermissive` in the License: field since they are associated with no conditions or obligations. In those special cases where the License: field would otherwise be empty, we can ask SPDX to create unique identifiers for the license text in question. We might want to extend this principle to other things, such as GPL exceptions that entail no conditions in the use case encountered in particular packages. (There is already an old issue about this, I think concerning the Bison exception.) This wouldn't do *that* much to make License: fields simpler, so maybe it's not particularly worthwhile. There is also the problem that if we make it optional, package maintainers may be less likely to scrutinize things that are assumed to fall into these kinds of categories, when in some cases they actually wouldn't, although I think it's now clear that those situations are uncommon. In theory we'd still expect package maintainers to submit issues to have things that seem to qualify for LicenseRef-Fedora-Public-Domain reviewed, but it might be challenging to enforce that expectation and the Fedora Legal team would have to end up doing all that work themselves, which might be a justifiable result. As with abandoning the "license of the binary" rule, this would seemingly be a major departure from the principles established under the Callaway system. Any thoughts on this? Richard

8 19

Fwd: SPDX Statistics - Passenger pigeon edition
by Miroslav Suchý 01 Sep '23

01 Sep '23

-------- Přeposlaná zpráva -------- Předmět: SPDX Statistics - Passenger pigeon edition Datum: Fri, 1 Sep 2023 10:33:23 +0200 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> Two weeks ago we had: > * 23030 spec files in Fedora > > * 29469license tags in all spec files > > * 16716 tags have not been converted to SPDX yet > > * 6149tags can be trivially converted using `license-fedora2spdx` > > * Progress: 43.28% ░░░░██████ 100% > > ELN subset: > > 895 out of 2492 packages are not converted yet > Today we have: * 23128 spec files in Fedora * 29572license tags in all spec files * 16519 tags have not been converted to SPDX yet * 6059tags can be trivially converted using `license-fedora2spdx` * Progress: 44.14% ░░░░██████ 100% ELN subset: 825 out of 2479 packages are not converted yet 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 9 new licenses. 33 licenses have been submitted to SPDX.org and are waiting to be review (and then added to fedora-license-data). Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. New projection when we will be finished is 2025-01-22 (we are slowing down. Again. :( ). 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. Tip of the day: You can use Chrome or Firefox plugin to find what is the license and how much it differ from nearest SPDX match. https://github.com/spdx/spdx-license-diff#installation Why Passenger pigeon edition? Passenger pigeon is extinct species. On today's date at 1914, last known one died at Cincinnati Zoo. https://en.wikipedia.org/wiki/Passenger_pigeon Do you hesitate how to proceed with the migration? Please follow https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ Miroslav

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal September 2023