[Mesa-dev] GPL'd vl_mpeg12_bitstream.c

[Younes Manton]

2011/8/12 Christian König <deathsimple at vodafone.de>:
> Am Donnerstag, den 11.08.2011, 12:04 -0400 schrieb Younes Manton:
>> It's been brought to my attention that the source this is based on is
>> GPL'd, which means it needs to go before 7.12 is released since it's
>> incompatible with Mesa's MIT license.
>
> That is actually not so problematic as it sounds in the first place,
> since parts of Mesa is already licensed under the LGPL, but it starts to
> be a problem when somebody tries to link a for example BSD licensed
> binary with the resulting VDPAU implementation (since it is the only
> implementation wich is using this code at the moment).
>
> I googled a bit before including this code and came around with the
> following mail conversation
> (http://www.mail-archive.com/license-discuss@opensource.org/msg01164.html):
>
>> > > > - The Free Software Foundation skirted the issue with its repackaging of the
>> > > > X rendering capability into libxmi.  They licensed the new library under
>> > > > GPL, but the original source files borrowed from X remain under MIT terms
>> > > > (even though those files have most likely been modified to embed them in a
>> > > > GPL library).
>> > >
>> > > It's the modification that's the key.  The FSF own the modifications, and
>> > > the copyright on those is GPL.  MIT own the pre-modified code.  To the
>> > > extent that the latter can be separated from the former, it can be
>> > > distributed under MIT terms.  To the extent that they're inseparable, both
>> > > licenses must be satisfied - possible, since they aren't contradictory.
>> >
>> > The FSF did that?  So that means that you can mix GPL code
>> > with other code and distribute both under the their respective
>> > licences?  What effect does this have on that GPL distribution
>> > clause?
>>
>> Exactly.  But the effect is that you must satisfy *both* licenses. Now the
>> MIT license makes no real restrictions on other works its combined into,
>> but the GPL does.  The problem comes when the GPL demands that you give
>> certain permissions (the permission to modify and distribute sources) on
>> any derived work, and this may conflict with one of the other licenses
>> applicable on a work - but doesn't in the MIT case.
>>
>> In particular, the GPL says that you must make available the source of the
>> whole work.  Now this is an additional restriction on top the the MIT one,
>> but it's not in conflict with the MIT one - it doesn't ask you to do
>> anything you aren't allowed to do.
>
> I already considered a configure option which makes this code to be not
> included, but in the long term it just should go away.
>
> Christian.

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.

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.