On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote: >> On Mon, 20 Dec 2010, Alan Cox wrote: >> >> >> My point which people keep missing is that graphics stacks are a >> >> single entity, that span kernel and userspace, one cannot exist >> >> without the other, and there are interfaces that join them. >> > >> > As a copyright holder on the kernel I'll also remind the people concerned >> > that the definition of a derivative work is a legal not a technical one >> > and if the kernel and user space cannot be used except together and one >> > half depends on GPL elements I hope your lawyers have reviewed it >> > carefully. I have never given anyone permission to link my GPL kernel >> > contributions with anything but GPL code, modular or otherwise, except >> > according to the derivative work rules laid down by the GPL (and indeed >> > by the boundaries placed on copyright law). >> >> but it can be circumvented by writing GPL driver which will act as 'glue >> logic' inbetween userspace driver and which will work in kernel space? >> >> technically then driver would be GPL, except it's closed parts which will >> be ran in userspace... or can you forbid usage of certain closed userspace >> components with kernel? > > Anyone can try shipping this and risk a lawsuit, and all copyright holders > of the kernel can try suing people that distribute such code. Most sensible > people stay out of both the shipping questionable code and the suing part, > but apparently the entire mobile phone industry is already doing both, so > we can just wait and see if anyone has deep enough pockets to bring this > up in court first ;-). Nobody will because it is unenforcable. The GPLv2 is written such that the "if you're interfacing the kernel or compiler you don't need to opensource that bit with your app" clause can actually be manipulated to basically disavow closed source code from having to be published as open source if it interfaces with the standard operating system components. It is meant to protect software developers from having to bundle a gigabyte of kernel and compiler code with their 100 line app that uses an ioctl, but legally it works against the GPL in this way. It is what means AMD, nVidia, Intel (hi Alan), and others can produce binary code and binary executables that run on opensource kernels (wireless regulatory daemon in the early days) basically with impunity. You may think it's a horrible idea, and from a technical perspective it is, but from a legal perspective.. it's not a problem. > The only thing that is currently being enforced is that no interfaces enter > the mainline kernel that rely on closed source user space. Once something > is merged in mainline, you are generally free to write code under any > license you want against that interface. Yes, this is basically it: the problem here is that Alan is stipulating that as a copyright holder in the kernel he has a big problem with merging the code, but in fact as the merge proposal only includes GPL code, nobody has a leg to stand on except on moral grounds, and policy grounds. There is no legal issue here. It is not going into mainline, fair enough. What I am curious about is why did Linaro push it to dri-devel in the first place? I think the concept of taking a driver from a BSP and then just FLINGING it at mainline is not responsible in the first place. Isn't it enough to go into the Linaro tree, discretely and quietly? Then we can have a discussion about what to do about it within Linaro. Frankly, this discussion (besides the sidetrack to the non-existant legal issues) did pop up a major problem in the possibility of unifying the IPU, dual GPU and other graphics subsystem frameworks on the i.MX processor line, and potentially others too (TI's LCDC and PVR graphics) in that DRM/DRI security policy will forbid them (in the form of David Arlie complaining) from sharing the same memory area, MMUs on or off. This actually means all 2D, 2D acceleration, 3D acceleration and DMA between the units requires bounce buffers and some overly complicated memory copying between memory areas for them to interoperate. I think TI hit this problem trying to get a texture from the DSP to the GPU to render it to a texture and came up with an awful (closed source :) method of ioctls and so on to achieve it. I had an idea to solve it using DRM and GEM but it's been shot down in concept now... what's the point? It'll never get into mainline. -- Matt Sealey <matt@xxxxxxxxxxxxxx> Product Development Analyst, Genesi USA, Inc. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
