legal July 2022

legal@lists.fedoraproject.org

16 participants
14 discussions

Is ECDSA secp256k1 elliptic curve permitted to be packaged in Fedora?
by Miro Hrončok 26 Aug '22

26 Aug '22

Hello legal. I see that ECDSA is already included in Fedora in various packages, so I assume that is OK. This software here: https://github.com/starkbank/ecdsa-python Says: > We currently support secp256k1 [curve]. Is that OK to package in Fedora or not? Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 5

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

Change in classification of CC0
by Richard Fontana 05 Aug '22

05 Aug '22

CC0 has been listed by Fedora as a 'good' license for code and content (corresponding to allowed and allowed-content under the new system). We plan to classify CC0 as allowed-content only, so that CC0 would no longer be allowed for code. This is a fairly unusual change and may have an impact on a nontrivial number of Fedora packages (that is not clear to me right now), and we may grant a carveout for existing packages that include CC0-covered code. While we are moving towards a process in which license approvals are going to be done primarily through the Fedora license data repository on gitlab.com, I wanted to note this on the mailing list because of the significance of the change. The reason for the change: Over a long period of time a consensus has been building in FOSS that licenses that preclude any form of patent licensing or patent forbearance cannot be considered FOSS. CC0 has a clause that says: "No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document." (The trademark side of that clause is nonproblematic from a FOSS licensing norms standpoint.) The regular Creative Commons licenses have similar clauses. A few months ago we approved ODbL as a content license; this license contained its own "no patent license" clause. Up till this time, the official informal policy of Fedora has been that 'content' licenses must meet the standards for 'code' licenses except that they can prohibit modification. The new Fedora legal documentation on the license approval categories will note that allowed-content licenses can also have a no-patent-license clause. In a FOSS development and distribution context, the absence of patent licensing for non-software material is of significantly less concern than the software case. Feel free to ask any questions or make any comments about this! Richard

4 6

Important changes to software license information in Fedora packages (SPDX and more!)
by Matthew Miller 31 Jul '22

31 Jul '22

On behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce! New docs site for licensing and other legal topics -------------------------------------------------- All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at: https://docs.fedoraproject.org/en-US/legal/ Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki. Fedora license information in a structured format ------------------------------------------------- The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at: https://gitlab.com/fedora/legal/fedora-license-data This data is then presented in easy tabular format in the documentation, at: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ New policy for the License field in packages — SPDX identifiers! ---------------------------------------------------------------- We’re changing the policy for the "License" field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects. Updated licensing policies and processes ---------------------------------------- Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated. New guidance on “effective license” analysis -------------------------------------------- Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way. When do these changes take effect? ---------------------------------- The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that! Thank you everyone! ------------------- A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums. Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

5 9

API change and License change: python-ezdxf 0.18
by Ben Beasley 30 Jul '22

30 Jul '22

I am preparing to update python-ezdxf from 0.17.2 to 0.18[1]. Since there are some small API changes, the update will be for Rawhide only, and I will wait one week (2022-08-06) to merge and build the PR. However, this should not affect any other packages, since the sole dependent package is python-trimesh and I have already confirmed it is not affected by the API changes. In python-ezdxf 0.18, a few new Python modules are included that are derived from other software. The License is therefore no longer simply “MIT.” Of the new modules in question, one is a fork of its original upstream. I have treated it as a bundled dependency, adding the appropriate virtual Provides. The others are full rewrites from different languages; the licenses of the original projects still affect the ezdxf License, but I have not treated them as bundled dependencies since no code is copied from the original projects. See the comments in the spec file above the License field if the details matter to you. In classic “Calloway” notation, the new License field would become: MIT and (ISC and MIT) and (AGPLv3 and MIT) However, I am taking the opportunity to convert the package to SPDX, and so the License will become: (MIT AND (ISC AND MIT) AND (AGPL-3.0-only AND MIT)) In accordance with the updated requirements for license changes, I have directed this message to both the devel list and the legal list. – Ben Beasley [1] https://src.fedoraproject.org/rpms/python-ezdxf/pull-request/1

2 2

Fedora adoption of SPDX ids and changes to packaging guidelines
by Jilayne Lovejoy 27 Jul '22

27 Jul '22

Hi Fedora packaging committee, I see that FESCO has approved the Change Proposal for the adoption of SPDX ids, moving license lists off wiki to a data repo, and updating the licensing documentation https://pagure.io/fesco/issue/2799 We are aiming to "go live" with the new Fedora-legal documentation on Wednesday, July 27th. A key piece of that will be getting the PR to update the packaging guidelines for license info merged https://pagure.io/packaging-committee/pull-request/1142 Can someone merge that PR on Tuesday evening or Wednesday morning (US time)? That way if there are formatting issues, typos, etc, we can try to get them fixed so everything is live and pretty by Wednesday afternoon. Thanks! Jilayne (sending this here, and made comment in PR)

2 2

Good/bad dual licenses in Fedora packages
by Richard Fontana 27 Jul '22

27 Jul '22

Is anyone aware of any Fedora package where there is a (disjunctive) dual license, where one side of the dual license is a not-allowed ('bad') license, *not* involving the familiar GPL/Artistic dual license of the Perl community? By this I don't mean what's in the license tag but the actual license granted upstream. Richard

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal July 2022