Re: [Fedora-legal-list] CAcert.org license
by Tom Callaway
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. :)
~spot
7 years, 10 months
LGPL for noncommercial works only?
by Jason L Tibbitts III
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
all.
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.
- J<
13 years
Can i use Fedora
by kiran
Dear Sir,
Can I download the fedora and use it in my office or commercial purpose
without buying any licence or paying anything.
Regards,
Kiran.
13 years
visualvm multi licensing
by Stanislav Ochotnicky
I am doing review of old/new package - visualvm [1]. 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
understand it).
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)
Thanks,
[1] https://bugzilla.redhat.com/show_bug.cgi?id=640205
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
PGP: 71A1677C
Red Hat Inc. http://cz.redhat.com
13 years
Re: [Fedora-legal-list] Regarding ghc-failure
by Tom Callaway
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:
> <snip>
>
> Thanks. It's been changed to BSD3[1].
Thanks Ben!
~tom
==
Fedora Project
13 years
Regarding ghc-failure
by Lakshmi Narasimhan T V
Hello,
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
13 years
Fwd: Package Licensing
by Steven Garcia
---------- 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
"library", includes interpreted third party source code such as JavaScript,
PHP and others.
There are two places where I should have been able to answer my own
questions:
http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Split_up_the_p...
http://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_...
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
as JavaScript, PHP and others." Also, consider adding a note similar to, "If
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:
>
> http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>
> ~spot
>
13 years
Re: [Fedora-legal-list] Free emulators that run free games
by Damian Yerrick
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:
<http://playpower.org/>
> 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?
<https://launchpad.net/ubuntu/maverick/+package/efp>
To put it another way, what's the specific legal difference between
FCEUX and DOSBox?
<http://koji.fedoraproject.org/koji/buildinfo?buildID=174907>
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
platform?
--
Damian Yerrick
13 years
Package Licensing
by Steven Garcia
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
this package.
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
consists of interpreted code such as PHP and JavaScript. There aren't any
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
file group/library:
NAME: ezSQL
LICENSE: LGPL
BRIEF: Third-party PHP source files
NAME: jQuery
LICENSE: MIT or GPLv2
BRIEF: Third-party JavaScript source file
NAME: Sizzle
LICENSE: MIT or BSD or GPL
BRIEF: Third-party JavaScript source file
NAME: jqXslTransform
LICENSE: MIT
BRIEF: Third-party JavaScript source file
NAME: jqLayout
LICENSE: MIT or GPL
BRIEF: Third-party JavaScript source file
NAME: jqForm
LICENSE: MIT or GPL
BRIEF: Third-party JavaScript source file
NAME: jqUI
LICENSE: MIT or GPL
BRIEF: Third-party JavaScript source files
NAME: jsTree
LICENSE: MIT or GPL
BRIEF: Third-party JavaScript source files
NAME: Sarissa
LICENSE: ASL 2.0 or GPLv2+ or LGPLv2+
BRIEF: Third-party JavaScript source files
NAME: Plupload
LICENSE: GPLv2
BRIEF: Third-party JavaScript and PHP source files
NAME: Gears Init
LICENSE: BSD 3-clause no advertising
BRIEF: Third-party JavaScript source file
NAME: BrowserPlus Gateway
LICENSE: MPLv1.1
BRIEF: Third-party JavaScript source file
NAME: CodeMirror
LICENSE: zlib
BRIEF: Third-party JavaScript source files
NAME: ParsePHP
LICENSE: BSD 3-clause no advertising
BRIEF: Third-party JavaScript source files
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
field?
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
source group/library?
Please, assist me in specifying the proper RPM Spec license field for
approval as a Fedora package.
Thank you.
13 years
