2011/10/17 Arun Raghavan <arun.raghavan at collabora.co.uk>: > On Sun, 2011-10-16 at 15:07 -0500, Brian Cameron wrote: >> Maarten: >> >> > Do I conclude correctly from the bug that in pulse 1.0 it isn't true >> > anymore that the library dependencies are: >> > libpulse -> ?libpulsecommon >> > libpulsecore -> ?libpulsecommon >> >> I am not familiar enough with PulseAudio to be able to describe the >> library dependencies. ?I just know that programs which use libpulse >> fail to compile unless you link in libpulsecore. ?It seems that >> libpulse or libpulsecommon uses symbols in libpulsecore. > > At least on my system, this is not the case: > > $ readelf -d /usr/lib/libpulse.so | grep pulse > ?0x0000000000000001 (NEEDED) ? ? ? ? ? ? Shared library: [libpulsecommon-1.98.so] > ?0x000000000000000e (SONAME) ? ? ? ? ? ? Library soname: [libpulse.so.0] > > readelf -d /usr/lib/libpulsecommon-1.98.so | grep pulse > ?0x000000000000000e (SONAME) ? ? ? ? ? ? Library soname: [libpulsecommon-1.98.so] Right, good to know that the library setup is still sane. > Are you sure this isn't some Solaris linker weirdness? > >> > I do remember some stuff about circular dependencies. But as only >> > libpulsecore links to libsamplerate, the above dependency chain would >> > be the best to have, because libpulse is always LGPL, regardless of >> > pulse is build with libsamplerate support. >> >> I think it may be ambiguous if libpulse is LGPL if it links in >> libpulsecore built with GPL libsamplerate. > > It does not, *but*, I see one bug that I've fixed now [1] -- during a > Makefile.am cleanup, a bunch of extra dependencies got added to > libpulsecommon, including libsamplerate. This will get fixed in the next > release which shouldn't be too far away. > > [1]: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=bb4b8f896e63559df2b53617ff205d8a4024178c Erm, yes, sorry about that mistake. Thanks for spotting that, Arun! And of course, during the time we had this bug unfixed, the LICENSING file really was wrong about libpulse not linking against libsamplerate. > [...] >> > And I'm a bit confused about why you would >> > have a GPL library installed, but don't want pulse to use it in order >> > to keep it LGPL. (and of course for these kind of use cases you can >> > easily override the autodetection) >> >> To me, it seems more "safe" to avoid linking a GPL library into a >> LGPL program by default. ?This is the sort of licensing concern that >> would be better for people to make a conscious decision about rather >> than having a configure script make a decision for you. ?Personally I >> think this is especially a concern if the LICENSING file is not >> well maintained, or contains incorrect or misleading information. > > It is well-maintained, insofar that when things with different licenses > are pulled in, the file is updated. I'm assuming that people who care > keen about the GPL/LGPL division would also be careful about how the PA > server is compiled. I'm not completely against making libsamplerate an > off-by-default choice if others feel this is more prudent, though. With your Makefile.am fix there shouldn't be a problem with using libsamplerate automatically if it is available, because the GPLness is contained at the daemon and not leaked anymore to the client library. Maarten
