legal August 2022

legal@lists.fedoraproject.org

13 participants
18 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

4 6

Brainpool Curves in Fedora (openssl, libgcrypt, gnupg)
by Timothée Ravier 21 May '24

21 May '24

Hi everyone, The ECC Brainpool Curves [1][2] are currently not available in Fedora as according to this BZ [3], this needs Fedora Legal approval. Could someone from the legal team take a look to see if there are any blockers regarding Brainpool Curves inclusion in Fedora? Thanks! [1] https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Implementation [2] https://tools.ietf.org/html/rfc5639 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1413618

14 31

Henry Spencer's license
by Petr Šabata 06 Mar '23

06 Mar '23

Dear legal, While checking the contents of our `perl' package, I noticed the following: (...) /* NOTE: this is derived from Henry Spencer's regexp code, and should not * confused with the original package (see point 3 below). Thanks, Henry! */ /* Additional note: this code is very heavily munged from Henry's version * in places. In some spots I've traded clarity for efficiency, so don't * blame Henry for some of the lack of readability. */ /* The names of the functions have been changed from regcomp and * regexec to pregcomp and pregexec in order to avoid conflicts * with the POSIX routines of the same names. */ (...) * pregcomp and pregexec -- regsub and regerror are not used in perl * * Copyright (c) 1986 by University of Toronto. * Written by Henry Spencer. Not derived from licensed software. * * Permission is granted to anyone to use this software for any * purpose on any computer system, and to redistribute it freely, * subject to the following restrictions: * * 1. The author is not responsible for the consequences of use of * this software, no matter how awful, even if they arise * from defects in it. * * 2. The origin of this software must not be misrepresented, either * by explicit claim or by omission. * * 3. Altered versions must be plainly marked as such, and must not * be misrepresented as being the original software. * **** Alterations to Henry's code are... **** **** Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, **** 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 **** by Larry Wall and others **** **** You may distribute under the terms of either the GNU General Public **** License or the Artistic License, as specified in the README file. (...) You can see the whole file here: https://metacpan.org/source/SHAY/perl-5.20.1/regexec.c I looked but couldn't find any common name for this license of Henry's. Is it on our list? Is it free? What name should I use in the License tag? Thank you, Petr

5 9

about openssl we may enable and build all elliptic curves on corp ?
by Sérgio Basto 05 Nov '22

05 Nov '22

Hello, I reopen or start thinking again on this question of enable elliptic curves of openssl [1] So going directly to the point, may I built all source of openssl in copr [2] ? or at least some other curves that fedora package don't ship? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1405843 [2] Version: 1.0.2k %global fips_version 2.0.14 I mean sources: http://ftp.o penssl.org/source/openssl-%{version}.tar.gz and http://ftp.openssl.org/s ource/openssl-fips-%{fips_version}.tar.gz Thanks , -- Sérgio M. B.

4 6

license submissions to SPDX on behalf of Fedora
by Jilayne Lovejoy 02 Sep '22

02 Sep '22

Hi all, Richard has been very busy reviewing licenses and related activities, and consequently approx 13 new license submissions to SPDX on behalf of Fedora. See: https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+labe… Some of these have corresponding issues in our Gitlab data repo and labeled as "blocked on SPDX." From the SPDX side to best shepherd these, can I get a little help on two aspects: 1) which of these submissions are priority from a Fedora perspective? That is, are any package maintainers waiting on SPDX (I know some of these are from leftover Fedora licenses we tagged as "needs more research" when we did the initial compare, which seems to suggest it may not be a blocking issue) - comments in the SPDX Github issue would be appreciated as to any that should be prioritized above others. 2) By way of SPDX processes, when a license has been determined to be accepted, we ask the submitter to help prepare the files for the SPDX license data. However, I'm not sure if Richard should be on the hook for all of these! Can anyone else from the Fedora legal community offer to help with this part? If so, indicate in the relevant issue and SPDX folks will point you to documentation to explain the process further (it's pretty easy, even I can do it) Thanks! Jilayne

2 2

rpmlint and SPDX licenses: W: invalid-license BSD-3-Clause
by Miro Hrončok 31 Aug '22

31 Aug '22

Hello license folks. I see that Fedora's rpmlint is yet to be taught to understand SPDX: python3-lxml.x86_64: W: invalid-license BSD-3-Clause python3-lxml.x86_64: W: invalid-license MIT-CMU Is this support tracked somewhere? I know openSUSE already uses SPDX, so rpmlint probably knows how to read that. Right? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 6

ansible-collection-community-mysql License Change
by Maxwell G 27 Aug '22

27 Aug '22

Hi Fedorians, The license of ansible-collection-community-mysql has been updated from "GPLv3+ and Python" to "GPL-3.0-or-later AND PSF-2.0 AND BSD-2-Clause". See https://src.fedoraproject.org/rpms/ansible-collection-community-mysql/c/242…. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

More Ansible license changes
by Maxwell G 26 Aug '22

26 Aug '22

Hi Fedorians, I'm back with more ansible license updates. Upstream, some of the community Ansible Collections have adopted the REUSE specification, which makes it much easier to determine the overall license. For collections that have adopted this, the license texts are all stored as files in one directory, instead of being spread out throughout the source tree as file headers. I would like to thank the upstream developers for working with me on this. The License tag of ansible-collection-community-general has changed from "GPLv3+ and BSD and Python" to "GPL-3.0-or-later AND BSD-2-Clause AND PSF-2.0 AND MIT". See https://src.fedoraproject.org/rpms/ansible-collection-community-general/pul…. The License tag of ansible has changed from "GPLv3+" to "GPL-3.0-or-later AND Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT AND MPL-2.0 AND PSF-2.0". I cannot claim this to be 100% accurate, but I have done my best to determine the overall license. Note that ansible is a curated bundle of 103 Ansible collections, so this task is a bit difficult. See https://src.fedoraproject.org/rpms/ansible/pull-request/32. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

2 1

Is ECDSA secp256k1 elliptic curve permitted to be packaged in Fedora?
by Miro Hrončok 26 Aug '22

26 Aug '22

Hello legal. I see that ECDSA is already included in Fedora in various packages, so I assume that is OK. This software here: https://github.com/starkbank/ecdsa-python Says: > We currently support secp256k1 [curve]. Is that OK to package in Fedora or not? Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 5

Consider changing the license change announcement policy
by Maxwell G 24 Aug '22

24 Aug '22

Hi Legal folks, Can you please consider removing the following rule? > Fedora package maintainers are expected to announce upstream license > changes that they become aware of on the Fedora devel list. -- https://docs.fedoraproject.org/en-US/legal/license-review-process/#_what_if… This creates unnecessary friction for packagers that simply wish to have correct License fields. I'm also not sure what purposes it serves. Richard explicitly said that Fedora does not concern itself with cross-package license compatibility. And even if it did, a "GPLv3+" to "GPL-3.0-or-later AND MIT" license change shouldn't cause any new license compatibility issues. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

3 3

Updating the Python license tag to SPDX and adjusting the license of Python documentation
by Miro Hrončok 23 Aug '22

23 Aug '22

Hello. I plan to update the license tag of Python interpreters in Fedora from "Python" to "Python-2.0.1". See this PR which added it to fedora-license-data: https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/61 See this PR to Python 3.11 (to be backported to older Pythons later): https://src.fedoraproject.org/rpms/python3.11/pull-request/78 I also plan to update the license of python3-docs to: Python-2.0.1 AND (Python-2.0.1 OR 0BSD) Because examples, recipes, and other code in the documentation are dual licensed under Python-2.0.1/0BSD. This was previously not reflected in the License tag. See this PR: https://src.fedoraproject.org/rpms/python3-docs/pull-request/82 Unfortunately, Python-2.0.1 is still not listed at https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 2

python-ntlm-auth License Correction
by Maxwell G 19 Aug '22

19 Aug '22

I've corrected the license of python-ntlm-auth from LGPLv3+ to MIT. It was relicensed upstream 5 years ago, but the previous maintainer never updated the License field. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

Modified Apache Software licenses
by Benson Muite 17 Aug '22

17 Aug '22

The software wrk[0] is currently under review[1]. It uses a modified Apache Software license[2]. Is this something that can be included in Fedora? 0) https://github.com/wg/wrk/ 1) https://bugzilla.redhat.com/show_bug.cgi?id=2116187 2) https://github.com/wg/wrk/commit/db6da47fe3ee604d70304c8d10896f8349b972da

2 1

Updated IEEE license
by Florian Weimer 09 Aug '22

09 Aug '22

The licensing wiki says that the IEEE license is a “good” documentation license. However, with the 2017 release, IEEE switched to this license: | The Institute of Electrical and Electronics Engineers and The Open Group, | have given us permission to reprint portions of their documentation. | | In the following statement, the phrase ``this text'' refers to portions of | the system documentation. | | Portions of this text are reprinted and reproduced in electronic form in | the Linux man-pages project, from IEEE Std 1003.1-2017, Standard for | Information Technology -- Portable Operating System Interface (POSIX), The | Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 | by The Institute of Electrical and Electronics Engineers, Inc and The Open | Group. In the event of any discrepancy between these versions and the | original IEEE and The Open Group Standard, the original IEEE and The Open | Group Standard is the referee document. The original Standard can be | obtained online at http://www.opengroup.org/unix/online.html . | | This notice shall appear on any product containing this material. <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/man-pages-posix/ma…> This license no longer permits modified redistribution, as far as I can see. Is this still an acceptable documentation license as far as Fedora is concerned? Thanks, Florian

2 4

Change in classification of CC0
by Richard Fontana 05 Aug '22

05 Aug '22

CC0 has been listed by Fedora as a 'good' license for code and content (corresponding to allowed and allowed-content under the new system). We plan to classify CC0 as allowed-content only, so that CC0 would no longer be allowed for code. This is a fairly unusual change and may have an impact on a nontrivial number of Fedora packages (that is not clear to me right now), and we may grant a carveout for existing packages that include CC0-covered code. While we are moving towards a process in which license approvals are going to be done primarily through the Fedora license data repository on gitlab.com, I wanted to note this on the mailing list because of the significance of the change. The reason for the change: Over a long period of time a consensus has been building in FOSS that licenses that preclude any form of patent licensing or patent forbearance cannot be considered FOSS. CC0 has a clause that says: "No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document." (The trademark side of that clause is nonproblematic from a FOSS licensing norms standpoint.) The regular Creative Commons licenses have similar clauses. A few months ago we approved ODbL as a content license; this license contained its own "no patent license" clause. Up till this time, the official informal policy of Fedora has been that 'content' licenses must meet the standards for 'code' licenses except that they can prohibit modification. The new Fedora legal documentation on the license approval categories will note that allowed-content licenses can also have a no-patent-license clause. In a FOSS development and distribution context, the absence of patent licensing for non-software material is of significantly less concern than the software case. Feel free to ask any questions or make any comments about this! Richard

4 6

Updating several packages to SPDX
by Ben Beasley 03 Aug '22

03 Aug '22

I am preparing to update a batch of packages’ License tags to SPDX, with License field changes as reported below. ---------------------------------------- The License field for the agenda package will be updated from an effective license “GPLv3+” to “GPL-3.0-or-later AND GPL-2.0-or-later AND CC0-1.0”. The portion covered by CC0-1.0 is the AppData XML file, which is content. ---------------------------------------- The License field for the appeditor package will be updated from an effective license “GPLv3” to “GPL-3.0-only AND CC0-1.0”. The portion covered by CC0-1.0 is the AppData XML file, which is content. ---------------------------------------- The License field for the arpwatch package will be updated from “BSD with advertising”—which should have been just “BSD”—to “BSD-3-Clause”. ---------------------------------------- The License field for the c4core package will be updated from “MIT and Boost” to “MIT AND BSL-1.0”. ---------------------------------------- The License field for the c4project package will be updated from “MIT and ASL 2.0” to “MIT AND Apache-2.0”. ---------------------------------------- The License field for the cairomm and cairomm1.16 packages will be updated from “LGPLv2+” to “LGPL-2.0-or-later”. ---------------------------------------- The License field for the casc package will be updated from “LGPLv2+” to “LGPL-2.1-or-later”. ---------------------------------------- The License field for the cpp-hocon package will be updated from “ASL 2.0” to “Apache-2.0”. ---------------------------------------- The License field for the debugbreak package will be updated from “BSD” to “BSD-2-Clause”. ---------------------------------------- The License field for the dippi package will be updated from “GPLv3+”—which should have been just “GPLv3”—to “GPL-3.0-only AND CC0-1.0”. The portion covered by CC0-1.0 is the AppData XML file, which is content. ---------------------------------------- The License field for the dr_libs package will be updated from “Unlicense or MIT-0” to “Unlicense OR MIT-0” ---------------------------------------- The License field for the edac-utils package will be updated from “GPLv2+” to “GPL-2.0-or-later”. ---------------------------------------- The License field for the fast_float package will be updated from “ASL 2.0 or MIT” to “Apache-2.0 OR MIT”. ---------------------------------------- The License field for the festival-freebsoft-utils package will be updated from “GPLv2+” to “GPL-2.0-or-later”. Furthermore, the License field for the festival-freebsoft-utils-doc subpackage, previously inherited from the base package, will be updated and corrected to reflect its dual-licensed status: “GPL-2.0-or-later OR GFDL-1.2-no-invariants-or-later”. ---------------------------------------- The License field for the fflas-ffpack package will be updated from “LGPLv2+” to “LGPL-2.1-or-later AND LGPL-2.0-or-later”. ---------------------------------------- The License field for the flatbuffers package will be updated and corrected from “ASL 2.0 and BSD” to “Apache-2.0”. The code previously considered BSD (BSD-3-Clause) is that which is derived from grpc, which has an upstream license of BSD-3-Clause. It is now clear that even code from grpc is intended to be Apache-2.0 in this project. (Google is the copyright holder for both projects, so it can relicense at will.) See https://github.com/google/flatbuffers/pull/7073. ---------------------------------------- The License field for the flintqs package will be updated from “GPLv2+” to “GPL-2.0-or-later”. ---------------------------------------- The License field for the fmidi package will be updated from “Boost” to “BSL-1.0”. ---------------------------------------- The License field for the freexl package will be updated from “MPLv1.1 or GPLv2+ or LGPLv2+” to “MPL-1.1 OR GPL-2.0-or-later OR LGPL-2.1-or-later”. ---------------------------------------- – Ben Beasley

4 3

Re: Important changes to software license information in Fedora packages (SPDX and more!)
by Maxwell G 01 Aug '22

01 Aug '22

Kevin Kofler via devel wrote: > Now you have to compare every word of the MIT license > with the very similar templates such as MIT, MIT-CMU, MIT-feh, etc., and > then figure out which one it actually is. If it is even one of these and not > some random mix of several variants (one sentence from here, one sentence > from there, …). You're right. MIT/BSD License variants are a pain to deal with. In practice, they are mostly equivalent, so having to identify is a burden without a lot of benefit. Currently, there's MIT variants such as the HPND that aren't even part of the new license list, despite being explicitly listed on the old list and being used by packages like libX11[1]. As that license deprecated, it's not likely to cause issues when importing new packages, but it is still used by older packages. There are other examples of licenses missing from the new list that are already blocking new packages[2]. [1]: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/1#note_9695733… [2]: https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/12#not… > But that is how things work in practice. It is just impossible to read > through every source file and scan for copied snippets. They can even appear > in the middle of a file, with the license attached right there. So the > packager and the reviewer will both check the COPYING/LICENSE/LICENCE file > provided by upstream, then go exemplarily through a handful source files to > check that the copyright header and/or SPDX REUSE header matches that > license, and then declare that as the one License. This is onerous if you do it manually, but there are tools to make it a bit easier. You can use scancode-toolkit or licencecheck to scan the entire codebase. I believe the RH legal folks recommended the former at some point, but licensecheck is used by fedora-review and actually packaged in Fedora[^1]. The Legal docs recommend SPDX license-diff[3] and [4] to see if a certain license text exists in SPDX. [^1]: I wish luck to anyone who tries to package tries to package scancode. There are quite a few unpackaged dependencies... [3]: https://addons.mozilla.org/en-US/firefox/addon/spdx-license-diff/ [4]: https://tools.spdx.org/app/check_license/ -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

Important changes to software license information in Fedora packages (SPDX and more!)
by Matthew Miller 31 Jul '22

31 Jul '22

On behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce! New docs site for licensing and other legal topics -------------------------------------------------- All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at: https://docs.fedoraproject.org/en-US/legal/ Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki. Fedora license information in a structured format ------------------------------------------------- The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at: https://gitlab.com/fedora/legal/fedora-license-data This data is then presented in easy tabular format in the documentation, at: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ New policy for the License field in packages — SPDX identifiers! ---------------------------------------------------------------- We’re changing the policy for the "License" field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects. Updated licensing policies and processes ---------------------------------------- Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated. New guidance on “effective license” analysis -------------------------------------------- Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way. When do these changes take effect? ---------------------------------- The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that! Thank you everyone! ------------------- A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums. Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

5 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal August 2022