legal January 2023

legal@lists.fedoraproject.org

15 participants
21 discussions

License compliance in fedora-review
by Benson Muite 18 Jan '23

18 Jan '23

Fedora-review has a license check component that lists license types available in a package. However, not all licenses are compliant with each other. A chart indicating which licenses can be included with other licenses is available at: https://dwheeler.com/essays/floss-license-slide.html Would it be possible to create a similar chart for all SPDX identifiers that can be used in Fedora? This would enable adding such a check to fedora-review.

7 16

Here's another couple
by David Cantrell 18 Jan '23

18 Jan '23

xmalloc.c from tmux: /* * Author: Tatu Ylonen <ylo(a)cs.hut.fi> * Copyright (c) 1995 Tatu Ylonen <ylo(a)cs.hut.fi>, Espoo, Finland * All rights reserved * Created: Mon Mar 20 22:09:17 1995 ylo * * Versions of malloc and friends that check their results, and never return * failure (they call fatal if they encounter an error). * * As far as I am concerned, the code I have written for this software * can be used freely for any purpose. Any derived versions of this * software must be clearly marked as such, and if the derived work is * incompatible with the protocol description in the RFC file, it must be * called by a name other than "ssh" or "Secure Shell". */ Which to me means this originated from the original ssh, not that that's relevant. Just historical. So how does this one match? And what about: /* * Portions Copyright (c) 1995 by International Business Machines, Inc. * * International Business Machines, Inc. (hereinafter called IBM) grants * permission under its copyrights to use, copy, modify, and distribute this * Software with or without fee, provided that the above copyright notice and * all paragraphs of this notice appear in all copies, and that the name of IBM * not be used in connection with the marketing of any product incorporating * the Software or modifications thereof, without specific, written prior * permission. * * To the extent it has a right to do so, IBM grants an immunity from suit * under its patents, if any, for the use, sale or manufacture of products to * the extent that such products are used for performing Domain Name System * dynamic updates in TCP/IP networks by means of the Software. No immunity is * granted for any product per se or for any other function of any product. * * THE SOFTWARE IS PROVIDED "AS IS", AND IBM DISCLAIMS ALL WARRANTIES, * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A * PARTICULAR PURPOSE. IN NO EVENT SHALL IBM BE LIABLE FOR ANY SPECIAL, * DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER ARISING * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE, EVEN * IF IBM IS APPRISED OF THE POSSIBILITY OF SUCH DAMAGES. */ Thanks, -- David Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. | Boston, MA | EST5EDT

2 2

xscreensaver and x11-ssh-askpass licenses
by David Cantrell 16 Jan '23

16 Jan '23

