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
6 months, 2 weeks
FIGlet fonts
by Lyes Saadi
Hello Legal,
I'm bringing back a discussion from 2012[1]: Figlet fonts!
Indeed, I am trying to package python-pyfiglet[2] as a dependency for other
packages. But, after the review, it came up that a lot of weird fonts were
included. At the time, I didn't know anything about the discussion, and
decided
to abort everything.
Recently though, a developer contacted me through the bug report, and
proposed
to help on the issue. He triaged the fonts and separated them depending on
whether they were Open-Source or not, and we were thus able to create a
clean
package with none of the problematic fonts in it.
In that discussion[3], emerged the fact that a discussion over this already
happened ([1]), but it seems that either no consensus was reached, or
that such
consensus was lost to time as I wasn't able to find any conversation on
figlet
either on legal or devel mailing lists archives. And, it seems that the
issue
was just simply avoided since figlet ended up removing the problematic fonts
anyway.
But, upstream would like to keep the problematic fonts if possible in
Fedora.
And so, I would like to ask Legal to either give me the answer, if it
actually
was a settled matter, or to reach a consensus on Figlet fonts.
To resume the situation (as I understand it, I am not a lawyer, obviously):
In the US, fonts glyphs are not copyright-able as it is considered
insufficiently creative. For the same reason, Bitmap fonts (fonts
defined pixel
by pixel) are also not copyright-able, as they are only considered as
data which
represents glyphs. But, Vector fonts (fonts defined using drawing
instructions
and code), is, on the other hand, copyright-able because it is defined
through a
software code.
Then, we come to Figlet fonts. For those not aware of what Figlet fonts,
they
are also known as ASCII fonts:
__ __ ____ __ ____
/ / / /__ / / /___ / / ___ ____ _____ _/ / /
/ /_/ / _ \/ / / __ \ / / / _ \/ __ `/ __ `/ / /
/ __ / __/ / / /_/ / / /___/ __/ /_/ / /_/ / /_/
/_/ /_/\___/_/_/\____( ) /_____/\___/\__, /\__,_/_(_)
|/ /____/
The issue with those is that no ruling (as far as I know) ever concerned
that
type of font in US Court. Though, one argument would be that Figlet
fonts are
similar to Bitmap fonts, as they only contain data about glyphs, and do
not, in
the same way as Vector fonts do, contain code giving to the computer drawing
instructions for the fonts. As such Figlet fonts are not modular, or
extensible,
they just contain raw data about a font.
But still, all this is speculation, and, as I said, I am not a lawyer, so I
don't have any slight idea if such a defense would hold in court.
I hope to have resumed the situation clearly enough and that I didn't
make any
mistake.
Greetings,
Lyes Saadi
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=820642
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1876108
[3]: https://github.com/pwaller/pyfiglet/issues/89
PS: Can we remove the FE-legal blocker from the review request now that
all the
fonts have been sorted out?
1 year, 1 month
Draft attempt to define Fedora license categories
by Richard Fontana
Greetings,
As part of some ongoing efforts to improve information relating to
Fedora licensing and licensing policy, we want to provide better
documentation around the various license approval categories for
Fedora, as currently set forth here:
https://fedoraproject.org/wiki/Licensing:Main
but which probably will live in the future on docs.fedoraproject.org.
Here's a rough draft which I wanted to publish here for review.
Feedback/criticisms/suggestions welcome.
Side note: This preserves Tom Callaway's historical usage of "good" to
mean "Fedora-approved", but I have mixed feelings about this
terminology.
1. Licenses for Code
“Code” means software code, any other functional material whose
principal purpose is to control or facilitate the building of
packages, such as an RPM spec file, and other kinds of material that
the Fedora Council has classified as "code" rather than "content", but
does not include font files.
[Comment: This annoyingly and confusingly does not line up with
definitions in the FPCA, but Fedora should get rid of the FPCA anyway]
A license for code is “good” if the Fedora Project determines that the
license is a free/libre//open source license.
[Not sure if it's helpful to add the following:]
In making this determination, Fedora historically relied primarily on
the Free Software Definition as maintained and interpreted by the Free
Software Foundation, but out of necessity Fedora passed judgment on
many licenses never addressed by the FSF and, in the process, built up
an informal body of interpretation and policymaking (admittedly,
mostly undocumented) that went far beyond what the FSF had done.
Fedora has also sometimes considered the decisions of other community
Linux distributions and other important efforts to define and apply
FLOSS norms, most notably the OSI’s Open Source Definition. In a small
number of cases, Fedora has disagreed with decisions of the FSF and
OSI regarding whether particular licenses are FLOSS.
2. Licenses for Documentation
Any license that is good for code is also good for documentation.
In addition, Fedora may designate a license as good for documentation
if (a) the license meets the standards for good licenses for code, (b)
the license is designed primarily for technical documentation or
otherwise has a history of substantial use in free software
communities for documentation, and (c) the license is not commonly or
normally used for code.
[Comment: this feels unsatisfactory to me, for multiple reasons, but I
think it does accurately represent the historical Fedora policy.]
3. Licenses for Content
“Content” means any material that is not code, documentation, fonts or
binary firmware.
Any license that is good for code is also good for content.
In addition, Fedora may designate a license as good for content if it
restricts or prohibits modification but otherwise meets the standards
for good licenses for code.
4. Licenses for Fonts
Any license that is good for code is also good for fonts.
In addition, Fedora may designate a license as good for fonts if it
contains a nominal prohibition on resale or distribution in isolation
but otherwise meets the standards for good licenses for code.
5. Licenses for Binary Firmware
Some applications, drivers, and hardware require binary-only firmware
to boot Fedora or function properly. Fedora permits inclusion of these
files if they meet certain requirements [currently set forth at:
https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware but the
non-license part of this needs to move somewhere else ].
Any license that is good for code is also good for binary firmware.
In addition, Fedora may designate a particular firmware license as
good for firmware if the terms in the license that would not be
acceptable in a good code license are limited to the following:
* Requirements that the firmware be redistributed only as incorporated
in the redistributor's product (or as a maintenance update for
existing end users of the redistributor's product), possibly limited
further to those products of the redistributor that support or contain
the hardware associated with the licensed firmware
* Requirements that the redistributor to pass on or impose conditions
on users that are no more restrictive than those authorized by Fedora
itself with respect to firmware licenses
* Prohibitions on modification, reverse engineering, disassembly or
decompilation
* Requirements that use be in conjunction with the hardware associated
with the firmware license
Richard
1 year, 2 months
Re: How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?
by Miro Hrončok
On 23. 03. 22 9:35, Vít Ondruch wrote:
>>
>> I understand your answer as that:
>> it is irrelevant whether the contributor specified the license (e.g.
>> text "I submit this under GPL-2.0 license" in the pull request
>> comment)
>
>
> If somebody states license of the contribution, then it has to be respected.
> Otherwise it is assumed that the contribution has similar licensing conditions
> as the target project.
If that's the case, can we please stop enforcing the signed-off-by thing in
Fedora projects (such as various Fedora projects on Pagure or Bodhi on GitHub)?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 6 months
How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?
by Michal Schorm
Hello,
I'm trying to answer this question:
"Under which license are the contributions done to Fedora Project,
unless license is specified - and how make this clear to the
contributors (or whether we make this clear enough)".
The answer is _probably_ FPCA [1].
But I've run into practical questions of how contributions can be made
to the Fedora Project in the first place. Let's start with
contributions to Fedora Linux.
--
The first Google result for "Fedora pull request" query points to [2].
On the first glance it looks fine, but it has two major issues.
1/ The instructions won't work and are holey
2/ It is a page under a "Fedora CI" project.
1/
Nowadays, we have a way for contributors outside of the 'packager'
group to make pull requests. It is a git push via HTTPS [3].
Neither [2] nor [3] describes that you need to have a FAS account
first, since without it you can't log in the pagure to fork a project
(otherwise there's nowhere you can push to).
I wanted to propose an update, but ...
2/
... this leads to a belief that such an important piece of
documentation should be probably placed outside of the "Fedora CI"
project, as it can be generalized to any project.
What could be this better location for a new documentation page to
which other pieces of documentation would point to?
And this HTTPS workflow leads back to my original question - since FAS
users outside of 'packager' group AFAIK don't need to sign FPCA [1],
but can contribute a code - under which license or agreement it is
contributed ? If it is FPCA - are such contributors aware ?
3/ Are there any other ways to contribute to either Fedora Linux or
the Fedora Project, which face the similar issue ?
[1] https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement
[2] https://docs.fedoraproject.org/en-US/ci/pull-requests/
[3] https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
1 year, 6 months
good/bad v. approved/not-approved
by Jilayne Lovejoy
Hi all,
As has been mentioned here prior, Richard and I are having a look at the
Licensing part of the Wiki with an eye towards any updates and
improvements, as well as moving that to the Fedora Docs (along with
David C's work on the database for the license info).
Recently Richard posted here regarding an attempt to better define the
Fedora license categories in terms of what constitutes a "good" license.
He referenced the use of the terminology of "good" and "bad" to indicate
whether a license is approved for use in Fedora or not.
I wanted to raise that separately b/c as we go through the
documentation, how to best explain things in the clearest way comes up.
It'd be helpful to hear people's views on this.
Historically - "good" has meant the license is approved for use in
Fedora; "bad" has meant the license is not approved for use in Fedora;
and then there are also three nuanced categories related to fonts,
documentation, and content which mean that certain licenses are only
approved for use in that context, but not otherwise approved.
How do people feel about the use of "good", "good-for-fonts", "bad", etc
to describe these categories? Would simply using "approved",
"approved-for-fonts", "not-approved", etc. be easier to understand?
I'll throw in my opinion here, since I'm asking for that of others: I'm
kind of mixed on this. I always thought the good/bad indicator was kind
of nice in it's informality. However, now that I'm looking more closely
at documentation, sometimes the use of good and bad can end up reading
oddly. Practically speaking, I think use of "approved" and
"not-approved" might end up being easier to understand. Good/bad also
also has a greater connotation of judgement versus simply "approved" -
which implies more closely that it must be approved for something. So, I
guess I'd lean towards simply using "approved" and "not-approved".
Given that "good" and "bad" are historical for the Fedora licensing
documentation - what are your thoughts on this?
Jilayne
1 year, 6 months
GFDL invariant sections question
by Jilayne Lovejoy
Hi all,
Fedora lists the GNU Free Documentation License as "good" for
documentation. the GFDL has this concept of "invariant sections" which
can be declared or not in the license header. If this is used, then it
creates some restrictions for those sections and there are some other
specific obligations in the license. (I'm not going to try to explain
this here, but if you are interested, this is probably a better summary
than trying to actually parse the text of the license
https://www.gnu.org/licenses/fdl-howto-opt.en.html)
Does any one know if GFDL is approved for Fedora regardless of if the
invariant section is triggered?
Thanks,
Jilayne
1 year, 6 months
