Bug#658084: libav-extra: Really necessary?

[Fabian Greffrath]

Am 31.01.2012 17:55, schrieb Reinhard Tartler:
> On Tue, Jan 31, 2012 at 5:44 PM, Jonas Smedegaard<dr at jones.dk>  wrote:
>> Problem is that other packages can carefully ensure not violating
>> licensing when linking against libav, and libav-extra then "distorts"
>> that by causing Debian as a whole to not ensure against same violation.

Yes, that's it. Thanks for finding clear words, Jonas. ;)

>> How about having libav-extra package conflict with other packages known
>> to not be compatible with the tighter licensing?
>
> That would be an option. Another option would be to have those
> packages declare a conflicts on libav-extra.
>
> nit: wouldn't the "breaks" relationship be more appropriate here?

Yes, sure. No need to deconfigure offending packages, it should be 
enough to make sure they are not installed at the same time.

> I don't think we should overdo the "license-policy" game. If we become
> aware of a license clash, we can add a conflict, as Jonas suggest.

This leads us to the next question (the one I meant with "analysis"): 
Do we already *know* of license clashes of specific software with a 
GPL-v3 licensed libav? Or is the whole introduction of libav-extra 
done for precaution?

How is this handled in the gstreamer packages? I see that 
gst-plugins-ugly0.10 is linked against the apache-2.0 licensed 
libopencore-amrwb0 and is still distributed under the terms of the 
LGPL-2.0+.

> Legally, I don't think there is much difference here. However, there
> is a practical difference for Debian as distribution: we do not
> violate the packages if users install a combination of packages that
> result to a license clash. Yes, we can add conflicts, and probably
> have to if we become aware of it, but we cannot be held responsible
> for funky stuff that random users do on their (own) systems.

Reminds me of the libcurl situation. We have both libcurl (linked 
against openssl) and libcurl-gnutls packages in Debian. The latter is 
for packages with licenses incompatible to openssl's one. However, 
nothing prevents you from installing the openssl-linked libcurl 
package on your system if you wish so.

What parts of libav are actually affected by the two additional 
codecs? I guess it's only libavcodec (and maybe libavformat). If it 
really boils down to rebuild only one library with aditional 
confflags, I begin to like Andres' idea more and integrate libav-extra 
into the libav package.

  - Fabian