----- Original Message ----- > 2011/8/12 Christian König <deathsim...@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.
I'd prefer to keep Mesa core MIT/BSD licensed. Business models of several past/current/future companies sponsoring Mesa development have/do/may depend on that. _Optional_ LGPL dependencies, although preferably to avoid, are not too worrysome. Vanilla (i.e, without exceptions) GPL licensed code is a no-no, as Mesa drivers will potentially be dynamically loaded by closed source applications, being very murky whether that forms a derived work or not [1]. IMO, it would be necessary an exception that waives the requirement of applications merely using the OpenGL/VDPAU/etc APIs from being open sourced, similar to GNU Classpath GPL exception. But this is merely hypothetically speaking -- as keeping Mesa MIT/BSD is by far the ideal. Therefore, concerning vl_mpeg12_bitstream.c, it sounds the best would be to ask original authors to re-license, and rewrite if denied. Jose [1] It's so murky that even Linus thought it was a good idea to clarify that user space programs do not form derived works from linux kernel in http://www.kernel.org/pub/linux/kernel/COPYING ... _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
