Important changes to software license information in Fedora packages (SPDX and more!)
by Matthew Miller
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
6 days, 23 hours
inclusion of kernel module sources in a package
by Zbigniew Jędrzejewski-Szmek
Hi,
this question is for https://bugzilla.redhat.com/show_bug.cgi?id=2099771:
'Review Request: wult - Tool for measuring Intel CPU C-state wake latency'.
The full project consists of user-space tooling and a kernel driver that is under
development. The package wants to include the kernel drivers sources to make it
easier for users to compile the driver on the end-user machine. Is this OK
according to our guidelines?
Zbyszek
1 week, 2 days
Fedora adoption of SPDX ids and changes to packaging guidelines
by Jilayne Lovejoy
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)
1 week, 4 days
What way of opting out form a particular Python shebang flag do you prefer?
by Miro Hrončok
Hello Pythonistas, packagers.
In the context of this change:
https://fedoraproject.org/wiki/Changes/PythonSafePath
Python shebangs will have be:
#! /usr/bin/python3 -sP
In order to remove certain flags, packagers have the following tool:
# Unset -s on python shebang - ensure that extensions installed with pip
# to user locations are seen and properly loaded
%global py3_shebang_flags %(echo %py3_shebang_flags | sed s/s//)
Or:
# Don't add -P to Python shebang
# This package only works when /usr/bin is in sys.path
%global py3_shebang_flags %(echo %py3_shebang_flags | sed s/P//)
In the implementation PR, Maxwell suggested a different approach:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/141#com...
Basically, packagers would do something like this:
# Unset -s on python shebang - ensure that extensions installed with pip
# to user locations are seen and properly loaded
%global _python3_shebang_nousersite %{nil}
Or:
# Don't add -P to Python shebang
# This package only works when /usr/bin is in sys.path
%global _python3_shebang_safepath %{nil}
The macro names are not set in stone, it could even be %_python3_shebang_s and
%_python3_shebang_P.
The previous sed-based way would still work and packages that already use it
would not need to change immediately.
Do you consider the macro based approach better (worth it)? And if so, do you
prefer actual flag letters in the macro names, or the verbose names?
Thanks for your input.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 weeks, 5 days
QEMU info
by Jilayne Lovejoy
Hi all,
As Richard and I go through the legal/licensing related wiki pages,
we've come across some info that is clearly not legal or licensing related.
The info on QEMU (pasted below) is one example. Seems like this would be
more appropriately suited for a page related to technical requirements
for packaging?
I'm not sure where that would be - could someone maybe take the info
below and make sure it gets to a proper location in packaging (or other)
docs??
Thanks!
Jilayne
"QEMU ROMs
Whenever possible, ROMS implementing BIOS or Firmware for QEMU system
targets must be built from source on the intended architecture. However,
in many situations, this is not practical or possible. As a special
exception for those situations where it is not practical or possible,
prebuilt binary ROMS implementing BIOS or Firmware for QEMU system
targets may be included in Fedora Packages, as long as the corresponding
source code is also included in the Source RPM package.?
2 weeks, 5 days
license of the binary policy
by Jilayne Lovejoy
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/LicensingGuidel...
) 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
3 weeks, 3 days
