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
1 year, 2 months
Earliest use of Fedora CLA
by Richard Fontana
Hi,
Does anyone happen to know when precisely the old Fedora CLA (not the
current FPCA) began to be used? The presumably ancestral Apache
Software Foundation Individual CLA was adopted by the ASF on
2004-06-23, which was in between the release of Fedora Core 2 and
Fedora Core 3.
Richard
7 years, 11 months
Licensing of code derived from Apache 2.0 data
by Adam Jackson
Consider an API whose normative specification is maintained in an XML
file describing enum values, entrypoints, etc. The XML file is covered
under Apache 2.0. I write a python script to parse that XML and emit a
C header describing that API. What license options do I have for that
header?
My amateur reading of Apache 2.0 Section 4 (Redistribution) is that I
can choose whatever I want for the generated header. The last paragraph
in particular:
> You may add Your own copyright statement to Your modifications and
> may provide additional or different license terms and conditions for
> use, reproduction, or distribution of Your modifications, or for any
> such Derivative Works as a whole, provided Your use, reproduction,
> and distribution of the Work otherwise complies with the conditions
> stated in this License.
The header is the Derivative Work, and I need not distribute the source
XML at all. On the other hand, my amateur reading of the definition of
"Derivative Work" in Apache 2.0:
> "Derivative Works" shall mean any work, whether in Source or Object
> form, that is based on (or derived from) the Work and for which the
> editorial revisions, annotations, elaborations, or other
> modifications represent, as a whole, an original work of authorship.
> For the purposes of this License, Derivative Works shall not include
> works that remain separable from, or merely link (or bind by name) to
> the interfaces of, the Work and Derivative Works thereof.
Suggests that such a header file would not count as a Derivative Work;
I'm not sure what it would count as, but as it's merely a binding to
the interfaces defined by the Work...
- ajax
7 years, 12 months
Policy change on emulators
by Tom Callaway
To the Fedora Community,
The Fedora policy on emulators has been in place for quite some time, it
is one of the first legal rules we put in place. Recently, we
reconsidered that rule and have amended our position (with discussion
from Red Hat Legal).
Previously, the guidelines forbid the majority of emulators from being
included in Fedora, but the new guidelines, while longer, are more
permissive.
=== Emulators ===
Some emulators (applications which emulate another platform) are not
permitted for inclusion in Fedora. These rules will help you determine
whether an emulator is acceptable for Fedora.
* Emulators which depend on firmware or ROM files to function may not be
included in Fedora, unless the copyright holder(s) for the firmware/ROM
files give clear permission for the firmware/ROM files to be distributed
(either under a Fedora permissible license or under the Fedora firmware
exception criteria). Note: This only covers the situation where an
emulator will not run at all without firmware/ROM files. For example,
emulators that compile and run, but ship with no game ROMs are not
covered by this rule.
* Emulators must not ship with any ROM files (e.g. games) unless those
ROM files are available under a Fedora permissible license and have been
built from source code in the Fedora buildsystem.
* Emulators must not point to any third-party sites which provide
firmware or ROM files that are distributed without the clear and
explicit permission of their copyright holders.
* All other Fedora licensing and packaging rules apply to emulators.
=================
The home for this policy is here:
https://fedoraproject.org/wiki/Licensing:SoftwareTypes#Emulators
This change is effective immediately and also applies to Copr.
If you have questions about this change, please feel free to email me
(either directly or on the devel/legal lists).
Thanks,
~tom
==
Red Hat
8 years
Re: Policy change on emulators
by Tom Callaway
On 05/03/2016 03:14 PM, Andrew Lutomirski wrote:
> Does this mean that, if we strip FreeDOS out of dosemu / dosemu2, we can
> ship it and even point to a website with FreeDOS binaries?
>
> AIUI the only problem with FreeDOS is that no one knows how to compile
> it with a free software toolchain. As far as I know, the binary is
> pretty clearly redistributable. (Hmm. Could FreeDOS ship as a firmware
> blob? That seems dubious to me.)
Are the FreeDOS sources under a Fedora-acceptable license?
I would not consider FreeDOS to be firmware, thus, the firmware
exception would not apply.
~tom
==
Red Hat
8 years
