Change in classification of CC0
by Richard Fontana
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
1 day, 17 hours
Updating several packages to SPDX
by Ben Beasley
I am preparing to update a batch of packages’ License tags to SPDX, with
License field changes as reported below.
----------------------------------------
The License field for the agenda package will be updated from an
effective license “GPLv3+” to “GPL-3.0-or-later AND GPL-2.0-or-later AND
CC0-1.0”. The portion covered by CC0-1.0 is the AppData XML file, which
is content.
----------------------------------------
The License field for the appeditor package will be updated from an
effective license “GPLv3” to “GPL-3.0-only AND CC0-1.0”. The portion
covered by CC0-1.0 is the AppData XML file, which is content.
----------------------------------------
The License field for the arpwatch package will be updated from “BSD
with advertising”—which should have been just “BSD”—to “BSD-3-Clause”.
----------------------------------------
The License field for the c4core package will be updated from “MIT and
Boost” to “MIT AND BSL-1.0”.
----------------------------------------
The License field for the c4project package will be updated from “MIT
and ASL 2.0” to “MIT AND Apache-2.0”.
----------------------------------------
The License field for the cairomm and cairomm1.16 packages will be
updated from “LGPLv2+” to “LGPL-2.0-or-later”.
----------------------------------------
The License field for the casc package will be updated from “LGPLv2+” to
“LGPL-2.1-or-later”.
----------------------------------------
The License field for the cpp-hocon package will be updated from “ASL
2.0” to “Apache-2.0”.
----------------------------------------
The License field for the debugbreak package will be updated from “BSD”
to “BSD-2-Clause”.
----------------------------------------
The License field for the dippi package will be updated from
“GPLv3+”—which should have been just “GPLv3”—to “GPL-3.0-only AND
CC0-1.0”. The portion covered by CC0-1.0 is the AppData XML file, which
is content.
----------------------------------------
The License field for the dr_libs package will be updated from
“Unlicense or MIT-0” to “Unlicense OR MIT-0”
----------------------------------------
The License field for the edac-utils package will be updated from
“GPLv2+” to “GPL-2.0-or-later”.
----------------------------------------
The License field for the fast_float package will be updated from “ASL
2.0 or MIT” to “Apache-2.0 OR MIT”.
----------------------------------------
The License field for the festival-freebsoft-utils package will be
updated from “GPLv2+” to “GPL-2.0-or-later”. Furthermore, the License
field for the festival-freebsoft-utils-doc subpackage, previously
inherited from the base package, will be updated and corrected to
reflect its dual-licensed status: “GPL-2.0-or-later OR
GFDL-1.2-no-invariants-or-later”.
----------------------------------------
The License field for the fflas-ffpack package will be updated from
“LGPLv2+” to “LGPL-2.1-or-later AND LGPL-2.0-or-later”.
----------------------------------------
The License field for the flatbuffers package will be updated and
corrected from “ASL 2.0 and BSD” to “Apache-2.0”.
The code previously considered BSD (BSD-3-Clause) is that which is
derived from grpc, which has an upstream license of BSD-3-Clause. It is
now clear that even code from grpc is intended to be Apache-2.0 in this
project. (Google is the copyright holder for both projects, so it can
relicense at will.) See https://github.com/google/flatbuffers/pull/7073.
----------------------------------------
The License field for the flintqs package will be updated from “GPLv2+”
to “GPL-2.0-or-later”.
----------------------------------------
The License field for the fmidi package will be updated from “Boost” to
“BSL-1.0”.
----------------------------------------
The License field for the freexl package will be updated from “MPLv1.1
or GPLv2+ or LGPLv2+” to “MPL-1.1 OR GPL-2.0-or-later OR LGPL-2.1-or-later”.
----------------------------------------
– Ben Beasley
4 days, 2 hours
Re: Important changes to software license information in Fedora packages (SPDX and more!)
by Maxwell G
Kevin Kofler via devel wrote:
> Now you have to compare every word of the MIT license
> with the very similar templates such as MIT, MIT-CMU, MIT-feh, etc., and
> then figure out which one it actually is. If it is even one of these and not
> some random mix of several variants (one sentence from here, one sentence
> from there, …).
You're right. MIT/BSD License variants are a pain to deal with. In
practice, they are mostly equivalent, so having to identify is a burden
without a lot of benefit.
Currently, there's MIT variants such as the HPND that aren't even part
of the new license list, despite being explicitly listed on the old list
and being used by packages like libX11[1]. As that license deprecated,
it's not likely to cause issues when importing new packages, but it is
still used by older packages. There are other examples of licenses
missing from the new list that are already blocking new packages[2].
[1]: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/1#note_96957...
[2]: https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/12#n...
> But that is how things work in practice. It is just impossible to read
> through every source file and scan for copied snippets. They can even appear
> in the middle of a file, with the license attached right there. So the
> packager and the reviewer will both check the COPYING/LICENSE/LICENCE file
> provided by upstream, then go exemplarily through a handful source files to
> check that the copyright header and/or SPDX REUSE header matches that
> license, and then declare that as the one License.
This is onerous if you do it manually, but there are tools to make it a
bit easier. You can use scancode-toolkit or licencecheck to scan the
entire codebase. I believe the RH legal folks recommended the former at
some point, but licensecheck is used by fedora-review and actually
packaged in Fedora[^1]. The Legal docs recommend SPDX license-diff[3]
and [4] to see if a certain license text exists in SPDX.
[^1]: I wish luck to anyone who tries to package tries to package scancode.
There are quite a few unpackaged dependencies...
[3]: https://addons.mozilla.org/en-US/firefox/addon/spdx-license-diff/
[4]: https://tools.spdx.org/app/check_license/
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
6 days, 4 hours
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, 18 hours