[Mesa-dev] GPL'd vl_mpeg12_bitstream.c

[Patrick Baggett]

Why not ask the original author to relicense?

2011/8/12 Marek Olšák <maraeo at gmail.com>

> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110812/76ea0b8b/attachment.html>