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
9 months, 1 week
arpy and pyelftools ok for Fedora?
by Gary Benson
Hi,
I'm writing a compiler that will eventually be a build dependency of
glibc and so (hopefully!) end up in Fedora. I want to use two Python
libraries as dependencies, but I'd like clarification that both have
ok licenses for Fedora before I dive in.
1. https://pypi.python.org/pypi/arpy
This one has no LICENSE file; the top of the source file says this:
# Copyright 2011 Stanisław Pitucha. All rights reserved.
# Copyright 2013 Helmut Grohne. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without modification, are
# permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice, this list of
# conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice, this list
# of conditions and the following disclaimer in the documentation and/or other materials
# provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY Stanisław Pitucha ``AS IS'' AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
# FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL Stanisław Pitucha OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
# ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# The views and conclusions contained in the software and documentation are those of the
# authors and should not be interpreted as representing official policies, either expressed
# or implied, of Stanisław Pitucha.
Could you confirm that this is 2 clause BSD ("License: BSD") and that
I just need to get the maintainers to add a LICENSE file for this to
be ok for Fedora?
2. https://pypi.python.org/pypi/pyelftools
This one has two license files, LICENSE:
pyelftools is in the public domain (see below if you need more details).
pyelftools uses the construct library for structured parsing of a binary
stream. construct is packaged in pyelftools/construct - see its LICENSE
file for the license.
-------------------------------------------------------------------------------
This is free and unencumbered software released into the public domain.
Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.
In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
For more information, please refer to <http://unlicense.org/>
and elftools/construct/LICENSE:
Copyright (C) 2009 Tomer Filiba, 2010-2011 Corbin Simpson
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Am I right that the second is MIT (Modern Style with sublicense) and
that this package would have "License: Public Domain and MIT"?
Thanks in advance,
Gary
--
http://gbenson.net/
7 years, 4 months
Switching to SPDX in license tags redux
by Richard Fontana
About a year ago Haïkel Guemar started a thread[1] on devel@ and legal@
about adopting SPDX (I think he meant the entirety of the SPDX
specification and not just the SPDX license identifiers).
I'd like to propose reconsideration of replacement of the existing
Fedora license tag scheme with the SPDX license identifiers.
I've been mildly critical of SPDX on, frankly, mostly political and
aesthetic grounds (to the point of asserting that the SPDX identifiers
represent a form of cultural imperialism). I've complained about and
lamented the apparent rising influence of the SPDX identifiers (based
on the number of instances in recent years of people making non-ironic
references in normal discourse to things like "Apache 2" [which I
assume derives from SPDX's Apache-2.0, for what we all used to call
the Apache License except for those who insist on calling it "ASL"]
and "BSD-2-Clause" [for what was once rightly called the 2-clause BSD
license]).
Nevertheless, I am starting to think that the venerable Fedora license
tag system has outlived its usefulness. The main annoyance is not the
abbreviations themselves, which I find quite charming overall, but the
degree to which a single abbreviation can refer to a potentially large
set of what I'd think of as substantively different license texts.
The SPDX identifiers are not a perfect solution since there are so
many distinct license texts encountered in Fedora which are not
currently the subject of an SPDX short identifier and are not likely
ever to be. But I could envision a Fedora extension to the SPDX
identifiers. Then again, maybe my suspicion that there could be some
benefit to rebasing off the SPDX identifiers is not well informed. As
an aside, I detect that in a lot of discussion of the topic of SPDX
identifiers there is a sort of "standardization is always good, no
matter the cost" bias at work, and for better or worse I think I am
immune to that bias.
In full candor, I imagine the benefits to Fedora itself of using SPDX
identifiers are likely quite low, and so perhaps not worth the
disruption of switching. I do see some potential benefit for Red Hat
as a downstream commercial inheritor of Fedora packages.
So, any thoughts on this? What's the right forum in which to raise
this issue? (I'm only raising it here since Haïkel did so last year
and it's the only arguably on-topic Fedora mailing list I'm already
subscribed to).
This is not a suggestion to adopt the SPDX specification in any
broader sense. I don't really have a well-informed non-political view
of it other than to observe that it seems to be mainly of interest to
a narrow group of enthusiasts at present and also it seems like it
would be highly impractical and pointless for Fedora to consider such
a thing.
Richard
[1] http://www.spinics.net/linux/fedora/fedora-legal/msg02633.html
7 years, 4 months
"Fedora Incubator/Innovator/Experimental" branding
by Matthew Miller
I have an idea¹ for creating a label for experimental/innovative work
within the Fedora Project which is not ready to be (or maybe is never
intended to be) Official Fedora. For example, release engineering wants
to make sure that all bits that are "official" go through releng
processes — which is totally reasonable, and helps support the high
quality people have come to expect from the Fedora name. At the same
time, we have a charter to be leaders, and to do that we need a space
where we can be more flexible.
The secondary mark (Fedora Remix) can provide an avenue for this, but
it's made for work done entirely outside of the Fedora project
umbrella. I'd like some way to label projects which are done by Fedora
developers using Fedora resources and in line with the Fedora foundations
but which are not part of the traditional OS or infrastructure with all
of the expectations those things bring.
From a legal standpoint: a) does this make sense and b) what would we
need to do make it happen?
1. http://lists.fedoraproject.org/archives/list/council-discuss@lists.fedora...
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7 years, 4 months
License files in debuginfo packages
by Jason L Tibbitts III
Does Fedora/Red Hat Legal have any opinion on whether debuginfo packages
need to include license files?
Background:
There is a packaging guideline, drafted long ago according to
requirements given by the legal team, regarding the placement of license
files as they relate to subpackages:
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Subpackage_L...
However, RPM itself generates debuginfo packages automatically in a way
that's not really controllable by the packager. These packages do not
have dependencies on the base packages and will not generally include
license files.
Since, like drpms and such, they are a non-packager-controlled product
of the build system, the packaging committee hasn't ever considered them
subject to most guidelines besides a general "turn them off if they
aren't useful" rule. Personally I'd like to keep doing that, but an FPC
ticket was opened (https://fedorahosted.org/fpc/ticket/639), so....
I will relay any feedback back to the packaging committee.
- J<
7 years, 4 months
Sleepycat license with SaaS restriction
by Florian Weimer
cryptlib is licensed under the Sleepycat license with a SaaS restriction:
“Note that decoupling the software from the user, for example by running
in a SaaS configuration, does not exempt you from these requirements.”
(Full text attached.)
This was not part of the original Sleepycat license, so a new license
tag is required.
Maybe this license is not even free; this additional clause seems to be
a restriction on use. But perhaps it is not so different from the AGPL.
Thanks,
Florian
7 years, 5 months
Sleepycat license compatibility and GPL version 3
by Florian Weimer
cryptlib has entered rawhide and is licensed under the Sleepycat license
(among other things).
Historically, the Sleepycat license was deemed compatible with the GPL,
version 2, because it was another (soft) copyleft license.
However, I'm not so sure if this is true for GPL, version 3. The
Sleepycat license implements copyleft like this:
“
3. Redistributions in any form must be accompanied by information on
how to
obtain complete source code for the cryptlib software and any
accompanying
software that uses the cryptlib software. The source code must
either be
included in the distribution or be available for no more than the
cost of
distribution, and must be freely redistributable under reasonable
conditions. For an executable file, complete source code means
the source
code for all modules it contains or uses. […]
”
The above appears to be a further restriction on top of the GPL, version
3, which gives this permission:
“
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
”
I think it is impossible to grant a downstream user these additional
permissions if the combined work also needs to comply with the Sleepycat
license.
Should <https://fedoraproject.org/wiki/Licensing:Main> be updated to
state that the Sleepycat license is only compatible with the GPL, version 2?
Thanks,
Florian
7 years, 5 months
