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: <20070617084610.GD6267@elte.hu>
Date:	Sun, 17 Jun 2007 10:46:10 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexandre Oliva <aoliva@...hat.com>
Cc:	Michael Poole <mdpoole@...ilus.org>,
	Daniel Hazelton <dhazelton@...er.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	Greg KH <greg@...ah.com>,
	debian developer <debiandev@...il.com>,
	"david@...g.hm" <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


* Alexandre Oliva <aoliva@...hat.com> wrote:

> On Jun 15, 2007, Ingo Molnar <mingo@...e.hu> wrote:
> 
> > it is a false statement on your part that the executable "does not 
> > function properly" if it lacks that part. Try it: take out the harddisk 
> > from the Tivo (it's a bog standard IDE harddisk), put into a nice Linux 
> > PC, mount it, modify a bit in the kernel image header and it will likely 
> > still boot just fine on that PC.
> 
> Ok, try this: take the disk out, remove/replace/modify the signature, 
> put the disk back in, and tell me what it is that fail to run.

you mean back into the Tivo? That is not support for what you claimed. 
You claimed the "executable does not function properly" if it lacks that 
part (and you did not qualify your statement with anything). That was a 
false statement, because it still works fine in just about any 
bog-standard PC. A true statement would be: "the modified executable 
does not function properly _in the Tivo_". It still works fine on a 
general purpose PC.

In fact, you couldnt even modify the binary on the Tivo, because the 
Tivo is not a general purpose PC, it is a PVR. You'd have to put the 
disk into a PC to modify the binary. And then you'd have to put it back 
into the Tivo. So even in this silly example of yours you _already_ have 
to have a general purpose programmable system where the free software 
runs fine, and even under your strained and invalid interpretation of 
the GPLv2, your "rights" to modify the software are very well present on 
that general purpose system.

But you didnt really want to make use of Tivo's free software 
enhancements, right? Lets face the sad truth: the overwhelming majority 
of Tivo 'modders' wanted to hack the PVR not to enhance the Tivo, they 
more likely wanted to watch pay-per-view content without the pay bit and 
they perhaps wanted to get around service restrictions that the Tivo 
implements (and through which it funds lower-than-production-cost for 
the PVR). So the 'rights' you are trying to protect are invented 
'rights' of mostly _freeloaders_ in fact. The 'Tivo community' was 
conjured up after the fact. So even in this supposedly golden and 
hand-picked DRM example of RMS, the whole story stinks from beginning to 
end and has all the classic earmarks of detached-from-the-real-world 
religious extremism in the works ...

and the whole effort is totally pointless anyway. Consumers are already 
voting with their feet against DRM restrictions. So the only DRM victims 
of the GPLv3 attack measures will be the _good_ uses of DRM. People will 
be able to use tamper-proof, vendor-upgradable hardware based on 
FreeBSD, but not based on any GPLv3 kernel. Nobody will care about 
content DRM at that point anymore, and all that remains is a license 
that is crippled for the _good_ uses. Smart move to advance free 
software, eh? Really, RMS should have kept hacking code a bit longer so 
that he doesnt become that totally detached from the rest of us.

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