-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Wise wrote: > [CCing you since I presume you aren't subscribed, apologies if you are] No I'm not. Thanks for paying attention.
> On Fri, May 21, 2010 at 1:17 AM, Robin Gareus <ro...@gareus.org> wrote: > >>> xmalloc is GPL not LGPL so I'm wondering why upstream and >>> debian/copyright refer to the LGPL. >> xmalloc is 'generated' by autotools (autotools replaces the project-name in >> there) and /usr/share/doc/autoproject/README reads: >> >> "autoproject itself is distributed under the GNU General Public License. >> As a special exception to the GNU General Public License, you may >> use the files generated by autoproject without any restriction." > > Hmm. I'd say that exception is so vague as to be useless. A permissive > license would be much better. I've contacted the autotools author and suggested to change that sentence in the README to: "..without any restriction unless the generated-file states otherwise." Getting the FSF to change the license of xmalloc.c to something more permissive would be great; but I'm not prepared to fight that uphill battle any longer :) I usually like the GPL and it's easy enough to re-invent xmalloc, anyway. >>> xmalloc reduces the amount of software that can link with liboauth >>> (due to GPL licensing incompatibilities), it would be nice if upstream >>> could use plain malloc. You may want to send upstream a patch. >> no need to send a patch: >> xmalloc is only used IFF liboauth is configured with --enable-gpl. > > Ah. The README says that --disable-gpl may cause segfaults, that > doesn't sound good. Well, in practice it does not make much of a difference if the program exit(1) or segfaults if it encounters an out-of-memory error, does it :) Anyway I figured it's easier to just replace GPL-xmalloc with some equivalent.. done in >= liboauth 0.8.0. > Also, by using OpenSSL, you are preventing GPLed apps from using > liboauth due to license incompatibility between the apps and OpenSSL, > yay transitive license violations :D > > http://lists.debian.org/debian-legal/2007/11/msg00061.html > > Providing GnuTLS and or NSS backends might be one option to fix this. > Another might be to delegate SSL stuff to the app using liboauth. Since liboauth-0.7.2 '--enable-nss' is available which makes liboauth use NSS instead of OpenSSL. > Also, in 0.7.1, xmalloc is still linked into the library, you need to > do some ifdefs in src/Makefile.am. Thanks for the hint; so far I was under the impression that simply not using the code (#ifdefs in xmalloc.h/xmalloc.c) would do the trick. > libtool: link: x86_64-linux-gnu-gcc -shared .libs/liboauth_la-oauth.o > .libs/liboauth_la-hash.o .libs/liboauth_la-xmalloc.o > .libs/liboauth_la-oauth_http.o -lm -lcrypto /usr/lib/libcurl.so > -Wl,-z -Wl,defs -Wl,-soname -Wl,liboauth.so.0 -o > .libs/liboauth.so.0.5.2 water under the bridge now. >>> Uhh, actually since you are linking xmalloc and OpenSSL (GPL & OpenSSL >>> licenses are not compatible), the liboath0 binary package is not >>> distributable! >> Thanks for bringing this to my attention, I've added an exemption as >> suggested >> by http://lists.debian.org/debian-legal/2004/05/msg00595.htm > > Uh, you are not the copyright holder of the xmalloc code, so you cannot do > this. > > As said above, --disable-gpl and dropping OpenSSL is the solution here. since 0.8.0 there's no GPLed code in liboauth anymore. The packaging (debian/ folder in the source-repo) is still GPL; but that's mostly for my own convenience and once you're done I'm happy to remove it from the source (unless you suggest otherwise). >>> libtoolize: rerunning libtoolize, to keep the correct libtool macros >>> in-tree. >>> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. >> ?? I don't use ACLOCAL_AMFLAGS in Makefile.am. > > Probably it is prompting you to add it. No, but I've added it anyway (liboauth-0.8.3). >>> lintian complaints (send most upstream): > >>> X: liboauth0: shlib-calls-exit usr/lib/liboauth.so.0.5.2 > > Looks like that was caused by using xmalloc. > >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:374 >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:376 >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:403 >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:405 >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:863 >> Well, these are tricky! Said man-page is generated by Doxygen. Any ideas how >> to >> tell doxygen to properly escape those hyphens? >> >> I've found >> http://www.mail-archive.com/debian-mentors@lists.debian.org/msg39606.html >> but replacing them is not really an option since doxygen is also generating >> html >> from the same sources. > > How are you building the manual page? Your Makefile.am doesn't list > any commands for doing so. The top-level Makefile.am contains: stamp-doxygen: src/oauth.h doc/mainpage.dox $(DOXYGEN) Doxyfile && touch stamp-doxygen cp doc/man/man3/oauth.h.3 doc/oauth.3 Cheers! robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkv3+rQACgkQeVUk8U+VK0KiHgCgjY3+FrIeAL+StlLLE4l1OwX+ 2vEAn1Yafo7He8Awk7J2YOR09ShjmCoz =3l+x -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf7fab4.7070...@gareus.org
