2011/10/15 Brian Cameron <brian.cameron at oracle.com>: > 2) Bug #41822 highlights that there may be licensing issues with > ? PulseAudio. ?It says anything that links against libpulsecore is > ? GPL'ed. ?Now that libpulsecommon and libpulse and the GStreamer Pulse > ? plugin now link against libpulsecore, this raises concern that any > ? program linking against PulseAudio is GPL, such as anything using > ? the GStreamer PulseAudio plugin. ?Now that the speex resampler is > ? available, maybe it is time to drop libsamplerate as a dependency? > > ? https://bugs.freedesktop.org/show_bug.cgi?id=41822 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 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. > ? At any rate, on Solaris, we are disabling building with libsamplerate > ? for this reason. ?It seems a bit ugly that libsamplerate is enabled > ? by default by the PulseAudio configure script if it is available if > ? there are these sorts of concerns. In what way does compiling pulse with --disable-samplerate no solve your licensing problems here? I would not be in favor of removing an _optional_ dependency alltogether just because enabling it is not desired by some subset of users. Enabling of an optional depency if all the requirements are met is quite standard practice. 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) Maarten
