Bug 198137 - GeoIP contains the GeoIP.dat file without its license information
Summary: GeoIP contains the GeoIP.dat file without its license information
Alias: None
Product: Fedora
Classification: Fedora
Component: GeoIP   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Michael Fleming
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-10 09:07 UTC by Matthias Saou
Modified: 2014-01-21 22:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-07 02:12:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Simple perl hack to fetch new GeoIP.dat files. (1.02 KB, application/x-perl)
2006-11-28 10:52 UTC, Michael Fleming
no flags Details

Description Matthias Saou 2006-07-10 09:07:38 UTC
The current GeoIP-1.3.17 package includes /usr/share/GeoIP/GeoIP.dat which
upstream apparently provides inside their "GPL licensed C API". But that file
isn't GPL licensed. It has its own license which can be found here :


1) Upstream should at least include that license inside the "data" directory of
their C API sources, or not ship the .dat inside the tarball altogether.
2) Something should be done about the Extras package. Suggestions :
   - Include the required LICENSE.txt file.
   - Exclude the GeoIP.dat file and put it in its own package.

I would really prefer this last solution since it's currently hard to use the
latest GeoIP.dat file (Extras package has May version, but July version is
available!). One has to rebuild the package with some changes or force a manual
overwrite of the file (ugly...). Creating a GeoIP-country-data (or
GeoIP-country-data-lite or whatever) package that would be required by GeoIP for
instance. One could then also package the optional city data in the same way,
and since these would be noarch, some space would be saved too.

Comment 1 Michael Fleming 2006-07-20 09:29:22 UTC
Good point re: LICENSE.TXT, will integrate that next package.

My first thought was a cron script that pulled the monthly data file (backing up
the previous one) but granted, it's ugly and would add a curl/wget dependency
(if a shell script). I'd consider it if I get desperate ;-)

However do folks really want a new package, just for the data, this frequently
(Maxmind release them monthly both City and Country, usually on the 1st-3rd) -
especially for the 15mb+ City database. I could do this but dialup / slow-link
users will hate me :-)

I'd also need to add a Requires: GeoIP-data to GeoIP/mod_geoip/python-GeoIP too
(not that it's a hardship) and an %exclude to the existing package for the data

How would GeoIP-data-YYYYMMDD-1.%{dist}.noarch.rpm for a naming convention work
for you?

Comment 2 Matthias Saou 2006-07-25 11:51:40 UTC
I don't know what the best solution would be here. The current included dat file
that people need to manually overwrite to get updated, but that a package update
could actually downgrade doesn't seem right.

If you want to split out the country data, why not, but you'll need to update it
monthly, and you shouldn't add %{?dist} since it's not compiled code (thus
distribution independent) and request it to be copied across distributions every

The GeoIP-data-YYYYMMDD-1.noarch.rpm naming seems mostly ok, it could use the
"country" information somewhere though if it doesn't contain the city data. Or
you could go with plain "data" for the country file and "data-city" for the huge
city file. Only suggestions... there are many options here :-)

Comment 3 Michael Fleming 2006-11-28 10:52:29 UTC
Created attachment 142276 [details]
Simple perl hack to fetch new GeoIP.dat files.

Comment 4 Michael Fleming 2006-11-28 10:54:42 UTC
I've fixed the LICENSE file issues in the last set of package builds and attach
the following perl script, which I've hacked together to fetch newer data files
from the Maxmind website. This could be used in a cron job to fetch an updated
file once a month (MM tend to release these on the 1st-3rd of the month)

It's rough (about an hour of writing and testing undertaken at 11pm last night)
but it's yet to destroy nations or hit on your best mate's significant other -
I'm now using it to keep my own databases up-to-date. If it does destroy nations
 let me know. I tend to miss mass genocides in amongst the hubbub of everyday
life so a followup report would be handy.

I'm currently working on version that allows you to fetch the GeoIPCity Lite
database that a) works and b) looks like it was written by something that would
pass a Turing test.

Comment 5 Michael Fleming 2007-01-07 02:12:12 UTC
I've whipped these scripts into some shape and added them to 1.4.1-1.fc7 (as
%doc entries = an optional convenience / addition folks can use). Once the above
builds successfully and noone screams I'll add them to a new FC5/FC6 release.

FWIW I've been using them locally and not broken them yet. They're not
all-singing-all-dancing but they're doing the job.

Note You need to log in before you can comment on or make changes to this bug.