legal August 2023

legal@lists.fedoraproject.org

23 participants
20 discussions

Re: RFC: PR to update exiv2 in Rawhide
by Gary Buhrmaster 22 Aug '23

22 Aug '23

On Mon, Aug 21, 2023 at 7:02 PM Michel Alexandre Salim <salimma(a)fedoraproject.org> wrote: > > Dear all, > > exiv2 has had a new release for a few months now - 0.28.0 - which causes > an soname bump. > > I've put up a PR for the update - > https://src.fedoraproject.org/rpms/exiv2/pull-request/3 - would > appreciate people taking a close look at this; I'll also prepare a COPR > with the dependent packages rebuilt > > In the meantime, there's a 0.27.7 bugfix release, any objection to > getting that packaged for stable releases? Per https://bugzilla.redhat.com/show_bug.cgi?id=1979565#c12 there appears to still be a pending legal review issue and you may need to scrub the sources of the BMFF parts before uploading to dist-git. I believe legal was pinged recently as to the status of the BMFF question. I have CC: the legal mailing list in case they have any input.

2 1

Re: Fwd: SPDX Statistics - Voyager 2 edition
by Miroslav Suchý 20 Aug '23

20 Aug '23

Dne 20. 08. 23 v 11:15 Bob Mauchin napsal(a): > Hello, > > > Is there a reason we don't use PP power to do it globally? Yes. 1) non trivial conversion (10k packages to go) - there is no know way because a) the license in old system has more options in SPDX standard. E.g. $ license-fedora2spdx'BSD' Warning: more options on how to interpret BSD. Possible options: ['BSD-3-Clause', 'BSD-3-Clause-Modification', 'BSD-2-Clause', 'BSD-2-Clause-Views', 'BSD-2-Clause-FreeBSD', 'BSD -1-Clause'] b) the license is not on SPDX list yet. Or its part. E.g. previously we had just GPLv3+ but it has some exception at the and so in SPDX it has to be "GPL-3.0-or-later WITH Classpath-exception-2.0". Lots of these exceptions was missing in SPDX list. We are adding 3+ licenses to SPDX every week. 2) trivial conversions (7k packages to go). While the change can be trivial, there are several things to be considered: a) No "effective license" analysis. https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_lic… This changed recently and you should check licensing of your package even without the SPDX change. This cannot be automated with current status of tooling. b) Surprisingly high amount of packages has "issues". Exceptions in licenses (see above). License is similar to stated liceses, but there are differences that justify new id. Bundled files with different license. If you know your upstream well and your package is simple then feel free to follow: $ license-fedora2spdx'GPLv2+' GPL-2.0-or-later and you are done in 30 seconds. But if your project is bigger then we recommend to use https://www.fossology.org/get-started/ (see bottom of page) or scantool, askalono... -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

1 0

Fwd: SPDX Statistics - Voyager 2 edition
by Miroslav Suchý 20 Aug '23

20 Aug '23

