legal September 2022

legal@lists.fedoraproject.org

10 participants
10 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

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

SPDX progress
by Miroslav Suchý 10 Oct '22

10 Oct '22

I was curious how many packages are already converted to SPDX. I downloaded all spec files and count how many of them contains "spdx" string (case insensitive). Assuming most packagers mention it either in changelog or in comment near License field. The string is in 347 out of 23155 spec files. That is less than 2% of packages. It is wild guess with many incorrect of assumtions, but I guess the order of magnitude is correct. That is just FYI. I will not do anything to progress faster, because `fedora-license-data` has enough issues (and mainly flow of new issues). Miroslav

6 7

Mesa patented codecs approval
by Robert-André Mauchin 27 Sep '22

27 Sep '22

Hello, So recently Mesa disabled by default patented codecs. They added an option to re-enable it with -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec Dave Airlie elected to not include this line in: https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe4… because "we don't have legal approval for this". Could it be waived by legal to be re-enabled? Not having basic h264 decoding is quite taxing. And we all already pay patents when buying the video card. Best regards, Robert-André fas: eclipseo

2 1

Correction of libpri License field
by Ben Beasley 22 Sep '22

22 Sep '22

As a temporary measure, the License field for the libpri package will be corrected from “GPLv2+” to “GPLv2 with exceptions”. This reflects a re-review of package contents rather than an upstream change. The specific exceptions have been submitted to the fedora-license-data repository for legal review, and the License field will be further updated to use SPDX notation once that process is complete. https://gitlab.com/fedora/legal/fedora-license-data/-/issues/75 https://gitlab.com/fedora/legal/fedora-license-data/-/issues/76 – Ben Beasley (FAS music)

1 0

Correct link to spdx.org
by Miroslav Suchý 06 Sep '22

06 Sep '22

Working on the script generating documentation.... What is correct link for this license to spdx.org? License: GPL-2.0-only WITH Classpath-exception-2.0.html My script naively assume https://spdx.org /licenses/GPL-2.0-only WITH Classpath-exception-2.0.html Which does not exists. Is it: https://spdx.org/licenses/GPL-2.0-with-classpath-exception.html or https://spdx.org/licenses/LGPL-2.0-only.html for the part "GPL-2.0-only" https://spdx.org/licenses/Classpath-exception-2.0.html for the part "Classpath-exception-2.0". So correct adoc string will be https://spdx.org/licenses/LGPL-2.0-only.html[GPL-2.0-only] WITH https://spdx.org/licenses/Classpath-exception-2.0.html[Classpath-exception-… Miroslav

2 1

Updating old FSF address in license
by Mattia Verga 06 Sep '22

06 Sep '22

Hello, I've started the package process for Xephem, an astronomy ephemeris program, but I've found that some headers and the license file of a bundled (*) library still report the old FSF address. I've asked upstream to update the address with a patch [1], but, indeed, they've pointed me to https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address where it's said that the license file itself should not be patched. How should I interpret that statement? Should I leave the old address in the license and update only the headers, or should I replace the LICENSE file with an updated version from FSF (which, I suppose, it will result in the same patch)? Is it fine to replace the license file of a bundled (*) library? (*) the bundled library is not available anywhere else, AFAIK, so it doesn't make sense to unbundle it. Mattia [1] https://github.com/XEphem/XEphem/pull/57

2 1

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal September 2022