Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759110AbXFTTNe (ORCPT ); Wed, 20 Jun 2007 15:13:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754466AbXFTTNZ (ORCPT ); Wed, 20 Jun 2007 15:13:25 -0400 Received: from gateway12.iders.ca ([206.45.72.61]:56387 "EHLO koko.iders.ca" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1754194AbXFTTNY (ORCPT ); Wed, 20 Jun 2007 15:13:24 -0400 Message-ID: <46797C52.4020907@iders.ca> Date: Wed, 20 Jun 2007 14:13:22 -0500 From: Andrew McKay User-Agent: Thunderbird 1.5.0.9 (X11/20061219) MIME-Version: 1.0 To: Alan Cox CC: Alexandre Oliva , Linus Torvalds , Al Viro , Bernd Schmidt , Ingo Molnar , Daniel Hazelton , Greg KH , debian developer , david@lang.hm, Tarkan Erimer , linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 References: <20070614195517.GA4933@elte.hu> <20070614235004.GA14952@elte.hu> <20070615011012.6c09066e@the-village.bc.nu> <20070615012623.GA25189@elte.hu> <20070615101007.0cbfd078@the-village.bc.nu> <4673CA7C.5040207@t-online.de> <20070616181902.GB21478@ftp.linux.org.uk> <4679557C.5080907@iders.ca> <20070620175627.319a6c55@the-village.bc.nu> In-Reply-To: <20070620175627.319a6c55@the-village.bc.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2723 Lines: 52 Alan Cox wrote: >> Secondly GPLv3 will cause companies like TIVO, router companies, security >> companies to not adopt Linux as an operating system, because they can't secure >> their system. Placing code in a ROM so they can't upgrade their own systems is > > You've made an important mistake. You said "their system". Now its "our > code" and "whoever bought the units' hardware" so it isn't their anything. Yes, the hardware belongs to the user, and the software belongs to the Linux community. However I think I wasn't 100% clear, I also mean keeping companies networks and content secured. Credit card companies insuring the software hasn't been modified to skim cards (not that it's the only way to skim a card), or Tivo making sure that their content providers are protected. Lets look at the credit card example. Sure the user could modify the system and boot their own kernel, but it doesn't have to play nice with Mastercard's network anymore. Or better yet, would actually report that a certain business's card reader had been tampered with. > > You've made a second mistake I think by assuming that vendor held keys > "improve" security and must be vendor held and secret for it to work. In > fact vendor owned key systems that cannot be changed usually reduce > security. > > There are very very good reasons for having vendor owned secret keys. > There are also very very good reasons for being able to rekey or disable > the key on your box. > > Ask people whose product vendor went bankrupt. With the ability to > override/replace the keys they could have maintained their system > securely instead they could make no updates and the boxes were left > insecure. I do see what you're saying here, and I can see how this is a problem. However what is the solution? Sure having the system open for users to replace software and tinker is great. It's how I got into engineering. I can also appreciate the ability for the end user to fix and continue to use a system long after a vendor goes out of business. However, I don't see how this would ever require a company like Tivo or Mastercard to have their networks play nice with a unit that has been modified by the end user, potentially opening up some serious security holes. From what I understand this would still violate GPLv3 because the system could no longer preform the task it was designed to do with modified code, but maybe I have misunderstood. Andrew McKay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/