On Thu, 2006-11-16 at 11:07 +0100, Simon Josefsson wrote: > Yoann Vandoorselaere <[EMAIL PROTECTED]> writes: > > > Considering the above reaction, and unless we can find a technically > > viable way of fixing the problem, maybe removing the Gnulib --lgpl > > feature should be considered (although I really don't like that idea). > > Maybe then an LGPL version of Gnulib should be forked from the current > > LGPL module base. > > Well, I created http://josefsson.org/lessergnulib/ some time ago for > that, but I believe it is better if we don't have to fork gnulib. So > far, all the problems I've had in gnulib have eventually been resolved > (e.g., getline, thread safety) , and I hope this will be the case now > too. > > It would be nice to have something automated to test this kind of > regressions. I'm working on an autobuilder, and it could check lgpl > vs gpl too. That would detect these issues faster, and help us > resolve it immediately. All assuming that this is something everyone > believe is a good idea, of course.
The code to implement license verification has been checked into GnuLib: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/7833/focus=7839 http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/7833/focus=7839 To test a single module: $ ./gnulib-tool --dir test --create-testdir <name of the module> To test all the module: $ ./gnulib-tool --dir test --create-testdir You'll now get a warning for each invalid LGPL -> GPL module dependencies. -- Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.com
