Am 04.01.2020 um 01:53 schrieb Faidon Liambotis:
> On Sat, Jan 04, 2020 at 12:44:49AM +0100, Patrick Matthäi wrote:
>> So if we are not allowed to distribute it anymore we have got the
>> following options:
>> 1) we keep the the current free database in our repository, which is
>> free and works. We dont care about the precision after X years (not our
>> fault)
> That would be (very) misleading and I'm not sure if it would be in the
> service of our users. The data gets stale really quick --I think it was
> something like 2-5% loss per month? My opinion is that shipping no data
> is better than shipping garbage data...

I support this opionion for 100%.

>> 2) we drop the database package. Also if it is something like contrib,
>> but if there is no free working alternative, shouldnt we (as in Debian
>> as open source community) then also remove all libraries and
>> implementations using GeoIP from Maxmind from our repositories? 
> I don't agree with that; the libraries are free-libre, the file format
> is open and freely documented (CC-BY-SA 3.0), and there are both readers
> and writers for those formats in the archive. There are even
> free-as-in-beer databases available in the wild, although that wouldn't
> even be a requirement IMO. There is nothing in the DFSG that says that
> software is free-libre only if it operates on publicly available
> free-libre data.

We have got many similar examples in another category: games
Old games like Quake, Red Alert, Roaler Coaster Tycoon etc etc, the game
code now itself is free: sometimes reverse engin., new code or open
sourced by the publisher itself. But often the required game data
(images, videos, etc) are not distributable and required from the
original cd-rom.

So the game code itself is free, but we have to put it in contrib,
because it is only useable with non-free data.
This is exactly the situation with geoip now: there is so much free
code, but it is only useable with a non-free additional.

That also means every software depending on that/compiling on that is
also contrib and so on not main/free anymore. A desaster

>> 3) We/others/I and others start a fork: I would welcome volunters to
>> start a fork to maintain the database, so that it is not useless in a
>> few years, but this is also one of my last options. I would like to have
>> a solution with Maxmind together.
> I wouldn't mind that option of course, but I have my doubts it'd be
> successful... That's essentially MaxMind's entire business that you'd be
> trying to replicate, after all :)

Correct ;)
But I also have to think about some other ways. And Debian is not the
only distribution with this problem now

> How about option (4):
> - We drop geoip-database, assuming that we determine we can't legally
>   distribute it anymore, or ship it in non-free if we determine we can.
>   [I haven't read the terms yet]

I would like to have an expert opinion about the options.. The license
itself sucks and says fcky. If understood the law correctly the it would
be enough to get a free version of the data without any california users
(if in/or country database.. who cares). But the ball is now on the side
of maxmind..

> - We let users generate and/or ship their own MMDBs. For example,
>   organizations may have internal data in their databases of sufficient
>   accuracy that they can use to generate MMDBs and use them locally.

This would move all packages linking again libgeoip then to contrib

> - Optionally, users can also use geoipupdate, which is already in Debian
>   (and in contrib). They can sign up on, for either a free
>   or paid account, configure geoiupdate with their username & license
>   key and get fresh and up-to-date databases. They can continue to use
>   all MMDB/GeoIP2 software as they previously did.
Again to contrib
> Definitely not as easy to set up or practical as the previous situation,
> but still better than options 1-3 I think :)
>> So @Maxmind:
>> <snip>
> My intepretation of the change is very different than yours, but I'll
> avoid speaking for MaxMind folks here :)
> Regards,
> Faidon

Reply via email to