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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Sep 2006 10:03:57 +1000
From:	Neil Brown <neilb@...e.de>
To:	Chase Venters <chase.venters@...entec.com>
Cc:	Theodore Tso <tytso@....edu>, Linus Torvalds <torvalds@...l.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Sergey Panov <sipan@...an.org>,
	James Bottomley <James.Bottomley@...elEye.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: GPLv3 Position Statement

On Wednesday September 27, chase.venters@...entec.com wrote:
> 
> What I was really addressing here is that the whole F/OSS community 
> exploded over the news that Linux was not adopting the GPLv3. I think it's 
> fair to say that the reason why Linux is not adopting GPLv3 (aside from 
> the very practical matter of gaining the consensus of copyright holders)
> is that Linus and other top copyright holders don't think what Tivo is 
> doing is wrong. But when that statement first came out, it was almost lost 
> in the noise of "The FSF is not going to listen to us, and what about 
> encryption keys?" The former probably has no place outside of LKML; the 
> latter is the sort of thing you'd bring up at gplv3.fsf.org if you wanted 
> to participate in the process.

I don't think that anyone is saying that what Tivo is doing isn't
wrong.  What is being said is that the license is the wrong place to
try to stop this sort of behaviour.  It is too broad a brush.
There are a number of different reasons for wanting to use
technological measures for stopping people from re-purposing a device
and they aren't necessarily all bad.  Do we want our code to be
prohibited from being used in all of these cases?  Some people think
not.

But I wonder if GPLv3 will really stop Tivo....
I just read it again and saw - at the end of section 1.

  The Corresponding Source need not include anything that users can
  regenerate automatically from other parts of the Corresponding
  Source. 

So if Tivo included the code they used to generate the key, then they
don't need to include the key itself :-)  Users can regenerate the key
form that program.  Not sure how long it will take though.

NeilBrown

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