Freescale Linux BSP review

[Matt Sealey]

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.

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