legal

legal@lists.fedoraproject.org

1 participants
1396 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal