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:
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?
On Tue, 2008-12-09 at 23:03 +0100, Matthias Saou wrote:
> > >>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:
> > TC> Given that it does not give permission for us to redistribute (the
> > TC> cornerstone requirement for Content licenses), this license is not
> > TC> acceptable for Fedora.
> > I guess I'm glad I looked before approving the package, but I have to
> > wonder: Do the cacert folks actually want anyone to use their
> > certificates? I mean, this prevents basically everyone from using
> > them, because they can't come with the OS or the browser.
> Personally, the more I read the document, the more I'm confused.
> "You may NOT distribute certificates or root keys under this
> licence"... does this mean we can distribute under a different license?
Well, sortof. The wording here is strange because you can get a
different license from the CA issuer. We can't just pick a license, but
the CA issuer might be willing to give us a different one.
> Would it be worth getting in contact with CAcert.org in order to try
> and have them allow us to redistribute the root certs under conditions
> which are acceptable to the Fedora Project?
Probably, yes. :)
I noticed there is a website called usefedora.com that sells a product to
make online schools. Is this a violation of any trademark that redhat might
hold with regards to the Fedora name?
winetricks  is free software, but I was originally under the
impression that it was ineligible for inclusion in Fedora because it
is used primarily to download and install non-free software. (That is
not it's only function, though--it also does some registry hacks and
can manage multiple WINEPREFIXes.)
However, some members of the community disagree  and say that it
might be eligible for Fedora, so we'd like confirmation one way or the
I would like to get feedback from Fedora Legal and also my fellow
contributors about considering
SPDX (Software Package Data Exchange) is a specification hosted by the
Linux Foundation defining
a standard format for communicating components, licenses and
copyrights associated with a software package.
It would make it much easier collaborating with other distributions
and upstream projects.
On a more practical side, it would mean standardizing on SPDX short
identifier to design licenses
and exceptions in all our packages.
I just discovered a Fedora package which ships a screen capture from a
(still copyrighted, I assume) TV show in the SRPM. Is this a problem?
(The package does not discuss the screen capture or engages with it on
an intellectual level, it's just there for laughs.)
Florian Weimer / Red Hat Product Security
2015-07-09 14:24 GMT+02:00 Richard Fontana <rfontana at redhat.com>:
>On Thu, Jul 09, 2015 at 02:03:43PM +0200, Haïkel wrote:
>> On a more practical side, it would mean standardizing on SPDX short
>> identifier to design licenses
>> and exceptions in all our packages.
>I am aware of some projects using these identifiers. However, Fedora's
>use of license abbreviations is different in nature from that of SPDX,
>so I'd be concerned that use of the SPDX abbreviations would result in
>confusion (or else a costly change to Fedora's practices).
The attached spreadsheet compares the SPDX license identifiers with the
short form used by Fedora.
The first tab contains the SPDX License List v2.1 and shows the equivalent
short form identifiers in Fedora. At this point, there are probably more
forms alike than different, as the SPDX legal team has been working very
hard to make sure there is coverage of the licenses Fedora cares about
and differences are minimized. Over 80 license short forms from Fedora's
good list were added last year by the legal team.
The second tab is a list of all the Fedora licenses (from the good list)
are not on the SPDX license list, with some comments. We are
certainly willing to re-consider adding them if you'd like to join us
(or email the list), helping to clarify some of the ambiguities.
For those that prefer, a google sheet with the same information can be
>(Separately I consider the SPDX identifiers problematic because in a
>number of cases they clash with common organic community abbreviations
>which happen to be in wide use in the Fedora community.)
Challenge is that common organic community practices vary from one
community to another, and have been changing over time. A goal of
the SPDX license list is to reduce the ambiguity as to which specific
of a license is meant.
The license list itself builds on the work that Fedora started, making it
for the developers to accurately and unambiguously identify specific
The template for each license in the list that we ended up adopting is
based on some of Tom's excellent recommendations from 2010.
We welcome further constructive suggestions on how to bridge
any remaining gaps with the Fedora license list to spdx-legal at
Information on historical discussions of what is included, as well as
the thinking behind the discussion is documented in the team's weekly
can be found on http://wiki.spdx.org/view/Legal_Team for those interested.
I'm starting a review of a new package:
I'm a bit confused about license of the package: some files are licensed
GPLv3, some other GPLv2 and one file is licensed LGPLv2... is it ok to
have the program licensed under GPLv3?