Re: Proposed Module: canonicalize-lgpl

[Charles Wilson]

[Sorry for the previous mail; I accidentally sent a reply before I was
finished writing it]

On Thu, 02 Nov 2006 09:11:46 -0800, "Paul Eggert" <address@hidden>
said:
> Charles Wilson <address@hidden> writes:
> 
> > Precedent: the fts and fts-lgpl modules each provide functionality
> > similar to the other, under different licenses -- where the module
> > under the lesser license provides lesser, but still useful,
> > functionality. That is the case here, as well: the canonicalize module
> > protects against cycles, and uses the x* memory functions; the
 > > canonicalize-lgpl module does not have this protection.
> 
> It's a reasonable idea, but I'd prefer something more like fts, where
> the code itself is the same in both modules; all that differs is that
> the GPL'ed version uses some other modules that are GPL'ed, wheras the
> LGPL'ed version does not.  With the proposed patch for canonicalize-lgpl,
> there are two copies of the source code, even though the idea is
> essentially
> the same.  Can't we slim it down to one copy?

I don't think so.  From what I can tell, the version in gnulib has
deviated in significant ways from its GNU C lib origins [[[ SCRATCH
THAT.  gnulib's canonicalize didn't come from GNU C lib ]]], and uses
GPL'ed modules all over the place:
   cycle-check:    GPL
   filenamecat:    GPL
   xalloc:         GPL
   xgetcwd:        GPL
   xreadlink:      GPL

But further, the two versions do not have the same heritage -- gnulib's
canonicalize did not derive from GNU C lib.  Rather, it seems to derive
from coreutils, not GNU C lib (gnulib's canonicalize.c revision 1 has
this checkin comment: "New module, from coreutils.")

And digging in coreutils' cvs [attic, since coreutils now re-imports
*gnulib's* canonicalize.  Nice, huh?]

http://cvs.savannah.gnu.org/viewcvs/coreutils/lib/Attic/canonicalize.c?root=coreutils&rev=1.25&hideattic=0&view=log

it seems that their version was originally contributed by "Dmitry
Levin." under an explicit GPL license. Further, that coreutils code
(revision 1 from Jan 11 2003) looks *nothing* like the canonicalize.c in
glibc's cvs from the same time period -- but still looks quite similar
to today's gnulib canonicalize.c.  So Dmitry didn't adapt his coreutils
contribution from GNU C lib; it looks to me like he wrote it from
scratch under GPL, deliberately using GPL x* memory functions and all.

I don't think it's kosher scrub references to xreadlink xmalloc etc.
from gnulib's canonicalize, and then relicense the remaining code. If
gnulib is to have an LGPL canoncicalize, it will necessarily be
*different* code.

The alternative is to use the code in this proposed module as the basis
for both canonicalize-lgpl and a new GPL canonicalize, grafting in the
spiffy features from the current canonicalize with a macro to turn 'em
off if LGPL.  But that's FAR beyond what I was proposing -- and I'd bet
the current maintainer, and users, of the existing canonicalize module
would be suspicious of such a massive change in a perfectly good module,
to accomodate LGPL users.

--
Chuck
--
  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm