legal February 2022

legal@lists.fedoraproject.org

14 participants
13 discussions

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

FIGlet fonts
by Lyes Saadi 25 Jul '22

25 Jul '22

Hello Legal, I'm bringing back a discussion from 2012[1]: Figlet fonts! Indeed, I am trying to package python-pyfiglet[2] as a dependency for other packages. But, after the review, it came up that a lot of weird fonts were included. At the time, I didn't know anything about the discussion, and decided to abort everything. Recently though, a developer contacted me through the bug report, and proposed to help on the issue. He triaged the fonts and separated them depending on whether they were Open-Source or not, and we were thus able to create a clean package with none of the problematic fonts in it. In that discussion[3], emerged the fact that a discussion over this already happened ([1]), but it seems that either no consensus was reached, or that such consensus was lost to time as I wasn't able to find any conversation on figlet either on legal or devel mailing lists archives. And, it seems that the issue was just simply avoided since figlet ended up removing the problematic fonts anyway. But, upstream would like to keep the problematic fonts if possible in Fedora. And so, I would like to ask Legal to either give me the answer, if it actually was a settled matter, or to reach a consensus on Figlet fonts. To resume the situation (as I understand it, I am not a lawyer, obviously): In the US, fonts glyphs are not copyright-able as it is considered insufficiently creative. For the same reason, Bitmap fonts (fonts defined pixel by pixel) are also not copyright-able, as they are only considered as data which represents glyphs. But, Vector fonts (fonts defined using drawing instructions and code), is, on the other hand, copyright-able because it is defined through a software code. Then, we come to Figlet fonts. For those not aware of what Figlet fonts, they are also known as ASCII fonts: __ __ ____ __ ____ / / / /__ / / /___ / / ___ ____ _____ _/ / / / /_/ / _ \/ / / __ \ / / / _ \/ __ `/ __ `/ / / / __ / __/ / / /_/ / / /___/ __/ /_/ / /_/ / /_/ /_/ /_/\___/_/_/\____( ) /_____/\___/\__, /\__,_/_(_) |/ /____/ The issue with those is that no ruling (as far as I know) ever concerned that type of font in US Court. Though, one argument would be that Figlet fonts are similar to Bitmap fonts, as they only contain data about glyphs, and do not, in the same way as Vector fonts do, contain code giving to the computer drawing instructions for the fonts. As such Figlet fonts are not modular, or extensible, they just contain raw data about a font. But still, all this is speculation, and, as I said, I am not a lawyer, so I don't have any slight idea if such a defense would hold in court. I hope to have resumed the situation clearly enough and that I didn't make any mistake. Greetings, Lyes Saadi [1]: https://bugzilla.redhat.com/show_bug.cgi?id=820642 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1876108 [3]: https://github.com/pwaller/pyfiglet/issues/89 PS: Can we remove the FE-legal blocker from the review request now that all the fonts have been sorted out?

4 8

Draft attempt to define Fedora license categories
by Richard Fontana 24 Jul '22

24 Jul '22

Greetings, As part of some ongoing efforts to improve information relating to Fedora licensing and licensing policy, we want to provide better documentation around the various license approval categories for Fedora, as currently set forth here: https://fedoraproject.org/wiki/Licensing:Main but which probably will live in the future on docs.fedoraproject.org. Here's a rough draft which I wanted to publish here for review. Feedback/criticisms/suggestions welcome. Side note: This preserves Tom Callaway's historical usage of "good" to mean "Fedora-approved", but I have mixed feelings about this terminology. 1. Licenses for Code “Code” means software code, any other functional material whose principal purpose is to control or facilitate the building of packages, such as an RPM spec file, and other kinds of material that the Fedora Council has classified as "code" rather than "content", but does not include font files. [Comment: This annoyingly and confusingly does not line up with definitions in the FPCA, but Fedora should get rid of the FPCA anyway] A license for code is “good” if the Fedora Project determines that the license is a free/libre//open source license. [Not sure if it's helpful to add the following:] In making this determination, Fedora historically relied primarily on the Free Software Definition as maintained and interpreted by the Free Software Foundation, but out of necessity Fedora passed judgment on many licenses never addressed by the FSF and, in the process, built up an informal body of interpretation and policymaking (admittedly, mostly undocumented) that went far beyond what the FSF had done. Fedora has also sometimes considered the decisions of other community Linux distributions and other important efforts to define and apply FLOSS norms, most notably the OSI’s Open Source Definition. In a small number of cases, Fedora has disagreed with decisions of the FSF and OSI regarding whether particular licenses are FLOSS. 2. Licenses for Documentation Any license that is good for code is also good for documentation. In addition, Fedora may designate a license as good for documentation if (a) the license meets the standards for good licenses for code, (b) the license is designed primarily for technical documentation or otherwise has a history of substantial use in free software communities for documentation, and (c) the license is not commonly or normally used for code. [Comment: this feels unsatisfactory to me, for multiple reasons, but I think it does accurately represent the historical Fedora policy.] 3. Licenses for Content “Content” means any material that is not code, documentation, fonts or binary firmware. Any license that is good for code is also good for content. In addition, Fedora may designate a license as good for content if it restricts or prohibits modification but otherwise meets the standards for good licenses for code. 4. Licenses for Fonts Any license that is good for code is also good for fonts. In addition, Fedora may designate a license as good for fonts if it contains a nominal prohibition on resale or distribution in isolation but otherwise meets the standards for good licenses for code. 5. Licenses for Binary Firmware Some applications, drivers, and hardware require binary-only firmware to boot Fedora or function properly. Fedora permits inclusion of these files if they meet certain requirements [currently set forth at: https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware but the non-license part of this needs to move somewhere else ]. Any license that is good for code is also good for binary firmware. In addition, Fedora may designate a particular firmware license as good for firmware if the terms in the license that would not be acceptable in a good code license are limited to the following: * Requirements that the firmware be redistributed only as incorporated in the redistributor's product (or as a maintenance update for existing end users of the redistributor's product), possibly limited further to those products of the redistributor that support or contain the hardware associated with the licensed firmware * Requirements that the redistributor to pass on or impose conditions on users that are no more restrictive than those authorized by Fedora itself with respect to firmware licenses * Prohibitions on modification, reverse engineering, disassembly or decompilation * Requirements that use be in conjunction with the hardware associated with the firmware license Richard

