legal December 2022

legal@lists.fedoraproject.org

12 participants
9 discussions

Request to stop hobbling crypto libraries
by Neal Gompa 12 Sep '24

12 Sep '24

Hey all, As part of the discussion going on about Mesa on devel@, the situation around OpenSSL was brought up, and Adam Williamson brought up that we might not need to hobble OpenSSL anymore[1]. A quick check seems to indicate we no longer do it for GnuTLS either, and haven't for many years[2]. Could we just drop all this stuff and use pristine OpenSSL sources? All the crypto algorithm usability stuff is controlled through crypto-policies, so I don't think it makes sense to do this anymore for OpenSSL since all the patents indicated in the script have expired for a couple of years now[3]. Dropping this will eliminate a chunk of cruft that nobody needs around anymore and simplify OpenSSL maintenance. [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [2]: https://src.fedoraproject.org/rpms/gnutls/c/46d865d8451be0f4576dcc56841175a… [3]: https://src.fedoraproject.org/rpms/openssl//blob/rawhide/f/hobble-openssl -- 真実はいつも一つ！/ Always, there's only one truth!

7 16

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

Permissibility of P-434 based elliptic curve in Fedora
by Fabio Valentini 30 Apr '23

30 Apr '23

Hello, During package review of the fiat-crypto Rust library, I noticed that it contains an implementation of an elliptic curve (p434) which isn't mentioned on the "good" list here: https://fedoraproject.org/wiki/Legal:ECC I also can't find any references or sources for this curve (search results for P-434, p434, and curve434 all come up empty). The only mention of "p434" with respect to cryptography is in this Microsoft project: https://github.com/microsoft/PQCrypto-SIDH And looking at the source code, I'm not even sure whether the P-434 curve in fiat-crypto is at all related to SIKEp434 / SIDHp434 schemes that are mentioned there, other than the fact that they happen to be based on the same prime number (2^216 * 3^137 - 1). Given that there's no mention of any elliptic curves that use p434 on the internet (that I could find), is it OK to ship it in a Fedora package, or do we need to remove it from the sources? ref. https://bugzilla.redhat.com/show_bug.cgi?id=2005536 Fabio

2 4

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

How to handle CC0 in .NET 7 (dotnet7.0) ?
by Omair Majid 15 Jan '23

15 Jan '23

Hi, I am trying to package .NET 7 in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2142178 (This is a new package, though it's "just" an updated version of the .NET 6 package that we already include in Fedora.) The reviewer has helped identify that the source code archive includes a few files that include notes about Creative Commons. I am looking on advice on how to handle it. I found basically these 7 non-content files that have a pointer to creativecommons.org: https://github.com/dotnet/runtime/tree/main/src/libraries/System.Private.Co… https://github.com/dotnet/runtime/tree/main/src/libraries/System.Private.Co… These two files have an MIT license header in addition to the comment that the code is based on an algorithm originally licensed under CC0. These files are a critical part of .NET that we absolutely need to build and include in Fedora. Can I ignore the comment about CC0 because of the MIT license header in the file? Is it safe to treat these files as under MIT only? If not, what are my options to handle this piece of code? https://github.com/dotnet/fsharp/tree/main/tests/benchmarks/CompiledCodeBen… https://github.com/dotnet/fsharp/tree/main/tests/FSharp.Core.UnitTests/FSha… https://github.com/dotnet/fsharp/tree/main/tests/FSharp.Core.UnitTests/FSha… These 3 don't have an MIT or Apache header. Only a Creative Commons header. Given that these files are benchmarks and unit tests that we don't run during the build, I suppose I can just delete these files? Do I need to delete them from the source archive or can I delete them in %prep? Are other/easier options on the table here? https://github.com/dotnet/runtime/tree/main/src/mono/mono/utils/dlmalloc.c https://github.com/dotnet/runtime/tree/main/src/mono/mono/utils/dlmalloc.h These are under CC-PDDC and hence acceptable without any issues, right? It looks like newer versions of dlmalloc use CC0 and so are unacceptable to Fedora? Is there any guidance I can share with .NET upstream in terms of the impact of eventually switching to the newer version of dlmalloc? Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0

5 17

Guidelines for dealing with licensing issues in distributed packages
by Florian Weimer 13 Jan '23

13 Jan '23

What's the best way to raise licensing issues in already-added packages? I think there are largely two cases: * Fedora and its distributors comply with the licensing terms, but the license is not obviously on Fedora's allowed list. An example would be an obscure field-of-use restriction (as in the JSON license). * Fedora and its distributors appear violating the license. An example would be a package that ships a pre-built Linux kernel binary without the required GPL notices, and without corresponding soruce code. Do these two cases need to be treated differently? In the past, I may have filed bugs in Bugzilla, but this might be construed as a bit rude. I looked at <https://docs.fedoraproject.org/en-US/legal/> and couldn't find any discussion of this topic. Sorry if I missed it. Thanks, Florian

6 10

rust-regex-syntax package license change: added Unicode-DFS-2016 license
by Fabio Valentini 04 Jan '23

04 Jan '23

Hi all, With the update to the regex-syntax crate package that I'm building right now, the license will change from "MIT OR Apache-2.0" to "(MIT OR Apache-2.0) AND Unicode-DFS-2016". The project includes code that is derived from Unicode data files, and it already shipped a license text for the Unicode-DFS-2016 license for this reason - but the SPDX license string in upstream crate metadata doesn't reflect this fact. It also appears that the inclusion of the additional license file was made after the package was initially reviewed for Fedora, and as a result, previous versions of this package didn't include the Unicode license in its License tag. I have also opened an upstream discussion about this, since I believe that the upstream license specifier is wrong (i.e. missing " ... AND Unicode-DFS-2016"), but upstream developers don't appear convinced (even though similar changes were already made in equivalent cases for other Rust projects): https://github.com/rust-lang/regex/discussions/933 This change will probably have at least some "ripple effect" across Rust packages in Fedora once they are rebuilt against this new version, since basically everything depends on the "regex" crate (which depends on regex-syntax), either directly, or indirectly. I'm pretty sure that this package now has the the correct license tag (i.e. project has two parts: first part is dual-licensed "MIT OR Apache-2.0", second part is derived from Unicode data and is licensed "Unicode-DFS-2016", so the license tag should reflect *both* parts), but if I am wrong about this, please get my attention, so I can revert this change in a timely manner. Fabio

2 4

What is this simple license called?
by Björn Persson 10 Dec '22

10 Dec '22

The manual for XMLada comes with this statement: | Copyright (C) 2000-2002, Emmanuel Briot | | Copyright (C) 2003-2011, AdaCore | | This document may be copied, in whole or in part, in any form or by | any means, as is or with alterations, provided that (1) alterations | are clearly marked as alterations and (2) this copyright notice is | included unmodified in any copy. That's all of it. The upstream source is here: https://github.com/AdaCore/xmlada/blob/master/docs/index.rst What shall we call this license in SPDX notation? Björn Persson

1 0

Re: What license should be used for package that contains "Redistributable, no modification permitted" binaries?
by Miro Hrončok 07 Dec '22

07 Dec '22

On 02. 12. 22 8:23, Sun, Yunying wrote: > Hi, > > I'm packaging linux-sgx SDK for Fedora, with review request ticket: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2085444 > <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2085444> > > linux-sgx has some Intel signed binaries included such as > libsgx_{qve,tdqe,id_enclave,pce,qe3,le,qe,pve}.signed.so, as stated in License.txt: > > https://github.com/intel/linux-sgx/blob/master/License.txt > <https://github.com/intel/linux-sgx/blob/master/License.txt> > > According to > https://fedoraproject.org/wiki/Licensing:SoftwareTypes#Binary_Firmware > <https://fedoraproject.org/wiki/Licensing:SoftwareTypes#Binary_Firmware>, it has: > > /The License tag for any firmware that disallows modification must be set to: > "Redistributable, no modification permitted"/ > > So I added "Redistributable, no modification permitted" to the “License:” in > spec file: > > https://yunyings.fedorapeople.org/sgxsdk.spec > <https://yunyings.fedorapeople.org/sgxsdk.spec> > > In recent review comment, Miro suggested that this "Redistributable, no > modification permitted" is not appropriate for license name. > > But going through all licenses on > https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ > <https://docs.fedoraproject.org/en-US/legal/allowed-licenses/>, I can’t find > the right license for these Intel signed binaries. > > Could you point me to the right license, or if none exists for this case, guide > me how to proceed? Thank you. I think that each such license now needs to be reviewed separately. See https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1#I_maintain_a_f… Legal folks, note that this is not a firmware per se, but FESCo approved to treat it as such, pending legal review, in https://pagure.io/fesco/issue/2153 """ FESCo permits the use of pre-signed Intel SGX components under the firmware clause of the Licensing Guidelines, provided that Fedora Legal concurs. """ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal December 2022