legal June 2022

legal@lists.fedoraproject.org

14 participants
11 discussions

Updated IEEE license
by Florian Weimer 09 Aug '22

09 Aug '22

The licensing wiki says that the IEEE license is a “good” documentation license. However, with the 2017 release, IEEE switched to this license: | The Institute of Electrical and Electronics Engineers and The Open Group, | have given us permission to reprint portions of their documentation. | | In the following statement, the phrase ``this text'' refers to portions of | the system documentation. | | Portions of this text are reprinted and reproduced in electronic form in | the Linux man-pages project, from IEEE Std 1003.1-2017, Standard for | Information Technology -- Portable Operating System Interface (POSIX), The | Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 | by The Institute of Electrical and Electronics Engineers, Inc and The Open | Group. In the event of any discrepancy between these versions and the | original IEEE and The Open Group Standard, the original IEEE and The Open | Group Standard is the referee document. The original Standard can be | obtained online at http://www.opengroup.org/unix/online.html . | | This notice shall appear on any product containing this material. <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/man-pages-posix/ma…> This license no longer permits modified redistribution, as far as I can see. Is this still an acceptable documentation license as far as Fedora is concerned? Thanks, Florian

2 4

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

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

process for review of licenses
by Jilayne Lovejoy 24 Jun '22

24 Jun '22