4 6

Re: Package Licensing - Open Data Commons Open Database License (ODbL) License
by Justin Zobel 01 Mar '22

01 Mar '22

Ahh OK. Well, it would make sense to have a combined list. Hopefully, someone on the Fedora side can give me the all OK to include the package based on RHEL's inclusion policy. And I just realised I hit reply instead of reply-all on the email again. On Wed, Feb 16, 2022 at 8:55 AM Richard Fontana <rfontana(a)redhat.com> wrote: > In theory, the Fedora list is the RHEL list, but some time ago Red Hat > started supplementing it internally with another "list" (or compiled > information) resulting from review of results of certain scanning > tools on RHEL package source code. That "list" is not currently public > information. Our current plan is to essentially merge the two license > approval efforts so that there is one single public list of approved > and unapproved licenses. But it will take some time to undertake the > various steps for getting there. > > Richard > > On Tue, Feb 15, 2022 at 5:14 PM Justin Zobel <justin.zobel(a)gmail.com> > wrote: > > > > Thank you Richard. Is there an "Accepted Licenses" page for RHEL? > > > > On Wed, Feb 16, 2022 at 4:40 AM Richard Fontana <rfontana(a)redhat.com> > wrote: > >> > >> On Mon, Feb 14, 2022 at 9:52 PM Justin Zobel <justin.zobel(a)gmail.com> > wrote: > >> > > >> > Thank you for these insights. Are you able to provide a link to the > RHEL review of ODbL for the Fedora license team to refer to in their review > process? > >> > >> Unfortunately in this case there really isn't anything to link to > >> apart from a snarky comment by me about how lengthy the license is :-) > >> > >> Richard > >> > >> > >> > >> > > >> > On Tue, Feb 15, 2022 at 11:52 AM Richard Fontana <rfontana(a)redhat.com> > wrote: > >> >> > >> >> On Mon, Feb 14, 2022 at 6:49 PM Justin Zobel <justin.zobel(a)gmail.com> > wrote: > >> >> > > >> >> > Hi Team, > >> >> > > >> >> > I've just begun packaging for Fedora and of course, I happen to > choose one with a license that needs querying. > >> >> > > >> >> > The Open Data Commons Open Database License (ODbL) is for database > usage in the kpublictransport KDE library. It is used for access to > OpenStreetMap via the KTrip application designed to aid users in navigating > via public transport. > >> >> > > >> >> > From the OpenStreetMap Copyright page on their website: > >> >> > OpenStreetMap® is open data, licensed under the Open Data Commons > Open Database License (ODbL) by the OpenStreetMap Foundation (OSMF). > >> >> > > >> >> > Open Database License: https://opendatacommons.org/licenses/odbl/ > >> >> > Open Street Map: https://www.openstreetmap.org/copyright > >> >> > KDE Source Repository: > https://invent.kde.org/libraries/kpublictransport/ > >> >> > Fedora Source Repository: > https://src.fedoraproject.org/rpms/kpublictransport/ > >> >> > > >> >> > I would like to know if this license is acceptable to Fedora. > >> >> > >> >> This is somewhat interesting as it is the first case I can think of > >> >> where a license that Red Hat has specifically reviewed internally for > >> >> inclusion in Red Hat Enterprise Linux has at a later time come up for > >> >> a decision in Fedora. > >> >> > >> >> We actually approved ODBL for RHEL last year, and I think if we had > >> >> our contemplated merging of RHEL license review and Fedora license > >> >> review in place, it would just end up on the "good" list, but given > >> >> that the new process is not yet established it would probably be a > >> >> good idea to do another review now that it has come up for Fedora. > >> >> > >> >> Richard > >> >> > >> > > > -- > >

