Henry Spencer's license
by Petr Šabata
Dear legal,
While checking the contents of our `perl' package, I noticed the following:
(...)
/* NOTE: this is derived from Henry Spencer's regexp code, and should not
* confused with the original package (see point 3 below). Thanks, Henry!
*/
/* Additional note: this code is very heavily munged from Henry's version
* in places. In some spots I've traded clarity for efficiency, so don't
* blame Henry for some of the lack of readability.
*/
/* The names of the functions have been changed from regcomp and
* regexec to pregcomp and pregexec in order to avoid conflicts
* with the POSIX routines of the same names.
*/
(...)
* pregcomp and pregexec -- regsub and regerror are not used in perl
*
* Copyright (c) 1986 by University of Toronto.
* Written by Henry Spencer. Not derived from licensed software.
*
* Permission is granted to anyone to use this software for any
* purpose on any computer system, and to redistribute it freely,
* subject to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of
* this software, no matter how awful, even if they arise
* from defects in it.
*
* 2. The origin of this software must not be misrepresented, either
* by explicit claim or by omission.
*
* 3. Altered versions must be plainly marked as such, and must not
* be misrepresented as being the original software.
*
**** Alterations to Henry's code are...
****
**** Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
**** 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
**** by Larry Wall and others
****
**** You may distribute under the terms of either the GNU General Public
**** License or the Artistic License, as specified in the README file.
(...)
You can see the whole file here:
https://metacpan.org/source/SHAY/perl-5.20.1/regexec.c
I looked but couldn't find any common name for this license
of Henry's. Is it on our list? Is it free? What name should
I use in the License tag?
Thank you,
Petr
2 weeks, 2 days
Updated IEEE license
by Florian Weimer
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/...>
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
7 months, 2 weeks
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
7 months, 2 weeks
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
7 months, 3 weeks
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
7 months, 3 weeks
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)
7 months, 4 weeks
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
7 months, 4 weeks
