Concerns over SIF OFL
by Rahul Sundaram
Hi
Bruce Perens comments on some loopholes with OFL that allows anyone to
use fonts licensed under them as public domain equivalent. Since Fedora
has been recommending it over all other font licenses, maybe Red Hat
legal should look into it
http://lwn.net/Articles/319537/
Rahul
15 years, 1 month
"content" in source tarball
by Christian Krause
Hi,
I'm currently maintaining the package "anki" which is basically a
learning program. The original tarball includes a couple of sample files
with different licenses (some are not acceptable for Fedora). That's why
the tarball gets re-generated without the samples before it gets packaged.
In this case sample files mean that they contain larger amount of
"learning content".
Given the upstream package would be changed to contain only GPL-licensed
sample files - would the following be ok:
1. The new upstream package is used without modifications for packaging
and so the src.rpm would contain the (GPL-licensed) examples.
2. The binary package would not have these examples installed due to the
"no-content" policy.
Best regards,
Christian
15 years, 1 month
enabling CUDA support
by Milos Jakubicek
Hi all,
I've following bugreport from a BOINC user:
https://bugzilla.redhat.com/show_bug.cgi?id=487981
Basically, CUDA is a Nvidia technology which enables the GPU to be used
for various complex scientific computations (which are then even faster
than on CPU).
I was about to close the bug as WONTFIX as the whole CUDA is not open
source, but then I found out that BOINC (which recently added support
for CUDA applications) needs only the single libcudart.so library and
that this prebuilt library coming from Nvidia has been already included
in the source tarball (but not packaged as far).
Now I have a question: as it principally enables the hardware to be
controlled by some end-user applications, would it be possible to ship
the libcudart.so library in a subpackage as "Redistributable, no
modification permitted" like a firmware?
Actually this is what the Nvidia's EULA is saying about the Linux part
of CUDA:
http://developer.download.nvidia.com/compute/cuda/2_1/toolkit/CUDA_Toolki...
(see section 2.1.3)
Although I guess we can't do it in this way (I'm afraid that same
arguments could then be used for e.g. all closed-source modules), I
rather ask before definitely closing the bugreport.
Regards,
Milos
15 years, 1 month
regarding ntop binary data file formats
by Rakesh Pandit
Recently my co-maintainer made a update in rawhide for ntop package
from 3.3.8 to 3.3.9. It was without discussion with me. The update had
a dependency with GeoIP package which needs GeoLiteCity.dat and
GeoIPASNum.dat binary format files (they are compressed and optimized
form of big CSV files). GeoIP package can read this .dat files and
provide info. My questions is whether these .dat files can be included
into fedora ?
License for .dat files is at:
http://geolite.maxmind.com/download/geoip/database/LICENSE.txt
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=488717
Build id: http://koji.fedoraproject.org/koji/buildinfo?buildID=92821
Snippet from http://www.maxmind.com/app/geolitecity
"""
GeoLite City is offered in binary format, a highly optimized database
that supports fast lookups using our Open Source API code. We
recommend using the binary files with APIs instead of importing the
CSV files into SQL because the binary format is more efficient and is
easy to set up and use.
* Binary Format Installation Instructions
* Download the latest GeoLite City Binary Format (28 MB when
uncompressed, last updated February 1st, 2009, next update March 9th,
2009)
CSV Format
Our CSV format enables you to load the database into a SQL database.
The GeoIP City and GeoLite City use the same locationIDs, so the GeoIP
City CSV files can be used as a drop in replacement for GeoLite City
CSV files without having to change the locationIDs. Note that queries
made against the CSV data imported into a SQL database can take up to
a few seconds. If performance is an issue, the binary format is much
faster, and can handle thousands of lookups per second.
* Instructions on how to use our CSV databases with a SQL database.
* Download the latest GeoLite City CSV Format (100 MB when uncompressed)
"""
--
Regards,
Rakesh Pandit
15 years, 1 month
Do we need to remove proprietary code from previous releases?
by Orcan Ogetbil
Recently I took over the orphaned package libzzub in F-10 and devel. I
found that the upstream renamed the package to armstrong, so I opened
a review request for armstrong and it just got approved.
But whenever I was packaging armstrong, I found that the source
tarball contains some MS propriatary code. This code does not get
compiled into the final binary RPM but I removed it from the tarball
when I created the SRPM. libzzub is now going through the
PackageEndOfLife process and will be removed from F-10 and devel soon.
The thing is, the old package libzzub that is in F-7, F-8 and F-9
still has this code in the SRPM. How shall we proceed in this case?
Orcan
PS: Specifically, the directory src/rtaudio/include needs to be
removed from the libzzub tarball.
15 years, 1 month
Legality of staple / unstaple
by Michel Salim
staple / unstaple is an all-or-nothing data "binder" / unbinder,
licensed under the BSD license.
http://sysnet.ucsd.edu/projects/staple/
The author raises a concern that unstaple might be considered illegal
due to its ability to brute-force the stapled file, and the FAQ listed
some use cases involving misappropriation of intellectual property
(the pirated file is combined with the author's own files, stapled
together, and attempts to unstaple this collection arguably violates
the DMCA).
In view of this, staple is shipped separately from unstaple. Would
either, or both, be acceptable in Fedora? Could we get staple in
Fedora and unstaple in some non-US repositories?
This software has been discussed on Bruce Schneier's blog:
http://www.schneier.com/blog/archives/2009/03/all-or-nothing.html#comments
Thanks,
--
miʃel salim • http://hircus.jaiku.com/
IUCS • msalim(a)cs.indiana.edu
Fedora • salimma(a)fedoraproject.org
MacPorts • hircus(a)macports.org
15 years, 1 month
CeCILL licenses
by Michel Salim
Hello,
Upstream for a package I just submitted for review, Scheme2Js
(https://bugzilla.redhat.com/show_bug.cgi?id=487938) has indicated
that the license is switching from GPL+ to CeCILL-C (v2):
http://www.cecill.info/licences.en.html
CeCILL itself is free and GPL-compatible, and is FSF-approved, though
there's no clarification about whether this is GPLv2 or GPLv3:
http://www.gnu.org/licenses/license-list.html#SoftwareLicenses
CeCILL-C (component) is claimed to be LGPL-compatible, though I'm not
sure if FSF approves it as well, or just the main CeCILL license (and
again, version 2, 3 or both).
CeCILL-B (BSD) is like the BSD license with advertising, which I guess
rules it out from Fedora.
Could the legal team look into this? The license is INRIA-originated,
so it's possible that in the future, more INRIA software (such as
Bigloo, already in Fedora) might switch over.
Thanks,
--
miʃel salim • http://hircus.jaiku.com/
IUCS • msalim(a)cs.indiana.edu
Fedora • salimma(a)fedoraproject.org
MacPorts • hircus(a)macports.org
15 years, 1 month
