[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Module: canonicalize-lgpl
From: |
Charles Wilson |
Subject: |
Re: Proposed Module: canonicalize-lgpl |
Date: |
Thu, 02 Nov 2006 18:44:54 -0500 |
[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
- Proposed Module: canonicalize-lgpl, Charles Wilson, 2006/11/02
- Re: Proposed Module: canonicalize-lgpl,
Charles Wilson <=
- Re: Proposed Module: canonicalize-lgpl, Paul Eggert, 2006/11/03
- Re: Proposed Module: canonicalize-lgpl, Paul Eggert, 2006/11/03
- Re: Proposed Module: canonicalize-lgpl, Charles Wilson, 2006/11/03
- Re: [bug-gnulib] Proposed Module: canonicalize-lgpl, Bruno Haible, 2006/11/06
- Re: [bug-gnulib] Proposed Module: canonicalize-lgpl, Paul Eggert, 2006/11/06
- Re: Proposed Module: canonicalize-lgpl, Jim Meyering, 2006/11/07
- Re: Proposed Module: canonicalize-lgpl, Simon Josefsson, 2006/11/07
- Re: Proposed Module: canonicalize-lgpl, Ralf Wildenhues, 2006/11/07