Red Hat Bugzilla – Bug 198137
GeoIP contains the GeoIP.dat file without its license information
Last modified: 2014-01-21 17:54:54 EST
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 : http://www.maxmind.com/download/geoip/database/LICENSE.txt 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.
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 file. How would GeoIP-data-YYYYMMDD-1.%{dist}.noarch.rpm for a naming convention work for you?
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 time. 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 :-)
Created attachment 142276 [details] Simple perl hack to fetch new GeoIP.dat files.
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.
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.