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
Hello.
Forwarded from https://bugzilla.redhat.com/show_bug.cgi?id=1413646#c2
The upstream of librealsense, Intel demands that when we want to
contribute to librealsense via github pull request (for example):
https://github.com/IntelRealSense/librealsense/blob/master/CONTRIBUTING.md
such contributer are required to accept Intel CLA
(Individual Contributor **License** Agreement):
https://github.com/IntelRealSense/librealsense/blob/master/CLA.md
I suspect that this CLA may be additional requirement (or license) when
developing librealsense. So:
1. Should this CLA be regarded as something like additional "license"
or so?
2. In such case (or if not, in any case), can this CLA be accepted for
packages on Fedora?
Note that the license of librealsense itself is under "ASL 2.0 and BSD".
Thanks in advance.
Regards,
Mamoru
Hello Fedora Legal,
Would software under the following license be okay for inclusion in Fedora? Should I pursue the author to relicence?
> DO WHATEVER PUBLIC LICENSE*
> TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
>
> 0. You can do whatever you want to with the work.
> 1. You cannot stop anybody from doing whatever they want to with the work.
> 2. You cannot revoke anybody elses DO WHATEVER PUBLIC LICENSE in the work.
>
> This program is free software. It comes without any warranty, to
> the extent permitted by applicable law. You can redistribute it
> and/or modify it under the terms of the DO WHATEVER PUBLIC LICENSE
>
> Software originally created by Justin Lloyd @ http://otakunozoku.com/
Source: https://github.com/rednex/rgbds/blob/master/LICENSE
Thank you
Sanqui
Hello all,
I know that it's been discussed from time to time about using SPDX
identifiers for our license tags[1][2]. In the Rust SIG, we're
beginning the work to figure out the packaging of Rust things. Cargo,
the Rust equivalent of Python's pip, enforces the usage of SPDX
identifiers for license tags in the Cargo.toml (the file indicating
the metadata of a "crate").
If we're considering using SPDX identifiers for license tags (as it
appeared to be the case in Tom's FOSDEM talk[3]), would it be possible
to grant us the ability to just use that data instead of having to
attempt to maintain a mapping of SPDX to Fedora short tags? Since our
ecosystem in Fedora is basically zero right now, we could avoid the
ugliness right from the get-go.
Thanks and best regards,
Neal
[1]: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org…
[2]: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org…
[3]: https://fosdem.org/2017/schedule/event/fedoras_legal_state/
--
真実はいつも一つ!/ Always, there's only one truth!