[Mesa-dev] GPL'd vl_mpeg12_bitstream.c

[Maarten Lankhorst]

Hey,

On 08/12/2011 07:42 PM, Christian König wrote:
> Am Freitag, den 12.08.2011, 10:49 -0400 schrieb Younes Manton:
>> Sorry, by incompatible I didn't mean that you couldn't use them
>> together, but that one is more restrictive than the other. Like the
>> discussion you quoted states, if you combine MIT and GPL you have to
>> satisfy both of them, which means you have to satisfy the GPL. I
>> personally don't care that much, but unfortunately with the way
>> gallium is built it affects more than just VDPAU.
>>
>> Every driver in lib/gallium includes that code, including swrast_dri
>> (softpipe), r600_dri, etc, and libGL loads those drivers. If you build
>> with the swrast config instead of DRI I believe galllium libGL
>> statically links with softpipe, so basically my understanding is that
>> anyone linking with gallium libGL (both swrast and DRI configs) has to
>> satisfy the GPL now.
> A crap, your right. I've forgotten that GPL has even a problem when code
> is just linked in, compared to being used.
>
>> Maybe someone else who is more familiar with these sorts of things can
>> comment and confirm that this is accurate and whether or not it's a
>> problem.
> I already asked around in my AMD team, and the general answer was: Oh
> fuck I've no idea, please don't give me a headache. I could asked around
> a bit more, but I don't think we get a definitive answer before xmas.
>
> As a short term solution we could compile that code conditionally, and
> only enable it when the VDPAU state tracker is enabled. But as the long
> term solution the code just needs a rewrite, beside having a license
> problem, it is just not very optimal. The original code is something
> like a decade old, and is using a whole bunch of quirks which are not
> useful by today’s standards (not including the sign in mv tables for
> example). ffmpegs/libavs implementation for example is something like
> halve the size and even faster, but uses more memory for table lookups.
> But that code is also dual licensed under the GPL/LGPL.
>
> Using LGPL code instead could also be a solution, because very important
> parts of Mesa (the GLSL parser for example) is already licensed under
> that, but I'm also not an expert with that also.
>
gstreamer might have a LGPL version, but if we use LGPL, we probably want to move that code to vdpau/g3dvl instead of it being linked in with everything..

~Maarten