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: <47AB0238.5030400@davidnewall.com>
Date:	Thu, 07 Feb 2008 23:36:00 +1030
From:	David Newall <davidn@...idnewall.com>
To:	Chris Friesen <cfriesen@...tel.com>
CC:	Greg KH <greg@...ah.com>, Christer Weinigel <christer@...nigel.se>,
	Pekka Enberg <penberg@...helsinki.fi>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: mark USB drivers as being GPL only

Chris Friesen wrote:
> if I were to write a new GPL shim and then a new closed-source module
> that uses the shim to access kernel symbols, it is entirely possible
> that a court could rule that my closed-source module is a derivative
> work of the linux kernel because it was written specifically to run on
> linux.

A lot of software is written specifically to run on Linux, but that
doesn't mean it's derived from Linux.  In the case of user-space code
it's widely understood that no licence restrictions are conferred.  The
argument relating to kernel modules is that a module is somehow
different because it runs in kernel mode.  I can't see it, and in view
of the status of user-space code, strong arguments would have to be made.
>
> On the other hand if I were to sit down and write an OS-agnostic
> proprietary chunk of code, and then write a new GPL shim to use it
> under linux (and maybe other shim layers for other OS's as well), I
> _might_ be okay.  But I would have to be prepared to prove that the
> proprietary code was not derived from the Linux kernel.

No.  Holders of Linux copyrights would have to prove that the
proprietary code is derived from the kernel.  They have the burden of
proof, and defence needs merely show that their arguments are wrong. 
(So if the proof is faulty, the case fails even if the code is derivative.)
--
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