Hi all, As you all know, we have a larger project of moving Fedora license data to a data format and repository, updating and improving Fedora-legal documentation related to licensing, and adoption of SPDX ids. In light of that, it is also relevant to look at the process for review of a new license for potential inclusion in Fedora. I'd describe the past/current process as: - send email to this list, some discussion may ensue on list (with community members and Red Hat legal), decision made and then license is added to the applicable wiki table (good or bad) at https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing - Of course, up until somewhat recently, this entire workflow was shepherded by Tom Callaway Now that we have the license data in a repository, it seems like we can use Issues and Merge Requests for the process flow, instead of relying on email. As such, I'd like to propose something along the following lines: * **How to request review of a new license* If you find a license for a package you want to include in Fedora and that license is not listed in the Fedora License Data, you can submit it for review as follows: Note: you must be a Fedora contributer and become part of the Fedora Gitlab group. See LINK for more on how to become a Fedora contributor. 1) Create a new issue in the Fedora License Data repo with the following information: license name, link to text of license, package name and link, why you want to include it in Fedora, whether it is on the SPDX License List, and the SPDX expression as applicable (see below for hints on determining if a license text matches a license on the SPDX License List) 2) All discussion related to the license review based on the license criteria will be on the Issue thread and a decision will be noted there. ` If the license is not on the SPDX License List, then submit the license to the to the SPDX-legal team at https://tools.spdx.org/app/submit_new_license/. In addition to the required information, include a note that it is under review for Fedora and a link to the related Fedora License Data Gitlab issue. The ultimate decision for licenses allowed or not-allowed for Fedora based upon the license criteria rests with Red Hat legal. 3) Once a decision has been made, the person who submitted the license for review creates a Merge Request for the license using the TOML file format. 4) Merge Requests will be reviewed and merged by the Fedora License Data repo maintainers. Happy to hear your thoughts, feedback, and suggestions! Thanks, Jilayne

8 25

LGPL-ish license in Package Review for sfexp
by Ian McInerney 14 Jun '22

14 Jun '22

When verifying the license for sfsexp ( https://bugzilla.redhat.com/show_bug.cgi?id=2095717) in my review, I noticed it appears to have a modification to the LGPLv2+ license on it. The full license text provided by the package is: Copyright (2003-2006). The Regents of the University of California. This material was produced under U.S. Government contract W-7405-ENG-36 for Los Alamos National Laboratory, which is operated by the University of California for the U.S. Department of Energy. The U.S. Government has rights to use, reproduce, and distribute this software. NEITHER THE GOVERNMENT NOR THE UNIVERSITY MAKES ANY WARRANTY, EXPRESS OR IMPLIED, OR ASSUMES ANY LIABILITY FOR THE USE OF THIS SOFTWARE. If software is modified to produce derivative works, such modified software should be clearly marked, so as not to confuse it with the version available from LANL. Additionally, this library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, U SA LA-CC-04-094 (taken from https://github.com/mjsottile/sfsexp/blob/master/COPYING). This to me reads as a modification to the normal LGPL (since it puts requirements that derivative works be clearly marked as distinct). Is this modification acceptable for inclusion in Fedora? -Ian

4 4

Publishing containers based on Fedora
by Andreas Hartmann 13 Jun '22

13 Jun '22

Hello everyone, I recently started to host my own container registry via GitLab. I use it to build container images for my own use (bundling mostly CLI tools at the moment) and would like to publish them, too, so others may use them as well. Now since I use Fedora Linux on all of my systems, I would also like to use it as a base for the containers where necessary (I.e. where alpine Linux doesn't work). Now I'm wondering if there are any restrictions that I should be aware of with regard to the publishing of these images. That is mostly because I have hardly ever seen any container on e.g. the docker Hub that's based on Fedora. I do not use the Fedora trademark, I don't advertise that the containers are built on top of a Fedora base container, I never mention the word Fedora in any of the docs associated with the containers. The only relation between these containers and the Fedora project is the line `FROM registry.fedoraproject.org/fedora:36` at the beginning of my Containerfiles. Is this acceptable, or does that already mean that I mustn't publish these images? In case I am allowed to publish such container images: Are there any packages that need to be removed from the containers? I know that Fedora Remixes mustn't use the official Fedora logo RPMs but supply their own instead. Are these part of the containers and hence need I remove them? Finally, again in case I am allowed to publish such container images in the first place, which applications am I allowed to bundle with the containers? I am aware that Fedora has adopted e.g. the "3rd-party repositories" in Gnome Software, which give filtered access to flathub applications, due to legal reasons. I would *assume* that it's okay to publish e.g. GPL-licensed software along with a Fedora container. What about other licenses such as MIT? Sorry for the lengthy mail, but I haven't been involved much with legal matters regarding software in my life before. I just want to make sure I'm legally allowed to do what I want to, *before* I get into trouble for infringing trademarks/licenses or anything. I have already searched the web and the archives of this mailing list, but that didn't produce any results. Thank you in advance! Kind regards Andreas Hartmann

3 3

Re: [Fedora-packaging] Re: license of the binary policy
by Richard Fontana 07 Jun '22

07 Jun '22

On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi> wrote: > > As a maintainer of modest amount of packages and occassional new package > reviewer, > the issues I have with the current licensing policy as linked above are: > > 1. The "effective license" thing that is already discussed in another > thread does not appear in the policy at all, and it does not appear in > Fedora Licensing page, either. The only places that mention it that I > have discovered are Licensing:FAQ [1] and random discussions at mailing > lists and so on. This makes it quite difficult to understand if > "effective licensing" is actually part of the policy or not. It would be > easier to understand its status if it was covered in the policy itself. > The policy itself should be unambiguous and possible to interpret > without reference to any FAQ. A FAQ should not introduce new > requirements and exceptions. That part of the FAQ will have to be revisited, if the approach I suggested today is adopted (a good example of why it isn't exactly maintaining the existing policy). Basically, the "simple enumeration" approach would mean that there is no such thing as "effective licensing". If people think that "effective licensing" is something that is so valuable that it is worth the resulting unavoidable complexity of analysis and inconsistency across packages, that view should be voiced. I *can* imagine providing some more detailed rules about what "effective licensing" means (and at an earlier stage I was actually thinking of working on something like this). I basically gave up because it's clear no one agrees on what effective licensing means, which means it's not effective. :) > 2. In general, it is confusing that the policy is split between > Packaging Guidelines, Fedora Licensing main page and, apparently, also > the FAQ. How can I determine if any given docs or wiki page is > authorative? Would it be possible to consolidate everything that is > authorative to a single page and declare it such? Good idea. > 3. Specifically related to the effective licensing question, MIT and BSD > basically *only* ask to include the license text when shipping binaries. > The effective licensing thing then erases those licenses, if there is > GPL somewhere in the mix. The cognitive dissonance between wanting to > honor upstream licenses and not shipping them due to effective licensing > is serious. Since MIT and BSD are very common licenses, and code under > them is also very commonly found embedded in otherwise GPL projects, I > would like the licensing policy explicitly cover this situation and > explain why it is allowed to not ship the MIT/BSD license in this case. > (Perhaps, it would be good to revisit the part of the policy that > discussed shipping license texts and consider, why is that required: It > is in order to honor upstream licenses, or for some other reason, like > end user convenience?) All the licenses are shipped in that they are found in the SRPM. Implicitly, Fedora's position is that this is compliant with those permissive licenses. I think the issue you're raising is Fedora's policy on what license texts to install in /usr/share/licenses. I don't think that issue is directly tied to how the License: field is populated. I couldn't immediately find any documentation on the /usr/share/licenses policy, but my intuition from looking at lots of Fedora and RHEL packages is that this contains any license text that seems to be "global" in some way, and in cases where there is no obvious such license, some appropriate license is selected from the source files for this purpose. We might want to separately revisit the /usr/share/licenses policy at some point if there is interest. Richard > > [1]: https://fedoraproject.org/wiki/Licensing:FAQ > _______________________________________________ > packaging mailing list -- packaging(a)lists.fedoraproject.org > To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure --

3 3

license of the binary policy
by Jilayne Lovejoy 07 Jun '22

07 Jun '22

Hi Fedora legal and packaging, I'm cross-posting this, as I think it's relevant to both groups. The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelin… ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask." As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following: 1) how do you (package maintainers) interpret this policy in practice? 2) what further information/documentation about this policy would be helpful? 3) should this policy be different, and if so, how? 4) any other related thoughts or observations Thanks! Jilayne

4 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal June 2022