[Mesa-dev] GPL'd vl_mpeg12_bitstream.c

[Marek Olšák]

2011/8/12 Christian König <deathsimple at vodafone.de>:
> 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.

Even though the GLSL parser is licensed under LGPL (because Bison is),
there is a special exception that we may license it under whatever
licence we want if we don't make software that does exactly what Bison
does. So the whole GLSL compiler is actually licensed under the MIT
license. There was one LGPL dependency (talloc), but Intel has paid
special attention to get rid of that. My recollection is nobody wanted
LGPL or GPL code in Mesa.

Marek