bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: obstack: fix license problem


From: Jim Meyering
Subject: Re: obstack: fix license problem
Date: Fri, 24 Oct 2008 10:08:50 +0200

Bruno Haible <address@hidden> wrote:
> Hi Simon,
>
>> Using the obstack module results in warnings:
>>
>> warning: module obstack depends on a module with an incompatible license: 
>> exit
>> warning: module obstack depends on a module with an incompatible license: 
>> exitfail
>>
>> The reason appears to be because obstack is 'LGPL' while exit and
>> exitfail is 'GPL'.
>
> Yes, this is so, unfortunately.
>
>> Would you agree to re-license this module to 'LGPL'?
>
> This is the wrong approach, IMO. If you are using 'obstack' in a library,
> you don't _want_ it to call exit(). You need to change the 'obstack' module -
> locally, via a local override - so that it can not call exit any more.

You don't need to go that far.
obstack already provides a way.  See below.

> Paul Eggert and I wanted to do this long ago, but didn't find a _general_
> solution that would serve GPLed and LGPLed projects equally and yet be simple.
>
> Changing the licenses of 'exit' and 'exitfail' to LGPL would be the wrong
> approach, because then people would ask for all gnulib to become LGPL,
> piece by piece: first 'exit', then 'xmalloc', etc. etc.
>
>> Bruno, your 'exit' module looks strange: it doesn't do anything except
>> depending on stdlib.  It used to provide exit.h, but no longer does so.
>> Can't we simply remove the 'exit' module and suggest users to use the
>> stdlib module directly instead?
>
> We could in theory, but a few modules (copy-file, exitfail, pipe, xsetenv 
> etc.)
> depend on it. I find it quite clear to say: "if you need the exit() function,
> take the 'exit' module". Clearer than to say: "... take the 'stdlib' module".

Technically, we can remove obstack's dependency on exit and exitfail
altogether.  Until recently, I didn't think that was sensible, but with
a recent change to coreutils' src/remove.c, I discovered that there is
a way to use an obstack without resorting to library-unfriendly exit
calls.  Sure, you've always been able to define obstack_chunk_alloc and
obstack_chunk_free, but that interface merely displaced the problem.

Bottom line, for a truly obstack-dependent and library-clean solution,
you'd use obstack_specify_allocation_with_arg in place of obstack_init,
providing a longjump target and an allocator function that longjumps to
that target upon failure.  See these for diffs:

this one defines rm_malloc, which belongs in...
  http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=24412edeaf5

this *preceding* change to use obstack_specify_allocation_with_arg:
  http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=a5111af33ea




reply via email to

[Prev in Thread] Current Thread [Next in Thread]