Ubuntu 14.04 Codename Revealed, Mir Haters Attacked

[chrisb]

Android drivers generally have open source kernel components even if the user-space bits are proprietary and binary-only.

Torvalds has actually clarified that he believes closed kernel modules which were developed independently of Linux don't violate the GPL even though they run in kernel space, so if the drivers were truly not derivative works then the OEMs wouldn't care.whether they ran in kernel space or not. Besides that, I wonder what percentage of devices have completely open kernel drivers? As far as I understand, a large number have closed source kernel modules for GPU, wifi etc.

I am also not convinced that providing an open source shim around kernel functions provides the necessary degree of separation so that the driver is not a derivative work, even though it runs in user space. It might well if the kernel level functionality were something generic, like FUSE, but when the shim is specific to one driver, from one company, and major functionality is lost when that driver disappears, it would be hard to argue that the driver, written purely for the Linux kernel, isn't a derivative work just because it runs in user space. This isn't a new argument, see LWN in 2010:

The COPYING file shipped with the kernel begins with this text:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
Normally, kernel developers see user space as a different world with its own rules; it is not at all common for kernel maintainers to insist on free licensing for user-space components. Dave's raising of licensing issues might also seem, on its face, to run counter to the above text: he is saying explicitly that closed user-space graphics drivers might be a work derived from the kernel and, thus, a violation of the GPL. These claims merit some attention.

The key text above is "normal system calls." A user-space graphics driver does not communicate with its kernel counterpart with normal system calls; it will use, instead, a set of complex operations which exist only to support that particular chipset. The kernel ABI for graphics drivers is not a narrow or general-purpose interface. The two sides are tightly coupled, a fact which has made the definition of the interface between them into a difficult task - and the maintenance of it almost as hard. While a program using POSIX system calls is clearly not derived from the kernel, the situation with a user-space graphics driver is not nearly so clear.

[chrisb]

Oh, I see your confusion. You don't understand the ARM architecture and how the drivers there are different from what you know about in desktop systems. Learn about it and you will know why the analysis makes sense.

Are you suggesting that your legal arguments are only correct in the context of ARM architecture, and are incorrect on others? Please clarify:

Do you believe an OEM using the Nvidia or AMD closed source drivers (which both have closed source kernel modules) on a desktop is a violation of the GPL license of the Linux kernel? If not, then why would introducing a GPL display server suddenly create a GPL violation?

Do you believe an OEM using the Nvidia or AMD closed source drivers on an embedded system like the Steam Box is a violation of the GPL license of the Linux kernel? If not, then why would introducing a GPL display server suddenly create a GPL violation?

Do you believe an OEM using open source kernel drivers and closed source user space drivers on an ARM tablet is a violation of the GPL license of the Linux kernel? If not, do you believe that a simple kernel shim is enough to protect a driver from being a derivative work, even though that shim exposes complex kernel functionality? Do you believe that introducing a GPL display server would suddenly create a GPL violation, merely because the GPU driver runs in user space? Is this a situation analogous to the one quoted by Torvalds - where he does not believe that an independently developed GPU driver running in kernel space is a derivative work? Do you believe that an independently developed GPU driver running in user space forms a derivative work with the display server? Even though Torvalds explicitly stated that the equivalent running in kernel space does not form a derivative work - when in user space it suddenly becomes a derivative work?

[RahulSundaram]

Are you suggesting that your legal arguments are only correct in the context of ARM architecture, and are incorrect on others?

No because I am not a lawyer and don't pretend to be one and you shouldnt do that either. What you can do is read the analysis and understand that the context is different what you might have experienced. If you want to insist that you know better than people who have worked on such systems and have defended the license in actual court cases, go ahead but I have zero tolerance for such sillyness.

[chrisb]

Torvalds has actually clarified that he believes closed kernel modules which were developed independently of Linux don't violate the GPL even though they run in kernel space, so if the drivers were truly not derivative works then the OEMs wouldn't care.whether they ran in kernel space or not.

Here's another relevant Torvalds quote:

If you use the source code to build a new program, the GPL _explicitly_ says that that new program has
to be GPL'd too.

...

In short: you do _NOT_ have the right to use a kernel header file (or any
other part of the kernel sources), unless that use results in a GPL'd
program.

What you _do_ have the right is to _run_ the kernel any way you please
(this is the part you would like to redefine as "use the source code",
but that definition simply isn't allowed by the license, however much you
protest to the contrary).

So you can run the kernel and create non-GPL'd programs while running it
to your hearts content. You can use it to control a nuclear submarine, and
that's totally outside the scope of the license (but if you do, please
note that the license does not imply any kind of warranty or similar).

BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.

I wonder how many closed source drivers use kernel header files? Probably quite a few.

[Luke]

We should obstruct the marketing of locked-down devices

If an OEM intends to ship Ubuntu/Unity on a device, but wants to avoid any GPLv3 software, then it is going to have to have a non-GPLv3 version of Unity. If it doesn't, then the OEM has to give the user the freedom to replace Unity (and any other GPLv3 components), and hence can't lock the device down.

I've read the link you refer to before and its analysis is flawed. If an OEM can release their existing drivers for Android (which they do), and their lawyers are confident that the drivers are not a derived work of the GPL Linux kernel, then I see no reason why they would change this opinion because the display server is GPL. Whether it is GPLv2 or GPLv3 does not matter - if the lawyers are of the opinion that the drivers are not a derivative work, then neither applies. Conversely, if the lawyers are of the opinion that the presence of GPLv3 software would be a problem for their drivers, then that means that they believe the drivers are already a derivative work of that software, and hence they should already be releasing the source as required by the existing license.