-------- Přeposlaná zpráva -------- Předmět: SPDX Statistics - Voyager 2 edition Datum: Sun, 20 Aug 2023 09:10:52 +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> tl;dr summary - we are slowing down again, huge progress with adding new licenses Two weeks ago we had: > * 22983 spec files in Fedora > > * 29406license tags in all spec files > > * 16915 tags have not been converted to SPDX yet > > * 6242tags can be trivially converted using `license-fedora2spdx` > > * Progress: 42.48% ░░░░██████ 100% > > ELN subset: > > 986 out of 2500 packages are not converted yet > Today we have: * 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 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 13 new licenses. 26 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-11 (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: Do you want to check your LICENSE file? You can use SPDX online tool: https://tools.spdx.org/app/check_license/ Why Voyager 2 edition? Because on today's date at 1977 the space probe Voyager 2 was launched. It is one of five probes that managed to leave the Solar System. And only one probe that visited all ice giant planets. And it is still operational. https://en.wikipedia.org/wiki/Voyager_2 https://voyager.jpl.nasa.gov/mission/status/ Do you hesitate how to proceed with the migration? Please follow https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ Miroslav

1 0

Possibly problematic license terms: notify / notify-debouncer-mini Rust crates
by Fabio Valentini 17 Aug '23

17 Aug '23

Hi all, I've been working on updating a few Rust applications that are packaged for Fedora, and one of them (gitui) has added a new dependency on the "notify-debouncer-mini" crate. (GitHub project: https://github.com/notify-rs/notify) However, I think the license of both the "notify-debouncer-mini" crate (which is not packaged yet) and the "notify" crate as currently packaged are possibly problematic: The project was initially licensed "CC0-1.0", but was relicensed to "CC0-1.0 OR Artistic-2.0" with recent releases. This is reflected in the project's metadata, which claims "license = CC0-1.0 OR Artistic-2.0". However, reading the project's README, this is not accurate - old code was not relicensed, so it is still "CC0-1.0"-only, and only new code is dual-licensed as "CC0-1.0 OR Artistic-2.0": https://github.com/notify-rs/notify#license So if I understand this correctly, the SPDX identifier in the project metadata is wrong (should be "CC0-1.0 AND Artistic-2.0" instead). It looks like this was not noticed when the "notify" crate in Fedora was updated to this version, and as a result, the license tag of the package is currently inaccurate (i.e. "Artistic-2.0"). Additionally, the file that includes the license text for the Artistic-2.0 license contains this additional amendment from the project's author: """ Copyright © 2018 Félix Saparelli Any action relating to this license may only be brought in New Zealand. """ ref. https://github.com/notify-rs/notify/blob/main/LICENSE.ARTISTIC#L1-L2 I have no idea if this is a valid thing to do, but it looks at least potentially problematic.There have been discussions about this project's license in the past (because "CC0-1.0 OR Artistic-2.0" is a very weird license for the Rust ecosystem, which almost exclusively uses "MIT", "Apache-2.0", or "MIT OR Apache-2.0" for projects). I'm unsure how to proceed here. The "notify" crate has already been packaged for a while, so it was not covered by the "no packages must use the 'CC0-1.0' license" rule yet, but the "notify-debouncer-mini" crate was essentially split off from the main "notify" crate, so it shares its license. If the license terms of this project are indeed problematic, what would be the way to proceed? There is one existing application (alacritty) in Fedora that depends on this library, and the latest version of gitui (not updated yet) also added a dependency on it. It's the only popular cross-platform library for watching filesystem events, with over 700K downloads - no alternatives comes close to that, so I'm not sure if recommending upstream projects to migrate to a different library would be possible. Thanks, Fabio

2 3

Support of modern file formats in exiv2
by Mattia Verga 14 Aug '23

14 Aug '23

I have found an old (2021) ticket in BZ regarding exiv2 support being disabled for some modern file formats. https://bugzilla.redhat.com/show_bug.cgi?id=1979565 There it is said that the ticket is awaiting for some conclusion from Fedora Legal, yet I cannot find any discussion was ever opened here on ML, nor any comment was ever posted by legal there. Can someone drop a comment there? BTW support in exiv2 is now enabled by default, but disabled in Fedora specfile. Thanks.

2 1

License of perl-Data-UUID
by Jitka Plesnikova 09 Aug '23

09 Aug '23

Hi, I want to update License tag to SPDX format in perl-Data-UUID [1], and the Makefile.PL in source is declared as being BSD: https://metacpan.org/release/RJBS/Data-UUID-1.226/source/Makefile.PL#L75 There is no text which contains any variant of BSD license. However, it also contains this file: https://metacpan.org/release/RJBS/Data-UUID-1.226/source/LICENSE It was approved as HP-1989 [2]. The issue to clarify the license was already reported to upstream [3], but it wasn't solved yet. Current License tag for the package is "BSD and MIT". Could you please help me to find correct License tag value? Thank you, Jitka [1] https://src.fedoraproject.org/rpms/perl-Data-UUID [2] https://github.com/spdx/license-list-XML/issues/2019#issuecomment-1634809827 [3] https://github.com/bleargh45/Data-UUID/issues/26 -- Jitka Plesnikova Senior Software Engineer Red Hat

2 1

kickstart files and trademark licensing question on Ask Fedora
by Matthew Miller 07 Aug '23

07 Aug '23

https://discussion.fedoraproject.org/t/does-distributing-a-kickstart-file-c… -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

2 4

Assessment of Fedora legal/license policies
by Richard Fontana 06 Aug '23

06 Aug '23

It's been about a year since Fedora switched from the Callaway system [1] to the use of SPDX identifiers for purposes of package license metadata and license classification, along with the publication of significantly revamped and rationalized documentation relating to Fedora legal issues [2]. This provides a good opportunity to look back and identify any aspect of those changes that is not working well or could use reformulation or other improvement. The only things I see as 'closed' are: 1. Use of SPDX expressions in place of Callaway notation (for the specific purposes for which Callaway notation was used in the past). Despite the faults and limitations of SPDX, at this point I can't see how a return to the Callaway system would be justified, and there is no viable alternative license expression system that I'm aware of. I also think overall the migration to SPDX has been pretty successful thus far. 2. Rejection of undefined standards or methodologies for license characterization, particularly the application of "effective license theory". At least, I haven't yet seen any viable proposal for a well-defined set of rules around so-called effective licenses. 3. The principle that SPDX identifiers should mean approximately what the SPDX group seems to understand them to mean, bearing in mind that SPDX itself may have some contradictory or non-well-defined assumptions about this. For example, I would not want to see a superficial use of SPDX identifiers where, in reality, Fedora was cryptically forking that part of the SPDX spec to significantly redefine what particular SPDX identifiers are supposed to mean. There are a few specific issues that I plan to call attention to in one or more separate threads but any thoughts on this are very welcome. [1] https://en.wikipedia.org/wiki/Callaway_system [2] https://docs.fedoraproject.org/en-US/legal/ Richard

2 1

relaxng-datatype license
by Marián Konček 06 Aug '23

06 Aug '23

It looks like this project (https://github.com/java-schema-utilities/relaxng-datatype-java) will need to be added to Fedora as a part of jaxb 4.0.2 -> 4.0.3 update. The sources of this package have already been bundled and differently namespaced part of jaxb (see https://koji.fedoraproject.org/koji/rpminfo?rpmID=35187399) and present in Fedora. The jaxb project decided to unbundle them and depend on the upstream relaxng. The upstream relaxng has no LICENSE but from other sources it is more-less clear that it should be BSD: * https://relaxng.org/ * https://sourceforge.net/projects/relaxng/ * comment from Richard Fontana in open Issues in GitHub (https://github.com/java-schema-utilities/relaxng-datatype-java/issues/1) Nevertheless I would need to be completely sure that I can declare the package as being BSD-4-Clause, if I wanted to add it to Fedora. Can I get an official statement from Fedora legal team regarding acceptability of this package? -- Marián Konček

2 3

Fwd: SPDX Statistics - Flock edition
by Miroslav Suchý 05 Aug '23

05 Aug '23

-------- Přeposlaná zpráva -------- Předmět: SPDX Statistics - Flock edition Datum: Sat, 5 Aug 2023 08:07:55 +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> Two weeks ago we had: > * 23102 spec files in Fedora > > * 29514license tags in all spec files > > * 17401 tags have not been converted to SPDX yet > > * 6486tags can be trivially converted using `license-fedora2spdx` > > * Progress: 41.04% ░░░░██████ 100% > > ELN subset: > > 1125 out of 3083 packages are not converted yet > Today we have: * 22983 spec files in Fedora * 29406license tags in all spec files * 16915 tags have not been converted to SPDX yet * 6242tags can be trivially converted using `license-fedora2spdx` * Progress: 42.48% ░░░░██████ 100% ELN subset: 986 out of 2500 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 13 new licenses. New version of license-validate has been released too. It includes improvement that I gathered during Flock - thank you Sandro. 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-12-19 (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: Do you want to validate your License string? Use: license-validate "$YOUR_LICENSE_STRING" Why SPDX Flock edition? Because this week was Flock. You can watch the recordings from: https://www.youtube.com/playlist?list=PL0x39xti0_64OcXEGLCtoI4nouADqaTcT or use the links from the schedule https://flock2023.sched.com/ There was a talk about SPDX and workshop where we converted some packages. Thanks to all participants! 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 August 2023