Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759250AbXFTAsv (ORCPT ); Tue, 19 Jun 2007 20:48:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755458AbXFTAsn (ORCPT ); Tue, 19 Jun 2007 20:48:43 -0400 Received: from mx1.redhat.com ([66.187.233.31]:45782 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753795AbXFTAsm (ORCPT ); Tue, 19 Jun 2007 20:48:42 -0400 To: Daniel Hazelton Cc: Linus Torvalds , Al Viro , Bernd Schmidt , Alan Cox , Ingo Molnar , 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: <200706190423.47166.dhazelton@enter.net> <200706191928.13592.dhazelton@enter.net> From: Alexandre Oliva Organization: Red Hat OS Tools Group Date: Tue, 19 Jun 2007 21:47:41 -0300 In-Reply-To: <200706191928.13592.dhazelton@enter.net> (Daniel Hazelton's message of "Tue\, 19 Jun 2007 19\:28\:13 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.990 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2020 Lines: 52 On Jun 19, 2007, Daniel Hazelton wrote: > Company X has requirement for restriction Y > => License on product Z disallows restriction Y > => Product Z loses Company X and the exposure use in their product gives > => License on product Z is bad for the product > Understandable now? Well, considering that I've made this claim myself as part of my complete argument in a number of times I've presented it, yes, this is understandable and correct. This is indeed one of the cases. That said, very few companies have a scrict *requirement* for keeping the ability to modify the software on the customer's computer while denying this ability to the customer. So this case you're discussing is the least common case. It could nearly be dismissed, rather than being the dominating topic in the discussion, as it's been so far. > What I was stating is that are legal (and other reasons) why a > company might have to lock down their software in a process similar > to "Tivoization". Ok. Most of these can be addressed (with inconvenience) with ROM. Others are business reasons, and for these, the increased cost and inconvenience of the alternatives may shift them to an unlock situation. >> Therefore, this claim is false. > Only when you define a term as specifically as you have done > for "Tivoization". It's not my definition. This was from Wikipedia. > I should, perhaps, have used a different term - it would > then have been patently true. Depends on what the different term was. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} - 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/