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
9 months
SPDX progress
by Miroslav Suchý
I was curious how many packages are already converted to SPDX.
I downloaded all spec files and count how many of them contains "spdx" string (case insensitive). Assuming most
packagers mention it either in changelog or in comment near License field.
The string is in 347 out of 23155 spec files. That is less than 2% of packages.
It is wild guess with many incorrect of assumtions, but I guess the order of magnitude is correct.
That is just FYI. I will not do anything to progress faster, because `fedora-license-data` has enough issues (and mainly
flow of new issues).
Miroslav
1 year, 1 month
Mesa patented codecs approval
by Robert-André Mauchin
Hello,
So recently Mesa disabled by default patented codecs. They added an option to re-enable it
with -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec
Dave Airlie elected to not include this line in:
https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373f...
because "we don't have legal approval for this".
Could it be waived by legal to be re-enabled? Not having basic h264 decoding is quite
taxing. And we all already pay patents when buying the video card.
Best regards,
Robert-André
fas: eclipseo
1 year, 2 months
Updating old FSF address in license
by Mattia Verga
Hello,
I've started the package process for Xephem, an astronomy ephemeris program, but I've found that some headers and the license file of a bundled (*) library still report the old FSF address.
I've asked upstream to update the address with a patch [1], but, indeed, they've pointed me to https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address where it's said that the license file itself should not be patched. How should I interpret that statement? Should I leave the old address in the license and update only the headers, or should I replace the LICENSE file with an updated version from FSF (which, I suppose, it will result in the same patch)? Is it fine to replace the license file of a bundled (*) library?
(*) the bundled library is not available anywhere else, AFAIK, so it doesn't make sense to unbundle it.
Mattia
[1] https://github.com/XEphem/XEphem/pull/57
1 year, 2 months
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
1 year, 3 months
