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. > 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. >> 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? Compiling pulse with --disable-samplerate avoids this ambiguity and ensures that programs which use libpulse are more clearly LGPL. This is the solution we are using at the moment. > I would not be in favor of removing an _optional_ dependency > alltogether just because enabling it is not desired by some subset of > users. Me either. > Enabling of an optional depency if all the requirements are met is > quite standard practice. Sure, but it is also standard practice to not enable an optional dependency by default if there are reasons why using it may not be desired. Reasons can include because the optional dependency is experimental, it affects licensing, etc. > 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. Brian