I fully support the anti-Tivoisation clause of GPLv3, as I generally support any and all efforts to obstruct the marketing of any form of locked-down hardware that gives innovative users unpleasant surprises and forces them to discard devices or part them out. While you'd probably expect an iOS device to be locked down due to the publicity they get, a locked-down non-iOS tablet could be a surprise to someone. Never forget the desire of OEM's to lock devices to their software and media partners, never give them a chance to get away with it.

We should have two goals here: to force OEMs not to produce locked-down hardware, and to keep our own software ecosystem entirely isolated from DRM and corporate control. The latter is the job of things like GPLv3, the former is all of our job, by refusing to buy things like Tivo and locked-bootloader laptops or tablets. The nasty NSA publicity will help us a lot, even though Hollywood, Cable TV providers, ISPs in general, Google, and Facebook are each more dangerous to most users than the NSA ever dreamed of.

The GPLv3 helps obstruct the marketing of locked phones and tablets by making it harder for them to use our kernel, but not by much as they can still run something like BSD or Windoze 8 instead. I don't disagree with the use of other licenses to penetrate markets requiring interfacing with p/competing with proprietary SOFTWARE, but I feel our interaction with locked HARDWARE should be limited to hacking, rooting, and unlocking it.

[chrisb]

No because I am not a lawyer and don't pretend to be one and you shouldnt do that either. What you can do is read the analysis and understand that the context is different what you might have experienced.

Please answer the questions; I would like to know your argument actually is. Your linked analysis does not mention - at all - that it is restricted to the ARM architecture. In fact, it explicitly acknowledges that "Mir is ... intended to scale from mobile devices to the desktop". It does mention that Canonical has a focus on "GPLv3-hostile markets" - but wouldn't that equally apply to embedded x86 systems like the Steam Box?

If you want to insist that you know better than people who have worked on such systems and have defended the license in actual court cases, go ahead but I have zero tolerance for such sillyness.

Please show me where I said that I "know better than people who have worked on such systems and have defended the license in actual court cases"? I merely asked you to clarify your argument.

[RahulSundaram]

Please show me where I said that I "know better than people who have worked on such systems and have defended the license in actual court cases"? I merely asked you to clarify your argument.

Not true. You claimed that Matthew's analysis is incorrect when I tried to explain it to you and gave you the link. He has the direct expertise which you clearly don't. End of argument.

[chrisb]

Not true. You claimed that Matthew's analysis is incorrect when I tried to explain it to you and gave you the link. He has the direct expertise which you clearly don't. End of argument.

I said it was flawed, not incorrect. There is a difference. Your "explanation" consisted of the single claim that the analysis applied to the ARM architecture, when the actual blog doesn't mention ARM at all. When asked to clarify your claims, you either can't or refuse. You keep citing a blog post written by a software engineer as though it's the gospel truth when it comes to legal questions, but then refuse to answer questions about it. Don't you see the contradiction between quoting a software engineer's blog as an authoratative source, and telling people not to play internet lawyer? If you understand the argument, then answer the questions. If you don't understand the argument, then stop pretending that you do.

[RahulSundaram]

I said it was flawed, not incorrect. There is a difference. Your "explanation" consisted of the single claim that the analysis applied to the ARM architecture, when the actual blog doesn't mention ARM at all. When asked to clarify your claims, you either can't or refuse. You keep citing a blog post written by a software engineer as though it's the gospel truth when it comes to legal questions, but then refuse to answer questions about it. Don't you see the contradiction between quoting a software engineer's blog as an authoratative source, and telling people not to play internet lawyer? If you understand the argument, then answer the questions. If you don't understand the argument, then stop pretending that you do.

It is funny how you expect everyone else to spell out every single factor without any real understanding of what you are talking about. Have you wondered why Canonical choose to use GPLv3 and insists on a CLA for Mir? Do you have a good explanation of why Mir even exists? Matthew Garett isn't merely a software engineer but a Linux kernel developer and licensing expert. I will defer to his analysis over your non existest one. Sorry if that offends your sensibilities.

[mrugiero]

Are you suggesting that your legal arguments are only correct in the context of ARM architecture, and are incorrect on others? Please clarify:

Do you believe an OEM using the Nvidia or AMD closed source drivers (which both have closed source kernel modules) on a desktop is a violation of the GPL license of the Linux kernel? If not, then why would introducing a GPL display server suddenly create a GPL violation?

Do you believe an OEM using the Nvidia or AMD closed source drivers on an embedded system like the Steam Box is a violation of the GPL license of the Linux kernel? If not, then why would introducing a GPL display server suddenly create a GPL violation?

Do you believe an OEM using open source kernel drivers and closed source user space drivers on an ARM tablet is a violation of the GPL license of the Linux kernel? If not, do you believe that a simple kernel shim is enough to protect a driver from being a derivative work, even though that shim exposes complex kernel functionality? Do you believe that introducing a GPL display server would suddenly create a GPL violation, merely because the GPU driver runs in user space? Is this a situation analogous to the one quoted by Torvalds - where he does not believe that an independently developed GPU driver running in kernel space is a derivative work? Do you believe that an independently developed GPU driver running in user space forms a derivative work with the display server? Even though Torvalds explicitly stated that the equivalent running in kernel space does not form a derivative work - when in user space it suddenly becomes a derivative work?

Answer: it has nothing to do with the kernel, actually. The user space driver targets the display system, not the kernel. In desktop Linux it's MIT, so they can do whatever they want. On Ubuntu based devices, it will be Mir, which is GPLv3 with exceptions when Canonical explicitly authorizes them. GPLv3 prevents you from locking your device, MIT does not.