gdbm license change

Honza Horak hhorak at
Tue Dec 13 09:48:30 UTC 2011

On 12/12/2011 07:15 PM, Toshio Kuratomi wrote:
> On Mon, Dec 12, 2011 at 06:08:53PM +0100, Honza Horak wrote:
>> On 12/09/2011 10:01 PM, Tom Callaway wrote:
>>> On 11/15/2011 03:19 AM, Honza Horak wrote:
>>>> If there are some license issues not easy to solve, there is still a
>>>> compat-gdbm package, which ships gdbm-1.8.3 with GPLv2+.
>>> The problem is that compat-gdbm has no -devel package, and we cannot use
>>> the gdbm-devel package for this.
>>> Since Thorsten Kukuk is unwilling to relicense ypserv to resolve the
>>> licensing conflict, we are left with the following options:
>>> * Modify compat-gdbm to have a true -devel package (this will almost
>>> certainly require namespacing it somehow, like "")
>> I like this one, since it seems to be the easiest solution from my POV.
> Be wary of making a quick estimate of the amount of work involved here.
> Taking on a true compat-gdbm for this role means that you would be taking
> over code that is no longer supported by upstream for an indefinite time
> period.  You would then be responsible for solving all bugs in the package
> and fixing them yourself.  There might also be a legal line that needs to be
> observed here as the gdbm-1.8.x maintainer cannot use GPLv3+ code (the new
> gdbm) to help make fixes to the GPLv2+ code so it may be that you actually
> cannot maintain both packages yourself.... probably should discuss with spot
> just what would be okay in this case.
> To me, the easiest solution for you is probably going to be dropping ypserv
> from the distribution.  But if that's not possible, then attempting to
> convince the gdbm upstream to switch back to GPLv2+ would likely be
> a worthwhile investment.

I've asked gdbm upstream to do so, waiting for response right now.

Dropping ypserv isn't possible because there is no alternative for NIS 


>> But I don't see necessary to solve conflicts using renaming library and
>> header files. I'd rather just let compat-gdbm-devel and gdbm-devel
>> sub-packages to conflict (use "Conflicts:" explicitly), since it doesn't
>> make sense to me to have both packages installed at the same time (base
>> packages won't conflict). Then we don't have to change anything but
>> "Requires:" in packages like ypserv.
>> Please, let me know if you see any problems when solving that this way.
> The Fedora Packaging Guidelines forbid this.
> ( IIRC, this was last revisited this year and it was decided that the
> guideline should continue to prohibit Conflicts.  You're welcome to bring it
> up again but you would probably want to find the packaging meeting notes
> where relaxing the conflicts guideline was discussed and be sure that you're
> bringing new ideas to the table instead of rehashing the ones already
> discussed.)
> -Toshio

More information about the devel mailing list