Okay I hereby refrain from legal comments. In any case, this code has passed legal at Freescale and AMD *AND* Qualcomm. It would not be GPL if it has not been vetted (and it took them a year to get to this point). -- Matt Sealey <matt@xxxxxxxxxxxxxx> Product Development Analyst, Genesi USA, Inc. On Tue, Dec 21, 2010 at 7:32 PM, Dave Airlie <airlied@xxxxxxxxx> wrote: > On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey <matt@xxxxxxxxxxxxxx> wrote: >> 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. > > You should probably refrain from stating legal opinions around here, > Alan stated there is a possible issue legally and you should talk to > lawyers. I find his reasoning to be sane but no idea if its legal. The > point you are missing (you seem to not think much before typing) is > this: > > you have two pieces of code, a userspace 3D *driver* (not > application), and a kernel driver talking to the hw, if the userspace > 3D driver cannot exist without the kernel driver, it could very well > be considered a derivative work of the kernel driver. You are not > protected by the standard Linux system call exception since it states > "normal system calls", so adding a driver to the kernel to expose a > bunch of driver specific ioctls to allow the userspace 3D work blurs > the lines sufficiently that you are into the domain of derived works > and should call your lawyers. > > >> >> 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. > > I never said the security policy would forbid anything, I said they > need to prove > that they've thought about these things and can prove they are secure, if this > requires opening the code and/or documents then that is the way it is. The > thing is if you require a userspace application with user privs to > access these devices > then you must stop the user from doing bad things, from my experience vendors > give little concern for these issues until > > a) upstream people point out the problem and refuse to merge > b) they are used as the rootkit entry point. > > Dave. > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
