legal August 2007

legal@lists.fedoraproject.org

19 participants
20 discussions

Status?
by Tom Callaway 21 Aug '07

21 Aug '07

Todd, 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). ~spot

2 1

Re: texlive license
by Tom Callaway 17 Aug '07

17 Aug '07

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). > > http://people.redhat.com/jnovy/files/texlive/SRPMS/ 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 valid email). 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+) Public Domain (a lot of files are under the "GUST Font License", which is just the LPPL.) There are some files under different licenses: Acceptable for Fedora ===================== texmf-dist/doc/metapost/base/source/mpman.tex (MIT) texmf-dist/tex/latex/vntex/varioref-vi.sty (LGPLv2+) texmf-dist/doc/generic/vntex/source/vn-fonts.tex (Utopia) texmf-dist/doc/generic/enctex/unimap.diff (UCD) 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 included accidentally. Literat License: 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-dist/doc/fonts/literat/ texmf-dist/fonts/type1/paragrap/literat/ texmf-dist/fonts/map/dvips/literat/ texmf-dist/fonts/vf/paragrap/literat/ texmf-dist/fonts/afm/paragrap/literat/ texmf-dist/fonts/tfm/paragrap/literat/ texmf-dist/tex/latex/literat/ 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: texmf-dist/fonts/afm/public/qfonts/qhvcb.afm texmf-dist/fonts/afm/public/qfonts/qhvcri.afm texmf-dist/fonts/afm/public/qfonts/qhvcbi.afm texmf-dist/fonts/afm/public/qfonts/qhvcr.afm texmf-dist/fonts/afm/urw/bookman/ubkri8a.afm texmf-dist/fonts/afm/urw/bookman/ubkr8a.afm texmf-dist/fonts/afm/urw/bookman/ubkb8a.afm texmf-dist/fonts/afm/urw/bookman/ubkbi8a.afm texmf-dist/fonts/afm/urw/helvetic/uhvri8an.afm texmf-dist/fonts/afm/urw/helvetic/uhvri8a.afm texmf-dist/fonts/afm/urw/helvetic/uhvbi8a.afm texmf-dist/fonts/afm/urw/helvetic/uhvr8an.afm texmf-dist/fonts/afm/urw/helvetic/uhvb8an.afm 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 Fedora. texmf-dist/tex/latex/tools/multicol.sty Artistic (original): The original Artistic license is non-free, and thus, not ok for Fedora. These files are under the Artistic license: texmf-dist/tex/latex/fancybox/fancybox.sty texmf-dist/tex/latex/amscls/pcatcode.sty 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 a while. ~spot

5 7

Please add the Fedora Directory Server license to wiki/Licensing
by Rich Megginson 16 Aug '07

16 Aug '07

The Fedora Directory Server license is just GPLv2 (not or later) with the exception that any code that uses only the interfaces defined in the officially designated Interfaces file (slapi-plugin.h) distributed with Fedora Directory Server may use any license and be redistributed with Fedora Directory Server. This allows people to redistribute Fedora Directory Server with proprietary plugin code. This license was written and approved by Red Hat Legal. The full text is here: http://directory.fedoraproject.org/wiki/GPL_Exception_License_Text The annotated text is here http://directory.fedoraproject.org/wiki/Annotated_GPL_Exception_License

2 1

CDDL and cdrtools
by Harald Hoyer 16 Aug '07

16 Aug '07

I see on http://fedoraproject.org/wiki/Licensing that the CDDL License is ok. Can I reimport cdrtools then?

2 1

Packaging of standards in Fedora: Standards versus Documentation
by Daniel Veillard 14 Aug '07

14 Aug '07

Hi Danny, 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: https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c22 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 http://fedoraproject.org/wiki/Licensing#head-d8cc605dd386091c8b6be97b8a43fb… 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 or corrections. 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, Daniel -- 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/

2 1

Mesa licenses
by Ville Skyttä 14 Aug '07

14 Aug '07

Hi, 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. Thoughts?

1 0

Re: W3C documentation license
by Tom Callaway 13 Aug '07

13 Aug '07

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). > > Ouch. > > > 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" list. 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 RPM though. 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. ~spot

2 4

Artistic license
by Tom Callaway 10 Aug '07

10 Aug '07

Todd, 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. Thanks, ~spot

2 3

Re: [Fedora-packaging] Licensing guidelines suggestions
by Tom Callaway 08 Aug '07

08 Aug '07

Copying fedora-legal-list (where we should start having more public discussion). 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. ~spot

1 0

Trademark Conflict of "Fedora Project"
by Sean Stangl 08 Aug '07

08 Aug '07

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 Project. The bottom of the page is marked: (C) 2005-2007 Fedora Project. -Sean Stangl

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal August 2007