Happy New Year, everyone! Among the various packages I maintain is one called x11-ssh-askpass. The project itself is old but still runs and there are users. I am trying to generate an SPDX license expression for this package and am asking for help for clarification. x11-ssh-askpass uses code from xscreensaver (jwz.org/xscreensaver) In the Fedora package for xscreensaver we call it MIT licensed. The xscreensaver project provides sample spec file to build and RPM and in that spec file they call themselves BSD licensed. However, I see this at least in xscreensaver.c: /* xscreensaver, Copyright © 1991-2022 Jamie Zawinski <jwz(a)jwz.org> * * Permission to use, copy, modify, distribute, and sell this software and its * documentation for any purpose is hereby granted without fee, provided that * the above copyright notice appear in all copies and that both that * copyright notice and this permission notice appear in supporting * documentation. No representations are made about the suitability of this * software for any purpose. It is provided "as is" without express or * implied warranty. * Would we call this MIT? It begins mostly the same way but reduces the as-is paragraph to I guess the last two sentences. Or would this be more ISC or even HPND? ISC doesn't feel right but also feels less wrong somehow to me. HPND....??? With the xscreensaver license sorted out, that leaves the remaining original code in x11-ssh-askpass which carries this license: The remaining portions fall under the following copyright and license: by Jim Knoble <jmknoble(a)pobox.com> Copyright (C) 1999,2000,2001 Jim Knoble Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. +------------+ | Disclaimer | +------------+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the author(s) be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software. Again....MIT, ISC, HPND, something else? Anyone have any ideas? Thanks, -- David Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. | Boston, MA | EST5EDT

3 2

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

SPDX Statistics - Malanka edition
by Miroslav Suchý 13 Jan '23

13 Jan '23

Two weeks ago we had: > * 23184 spec files in Fedora > > * 29200 license tags in all spec files > > * 23682 tags have not been converted to SPDX yet > > * 9377 tags can be trivially converted using `license-fedora2spdx` > Today we have: * 23030 spec files in Fedora * 29390 license tags in all spec files * 22766 tags have not been converted to SPDX yet * 8986 tags can be trivially converted using `license-fedora2spdx` The list of packages needed to be converted is again here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f… New version of fedora-license-data has been released. I updated the progress in this spreadsheet: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807r… Interresting things: * The number of lines with License grow while number of spec file shrank. Is it because of bug in my script? Something else? * You converted 1106 license tags in 14 days! You rock! This speed moved the ETA to finish to 2024-03-06. * Due new licenses in fedora-license-data some packages that were notrivial to convert can be now trivially converted. * Why Malanka? Because today is Malanka. https://en.wikipedia.org/wiki/Malanka Do you hesitate how to proceed with the migration? Please follow https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ Miroslav

1 0

SPDX Office hours
by Miroslav Suchý 12 Jan '23

12 Jan '23

Hello. the owners of SPDX Change proposal want to have this Change as smooth as possible. And we decided to setup Office hours. Do you have any questions about SPDX migration? Do you hesitate about what steps you should take? How to proceed with your package? We will do our best to help you. This is intended to be bi-weekly. Every time in a different time, to match the time of different people in different time zones. The first round will happen on Tuesday 2023-01-17 16:00-17:00 UTC. (17pm CET, 11am EST) Google Meet joining info Video call link: https://meet.google.com/xob-irug-qqd Or dial: ‪(CZ) +420 234 610 745‬ PIN: ‪559 590 845‬# More phone numbers: https://tel.meet/xob-irug-qqd?pin=3490720094637 Or join via SIP: sip:3490720094637@gmeet.redhat.com Miroslav

5 4

License updates: c4core, grpc, libfplll, python-graph-tool, python-mapbox-earcut
by Ben Beasley 11 Jan '23

11 Jan '23

I am about to update a few packages that use header-only libraries (and which do not use them only for tests that are not installed, as is often the case with e.g. doctest-static) to include the licenses of those libraries in their SPDX license expressions. The rationale is that header-only libraries are otherwise treated as a kind of static library, and their implementations are compiled into the binary RPMs, so the licenses of the header-only libraries should be included too. The License for c4core will be updated from MIT AND BSL-1.0 to MIT AND BSL-1.0 AND BSD-2-Clause AND (Apache-2.0 OR MIT) because it BuildRequires debugbreak-static, which is BSD-2-Clause, and fast-float-static, which is Apache-2.0 OR MIT. The License for grpc will be updated from Apache-2.0 AND BSD-3-Clause AND MIT to Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT because it BuildRequires xxhash-static, which is BSD-2-Clause. This can be linked as a shared library or used as a header-only library (as in this case) depending on whether XXH_INCLUDE_ALL is defined. The License for libfplll will be updated from LGPL-2.1-or-later AND MIT to LGPL-2.1-or-later AND MIT AND CC0-1.0 because it BuildRequires json-static, which is MIT AND CC0-1.0 (the latter because it includes hedley, another header-only library; see https://gitlab.com/fedora/legal/fedora-license-data/-/issues/91#note_115194…, https://gitlab.com/fedora/legal/fedora-license-data/-/issues/32#note_104544…, https://gitlab.com/fedora/legal/fedora-license-data/-/issues/32#note_104546…, and https://github.com/nemequ/hedley/issues/56 for the full story on this). The License for python-graph-tool will be updated from LGPL-3.0-or-later AND BSL-1.0 to LGPL-3.0-or-later AND BSL-1.0 AND GPL-3.0-or-later AND MIT AND (MIT OR Apache-2.0) because it BuildRequires CGAL-static, which hasn’t yet been converted to SPDX but should be LGPL-3.0-or-later AND GPL-3.0-or-later AND BSL-1.0 AND MIT, and pcg-cpp-static, which is MIT OR Apache-2.0. The License for python-mapbox-earcut will be updated from ISC to ISC AND BSD-3-Clause because it BuildRequires pybind11-static, which is BSD-3-Clause.

2 1

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

Where are license files expected to reside?
by Mattia Verga 04 Jan '23

04 Jan '23

Does the license files of an installed foo package need to reside under /usr/share/licenses/foo/ or can they reside anywhere and the packager just needs to ensure they're installed? The question comes out from a review of a python package [1]: since python package already installs license files properly marked as such into the dist-info dir of the package, do we have to install them using the %license tag also? I would expect them to be under /usr/share/licenses but there's nothing in the packaging guidelines about this. Mattia [1] https://bugzilla.redhat.com/show_bug.cgi?id=2133080#c16

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal January 2023