Am 31.01.2012 17:55, schrieb Reinhard Tartler:
On Tue, Jan 31, 2012 at 5:44 PM, Jonas Smedegaard<d...@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
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
