Some of Fedora's packages are using an MD5 implementation which is under
a GPLv2/v3 incompatible license, specifically, the RSA implementation
which is under BSD with advertising.
You can look at this code here:
We've identified packages which are possibly using this implementation,
and all maintainers are on CC. Please take a moment to look at your
packages and check to see if this md5 implementation is used.
If your package is on this list, please email me back and let me know
once you've checked the md5 implementation. If it is the RSA
implementation, we're going to need to replace it (coreutils has a GPL
compatible implementation that should be a drop in). If your package is
not under GPL or LGPL, then there is no problem, and you can just email
me and let me know that.
Thanks in advance,
Recently, most (all?) of Dan Bernstein's software was relicensed into
the public domain.
Please hold off on packaging and submitting these packages for review
into Fedora, pending legal advice as to whether he can actually do that
or not, under US law.
When doing man-pages-es, I encountered following copyright announcement:
These man pages come under various copyrights.
All are freely distributable when the nroff source is included.
It obviously is not included in the Fedora-license list at
What should I put in the license field in SPEC file?
> There is a Kerkis package for TeX (tetex-font-kerkis). Nowadays, the
> author of this font publishes TTF and OTF files, quite suitable for
> on-screen display. The license, however, is a bit ambiguous, possibly
> even a removal candidate. http://iris.math.aegean.gr/kerkis/ (see the
> License subsection).
This one should have been passed through fedora-legal before
inclusion. Everyone please do not package any font with a new license
without getting its license approved on
I sent this to the rpmfusion-developers list yesterday. It occurred
to me that it might be worth sending here too...
So, is there any chance that the wording below justifies or leads to
approval of a b43-firwmare package in the official Fedora repository?
If so, then I will cease my efforts to get such a package into RPM
Fusion. It certainly would be better for our users to have these
packages in the main repository rather than in a 3rd party one.
Thanks for your consideration!
P.S. Regarding my reference to "any Fedora Authority", all my Fedora
project inquiries thus far have been 1:1 or 1:few between me and the
interested parties. This is my first formal inquiry on this issue.
----- Forwarded message from "John W. Linville" <linville(a)tuxdriver.com> -----
> Date: Mon, 12 Nov 2007 16:01:27 -0500
> From: "John W. Linville" <linville(a)tuxdriver.com>
> To: rpmfusion-developers(a)lists.rpmfusion.org
> Subject: consider a b43-firmware package like this?
> Probably some of you know my name and my role with Fedora and the
> Linux kernel. If not, then suffice it to say that I am very interested
> in having people get wireless working as easily as possible.
> One problem that often hinders users in that regard is firmware for
> their wireless devices. Fortunately, Fedora has accepted firmware
> packages in the main repository for some time. And, we have had
> good success with getting firmware made available under suitable
> licenses for Fedora. Still, one particular vendor has been non-
> (but not necessarily anti-)cooperative: Broadcom. This is a problem,
> as their devices are quite common.
> The "approved" firmware for use with the b43 and b43legacy drivers
> comes from the OpenWRT website, where it is provided as part of larger
> MIPS binaries. AFAIK Broadcom has never bothered OpenWRT about this,
> yet neither have they offered an explicitly stated license for this
> The MIPS binaries from the OpenWRT site in turn come from packages
> distributed by wireless AP vendors in order to comply with the GPL.
> The MIPS binaries are pre-compiled in those packages, but they are
> clearly intended to be linked into Linux kernels to run on those APs.
> In my mind, this at least implies intent that it is alright to
> redistribute these binaries.
> So, I have created packages which use these AP vendor's GPL packages as
> sources, extract the MIPS binaries, then further extract the wireless
> firmware using b43-fwcutter. It is a bit odd in that the src.rpm file
> (containing the AP vendor code) is huge, while the binary rpm file
> is tiny. But, they work just fine. :-) I have packages for both
> b43 and b43legacy. I will include the COPYING file I composed for
> inclusion in the b43 firmware package below. I have a similar one for
> the b43legacy package.
> Perhaps not surprisingly, the string of arguments above has yet to
> sway any Fedora authority to bless these packages. So I wonder,
> is the case above strong enough to merit including such packages in
> RPM Fusion? If that seems likely, then I'll be happy to submit the
> packages for your review. Obviously this would seem to belong in the
> "non free" section...
> P.S. COPYING file from the b43-firmware package below. (The "by
> permission of" bit was suggested by someone else -- I'm happy to
> augment it or remove it as anyone might suggest...)
> Redistributed by permission of Broadcom in binary form only, no
> modifications permitted.
> The source archive for this package was reached through a link at
> the following URL:
> The text at that location reads as follows:
> GPL Code Center
> The source code files available on this page have been provided
> under one or more open source licenses. Select your Linksys
> product model and a firmware version from the list below to
> download the source code library.
> The source code found here is complete to the best of
> Linksys’ knowledge. If you believe any additional
> source code files should be provided under the
> applicable open source license, please contact Linksys at
> linksys-opensource(a)linksys.com and provide in detail the
> product or code module in question. Linksys is committed to
> meeting the requirements of the open source licenses including
> the GNU General Public License (GPL) and will make all required
> source code available.
> The following URL is the direct link to the archive used as the source
> of this package:
> The source archive was specifically provided by Linksys in order to
> fulfill obligations arising from distribution of software licensed
> under the GPL and other open source licenses. Given that fact,
> it is reasonable to infer that redistribution of the archive itself
> and the contents of that archive is accepted by Linksys, Broadcom,
> and any other copyright holders.
> John W. Linville
----- End forwarded message -----
John W. Linville
I'm packaging rdflib ( http://rdflib.net/ ); what should the specfile
License: field read?
License follows inline:, appears to me to be a variant of 3-clause BSD:
LICENSE AGREEMENT FOR RDFLIB 0.9.0 THROUGH 2.4.0
Copyright (c) 2002-2006, Daniel Krech, http://eikeon.com/
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
* Neither the name of Daniel Krech nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.