GPL concerns halt Kororaa live CD (NewsForge) [LWN.net]

GPL concerns halt Kororaa live CD (NewsForge)

Posted May 16, 2006 13:25 UTC (Tue) by arjan (subscriber, #36785)
In reply to: GPL concerns halt Kororaa live CD (NewsForge) by jayorke
Parent article: GPL concerns halt Kororaa live CD (NewsForge)

I think you missed the point ;)

the gpl doesn't restrict what you say it restricts, it has restrictions on shipping the GPL code. (or rather, copyright law has those restrictions and the GPL doesn't waive those)

the difference is subtle but important: it's not "you can not ship [that other thing] if ..", it's "you cannot ship [me] if ..".

(and as for the binary drivers that don't contain GPL code.. that's tricky, Compiled binary drivers do tend to contain GPL code! What I mean is that nvidia ships blob+glue, when you compile that into a driver that gets mixed with the kernel code (via #include's) and as a result of that actual code (not just definitions) get put into the final resulting binary. If that is enough to make things "derived" or any other kind of problem is a matter for lawyers. But to blanketly say "no GPL code" is too simple. And this also means that there is a difference between distributing blob+glue as nvidia does and a final compiled thing as Kororaa apparently put on the cd)

(Log in to post comments)

GPL concerns halt Kororaa live CD (NewsForge)

Posted May 17, 2006 0:46 UTC (Wed) by arjan (subscriber, #36785) [Link]

> So even though the final blob+glue is tolerated because of the extra clause
> preceding the GPL in the Linux source COPYING file, the compiling of the
> blob+glue links it to other GPL software and triggers 2.a. in the GPL Terms
> and Conditions?

maybe I'm missing something but I didn't see a clause added to the kernel COPYING file that allows binary modules, all I see is an explenation from Linus that he considers *user space* applications that use normal syscalls indepdent and not a derived work. But not a word about kernel modules....

GPL concerns halt Kororaa live CD (NewsForge)

Posted May 17, 2006 1:45 UTC (Wed) by grouch (guest, #27289) [Link]

maybe I'm missing something but I didn't see a clause added to the kernel COPYING file that allows binary modules, all I see is an explenation from Linus that he considers *user space* applications that use normal syscalls indepdent and not a derived work. But not a word about kernel modules....

I think the problem is more my lack of clarity than you missing something. I wasn't suggesting shipping the ready-compiled driver; just the separate parts in the same way that nVidia is allowed to do. The confusion appears to be from my misuse of the terms you had selected in your previous comment. Sorry about that.

Including the same things that nVidia ships on the same CD as the kernel and the rest of the operating system would be "mere aggregation". It would be unusable as shipped and require the user to decide to compile it. That compiling produces the "taint", which is a thing that is not distributable under GPL.

GPL concerns halt Kororaa live CD (NewsForge)

Posted May 17, 2006 2:54 UTC (Wed) by grouch (guest, #27289) [Link]

Follow-up, because I realized I'm still lacking clarity in my response.

There is no exception clause for binary modules and I realize that my wording about the kernel tolerating binary modules can be taken to imply that. The extra clause, IIUC, is directed at the following part of the GPL:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

The sticky part that triggered the extra clause, again as I understand it, is that about "a work based on the Program". The nVidia installer is pretty much useless without Linux and a bunch of GNU software. The clarification by Torvalds of a derived work pretty well eliminates the argument that the installer is "based on the Program". This is "tolerated".

The nVidia installer ships with the closed, binary part separate from the GPL part. The closed, binary part is not a derivative of, or linked to anything GPL at this point.
The extra clause added before the GPL in the Linux source COPYING file clarifies the line for a "derived work". The nVidia installer (the open part, not the closed part) is not a derived work, even though it depends on the Linux kernel to do anything useful.
Once the installer does its compiling, the result is a derived work. This is the thing that cannot be distributed under the GPL, due to the lack of source for the closed, binary part within it. This is the finished kernel module that produces the "taint" to the kernel.

"[M]ere aggregation" applies to the unusable, closed blob in 1. above, before compiling. A CD is not violating the terms of the GPL if that blob is just saved on the CD with GPL software. The user can choose to compile and use that finished module in 3. above, but cannot redistribute that part under the terms of the GPL.

For those wondering how Ubuntu does it.

Posted May 17, 2006 11:34 UTC (Wed) by sladen (subscriber, #27402) [Link]

It is distribution of the combined ["linked"] work which is presenting the issue. For anyone wondering, Ubuntu side-steps this issue (after having received a similar treatened shake-down) with the following; in:

  /etc/init.d/linux-restricted-modules-common

Which is executed on bootup, The keys bits of which are:

  log_begin_msg "Preparing restricted drivers..."
  mount -t tmpfs -o mode=0755 tmpfs /lib/modules/"$KVER"/volatile/
  ...
  ld_static -d -r -o /lib/modules/"$KVER"/volatile/$module.ko $module/*

Hence ensuring that the linked result only ever exists in a tmpfs location—stored in volatile RAM—which is then lost at shutdown. As a result the combined result is never distributed; and neither can the components be directly used with each other.