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: <200802081436.53928.dhazelton@enter.net>
Date:	Fri, 8 Feb 2008 14:36:52 -0500
From:	Daniel Hazelton <dhazelton@...er.net>
To:	David Newall <davidn@...idnewall.com>
Cc:	Marcel Holtmann <marcel@...tmann.org>, Greg KH <greg@...ah.com>,
	Christer Weinigel <christer@...nigel.se>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] USB: mark USB drivers as being GPL only

On Friday 08 February 2008 14:08:21 David Newall wrote:
> I explained something poorly:
> > Now, Alan has made a big issue over numerous legal opinions he has
> > received, but he's been completely coy in the details.
>
> The point I wanted to make is that a few people have said that lawyers
> say that kernel modules are derivative, but I only remember Alan saying
> that he had actually spoken with the lawyers.  Therefore I infer that
> this somewhat widely held opinion originates from him.  My point was to
> those people who have been taking him at his word, and was to point out
> that there are more reliable and transparent sources.  Don't take his
> word on it.  Take the words of real experts in the law, because instead
> of a mere four word conclusion, they explain everything.

The one technically inclined lawyer that I asked about this said that the 
Lexmark decision meant that code using an API did not mean the work was a 
derivative of the API. However, in the case of the Linux Kernel, the code is 
meant to function inside a much larger framework and the API available to 
modules includes large amounts of "boilerplate code" buried behind handy 
chunks of code like "list_for_each".

The problem, he said, was that, in the US, such code is included in the module 
in a mechanical and wholly automated process. Which means that the module 
doesn't automatically inherit the GPL license. But, he cautioned me, this 
does not mean that a court couldn't (and/or wouldn't) rule that a module 
written specifically for Linux is a derivative of the kernel.

He also cautioned that, although the Bern Convention broadly controlled 
international copyright laws, specific countries do seem to have laws that 
cover the "kernel module" situation much better than the US laws and that 
those laws do apparently  make a module a derivative of the kernel.

His overall statement on it was that, in his opinion, whether a given module 
is a derivative or not would depend on the amount of "original" work 
contained in it compared to the number of places where linux specific code is 
used. He also stated that, while disagreeing with the idea that parts of an 
API could be "so deeply embedded that using them creates a derivative work", 
it would be a good idea to always pay attention to the beliefs of the 
developers of the code, because it is their opinion that will start the legal 
problems.

In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea", but 
people ignoring this and doing things that circumvent this will, eventually, 
have problems with the people who hold the copyright on the code. (In 
addition, he stated that circumventing the "EXPORT_SYMBOL_GPL" bit might also 
be in violation of the DMCA, but he isn't sure if a court would see it in the 
same light as someone cracking the CSS key on a DVD expressly for the purpose 
of creating pirated copies)

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