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, 3 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?
8 months
concerning who can change code licence
by Germano Massullo
Italian identity card middleware for Linux cannot be packaged for Fedora
because a developer assigned an "all rights reserved" licence to his code.
In the ticket [1] where I raised this problem, some developers of the
project said that they will investigate to find out if the lines of code
of the "wrong" license maybe erased.
My personal opinion is that only THE author must be the one allowed to
change the licence of his own code, not another person.
Is that correct?
Best regards
[1]: https://github.com/italia/cie-middleware-linux/issues/16
1 year, 1 month
Boolean logic in license
by Miroslav Suchý
I want to clarify one thing I am working on. When I have this string in License tag in spec:
Good License or Bad license
Then the result is Good license and the package is allowed to be in Fedora, right?
Miroslav
1 year, 2 months
SPDX identifiers
by Miroslav Suchý
Mathew and Richard several times in past days mentioned intention to migrate to SPDX identifiers in Fedora.
Is somebody actually working on this? Is there some ETA? Or is it just "intention".
Miroslav
1 year, 2 months
Re: List of packages with problematic license
by Matthew Miller
On Mon, Jan 03, 2022 at 01:26:33PM +0100, Miroslav Suchý wrote:
> The License tag was never formally defined. If we agree that there can be
> anything, then let it be.
The Pending PR here updates that to: SPDX License identifier or expression
(from our "Good" list).
https://pagure.io/packaging-committee/pull-request/1142#_1__38
Although given the context here, I note that that's ambiguous about whether
the _whole expression_ must be on the list — I don't think that's the
intention!
[CC'ing this to the legal list, btw.]
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1 year, 2 months
Fedora license categories
by Richard Fontana
A bunch of us are looking into various possible changes in how the
information on Fedora good/bad licenses is maintained, reviewed,
classified and represented. One aspect of this is the likely effective
replacement of such wiki pages as
https://fedoraproject.org/wiki/Licensing:Main with a repository (such
as https://pagure.io/fedora-legal/license-data). Among other things
this has prompted a review of how licenses are currently categorized
by Fedora. In particular, Fedora has separate lists of good and bad
licenses for content
https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses_3
https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses_3
and for documentation
https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses_2
https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses_2
A question that has arisen is whether we actually need to treat
documentation and content as separate categories. "Content" (and
documentation, software, fonts, etc.) are not defined in that wiki
page as far as I can tell. (FWIW the FPCA defines "Content" in a way
that includes documentation: "any copyrightable material that is not
Code, such as, without limitation, (i) non-functional data sets, (ii)
documentation,
(iii) wiki edits, (iv) music files, (v) graphic image files, (vi) help
files, and (vii) other kinds of copyrightable material that the Fedora
Council has classified as "content" rather than "code".") There is
some overlap in the content and documentation license lists and the
other lists as well -- for example, CC-BY is given as a good
documentation license and a good content license.
I think the answer is "yes", because of this policy:
"Note that content must be freely distributable without restriction
for inclusion in Fedora, and that a written statement from the content
owner granting this is considered an approved license for Fedora. The
one exception is that we permit content (but only content) which
restricts modification as long as that is the only restriction."
And indeed the content license lists includes a few non-libre licenses
including at least one well known one that does not permit derivative
works -- CC BY-ND.
I'm assuming that Fedora would not allow documentation under a
non-libre license, if only because there isn't a similar caveat in the
documentation license section and all the good documentation licenses
appear to be assumed to be libre. I think there may be some arguable
counterexamples that might be explained away as covering things that
are non-documentation content as opposed to documentation. I also am
pretty sure that Fedora has not attempted to officially list all the
approved non-libre licenses for "content" but I'm not sure if this is
something intentional. (The categorical example that comes to mind is
the inclusion of certain kinds of files from standards documents, such
as schemas and the like.)
Separately, I wonder if Fedora really needs separate categories for
software and documentation, if the criteria for approval are basically
the same -- essentially, whether the license is libre (by Fedora's own
assessment) -- except that documentation licenses are seen as normally
unsuitable for software. It is clear (to me at least) that any good
Fedora software license should be good for documentation as well, if
only because in practice documentation in packages is often covered by
the software license -- indeed, this is probably much more common than
cases where a special documentation license is used.
Anyway, I was just wondering if anyone had any thoughts or comments on this.
Richard
1 year, 2 months
