On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey matt@genesi-usa.com wrote:
On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann arnd@arndb.de 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.