Re: RFS: liboauth (Updated package)
-----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 <robin@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-----
Reply to: