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
license submissions to SPDX on behalf of Fedora
by Jilayne Lovejoy
Hi all,
Richard has been very busy reviewing licenses and related activities,
and consequently approx 13 new license submissions to SPDX on behalf of
Fedora. See:
https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+la...
Some of these have corresponding issues in our Gitlab data repo and
labeled as "blocked on SPDX."
From the SPDX side to best shepherd these, can I get a little help on
two aspects:
1) which of these submissions are priority from a Fedora perspective?
That is, are any package maintainers waiting on SPDX (I know some of
these are from leftover Fedora licenses we tagged as "needs more
research" when we did the initial compare, which seems to suggest it may
not be a blocking issue) - comments in the SPDX Github issue would be
appreciated as to any that should be prioritized above others.
2) By way of SPDX processes, when a license has been determined to be
accepted, we ask the submitter to help prepare the files for the SPDX
license data. However, I'm not sure if Richard should be on the hook for
all of these! Can anyone else from the Fedora legal community offer to
help with this part? If so, indicate in the relevant issue and SPDX
folks will point you to documentation to explain the process further
(it's pretty easy, even I can do it)
Thanks!
Jilayne
6 months, 3 weeks
rpmlint and SPDX licenses: W: invalid-license BSD-3-Clause
by Miro Hrončok
Hello license folks.
I see that Fedora's rpmlint is yet to be taught to understand SPDX:
python3-lxml.x86_64: W: invalid-license BSD-3-Clause
python3-lxml.x86_64: W: invalid-license MIT-CMU
Is this support tracked somewhere? I know openSUSE already uses SPDX, so
rpmlint probably knows how to read that. Right?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 months, 3 weeks
More Ansible license changes
by Maxwell G
Hi Fedorians,
I'm back with more ansible license updates. Upstream, some of the community
Ansible Collections have adopted the REUSE specification, which makes it much
easier to determine the overall license. For collections that have adopted
this, the license texts are all stored as files in one directory, instead of
being spread out throughout the source tree as file headers. I would like to
thank the upstream developers for working with me on this.
The License tag of ansible-collection-community-general has changed from
"GPLv3+ and BSD and Python" to "GPL-3.0-or-later AND BSD-2-Clause AND PSF-2.0
AND MIT". See https://src.fedoraproject.org/rpms/ansible-collection-community-general/p....
The License tag of ansible has changed from "GPLv3+" to "GPL-3.0-or-later AND
Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT AND MPL-2.0 AND PSF-2.0".
I cannot claim this to be 100% accurate, but I have done my best to determine
the overall license. Note that ansible is a curated bundle of 103 Ansible
collections, so this task is a bit difficult. See https://src.fedoraproject.org/rpms/ansible/pull-request/32.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
6 months, 4 weeks
Consider changing the license change announcement policy
by Maxwell G
Hi Legal folks,
Can you please consider removing the following rule?
> Fedora package maintainers are expected to announce upstream license
> changes that they become aware of on the Fedora devel list.
-- https://docs.fedoraproject.org/en-US/legal/license-review-process/#_what_...
This creates unnecessary friction for packagers that simply wish to have
correct License fields. I'm also not sure what purposes it serves.
Richard explicitly said that Fedora does not concern itself with
cross-package license compatibility. And even if it did, a "GPLv3+" to
"GPL-3.0-or-later AND MIT" license change shouldn't cause any new
license compatibility issues.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
7 months
