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
Adopt Debian-style 'common licenses' convention?
by Richard Fontana
Debian and at least some of its derivatives have long had a
requirement that each package have a so-called "copyright file" which
among other things is supposed to contain "a verbatim copy of its
copyright information and distribution license". However, for certain
widely-used licenses, copies are not bundled with individual packages,
but instead a systemwide copy of each is installed in
/usr/share/common-licenses. These include, from what I gather, the
Apache License 2.0, some version of the Artistic License, each extant
version of the GPL and LGPL, and (oddly) certain versions of the GFDL.
I've been thinking recently that Fedora, and the derivatives of Fedora
maintained by Red Hat engineers, would benefit from adopting a similar
approach, though I wouldn't suggest using an identical set of
licenses. I had a conversation with Neal Gompa yesterday and got the
impression he did not consider this to be an entirely crazy idea. I
have some concerns about the current Fedora practice of installing
certain individual package license files (including license files that
appear in thousands if not tens of thousands of Fedora packages in
identical form) in /usr/share/licenses and think this particular
Debian practice might be a marginal improvement in certain respects.
Any thoughts on this idea?
Richard
5 years, 10 months
fedora packaging: Inclusion of license(s) in fedora packages
by Siddharth Sharma
Hi,
If a project source code contain license files we need to include those
files using
%license macro. If package splits into multiple packages then which sub
package
must have license files ? It might be confusing so I will try to explain
scenario.
Usually when devel package is installed it installs main package with it.
So whenever
user install main package or devel package they get license files by
default if included
in main package. But for example if a package splits into main, libs, and
devel package
and user can just install libs package without actually installing devel
and main package
then at that point code is distributed without license. What needs to be
done in such
cases ? Is it required to embed license in each sub-package ?
Siddharth Sharma
5 years, 10 months
Re: License of jnlp-servlet.jar - part of Oracle JDK
by Mark Wielaard
Hi Dalibor,
[It seems the fedora legal list somehow dropped your response, so
keeping on CC.]
On Thu, 2017-04-27 at 10:31 +0200, dalibor topic wrote:
> the issue has been marked as resolved.
Thanks. Apparently some legal issues do indeed take years to resolve :)
But nice to see the license text being clarified now.
> After downloading 8u131 demos and samples from
> http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-21...
> I took a quick look at some of files and they seemed fixed.
Yes I couldn't find the "nuclear facility" clause anywhere anymore in
http://download.oracle.com/otn-pub/java/jdk/8u131-b11-demos/d54c1d3a095b4...
And the "Oracle BSD License" now seems to simply be the standard BSD
license without any extra terms.
Do note that there are still files (all under sample/jnlp/ except for
the GNUmakefile) that refer to SUN in the disclaimer text (instead of
ORACLE or leaving the company name out). But I assume that is fine.
Thanks,
Mark
> cheers,
> dalibor topic
>
> On 18.11.2013 18:55, Dalibor Topic wrote:
> > On 11/13/13 5:39 PM, Dalibor Topic wrote:
> >> On 11/13/13 10:37 AM, Mark Wielaard wrote:
> >>> Hi all,
> >>>
> >>> I added Dalibor from Oracle to the CC, who has been helpful cleaning up
> >>> some license issues around java in the past.
> >>
> >> As Tom said [0], filing a bug in the bug tracker is the way to go. I'll track down
> >> the owner of the file, and let you know what the bug ID is once I've done that.
> >
> > I filed an issue, it's available at https://bugs.openjdk.java.net/browse/JDK-8028538 .
> >
> > cheers,
> > dalibor topic
> >
5 years, 10 months
