Re: lgpl compatible files archive?

[Simon Josefsson]

Patrice Dumas <address@hidden> writes:

>> projects.  I still think either a Lesser GNULib project is needed, or
>> that gnulib modules could become parametrized, or that gnulib could
>> contain multiple implementations of the same interface (with different
>> characteristics, license-wise, thread-safety, malloc use, etc...).
>
> It seems to me that it is allready possible. If a module has another name 
> it could have different characteristics. If I'm not wrong the alloca and 
> alloca-opt have allready that kind of relationship, and also xalloc and
> xalloc-die for example. Maybe you want the similar things but within just one
> module with conditionnals?

I guess separating two implementations of the same interface by having
two different modules would be fine.  However, I don't think neither
alloca{,-opt} nor xalloc{,-die} are good examples, they don't
implement the same interfaces.

There is a potential problem with this approach though.  Consider if
the module is large, e.g. argp.  It would be good to have a version of
the argp module without the unlocked-io dependency (I know that
specific problem is discussed in other threads, but let's use this as
an example).

First, there is the file name collision of files.  Some files may be
shared between the modules, but some will differ.

Secondly, if the code is separated into different files, they would
likely have to be kept in sync.  The bigger the differences, the
harder it is to keep both versions working properly.  Consider a
thread-safe getline implementation, the one in gnulib differ
substantially from the glibc one, and when I needed a LGPL getline, I
wrote a gnulib module for it based on the glibc code.  Adding that
module to gnulib would mean two getline code bases to maintain.

So I think it would be better to parametrize one single implementation
to avoid those problems.  Perhaps it can be decided on a case-by-case
basis which approach is better, though.

>> I found it helped to attack the problem one module at a time,
>> carefully considering the details.  Exactly which modules do you need
>> which are under the GPL in gnulib today?
>
> alloca malloc realloc strtod atexit dup2 getcwd getpagesize memmove memset 
> strerror regex

Of those, only getcwd is GPL; the others are LGPL or public domain.
There is a LGPL getcwd in GLIBC, perhaps you can use it instead.

Regards,
Simon