linux-kernel - Re: [PATCH] USB: mark USB drivers as being GPL only

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080206221254.5780a862@weinigel.se>
Date:	Wed, 6 Feb 2008 22:12:54 +0100
From:	Christer Weinigel <christer@...nigel.se>
To:	"Pekka Enberg" <penberg@...helsinki.fi>
Cc:	"David Newall" <davidn@...idnewall.com>,
	"Marcel Holtmann" <marcel@...tmann.org>,
	"Greg KH" <greg@...ah.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: mark USB drivers as being GPL only

On Tue, 5 Feb 2008 13:46:08 +0200
"Pekka Enberg" <penberg@...helsinki.fi> wrote:

> Hi David,
> 
> Marcel Holtmann writes:
> > > You driver was meant to be running as Linux kernel module and
> > > thus it is derivative work.
> 
> On Feb 5, 2008 1:39 PM, David Newall <davidn@...idnewall.com> wrote:
> > It is precisely the fact that it is a loadable module, and does not
> > form part of the kernel, that removes the requirement to distribute
> > it under GPL.
> 
> What makes you qualified to make that statement (without giving any
> evidence)? Are you're an expert on international copyright law?

Are you?  You've made some very definite statements about copyright
law.  Things that I've been told are definitely in a gray area and not
at all as clear cut as you and the FSF likes to say.  FSF has a very
clear agenda, and taking what they say as the gospel is a big mistake.

If I link a binary .o file into a static kernel image, does that make it
a derivative work of the kernel?  It most definitely violates the GPL
in that the total is a derivative work, but does it really make the .o
file a derivative work?  What if I let the user do the linking at
runtime?  But as Alan Cox wrote, how the linking is done doesn't decide
if it is a derivative work or not, copyright law does.

So what does make it a derivative work then?

If I use an in kernel API, but from a piece of code which is external
to the kernel, is that really a derived work? If you say it is, do you
realise that you are advocating something which is very close to an API
copyright, something which I think most open source people are very
adverse to.  If API copyrights were valid, Wine, or editline, or
lesstiff would be in a lot of trouble.  

Of course, the Linux headers don't only define an API, they also
contain a lot of inline code.  But if I don't care about an extra jump,
I could write a glue layer between the Linux kernel and some
proprietary code that wraps all inline functions.  In that case, is a
module written against that glue layer a derivative work of the kernel?

If I write a glue layer that allows me to run the same driver in
userspace via libusb and directly in the kernel, and give the user a
choice to link my binary .o file either the userspace or kernel space
glue, does that make my code a derivative work of the kernel?  Most
probably not, it is independent of the kernel in that case.  

So where is the line in the sand that makes it clearly a derivative
work?  It's up to the courts to decide, and until there is a clear
and final court ruling it is a gray area.  Lawyers can guess at what
the outcome might be, and some companies are apparently willing to take
the risk that it isn't as clear cut as you think.

  /Christer

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/