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?
there is a repository with data about 3D printing materials  that I'd
like to package as a soft dependency for the Cura package.
It didn't have any license information and Gregor Riepl (I believe from
Debian) opened an issue asking for it .
The authors of the data clam that the data cannot has its license and
simply is (by default) accessible to all freely. After a long
discussion, they went with a solution: Add a LICENSE file that they
believe is only for the CMakeLists.txt file in that repository, but tell
me I can believe it belongs to the whole repo and everybody is supposed
to be happy .
However, when adding the LICENSE file (with CC0), this is the commit
> This license only applies to the CMakeLists.txt file since that is the
> only creative expression in here, according to one of our IP guys.
(They cannot make it easy, can they?)
Clearly, I was informed this LICENSE *does not apply* for the data
files. However, I was informed publicly in that issue that:
> All files in this repository can be seen as part of the public domain.
> Anyone is free to use them in any way they want.
Clearly, the authors / copyright holders:
1. want the content to be redistributed freely
2. do not think that content is copyrightable
The intent here is clear: Public Domain. However the information is
quite hard to grasp. I cannot, in my best effort, include that LICENSE
file and pretend it belongs to everything in that repository (ignoring
the commit message).
Should I print the issue comments log to a PDF (or save as HTML) and
include that in the package %license as well?
Thanks for any way out of this.
I'm VincentS, a newbie on fedora packaging. I contact you about
precisions on licenses for a new package.
Here is the log about sources licenses.
There is different licenses for all files. We think package license must
be GPLv2+ and MIT and CC BY-SA.
Did I forget anything? What do you think about this?
Thanks in advance for your reply.
GPG Key ID: 9EDE869D @ hkp://keys.fedoraproject.org
Empreinte: E4F6 EFB8 E37E FD8F 2D4A EFF9 1C96 73CF 9EDE 869D
I am an attorney.
Yes, GRSecurity is violating the licensing terms by adding an additional
term; which is explicitly forbidden in the license agreement under-which
they are given permission to modify, distribute, and create derivative
GRSecurity does not have a default right to modify,the linux kernel,
nor to create or distribute derivative works based on it;
this permission is only granted via license by the rights-holder;
the writing states that if its terms are violated that permission
is automatically revoked.
Here GRSecurity violated one of the terms in said writing:
Adding an additional term (no redistribution - or else) to
the agreement between them and further distributees.
Thus they no-longer have license to modify or distribute
the linux kernel, nor do they have license to create or
distribute wholly derivative non-standalone works of the
Their permission falls back to standard copyright without
some separate agreement with the rights-holder: all rights
Yes, they are violating the copyright to Linux at this current time.
On 2017-06-16 00:29, Boris Lukashev wrote:
> Your frustration is evident, sorry to see you're upset. However,
> spender and team have no obligation to open their source, and for
> years now have not done so in their private patches which have more
> functionality than the public ones. Nobody complained or sued then,
> why start now?
> There is no law firm representing Linux as a whole, and no money to
> file exploratory suits into uncharted waters allocated to any fund.
> I'm about to spend thousands of my own dollars to pay for some of the
> porting work upstream... Money far better spent than harassing people
> to give up their hard work for free on dubious legal ground. Just
> think of them as having gone out of business... For all intents and
> purposes they're gone.
> If you're not a committer to master, whom they have actually infringed
> upon (provably), you have no legal standing at all. If you have code
> in the kernel, I'm sure lwn would love to post a story about your
> lawsuit once you find an attorney willing to litigate and the money to
> pay for an extended plaintiffs position.
> Please don't spam the lists, it has no meaningful effect, makes people
> angry, and slows the flow of legitimate communication aimed at
> improving kernsec. There are better forums for this, and nobody will
> read anything anyone else writes and "hear the call to action" to go
> sue a man for his life's work... But they do let you vent.
> Boris Lukashev
> Systems Architect
> Semper Victus
-------- Original Message --------
Subject: Re: Why does no one care that Brad Spengler of GRSecurity is
blatantly violating the intention of the rightsholders to the Linux
Date: 2017-06-15 20:04
From: W Stacy Lockwood <vladinator(a)gmail.com>
I am my own employer so good luck with that. Since you have threatened a
lawsuit, let me reiterate that you are no longer welcome to contact me
at all in any way. Continuing to do so will lead to the involvement of
I'm completely serious. STFU and FOAD _now_.
W. Stacy Lockwood
On Thu, Jun 15, 2017 at 2:53 PM, <aconcernedfossdev(a)airmail.cc> wrote:
> I'm just informing you that I am going to be filing a suit against you
> 1) Putting my character a negative false light
> 2) Libel (communication to a third party a derogatory false statement)
> Perhaps your employer will indemnify you Mrs Lockwood.
> Thus; I will (as you requested) "bring it".
> On 2017-06-15 19:47, W Stacy Lockwood wrote:
> On Thu, Jun 15, 2017 at 2:46 PM, <aconcernedfossdev(a)airmail.cc>
> Keep digging that hole, Mrs Lockwood, I'm sure the court will look
> fondly on your most resent disparagement of my character.
> Bring it!
> As you wish.
Seriously, shut up. Now.
Your email is no longer welcome in my inbox, and will be filtered.
When people talk about bad actors in the Linux community, they're
talking about people like you. Get some fucking help, you clearly need
W. Stacy Lockwood
Why does no one care that Brad Spengler of GRSecurity is blatantly
violating the intention of the rightsholders to the Linux Kernel?
He is also violating the license grant, Courts would not be fooled by
his scheme to prevent redistribution.
The license grant the Linux Kernel is distributed under disallows the
imposition of additional terms. The making of an understanding that the
derivative work must not be redistributed (lest there be retaliation) is
the imposition of an additional term. The communication of this threat
is the moment that GRSecurity violates the license grant. Thence-forth
modification, making of derivative works, and distribution of such is a
violation of the Copyright statute. The concoction of the transparent
scheme shows that it is a willful violation, one taken in full knowledge
by GRSecurity of the intention of the original grantor.
Why does not one person here care?
Just want to forget what holds Libre Software together and go the way of
(Note: last month the GRSecurity Team removed the public testing patch,
they prevent the distribution of the patch by paying customers by a
threat of no further business: they have concocted a transparent scheme
to make sure the intention of the Linux rights-holders (thousands of
entities) are defeated) (This is unlike RedHat who do distribute their
patches in the form the rights-holders prefer: source code, RedHat does
not attempt to stymie the redistribution of their derivative works,
( This song is about GRSecurity's violation of Linus et al's
(A Boat Sails Away 2016 17) )
On Tue, Jun 6, 2017 at 6:34 PM, Adam Miller
> On Fri, Jun 2, 2017 at 3:07 PM, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
>> On Fri, Jun 02, 2017 at 09:42:48PM +0200, Pierre-Yves Chibon wrote:
>>> (Note: pagure can and will enforce the FPCA for dist-git)
>> I know Richard Fontana has expressed some interest in reducing the need
>> for FPCA. Maybe this is an opportunity to move in that direction? I
>> know Spot has said that "License In = License Out" is adequate for
>> projects on Github; I think Spot's concern with spec files is that we
>> don't give them an explicit license (right)?
> I was under the impression that everything in Fedora was MIT licensed
> unless otherwise specified as per:
> Is that incorrect?
That's enforced through the FPCA. If we accept contributions without
the FPCA or making sure each spec file has the appropriate license
header, that could be quite problematic...
真実はいつも一つ！/ Always, there's only one truth!
On Fri, Jun 02, 2017 at 09:42:48PM +0200, Pierre-Yves Chibon wrote:
> (Note: pagure can and will enforce the FPCA for dist-git)
I know Richard Fontana has expressed some interest in reducing the need
for FPCA. Maybe this is an opportunity to move in that direction? I
know Spot has said that "License In = License Out" is adequate for
projects on Github; I think Spot's concern with spec files is that we
don't give them an explicit license (right)?
As we're moving things, can we do something in Pagure to cover this, so
the FPCA isn't needed here?
Fedora Project Leader