On Fri, 20 Feb 2009, Bruno Haible wrote:
Reuben Thomas wrote:"Gnulib provides a module @samp{canonicalize-lgpl}"since there's a canonicalize and a canonicalize-lgpl module, shouldn't it just say "a module @samp{canonicalize}", and users can make the usual guess that there might be an LGPL version?The 'canonicalize' module is farther away from the realpath() function: Different API, and not usable in libraries due to xalloc(). I think mentioning 'canonicalize-lgpl' is therefore more adequate here.
How is the API different for canonicalize-lgpl, other than only declaring one function? It seems to use the same header file as canonicalize, which declares the GNU API canonicalize_file_name, which is documented as equivalent to realpath (foo, NULL).
The other differences are also a bit of a surprise, and to my mind are worth documenting. From reading the gnulib documentation, I generally expect, if I choose an LGPL version, simply to get the same code under a different license. Did I miss something? Or is canonicalize unusual in this respect?
In any case, it would seem worth documenting this, mainly because of the point about libraries. The obvious place would be in the canonicalize-lgpl module.
This seems a rather odd way to divide the code up, where a technical difference (xalloc) is hidden behind a license difference.
Would it make more sense to have a canonicalize module coming in two flavours, GPL and LGPL, and a GPL-only module canonicalize_mode which implements the extra APIs?
Forgive me if I've misunderstood something, but I hope it's at least obvious that there is a lack of clarity here, and I'm keen to help.
-- http://rrt.sc3d.org/ | wit, n. educated insolence (Aristotle)
