legal July 2022

legal@lists.fedoraproject.org

16 participants
17 discussions

other licensing guidance
by Jilayne Lovejoy 27 Jul '22

27 Jul '22

Hi Fedora packagers and legal, As Richard and I have been going through the wiki licensing documentation and creating the new Fedora-legal Docs pages (soon to be published!!!) - we have been trying to make sure we have all license-related guidance in one place. This way, Fedora community members know there is one place to go for this kind of information, instead of various places. This will also help in ensuring things stay current. We noticed there are a couple language-specific bits on licensing in the package guidelines. Is anyone opposed to moving those to the Fedora-legal docs pages on licensing? The pages we found were: - https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_license_fo… - https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_library_bi… - https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ Are there any other such pages? Thanks! Jilayne

4 11

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

SPDX identifiers for xmag-1.0.7
by Petr Pisar 15 Jul '22

15 Jul '22

Hello, I'm trying to use SPDX identifiers for xmag-1.0.7 package <https://www.x.org/archive//individual/app/xmag-1.0.7.tar.xz> and I run into difficulties with identifying MIT-family licenses. Specifically, two of them: CutPaste.c file reads: Copyright 1989, 1998 The Open Group 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. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. 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 OPEN GROUP 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. Except as contained in this notice, the name of The Open Group shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from The Open Group. That's clearly MIT-open-group <https://spdx.org/licenses/MIT-open-group.html> license. But Fedora's license list in /usr/share/fedora-license-data/licenses/fedora-licenses.json distributed within fedora-license-data-1.0-1.fc37 does not recognize this identifier. Could legal team look at this license, add the identifier to the Fedora database, and decide whether it is acceptable for Fedora packages? Then CutPaste.h file reads: Copyright (C) 1999 The XFree86 Project, Inc. All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. 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 XFREE86 PROJECT 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. Except as contained in this notice, the name of the XFree86 Project shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the XFree86 Project. It looks like MIT <https://spdx.org/licenses/MIT.html> license except the file has an additional "Except as contained..." paragraph. Is it "MIT" license? Or is it a different one from a <https://spdx.org/licenses/> list? Or is it a completely new variant? Please note that both these licenses are not new to xmag package. They were there probably from the very first days of Fedora. So far I postponed converting xmag Fedora package to SPDX syntax. That will mask these issues, but I'd like to solve them sooner than later to be ready when SPDX syntax becomes mandatory. -- Petr

2 2

License clarification: is CC-PDDC just "Public Domain"?
by Michel Alexandre Salim 14 Jul '22

14 Jul '22

Dear all, During the review of rust-pwd (needed as a new dependency for rust-nu- path): https://bugzilla.redhat.com/show_bug.cgi?id=2101580 it came to light that the upstream Rust crate declares the license to be CC-PDDC: https://spdx.org/licenses/preview/CC-PDDC.html The change itself happened after the previous patch release (1.3.0) and is released in the latest 1.3.1: https://gitlab.com/pwoolcoc/pwd/-/commit/8375b41379c6f7b2a3b7a675d6b892b27f… Two questions here: - can we treat CC-PDDC as basically Public Domain, which is approved by Fedora per https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses - if not, can we use the Git commit history to assume that the intent is to make this public domain? Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

4 12

Re: mininet license
by Iñaki Ucar 13 Jul '22

13 Jul '22

Hi, Kind reminder that the package was accepted [1], and we are blocking on legal. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2072115 Thanks, -- Iñaki Úcar

2 4

yq Licensing Question
by Maxwell G 13 Jul '22

13 Jul '22

Hi, I am reviewing yq, which is an MIT-licensed, statically linked (all go binaries are statically linked) go project that builds against golang-github-timtadh-data-structures-devel. The latter is licensed under GPL-2.0-only. My understanding is that distributing yq binaries with just the MIT license file as is constitutes a GPL violation. While we're waiting for upstram to rectify this situation (I filed an issue), would it be permissible to set the License field to `MIT AND GPL-2.0-only`, include a copy of the GPL v2 in the package, and add a comment to the specfile explaining the situation? -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

4 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal July 2022