[Mesa-dev] GPL'd vl_mpeg12_bitstream.c
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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
2011/8/12 Christian König : > 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
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
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
Hey, On 08/12/2011 07:42 PM, Christian König wrote: > 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. > gstreamer might have a LGPL version, but if we use LGPL, we probably want to move that code to vdpau/g3dvl instead of it being linked in with everything.. ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
2011/8/12 Christian König : > 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
Why not ask the original author to relicense? 2011/8/12 Marek Olšák > 2011/8/12 Christian König : > > 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GPL'd vl_mpeg12_bitstream.c
- Original Message - > 2011/8/12 Christian König : > > 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
