Can you run another check on how many packages are out of licensing
compliance (with regards to tagging in specs)?
We might want to start generating stats broken down by maintainer (I
know I still have some errors in my own packages, for example).
On Tue, 2007-08-14 at 09:46 -0400, Matthew D Truch wrote:
> There are three. I was starting with the texlive-texmf package (which
> is needed before one can build the texlive package).
I did a license audit on the texlive-texmf package this morning (derived
from texlive.texmf-2007.tar.bz2, texlive.texmf-var-2007.zip), in the
attempt to properly tag the package licenses (Distributable is _NOT_ a
valid license in Fedora).
I've CC'd several folks, including an upstream contact (hopefully, a
Here's what I found:
The majority of the files are under one of the following licenses:
LaTex Project Public License (LPPL)
GNU Public License v2 (GPLv2)
GNU Public License v2 or later (GPLv2+)
(a lot of files are under the "GUST Font License", which is just the
There are some files under different licenses:
Acceptable for Fedora
texmf-dist/doc/latex/fancyvrb/* (Artistic 2.0)
Not Acceptable for Fedora
I found several items which were licensed with non-free licenses. This
seems to conflict with the TexLive policies
(http://www.tug.org/texlive/copying.html), so I can only assume they're
There are several files under a "literat" license, this license does not
permit any modification of the fonts, so it is non-free and accordingly,
not acceptable for Fedora. The files under this license are:
texmf-doc/doc/german/latex-tipps-und-tricks/literat.sty (not under the
license, but probably irrelevant without the literat bits)
Aladdin Free Public License:
The Aladdin Free Public License is non-free, thus, not acceptable for
Fedora. The following files are under the AFPL:
LPPL with commercial use restriction:
There is one file which has an additional restriction to the LPPL,
forbidding commercial use without explicit permission from the author.
This almost certainly renders the file non-free, and it is not ok for
The original Artistic license is non-free, and thus, not ok for Fedora.
These files are under the Artistic license:
If they could be relicensed (either dual licensed with something
acceptable, or to something like Artistic 2.0), they'd be fine.
=== Fedora specific notes ===
If all of those files under bad licenses are removed, then the
appropriate Fedora licensing tag would be:
License: Artistic 2.0 and GPLv2 and GPLv2+ and LGPLv2+ and LPPL and MIT
and Public Domain and UCD and Utopia
As is, this package is not ok for Fedora. I've put an FE-Legal block on
the review ticket, please let me know when you have a cleaned SRPM (you
don't need a sanitized tarball, just don't package the "bad" items in
the buildroot, and nuke them during %setup if possible)
My brain hurts now. I'm going to curl up into a ball and rock gently for
sorry to bother you but I realized that my packaging of HTML-4.01 DTDs
for fedora had to be modified to not include the text of the HTML
specification from the package:
I though that was weird the goal is to make the W3C technical specifications
as widely availble as possible, checking further I found out that the reason
is that the Licence doesn't allow modification of the standards
I think W3C position makes perfect sense, you don't want another organization
to ship modified version of the XML standard specifications for examples
or at least not calling them XML or W3C documents. On the other hand
in general Fedora own principle to force documentation to be modifiable
can be considered good for the users, for example to provide translations
But I feel disturbing that as a result of this conflict we simply can't
ship any of the W3C specifications as part of Fedora. In that case clearly
the position taken by both entities ends up being against the people good.
I don't know if there is a way to solve this, maybe consider standard
specification as special case in Fedora. But I feel the core of the issue
is not a matter of modification, it's rather a branding problem, making
a derivation of the spec is not in the absolute a problem, it's claiming
that it's still the spec (and in this case the result of W3C process and
carrying the stapm of approval after the changes). Wouldn't that requirement
on usage be better addressed with a different mechanism like a trademark
rather than a rather strict 'you cannot modify this text and redistribute it'
which I feel doesn't fully address the point.
In any way I would look forward a solution allowing to ship W3C standard
specification as part of Fedora,
thanks in advance for any suggestion you could provide on the matter,
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
While looking into copyright notices in files included in xine-lib, I noticed
that it contains a private "myglext.h" header which has the "SGI Free
Software License B, Version 1.1" license notice. This license is currently
listed as non-free in Wiki and FSF's pages.
For xine-lib we can just disable the OpenGL output plugin - I gather it's
non-essential - but I also noticed that this license notice is present in a
lot of files included in various files in mesa-* packages, including public
header files, which sounds like a much bigger problem. Some of those files
have changed to MIT-like licenses in Mesa 7.x, but a lot of the SGI FreeB
licensed ones remain.
On Mon, 2007-08-13 at 00:31 +0300, Ville Skyttä wrote:
> On Sunday 12 August 2007, you wrote:
> > On Sun, 2007-08-12 at 23:18 +0300, Ville Skyttä wrote:
> > > Hi spot,
> > >
> > > The Fedora Wiki licensing pages do not have an entry for the W3C
> > > Documentation License, only W3C software. Could you look into it? The
> > > license is online at
> > > http://www.w3.org/Consortium/Legal/copyright-documents (currently
> > > redirects to
> > > http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231).
> > That license explicitly forbids derivative works, so I know what the FSF
> > will say about it (non-free).
> > Do we have documentation of significance that is using it?
> html401-dtds does ship the HTML 4.01 specification which is covered by that
> license. However, the DTDs and related items in it, which are the most
> important bits of the package, lack a specific license but the W3C IPR FAQ
> says in the absence of such a notice, they may be used under the W3C software
> license: http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#DTD
> xhtml1-dtds also contains documentation under the W3C documentation license,
> but unlike html401-dtds, only in the tarball inside the source rpm, not in
> binary packages.
So, the 6 million dollar question is whether documentation is code or
content. We permit content which is freely redistributable but not
modifyable, and the W3C Documentation License meets that criteria.
I think it comes too close to code for my tastes, thus, the W3C
Documentation License is not ok for Fedora. I've added it to the "bad"
I think this is simple enough, because nothing prevents the docs from
being placed online, and then replaced in the package with a text file
URL that points to the docs that we don't include.
I don't see a need to pull docs out of the SRPM under this license,
we've only had to use modified tarballs for cases where the item was
legally not redistributable. They definitely can't go into the binary
I'm forwarding this to fedora-legal-list, so it goes on the record. We
probably want to have these sorts of discussions there in the future.
Since I know you've got a checkout of everything already, can you tell
me how many packages have "Artistic" in their license list?
We need to figure out whether we will permit the Artistic license or not
in Fedora, and having those stats is step one.
Copying fedora-legal-list (where we should start having more public
On Wed, 2007-08-08 at 14:27 -0400, Todd Zullinger wrote:
> Hey Tom,
> Tom spot Callaway wrote:
> > Eh, I suppose there is no difference. I'll nuke LGPL+ off the list.
> I suppose we'll need to let the few folks that updated their specs to
> use LGPL+ then? Here's the list:
> devel/Hermes/Hermes.spec:License: LGPL+
> devel/hunspell-ee/hunspell-ee.spec:License: LGPL+
> devel/hunspell-en/hunspell-en.spec:License: LGPL+ and BSD
> devel/hunspell-es/hunspell-es.spec:License: LGPL+
> devel/hunspell-hr/hunspell-hr.spec:License: LGPL+ or SISSL
> devel/hunspell-nl/hunspell-nl.spec:License: LGPL+
> devel/hunspell-pl/hunspell-pl.spec:License: LGPL+ or GPL+ or MPLv1.1
> devel/hunspell-sl/hunspell-sl.spec:License: LGPL+
> devel/hunspell-th/hunspell-th.spec:License: LGPL+
> devel/imlib/imlib.spec:License: LGPL+
> devel/p7zip/p7zip.spec:License: LGPLv2 and (LGPL+ or CPL)
Yeah. Would you mind emailing these folks, with apologies?
> BTW, over 1000 packages now have the proper license tags. That still
> leaves a large amount with invalid tags, but I was looking for the
> positive point of view for once. :)
> I've been running my little check-licenses.py script each day to
> follow the progress. There've been a few changes to the short names
> since I started doing this. Are you working with Ville to keep the
> changes synced with rpmlint? I'm using the config from rpmlint in my
> tests and am wondering if there's an easier way to sync changes than
> by doing diffs on the wiki?
> The attached diff attempts to sync up the changes to the short names
> on the wiki with the rpmlint config. Perhaps it will be useful to you
> or Ville.
We've talked about it, and we're going to resync when things quiet down
a bit. There are several licenses still out for review at the FSF.
We seem to have a conflict of names with the "Fedora Project" at
http://www.fedora.info/ , a provider of open source software, who
therefore co-exists in the same market niche as Red Hat's Fedora
The bottom of the page is marked: (C) 2005-2007 Fedora Project.