Re: c-ctype, inttostr, intprops module license
On Wed, 2006-11-15 at 21:33 +0100, Jim Meyering wrote: Simon Josefsson [EMAIL PROTECTED] wrote: Yoann Vandoorselaere [EMAIL PROTECTED] writes: warning: getaddrinfo is LGPL but depend on intprops which is GPL warning: inttostr is LGPL but depend on intprops which is GPL Jim, Paul, is it possible to have intprops be under LGPL? The alternative solution I see is to revert the patch for getaddrinfo that made it use inttostr (which needs intprops), and use sprintf instead. Here's a work-around: remove the inclusion of intprops.h and add a simpler, slightly pessimistic definition instead: #define INT_BUFLEN_BOUND(t) ((sizeof (t) * CHAR_BIT) * 146 / 485 + 1 + 1) If that's the way we're going to fix LGPL modules dependencies to GPL modules, I'd like to ask if you volunteer to fix the others 37 invalid dependencies. ;-) Seriously, don't you think that tackling the problem this way will result in code duplication, dependencies nightmare, more bugs, and a harder to maintain project? As an example of such a failure, the fts-lgpl module has 18 dependencies to GPL modules... The GPL fts modules has 23 dependencies to other GPL modules. In the end the fts-lgpl is a failure and bring more complexity to the code. From an LGPL library maintainer point of view, this is also kind of frustrating: I'm not sure if it also happened to Simon with Gnutls, but I can remember many time where I updated GnuLib only to find out that some existing LGPL modules were now in broken state due to newly added GPL dependencies. You're then left with the choice of reverting to an older (and hence more buggy) version of GnuLib, stop using the broken module and develop your own instead, or raising the issue on the Gnulib mailing list in the hope that the problem would be fixed quickly. 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. -- Yoann Vandoorselaere | Responsable RD / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.com
Re: c-ctype, inttostr, intprops module license
Jim Meyering [EMAIL PROTECTED] writes: Simon Josefsson [EMAIL PROTECTED] wrote: Yoann Vandoorselaere [EMAIL PROTECTED] writes: warning: getaddrinfo is LGPL but depend on intprops which is GPL warning: inttostr is LGPL but depend on intprops which is GPL Jim, Paul, is it possible to have intprops be under LGPL? The alternative solution I see is to revert the patch for getaddrinfo that made it use inttostr (which needs intprops), and use sprintf instead. Here's a work-around: remove the inclusion of intprops.h and add a simpler, slightly pessimistic definition instead: #define INT_BUFLEN_BOUND(t) ((sizeof (t) * CHAR_BIT) * 146 / 485 + 1 + 1) So instead of if (snprintf (service, servicelen, %d, ntohs (((const struct sockaddr_in *) sa)-sin_port)) + 1 servicelen) return EAI_OVERFLOW; we'd have #define INT_BUFLEN_BOUND(t) ((sizeof (t) * CHAR_BIT) * 146 / 485 + 1 + 1) ... unsigned short int port = ntohs (((const struct sockaddr_in *) sa)-sin_port); char buf[INT_BUFSIZE_BOUND (port)]; char const *s = uinttostr (port, buf); if (strlen (s) + 1 servicelen) return EAI_OVERFLOW; memcpy (service, s, strlen (s) + 1); right? That still uses uinttostr which is from the inttostr module which depends on and uses the intprops module, so it would still need GPL'd code in a possibly LGPL'd project. I'm starting to feel that we should revert to the old code in getaddrinfo. It was shorter and more readable, hence more maintainable. snprintf() is C99 and POSIX, and there is a working replacement for it in gnulib, under the LGPL. /Simon
Re: c-ctype, inttostr, intprops module license
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. /Simon
Re: c-ctype, inttostr, intprops module license
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 RD / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.com
Re: c-ctype, inttostr, intprops module license
Paul Eggert wrote: I should have also said: I changed it to LGPL. Thanks. The remaining warnings from gnulib-tool --create-testdir are: module argp depends on a module with an incompatible license: dirname module argp depends on a module with an incompatible license: exit module argp depends on a module with an incompatible license: exitfail module argp depends on a module with an incompatible license: inline module argp depends on a module with an incompatible license: xalloc module argp depends on a module with an incompatible license: xalloc-die module argp depends on a module with an incompatible license: xstrndup module canon-host depends on a module with an incompatible license: intprops module euidaccess depends on a module with an incompatible license: exit module euidaccess depends on a module with an incompatible license: exitfail module euidaccess depends on a module with an incompatible license: group-member module euidaccess depends on a module with an incompatible license: inline module euidaccess depends on a module with an incompatible license: xalloc module euidaccess depends on a module with an incompatible license: xalloc-die module fts-lgpl depends on a module with an incompatible license: chdir-long module fts-lgpl depends on a module with an incompatible license: chown module fts-lgpl depends on a module with an incompatible license: d-ino module fts-lgpl depends on a module with an incompatible license: dirname module fts-lgpl depends on a module with an incompatible license: exit module fts-lgpl depends on a module with an incompatible license: exitfail module fts-lgpl depends on a module with an incompatible license: fcntl-safer module fts-lgpl depends on a module with an incompatible license: getcwd module fts-lgpl depends on a module with an incompatible license: inline module fts-lgpl depends on a module with an incompatible license: intprops module fts-lgpl depends on a module with an incompatible license: lchown module fts-lgpl depends on a module with an incompatible license: openat module fts-lgpl depends on a module with an incompatible license: save-cwd module fts-lgpl depends on a module with an incompatible license: unistd-safer module fts-lgpl depends on a module with an incompatible license: xalloc module fts-lgpl depends on a module with an incompatible license: xalloc-die module fts-lgpl depends on a module with an incompatible license: xgetcwd module fts-lgpl depends on a module with an incompatible license: xstrndup module getaddrinfo depends on a module with an incompatible license: intprops module glob depends on a module with an incompatible license: d-type module inttostr depends on a module with an incompatible license: intprops module obstack depends on a module with an incompatible license: exit module obstack depends on a module with an incompatible license: exitfail This boils down to the following issues: module argp depends on a module with an incompatible license: dirname module euidaccess depends on a group-member which depends on xalloc module fts-lgpl depends on a module with an incompatible license: openat module getaddrinfo depends on a module with an incompatible license: intprops module glob depends on a module with an incompatible license: d-type module inttostr depends on a module with an incompatible license: intprops module obstack depends on a module with an incompatible license: exitfail According to my rule of thumb if something is usable in libraries, we can put it under LGPL, if something uses exit, or xmalloc, or error, it is not usable in libraries I would propose: - argp: Either decide that argp should be GPL, or rework the 2006-01-21 patch to lib/argp-namefrob.h so that it doesn't use dirname any more, - euidaccess: change group-member.c so that it doesn't use xmalloc. If the memory allocation fails, let group_member() return -1 with errno = ENOMEM. Jim, would you accept patches to that effect? - fts-lgpl openat: no opinion. Jim, Paul? - getaddrinfo, inttostr: Paul, can you agree to put intprops under LGPL? - glob: d-type has no source code in lib/, therefore whether it has a GPL or LGPL license statement does not matter. Jim? - inline: Likewise, should be changed to LGPL. - obstack: If someone was to use/assign the obstack_exit_failure variable declared in obstack.h, he will get a link error. So I propose to move the #define obstack_exit_failure exit_failure from obstack.c to obstack.h. Then we can remove the dependency to exitfail. Paul Eggert writes: I haven't waded through that whole list, but I'm a bit antsy about wholesale conversion of gnulib to the LGPL. Noone is requesting that. Everything that calls xmalloc will stay GPL. The only changes of lib/ code to LGPL that are being requested are for group-member, intprops and possibly openat. The rest are mistakes that crept in during the last few months. Bruno
Re: c-ctype, inttostr, intprops module license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 11/16/2006 7:10 AM: According to my rule of thumb if something is usable in libraries, we can put it under LGPL, if something uses exit, or xmalloc, or error, it is not usable in libraries I would propose: - argp: Either decide that argp should be GPL, or rework the 2006-01-21 patch to lib/argp-namefrob.h so that it doesn't use dirname any more, Worse than that, it is using base_name, which was changed in July to malloc. argp needs to be changed anyways to avoid a memory leak. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXHaU84KuGfSFAYARAu/LAJ9nzpwk/gchzcNGx13xyP5DagHfSgCdHADs SciAmoSXyFuiQEEe6q6GwP4= =jcrv -END PGP SIGNATURE-
Re: c-ctype, inttostr, intprops module license
Bruno Haible [EMAIL PROTECTED] wrote: I would propose: ... - euidaccess: change group-member.c so that it doesn't use xmalloc. If the memory allocation fails, let group_member() return -1 with errno = ENOMEM. Jim, would you accept patches to that effect? Sure. - fts-lgpl openat: no opinion. Jim, Paul? Separating the LGPL and GPL'd parts of fts is no small task. I'm not even going to think about this right now. I've invested enough time in it recently, making it work correctly and efficiently. Openat emulation is similar. I think relaxing a GPL license to LGPL for any significant module should be done only if there is a very good reason. With these two modules (and all of their many dependents), I'm reluctant to switch just so that LGPL-restricted projects can use them. Perhaps the people who care about the distinction will investigate and propose a patch or two. But be warned: it might not even be feasible to complete the split cleanly. - getaddrinfo, inttostr: Paul, can you agree to put intprops under LGPL? Maybe someone will contribute a dumbed-down LGPL-able version that is good enough. - glob: d-type has no source code in lib/, therefore whether it has a GPL or LGPL license statement does not matter. Jim? Ok. I've switched it to LGPL.
