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. Christian. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
