Freescale Linux BSP review

[Matt Sealey]

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 at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.



On Tue, Dec 21, 2010 at 7:32 PM, Dave Airlie <airlied at gmail.com> wrote:
> On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey <matt at genesi-usa.com> wrote:
>> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann <arnd at 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.
>