On Tue, 2008-12-09 at 23:03 +0100, Matthias Saou wrote:
> > >>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:
> > TC> Given that it does not give permission for us to redistribute (the
> > TC> cornerstone requirement for Content licenses), this license is not
> > TC> acceptable for Fedora.
> > I guess I'm glad I looked before approving the package, but I have to
> > wonder: Do the cacert folks actually want anyone to use their
> > certificates? I mean, this prevents basically everyone from using
> > them, because they can't come with the OS or the browser.
> Personally, the more I read the document, the more I'm confused.
> "You may NOT distribute certificates or root keys under this
> licence"... does this mean we can distribute under a different license?
Well, sortof. The wording here is strange because you can get a
different license from the CA issuer. We can't just pick a license, but
the CA issuer might be willing to give us a different one.
> Would it be worth getting in contact with CAcert.org in order to try
> and have them allow us to redistribute the root certs under conditions
> which are acceptable to the Fedora Project?
Probably, yes. :)
The wiiuse library from http://www.wiiuse.net/ has an odd license; it is
GPLv3 or, for noncommercial uses, LGPLv3. I'm having trouble
understanding how that kind of use restriction works or if it works at
So: Is this kind of thing acceptable for Fedora? What would the
License: tag read?
My mind swirls with questions about whether I can accept their source
under the LGPLv3 and redistribute to someone under LGPLv3 who then uses
it in a commercial application, but I doubt that's on topic.
I am doing review of old/new package - visualvm . It used to be part
of openjdk until recently.
spec file contains multiple source tarballs.
* netbeans-profiler-visualvm_release69.tar.gz contains dual-licensed
files (GPLv2 with classpath exception or CDDL)
* visualvm_harness-*tar - GPLv2
* visualvm_13-src.tar.gz - GPLv2+
The jars from profiler tarball are separate (files from it are not mixed
into any other package, so classpath exception should be "working" as I
Harness tar is basically just configure scripts and build instructions.
visualvm_13-src contains the main application compiled using harness,
the jars from profiler tar are used as plugins.
I'd say it's OK to have this mix, but I'd like to be sure about exact
License tag that is appropriate here. Maybe:
License: GPLv2+ and (GPLv2 with classpath exception or CDDL)
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
Red Hat Inc. http://cz.redhat.com
On 11/23/2010 08:36 AM, Ben Boeckel wrote:
> On Mon, Nov 22, 2010 at 10:02:32AM -0500, Tom "spot" Callaway wrote:
>> On 11/21/2010 10:21 AM, lakshminaras2002(a)gmail.com wrote:
>>> There is no explicit disclaimer in the source package.
>> Please send the upstream copyright holder/author this message:
> Thanks. It's been changed to BSD3.
I am reviewing package request ghc-failure (
https://bugzilla.redhat.com/show_bug.cgi?id=630223 ). This is a haskell
package. Each haskell package has a cabal file (similar to a Makefile say)
that lists, among other things, the license of the sources.
In case of ghc-failure, the license is PublicDomain (as mentioned in the
cabal file). I looked at this page
http://fedoraproject.org/wiki/Licensing#Good_Licenses and found Public
Domain to be a *good* license. There reason for not having the space in the
word PublicDomain (based on my assessment) is that the cabal program will
not accept a license value with spaces.
Given that the license field in the cabal file is not textually matching the
license name that is listed in the webpage, is it ok to go ahead and use
"Public Domain" in the spec file? Is it required that the author of the
package be contacted to obtain a confirmation on PublicDomain
Thanks and Regards
Lakshmi Narasimhan T V
---------- Forwarded message ----------
From: Steven Garcia <webwhammy(a)gmail.com>
Date: Mon, Nov 15, 2010 at 2:22 PM
Subject: Re: [Fedora-legal-list] Package Licensing
To: Tom spot Callaway <tcallawa(a)redhat.com>
Thank you, for your reply.
I apologize for misinterpreting the packaging guidelines for bundled
libraries. For some reason when I was reading the guidelines, I was thinking
in the context of compiled shared or static libraries as is so often the
case. I failed to remember that in this context the definition of the term
PHP and others.
There are two places where I should have been able to answer my own
Again, I'm sorry for missing this. Please consider adding to the packaging
guidelines a note similar to, "In this RPM packaging context, the definition
of the term 'library' includes: compiled third party source code resulting
in shared or static linkable files, interpreted third party source code such
the license field of your RPM Spec file contains two or more licenses, be
sure to read http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries to
ensure you're meeting the packaging guidelines."
I merely mention these suggestions in an effort to reciprocate the help you
have given me in better understanding the packaging process.
I now realize the serious library flaws in my packaging. I'm going to
attempt individual packaging of the third party libraries.
Thank you for your time and consideration.
On Mon, Nov 15, 2010 at 7:28 AM, Tom "spot" Callaway <tcallawa(a)redhat.com>wrote:
> On 11/14/2010 11:30 PM, Steven Garcia wrote:
> > The following lists a name, license and brief for each third-party
> > source file group/library:
> I feel that you really should consider packaging (or using any already
> packaged) versions of these third party components, as opposed to
> bundling copies within your package.
> Not only would it resolve your licensing complexity, it would make it
> much more likely that your package would be permitted into Fedora
> without needing an exception, see:
Tom "spot" Callaway wrote:
> it is clear that the use of such emulators is primarily for use
> with non-free ROMs [with] few exceptions
By that logic, the use of media player software is primarily for
use with non-free music, which outnumbers music distributed under
a license for free cultural works. And the primary purpose for
a PDF viewer is for viewing non-free documents, which outnumber
documents distributed under a license for free cultural works.
If the issue is with the fact that only 27 games work, I can
dig up more exceptions. For example, an NES emulator is useful
to run software produced for the PlayPower project:
> it is not worth the likely risk of lawsuit to include
> "Nintendo" emulators
On what grounds would NOA sue Red Hat? As for patent infringement,
the patents on the NES expired half a decade ago. As for
contributory copyright infringement, as I understand it, an emulator
packaged with one or more free games appears to "be capable of
substantial noninfringing uses", as the U.S. Supreme Court put
it in Sony v. Universal. Another popular GNU/Linux distribution
demonstrates this noninfringing use by packaging a free NES game;
is it in trouble as well?
To put it another way, what's the specific legal difference between
FCEUX and DOSBox?
Once we characterize this difference, can someone update the
Licensing/SoftwareTypes page to mention emulators that will not be
packaged despite the availability of free software for the emulated
Please, allow me to introduce myself and the package I represent. I've
recently submitted a package for review at
https://bugzilla.redhat.com/show_bug.cgi?id=650767. This is my first Fedora
Core package and I'm not sponsored. I'm one of the upstream developers of
I was referred to this mailing list by
https://fedoraproject.org/wiki/Licensing#Discussion_of_Licensing. I have
thoroughly attempted to answer my own questions by reading the available
resources and looking at existing packages. However, I have much uncertainty
on how I should proceed regarding the licensing.
The package in question contains a web application similar in package
contents to wordpress or phpMyAdmin. The bulk content of the package
executable binaries being compiled or packaged. The source files that I and
the other upstream developers create is licensed under AGPLv3.
The following lists a name, license and brief for each third-party source
BRIEF: Third-party PHP source files
LICENSE: MIT or GPLv2
LICENSE: MIT or BSD or GPL
LICENSE: MIT or GPL
LICENSE: MIT or GPL
LICENSE: MIT or GPL
LICENSE: MIT or GPL
LICENSE: ASL 2.0 or GPLv2+ or LGPLv2+
NAME: Gears Init
LICENSE: BSD 3-clause no advertising
NAME: BrowserPlus Gateway
LICENSE: BSD 3-clause no advertising
The current RPM Spec license field for the package in question is:
License: AGPLv3 and GPLv2 and LGPLv2+ and MPLv1.1 and zlib and BSD and (MIT
or GPLv2) and (MIT or BSD or GPLv2+) and (ASL 2.0 or GPLv2+ or LGPLv2+)
I'm NOT sure that the above license field is correct.
Please, assist me in answering the following questions.
Is it acceptable in this specific case for approval as a Fedora package to
simply put 'License: AGPLv3' as the license field of the RPM Spec file? And
is it required in this case for approval as a Fedora package to express all
the third-party source group/library licenses in the RPM Spec file license
Is it required in this case for approval as a Fedora package to include in
the package a separate relevant license text file for every third-party
Please, assist me in specifying the proper RPM Spec license field for
approval as a Fedora package.