linux-kernel - Re: GPL vs non-GPL device drivers

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: <3d57814d0702171726l403c7812n19f2a226cba02e5d@mail.gmail.com>
Date:	Sun, 18 Feb 2007 11:26:54 +1000
From:	"Trent Waddington" <trent.waddington@...il.com>
To:	davids@...master.com
Cc:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	"Neil Brown" <neilb@...e.de>
Subject: Re: GPL vs non-GPL device drivers

On 2/17/07, David Schwartz <davids@...master.com> wrote:
> I don't think that's grey at all. I think it's perfectly clear that linking
> cannot create a derivative work. No automated process can -- it takes
> creativity to create a derivative work. (That doesn't mean that just because
> you can link A to B, a cannot be a derivative work of B or vice verse, of
> course. It just means that if A is not a derivative work of B, linking A to
> B cannot make it so, nor can the result be a derivative work.)

Sigh.  VJ is distributing the linux kernel with proprietary
extensions.  If you want to argue that the proprietary extensions in
isolation are not derivative works of the kernel, fine, you might have
a case, but the combined work, which VJ is distributing is *clearly* a
derivative work and must be distributed under the terms of the GPL.

Despite which, legal bullshit is best left for lawyers.. the *intent*
of the GPL is that if you distribute *any* changes, extensions or
plugins for a GPL work, you do so under the GPL.  The law may not
allow for this to be enforced, but it shouldn't need to.. one should
read the GPL as 100% enforceable and follow it without looking for
"loop holes" as it is the stated desire of how the author of the code
wants you to use his work.  Looking for loop holes, and worse yet,
discussing those loop holes in a public place, is just insulting.

Trent
-
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/