legal November 2024

legal@lists.fedoraproject.org

7 participants
6 discussions

Sleepycat license with SaaS restriction
by Florian Weimer 08 Jul '25

08 Jul '25

cryptlib is licensed under the Sleepycat license with a SaaS restriction: “Note that decoupling the software from the user, for example by running in a SaaS configuration, does not exempt you from these requirements.” (Full text attached.) This was not part of the original Sleepycat license, so a new license tag is required. Maybe this license is not even free; this additional clause seems to be a restriction on use. But perhaps it is not so different from the AGPL. Thanks, Florian

6 8

Usage of modified DUMB library with license patches
by Alexey Lunev 02 Dec '24

02 Dec '24

Hi everyone! I want to bring `zmusic` into Fedora, but there is some issues with licensing. ZMusic uses DUMB library, which has unusual DUMB-0.9.3 license[0], but it is basically zlib license with extra clauses which can restrict it to count as free and accepted license. Fedora already has `dumb ` package, it patches[1] license to make it equivalent to zlib, with permission from original authors[2]. It was 18 years ago. I cannot use this package, because DUMB library, which is bundled with ZMusic, is heavily modified[3]. Is it OK to do the same, or do i need to ask permission from authors again? [0]: https://github.com/kode54/dumb/blob/master/LICENSE [1]: https://src.fedoraproject.org/rpms/dumb/blob/rawhide/f/dumb-0.9.3-license-c… [2]: https://src.fedoraproject.org/rpms/dumb/blob/rawhide/f/license-clarificatio… [3]: https://github.com/ZDoom/ZMusic/blob/master/licenses/legal.txt#L15-L19

3 4

License change between Unicode 15.0.0 and 15.1.0? Unicode-DFS-2016 vs. Unicode-3.0
by Fabio Valentini 27 Nov '24

27 Nov '24

