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:	Mon, 18 Jun 2007 23:46:30 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Hans-Jürgen Koch <hjk@...utronix.de>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Ingo Molnar <mingo@...e.hu>,
	Daniel Hazelton <dhazelton@...er.net>,
	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>,
	Chris Friesen <cfriesen@...tel.com>,
	Bernd Schmidt <bernds_cb1@...nline.de>,
	Robin Getz <rgetz@...ckfin.uclinux.org>,
	Rob Landley <rob@...dley.net>,
	Bron Gondwana <brong@...tmail.fm>,
	Al Viro <viro@....linux.org.uk>
Subject: Re: mea culpa on the meaning of Tivoization

On Jun 18, 2007, Hans-Jürgen Koch <hjk@...utronix.de> wrote:

> Am Montag 18 Juni 2007 23:18 schrieb Alexandre Oliva:
>> On Jun 18, 2007, Hans-Jürgen Koch <hjk@...utronix.de> wrote:
>> 
>> >> Vendor would be entitled to the benefit of the doubt as to the
>> >> motivations in this case, so it would likely be unenforceable anyway.
>> 
>> > Right. If GPL v3 comes out, there'll probably be a new task for
>> > hardware development engineers: How to find excuses for hardware that
>> > prevents software modifications and how to conceal the true intent.
>> 
>> Yup.  And then GPLv4 will have to plug whatever holes they find to
>> disrespect users' freedoms.  That's how I expect the game to be
>> played.

> If you were right and it turned out that way, the whole GPL would
> become so ridiculous that it won't have any of its intended effects.

How so?  The intended effects are to protect users' freedoms, by
requiring them to be respected.  If we keep on plugging holes as they
appear, it will keep close to achieving its intended effects.  It's
earlier versions of the license that will get more and more distant
from it.

> As far as the kernel is concerned, I expect the game's played by
> simply keeping GPLv2. And I like it that way.

Just think about it...  What if, today, some law passed, or some court
decision came up, that rendered a significant defense provision of
GPLv2 or GPLv3 ineffective?

GPLv4 could plug that, and anyone using GPLvN+ would be able to switch
to it immediately.  This wouldn't revoke previous licenses, of course,
but further developments could be made under the newer license, and at
least those could still be defended, and, as time elapsed, earlier
versions of the software would become less and less relevant, to the
point that the holes in their license also become less and less
relevant, until copyright finally expires and they enter the public
domain.


The distrust for the FSF led to this very short-sighted decision of
painting the Linux community into a corner from which it is very
unlikely to be able to ever leave, no matter how badly it turns out to
be needed.  Let's just hope it never is, or that some influx of
long-sighted comes in and introduces mechanisms for the license of
Linux to be patched, should this ever be needed.  I'm not even talking
about GPLv2+, there are many other ways to accomplish this, that I've
already mentioned in another posting in another recent huge thread.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@...dhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@...d.ic.unicamp.br, gnu.org}
-
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