linux-kernel - Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

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]

Date:	Sun, 17 Jun 2007 06:14:51 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	Alexandre Oliva <aoliva@...hat.com>
Cc:	Daniel Hazelton <dhazelton@...er.net>,
	Bron Gondwana <brong@...tmail.fm>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	debian developer <debiandev@...il.com>, david@...g.hm,
	Tarkan Erimer <tarkan@...one.net.tr>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

On Sun, Jun 17, 2007 at 12:31:00AM -0300, Alexandre Oliva wrote:

> I'm not trying to say why Linus and others chose the GPLv2.
> 
> I'm not trying to determine what their motivations were.
> 
> I'm not trying to force them to change to GPLv3.
> 
> I'm not trying to convince them that tivozation is a bad thing.
> 
> I'm only trying to show that anti-tivozation is in line with the
> spirit of the GPL.

... and anti-tivoization section shows all symptoms of going in wrong
direction, *whether* *tivo* *is* *good* *or* *not*.  It's full of
kludges exactly because it tries to carve out a notion that can only
be determined on case-to-case basis and not by generic definition.
And no, that's not a matter of bad wording in that section.

I don't _care_ whether it breaks spirit, etc. - it's a fundamentally bad
idea for completely independent reasons.  Even if one thinks that tivo
in particular ought to be sued into the ground at some point.

Besides, it's fscking *pointless* for userland stuff.  If you insist that
e.g. glibc will infect by linking, you've just created a huge problem for
any GPLv2 userland code, which will make all bad blood about kernel look
trivial in comparison.  If you do not, then you've lost all leverage anyway;
kernel won't switch, libraries are OK, toolchain is obviously OK for building
code with any license... what's left?  The glorious /bin/cp?  Sorry, it would
work as usual, subject to open(2) not returning EACCES.  Just as on any
system.  Just what is it going to prevent?  Hell, they can slap selinux on
the box, protect what they want to protect, use crypto-loop to prevent offline
modifications of filesystem and hide the key in firmware.

Either GPLv2 is sufficient in given case (and e.g. Alan decides to go
after company in question), or you've at most created a moderate amount
of work rewriting the checks they are doing into a different form (if
that).  Good job.  In the meanwhile, you've got a load of ill-defined
verbiage around installation instructions.  I.e. a lovely fodder for
potential abusers.

Sod it.  GPLv3, with your involvement in its development or not, sucks
rocks, thanks to what you call anti-tivoization section.

-- 
How many GPL spirits can dance on the end of a pin?
-
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/