qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU License and proprietary hardware


From: M. Warner Losh
Subject: Re: [Qemu-devel] QEMU License and proprietary hardware
Date: Fri, 22 Jun 2007 11:30:34 -0600 (MDT)

[[ This is my last post on this topic, as we're starting to get quite
   far afield from QEMU and I'm starting to repeat myself.  "Luke -Jr"
   wants the last word, he can have it ]]

In message: <address@hidden>
            Luke -Jr <address@hidden> writes:
: On Friday 22 June 2007 11:46, M. Warner Losh wrote:
: > In message: <address@hidden>
: >             Luke -Jr <address@hidden> writes:
: > : On Friday 22 June 2007 11:07, you wrote:
: > : > > On Thursday 21 June 2007 17:33, M. Warner Losh wrote:
: > : > > > The GPL only has as much force of law as copyright law gives it,
: > : > > > and in order to be applicable, the work in question must somehow
: > : > > > rely on the GPL'd work.  The "somehow" here is an interesting legal
: > : > > > question that hasn't been well settled.
: > : > >
: > : > > And copyright law by default grants you no rights to modify or copy
: > : > > Qemu at all. The ONLY way you can get permission to copy or modify
: > : > > Qemu is to agree to the GPL in its entirety-- which does not restrict
: > : > > itself to merely derivative works, but covers all linking. (note:
: > : > > obvious the copyright holder(s) can make exceptions to this rule)
: > : >
: > : > Actually, the GPL does only apply to derived works, and it plainly
: > : > says so:
: > : >         The "Program", below, refers to any such program or work, and
: > : >         a "work based on the Program" means either the Program or any
: > : >         derivative work under copyright law
: > : > Linking typically is what makes a derived work, but not necessary.  It
: > : > is just the shade of grey that most people use as a rule of thumb.
: > :
: > : That's merely the definition of "Program" as used in the
: > : license. Read all the requirements, not just definitions...
: >
: > The definition is what is controlling here.  IF it is a derived work
: > THEN you must do X.  If it is not a derived work, then you may do as
: > you see fit.  If what you did somehow wasn't a derivative work, then
: > the there's no legal basis for forcing compliance with a license.
: > This is exactly what SCO is trying to do right now with its IBM case.
: 
: Unless you modify or distribute the work. These acts are illegal without 
: compliance with the license.

Modifying the work may create a derivative work.  If it does (and it
usually does), then you are correct.  If it does not for some reason,
then the terms do not apply.

: > : > If you do not have a derived work, then you can use and distribute
: > : > your work as you see fit, without the GPL restrictions.  While the GPL
: > : > is viral, it is only viral to the extent that the new work is
: > : > derivative of the GPL'd work.  This is why, for example, running my
: > : > proprietary program on a Linux box doesn't mean my proprietary program
: > : > is covered under the GPL.  Although it uses the kernel, and in a very
: > : > real sense the kernel links into the program due to address space
: > : > mapping for system calls and the like, this isn't enough to make my
: > : > program a derivative work.  So it isn't 'black' vs 'white' but more of
: > : > a 'this shade of grey is more white than black' or vice versa.
: > :
: > : The kernel contains exceptions for userland code. If it didn't, you would
: > : be unable to distribute your program alongside Linux.
: >
: > Even if it didn't, you would be able to.  Running a program on a
: > kernel does not create a derivative work.  I believe there is even
: > case law on this.  IIRC, there were cases with IBM and third parties
: > providing software for mainframes that settled this, but I don't have
: > the time to do an Internet search here.
: 
: I bet those cases weren't distributing the kernel along with their software, 
: were they?

They were, actually.  The cases I'm thinking of had to do with VARs
integrating their software and shipping the systems to end users.
Similar, but not identical.

: > It is unclear for the Linux kernel if the 'end run' people do with
: > loadable modules is a legal way to avoid source distribution.  The FSF
: > doesn't think so.  Linus has said he's cool with it, but absent a
: > statement from all the copyright holders of code in the Linux kernel,
: > the issue is at best murky.  It is unclear if the original poster
: > tried to do a binary-only module with QEMU if he'd be in compliance or
: > not (since the end user does the actual linking).
: 
: It is undisputed that it would be in violation if the kernel was distributed 
: with the modules.

It is not undisputed.  Linus Torvalds doesn't hold that view, for
example.  All the wireless device makers today that are based on linux
use binary-only modules for their wireless devices.  Similar issues
happen with NTFS write support in many of network attached storage
devices.  These devices are distributed with both the kernel and
devices in the same flash.

I've included some examples of divergent opinion within the Linux
kernel community below.

: The GPL is clear that mere use (end user) is always allowed. It is
: also fairly clear (the opinions of many kernel developers and IP
: lawyers) that proprietary modules for Linux are illegal to
: distribute. As with all copyright violations, however, the liability
: is on the distributor's end, so the end user is again not liable for
: the download either.

This does not square with Linus' prior statements that loadable
modules are OK.  He's written extensively about this, and his position
is a little more nuanced than 'good' vs 'bad.' in that he considers
how the module was written, and whether or not the methods make that
driver a derivative work or not.  See for example:
        http://www.linuxdevices.com/news/NS3501846795.html
which spells out this position quite clearly.  And a much earlier post
on the topic from Linus, which reads almost the same as the above one
from 2007:
        http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
For examples of vendors that do not hold your view, see:
        http://aplawrence.com/Blog/B1045.html

Like I said, this is an area of dispute.  Some people think that it is
contrary to the license, while others believe this is a legitimate
loophole.  For the binary modules are not ok, see:
http://www.oreillynet.com/linux/blog/2006/08/why_binaryonly_linux_kernel_mo.html

Hence my very careful wording about there being a dispute.  Both sides
have good arguments on their side, and the matter is far from settled.

Warner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]