linux-kernel - Re: GPLv3 Position Statement

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: <Pine.LNX.4.61.0609280947360.21498@yvahk01.tjqt.qr>
Date:	Thu, 28 Sep 2006 10:04:20 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Linus Torvalds <torvalds@...l.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Sergey Panov <sipan@...an.org>,
	James Bottomley <James.Bottomley@...elEye.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: GPLv3 Position Statement

>People don't have a clue!
>
>The GPLv2 never _ever_ mentions "linking" or any other technical measure 
>at all. Doing so would just be stupid (another problem with the GPLv3, 
>btw). So people who think that the GPLv2 disallows "linking" with 
>non-GPLv2 code had better go back and read the license again.
>
>Grep for it, if you want to. The word "link" simply DOES NOT EXIST IN THE 
>LICENSE!

Hah then read LICENSE.LGPL!

"""Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License.  This license, the GNU Lesser
General Public License, applies to certain designated libraries, and
is quite different from the ordinary General Public License.  We use
this license for certain libraries in order to permit linking those
libraries into non-free programs."""

If the GPL does not mention linking at all, and therefore does not
really forbid it, why do we need an LGPL to allow linking then?

>What the GPLv2 actually talks about is _only_ about "derived work". And 
>whether linking (dynamically, statically, or by using an army of worker 
>gnomes that re-arrange the bits to their liking) means something is 
>"derived or not" is a totally different issue, and is not something you 
>can actually say one way or the other, because it will depend on the 
>circumstances.

I would be of the opinion that dynamic linking does not make it a
derived work, because neither the ld program nor the ld-linux.so
dynamic linker knows whether -lfoo is actually GPL or not.

>> No. The definition of a derivative work is a legal one and not a
>> technical one.

And that is a major problem IMHO. If there is no definitive
[technical] answer to what constitues a derived work, and it leaves
you at risk to lose a case in court while it is a gray area.

Oh well back on the topic: A userspace app just is not a derivate
work of the kernel, for me at least.

>Now, it is also indisputable that if you _need_ to "link", it's a damn 
>good sign that something is _very_likely_ to be derivative, but as Alan 
>points out, you could do the same thing with RPC over a socket, and the 
>fact that you did it technically differently really makes no real 
>difference. So linking per se isn't the issue, and never has been.

Jan Engelhardt
-- 
-
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/