Hi all, The upstream project of one of the packages I maintain has changed its license metadata from `(MIT OR Apache-2.0) AND Unicode-DFS-2016` to `(MIT OR Apache-2.0` AND Unicode-3.0` in the last release: https://github.com/dtolnay/unicode-ident/pull/28 The Unicode-DFS-2016 license text is indeed no longer available from the unicode.org website, where it has been replaced with the Unicode-3.0 license text. As far as I know, the Unicode-DFS-2016 license was applicable to code derived from Unicode data - is this no longer the case? Has the Unicode-3.0 license replaced it for this purpose? If this is indeed the case, does this need to be reflected in other places (like the Rust standard library / compiler), which reference the old Unicode-DFS-2016 license text, too? Fabio

2 2

Fwd: SPDX Statistics - 305 packages remaining
by Miroslav Suchý 22 Nov '24

22 Nov '24

-------- Přeposlaná zpráva -------- Předmět: SPDX Statistics - 305 packages remaining Datum: Fri, 22 Nov 2024 08:24:46 +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: - I walked through all packages with "Public Domain" license. For all such packages I identified the public domain dedication and added it to https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/public-doma… Richard F. did the review and I opened PRs for such packages to change the license to LicenseRef-Fedora-Public-Domain. There are about 30 PRs wating to be merged. In several cases I had to open issue as the public domain dedication is not easy and has some sort of problem. - Unfortunately in several cases, the evaluation of dedication (either public domain or "Redistributable") was found as not good enough. I.e. the license is not allowed. Several packages has been already retired in Fedora Linux because of that. You can track it here: https://bugzilla.redhat.com/show_bug.cgi?id=2310597 - I started walking through "Redistributable, no modification permitted" that is usually used in firmware package. It is much smaller set of packages compared to Public Domain set. I should have it done by next report. But the analysis is much harder. - sometimes you used in License tag deprecated license id https://spdx.github.io/spdx-spec/v2.3/SPDX-license-list/#a3-deprecated-lice… Note that while we usually abbreviate the communication that you must use SPDX ID, but there is silent part "and approved for usage in Fedora Linux". I.e. such ID must be in fedora-license-data. And these deprecated ID are not there (and never will be). - We have 59 open issues for fedora-license-data https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?sort=updated_… From past experience, you should expect that it will take about 3 months to proceed all these issues. - For most packages the license change is "just" committed to dist-git. The change in binary RPM will be visible after next mass rebuild (scheduled to 2025-01-15). Two weeks ago we had: > * 24311spec files in Fedora > > * 30967license tags in all spec files > > * 360 tags are not SPDX complient (number from line bellow minus packages with LicenseRef-Callaway-*) > > * 2658 tags have not been converted to SPDX yet > > * 86 tags can be trivially converted using `license-fedora2spdx` > > * Progress: 98.84% ░░░░░░░░░█100% > > ELN subset: > 68 out of 2310 packages are not converted yet (progress 97.06%) > Today we have: * 24340spec files in Fedora * 30993license tags in all spec files * 305 tags are not SPDX compliant (number from line bellow minus packages with LicenseRef-Callaway-*) * 2587 tags have not been converted to SPDX yet * 56 tags can be trivially converted using `license-fedora2spdx` * Progress: 99.02% ░░░░░░░░░█100% ELN subset: 62 out of 2313 packages are not converted yet (progress 97.32%) Graph of these data 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… Packages that are neither in SPDX nor in Callaway format (highest priority for now) - 59 packages: https://pagure.io/copr/license-validate/blob/main/f/neither-nor-remaining-p… Most of such packages has open issue in fedora-license-data. A lot of them are waiting for SPDX to approved the license and assign ID. New version of fedora-license-data has been released. With: 7 new licenses and lots of public domain dedications and several firmware licenses 12 licenses are waiting to be reviewed 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-11-30 (+13 days from last report). Pure linear approximation. This information no longer makes sense. Most of the packages are already SPDX compliant and for most of the remaining packages we have open issue that will take weeks/months to be resolved. I will remove this prediction from future reports. 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. Miroslav

1 0

SPDX tag for this Unicode source license
by Peter Lemenkov 21 Nov '24

21 Nov '24

Hello! I've stumbled upon the following legal text (a bunch of usually bundled UTF-conversion routines are licensed under this one): ``` Copyright 2001-2004 Unicode, Inc. Disclaimer This source code is provided as is by Unicode, Inc. No claims are made as to fitness for any particular purpose. No warranties of any kind are expressed or implied. The recipient agrees to determine applicability of information provided. If this file has been purchased on magnetic or optical media from Unicode, Inc., the sole remedy for any claim will be exchange of defective media within 90 days of receipt. Limitations on Rights to Redistribute This Code Unicode, Inc. hereby grants the right to freely use the information supplied in this file in the creation of products supporting the Unicode Standard, and to make copies of this file in any form for internal or external distribution as long as this notice remains attached. ``` What's the proper SPDX tag for this one? License checking tool during the fedora-review says its "Unicode strict" but license-fedora2spdx doesn't know about this one although it is a quite popular one according to GitHub * https://github.com/search?q="This+source+code+is+provided+as+is+by+Unicode%2C+Inc"&type=code -- With best regards, Peter Lemenkov.

2 2

Fedora SPDX ID for CRC32 License
by Ian McInerney 08 Nov '24

08 Nov '24

I posted this as a comment in one of the old license review issues here https://gitlab.com/fedora/legal/fedora-license-data/-/issues/512#note_20755…, but it doesn't seem to have been noticed. Basically, in the license data there is a file for "LicenseRef-CRC32" here https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/data/Licens…, listing it as allowed and with the expression for the license line as "LicenseRef-CRC32". However, then there was a review request for that same license in https://gitlab.com/fedora/legal/fedora-license-data/-/issues/512 which ended up saying that the license identifier should be "LicenseRef-Fedora-UltraPermissive", and doesn't seem to mention the existing "LicenseRef-CRC32" in the license data. So, my question is, which is the proper expression to use for this license given that it seems there are now two expressions for it?

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal November 2024