4 10

Fedora's shortname -> SPDX
by Miroslav Suchý 28 Feb '22

28 Feb '22

I wrote a script which converts Fedora's shortname to SPDX https://pagure.io/copr/license-validate/blob/main/f/license-fedora2spdx.py It is not packaged yet. You need to have `license-validate` and `rpminspect-data-fedora` packages installed. Plus the script above. In fact you need https://github.com/rpminspect/rpminspect-data-fedora/blob/c06dee22da8db10c6… because the file fedora.json in master and in Fedora's `rpminspect-data-fedora` is not JSON valid. If you go over these obstacles you can try it: $ ./license-fedora2spdx.pyGPLv2 GPL-2.0 $ ./license-fedora2spdx.py'MIT or (GPLv1 and Glide)' Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', 'MI T-enna', 'MIT-feh', 'mpich2'] mpich2 or ( GPL-1.0 and Glide ) I.e. it will honor operators and parenthesis, and if the conversion is straight script will give you the result. If there is some confusion, e.g., Fedora's MIT shortname can be converted to more than one SPDX identifier, it will print a warning. And you should investigate what is the right SPDX identifier. I welcome your comments. I will resolve any issues you will find and then add it to `license-validate` package. I hope this will ease the migration to SPDX when the time comes. Miroslav

3 3

apache / patent / jbig2enc
by Ingmar Lippert 25 Feb '22

25 Feb '22

Hello, following up on an exchange at https://bugzilla.redhat.com/show_bug.cgi?id=2058336 I wonder whether anybody on this list feels able to comment on the legal possibility to generate a jbig2enc package for fedora. The license seems to be apache 2.0 https://github.com/agl/jbig2enc/blob/master/COPYING However, people are concerned that they do not know whether somewhere a patent exists - https://github.com/agl/jbig2enc/issues/58 Any thoughts on how to think about this? Cheers, Ingmar

1 0

Waydroid LineageOS licensing
by Alessandro Astone 24 Feb '22

24 Feb '22

Hi, I'm working on packaging Waydroid for fedora. This is a wrapper around lxc that natively runs a patched LineageOS android image. While the lxc wrapper itself is GPL3, the big elephant in the room is the LineageOS image. On the first use the user is supposed to run `waydroid init` which downloads the LineageOS image precompiled by the Waydroid team, from their servers. It also supports OTA updates from them. The user could instead provide its own images (to a specified location in /usr) and waydroid will skip the download and use those. My first question is: Would waydroid be allowed to download it's own precompiled images? Does it fall in the 'firmware for emulators' category, for which the policy is as follows? > * Emulators must not point to any third-party sites which provide > firmware or ROM files that are distributed without the clear and > explicit permission of their copyright holders. > If yes: who is the copyright holder? AOSP is a collection of projects, most of them being Apache licensed with owner "The Android Open Source Project", but also includes many external projects from various authors with various licenses. Of course there's also some Apache licensed "The LineageOS Team" code and some Apache licensed "The Waydroid Project" code. Ultimately the code is compiled by the Waydroid team. Some included third party projects are already problematic for fedora, for instance ffmpeg and chromium (which includes ffmpeg). If no: Can we source build LineageOS in koji? I would need help identifying the problematic packages in the huge list of packages that make up android. Here's my specfile for it: https://github.com/aleasto/waydroid-lineageos-devel/blob/main/waydroid-line…, it has 786 tarballs. If you prefer an xml listing of the projects you should look at default.xml and snippets/lineage.xml from https://github.com/LineageOS/android/tree/lineage-17.1 Problems should only arise from external/* projects, since everything else _should_ be Apache. I've already removed chromium (in the form of a prebuilt webview apk in aosp or lineageos) and ffmpeg from the specfile (maybe forever, maybe until later given the progress at src.fedoraproject.org/rpms/ffmpeg) Thank you! Alessandro

2 1

Package Licensing - Open Data Commons Open Database License (ODbL) License
by Justin Zobel 15 Feb '22

15 Feb '22

Hi Team, I've just begun packaging for Fedora and of course, I happen to choose one with a license that needs querying. The Open Data Commons Open Database License (ODbL) is for database usage in the kpublictransport KDE library. It is used for access to OpenStreetMap via the KTrip application designed to aid users in navigating via public transport. From the OpenStreetMap Copyright page on their website: OpenStreetMap® <https://www.openstreetmap.org/copyright#trademarks> is *open data*, licensed under the Open Data Commons Open Database License <https://opendatacommons.org/licenses/odbl/> (ODbL) by the OpenStreetMap Foundation <https://osmfoundation.org/> (OSMF). Open Database License: https://opendatacommons.org/licenses/odbl/ Open Street Map: https://www.openstreetmap.org/copyright KDE Source Repository: https://invent.kde.org/libraries/kpublictransport/ Fedora Source Repository: https://src.fedoraproject.org/rpms/kpublictransport/ I would like to know if this license is acceptable to Fedora. Regards, Justin Zobel

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal February 2022