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, 16 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
API change and License change: python-ezdxf 0.18
by Ben Beasley
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
1 week
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
Good/bad dual licenses in Fedora packages
by Richard Fontana
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
1 week, 4 days
FIGlet fonts
by Lyes Saadi
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?
1 week, 5 days
Draft attempt to define Fedora license categories
by Richard Fontana
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
2 weeks
SPDX identifiers for xmag-1.0.7
by Petr Pisar
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
3 weeks, 2 days
