siretart at ubuntu.com
Fri Nov 13 08:24:16 GMT 2009
Maia Kozheva <sikon at ubuntu.com> writes:
> On 09.11.2009 16:05, Reinhard Tartler wrote:
>> Either that, or have them removed from the ubuntu archive because of
>> license violation. Or get them ported to libavformat.
> Removal is a bit harsh. Let's look at the rdepends:
> The first five will pose no problems. kid3 and faac can be built without
> libmp4v2 support (in fact, for kid3, this is our only divergence from
filed as bug #481789
> exfalso (part of quodlibet) doesn't use libmp4v2 directly, and it is
> only in Suggests. It uses the python-mutagen library, which implements
> MP4 support entirely in Python and doesn't depend on libmp4v2. In fact,
> I have no idea why the suggest is even there - I'll talk to the Debian
> maintainer about this.
thanks for taking care of this.
> easytag-aac is a separate binary package, identical to easytag except
> for the packaging. It's an approach similar to gtkpod-aac, two different
> packages built with and without libmp4v2 - and I think we should
> eventually get rid of easytag-aac just as we made gtkpod-aac a
> transitional package in Karmic, by patching the source to load the
> library with dlopen/dlsym instead of linking to it.
yes, that could be an approach to adress this.
> Finally, there is gtkpod, which is patched to use the dlopen approach
> and thus not listed here.
the dlopen() approach is a trick. It moves the license violation from us
as distributors to the users doing the violation at run-time. Still not
nice, but still much better for us.
> In short, this leaves us with four applications currently using libmp4v2
> in Ubuntu: kid3, faac, gtkpod, and easytag (assuming easytag-aac will be
> merged and removed).
AFAIUI faac has its own copy of mp4v2 in common/mp4v2. Besides, faac is
affected by #374900. I believe that it is as such unredistributable and
we should probably have it removed from ubuntu, if we don't manage to
replace the problematic files.
The fact that I didn't (and nobody else) manage to contact upstream
about this isn't very helpful here.
> They can all be built without libmp4v2 (sacrificing the functionality
> for MP4 metadata), but perhaps we can instead contact upstreams and
> ask them to relicense with linking exceptions? If the licenses allow
> this, getting an exception at least for gtkpod won't be a problem,
> since that code is part mine and part by someone I can contact easily.
Yes, such a special excemption to explicitly allow linking against
libmp4v2 would indeed solve the matter.
> I think mpeg4ip has to go regardless of whether there will be
> dependencies on libmp4v2 left. If there are, we'll upload the new
> standalone version.
Reinhard Tartler, KeyID 945348A4
More information about the Ubuntu-motu