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. :)
winetricks  is free software, but I was originally under the
impression that it was ineligible for inclusion in Fedora because it
is used primarily to download and install non-free software. (That is
not it's only function, though--it also does some registry hacks and
can manage multiple WINEPREFIXes.)
However, some members of the community disagree  and say that it
might be eligible for Fedora, so we'd like confirmation one way or the
python-requests has a license change at version 1.0.0.
We currently have the old version packaged, licensed ISC.
The new version is licensed Apache2.
We've been hesitating about whether or not to update because we're not
sure what impact the license change will have on dependant
For instance, a hypothetical GPLv2 python program may currently be
importing python-requests for use at runtime. If we updated
python-requests (from ISC to Apache2), would we be throwing that
program into a license violation?
Should we go ahead and update? Do we need to take any special precautions?
It is my understanding that Mesa supports certain "floating point"
features that are currently disabled in Fedora builds. With Mesa 9.1,
Intel has now enabled these features by default.
I notice the Fedora Mesa 9.1 build still disables this support. Is
floating point support still not shippable?
I'm dealing with the code which is licensed under the following terms:
Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. All rights reserved.
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
L. Peter Deutsch
I've got two questions:
* Is this license OK for Fedora?
* If yes, can it be used in GPLv2+ licensed application?
With best regards, Peter Lemenkov.
On 02/11/2013 01:10 PM, mejiko wrote:
> 2013-02-11 (Monday) 10:52 +0100 Jan Safranek wrote:
>> Now, can Fedora ship these files? IMHO yes, reading RFC 5377, chap. 4.3,
>> it's IETF's intention to allow such extraction, modification and
>> distribution. But I am not a lawyer.
>> The MIB files are considered Code Components as defined at
>> http://trustee.ietf.org/license-info/ and its license is (probably)
>> defined at http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
> I viewed this license page.
> MIBs code licensed under BSD (3 cause) License.
> Its free (BSD license is "Good" license, See Reference).
> Its no license problem.
> but RFC document license is freely redistributable, but do not allow
> modify. RFC document is not code, Its document (not content).
In section 4.1 are MIB files inside RFCs defined as "code components".
And in 4.2, BSD is applied to these code components, i.e. MIB files in
the RFC texts as BSD licensed. Therefore we may distribute these code
components, i.e. MIB files, as separate files and even modify them if we
want (and we do, because there are typos in the MIB files).
IMHO while the RFC document is non-free (cannot be modified), the MIB
files inside are free (and can be modified and distributed separately).
Is the use of trademarked terms acceptable in a package Summary,
%description, or in it's .desktop files?
A concreate example are games, is it acceptable for game "foo" to say it's a
clone of popular (trademarked) game "bar"? Any guideline or advice to
follow? (my quick searching and googling failed me)
I've got bugs #901504 and #901505 stating that Fedora should not
distribute MIB files generated from IETF RFCs.
Some RFC, e.g. 4293 , contains MIB files as part of the RFC text. 1:
Net-SNMP and libsmi upstream tarball already contains these MIB files
extracted from the RFCs. The 'extraction' is just copy of part of the
RFC with removed page headers / footers.
Now, can Fedora ship these files? IMHO yes, reading RFC 5377, chap. 4.3,
it's IETF's intention to allow such extraction, modification and
distribution. But I am not a lawyer.
The MIB files are considered Code Components as defined at
http://trustee.ietf.org/license-info/ and its license is (probably)
defined at http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
Removing the MIB files from the packages would be very tedious, annoying
and IMHO useless.
-----BEGIN PGP SIGNED MESSAGE-----
I make a speech again about a couple of license issues.
In past, both questions have been discussed in two different
Currently, I have opened a new package review request
(https://bugzilla.redhat.com/show_bug.cgi?id=908089) of Ipopt which
considers both Mumps and Metis employment. Politely, Paulo shows me
that these license types have already been evaluated some months ago.
In particular, I wish to point out:
- - Mumps is released without any copyright or license rescriction but
as 'public domain': http://mumps.enseeiht.fr/index.php?page=credits
- - Metis seems "can be used for non-commercial projects without any
restrictions. For commercial-use, the essential restriction is for the
vendors not to be reselling Metis".
Should I consider these licenses incompatible with Fedora policies
"Fedora italian translation group"
Sip Address : sip:sagitter AT ekiga.net
Jabber :sagitter AT jabber.org
GPG Key: D400D6C4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
I am making a RPM package for javax.el-api, however I am not sure which license should I use for it.
From page http://uel.java.net/, it claims it uses license CDDL and GPLv2. Should I add ASL 2.0 for it?
Now I am using "(CDDL or GPLv2) and ASL 2.0".
David Xie (谢凌)
Founder of ScriptFan Technology Community
Manager of Xi'an GDG (Google Developer Group)