Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758625AbXFOV3r (ORCPT ); Fri, 15 Jun 2007 17:29:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757547AbXFOV3X (ORCPT ); Fri, 15 Jun 2007 17:29:23 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:59343 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757377AbXFOV3W (ORCPT ); Fri, 15 Jun 2007 17:29:22 -0400 Date: Fri, 15 Jun 2007 23:29:05 +0200 From: Ingo Molnar To: Alexandre Oliva Cc: Alan Cox , Daniel Hazelton , Linus Torvalds , 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 Message-ID: <20070615212905.GB4996@elte.hu> References: <200706132304.21984.dhazelton@enter.net> <20070614112329.3645c397@the-village.bc.nu> <20070614103846.GA7902@elte.hu> <20070614195517.GA4933@elte.hu> <20070614235004.GA14952@elte.hu> <20070615113123.GA6269@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.1.7 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4132 Lines: 93 * Alexandre Oliva wrote: > > see the slippery slope in action? Lets just use this limited > > concession on your part and show that _even this_ leads to absurd > > results: > > > - a "roadblock" such as a too small button? > > Why is it too small? > > > - a "roadblock" such as a soldered-on ROM instead of flash-ROM? > > Why is it soldered-ROM on rather than flash-ROM? > > > - a "roadblock" such as not opening up specifications to the hardware? > > Why is it not open, and why does that get in the way of replacing the > software? > > > - a "roadblock" such as not releasing the source of the BIOS? > > Why is it not released, and why does that get in the way of replacing > the software? > > > - a "roadblock" such as a virtual ROM implemented via an SHA1 key > > embedded in the hardware? > > Why is the virtual ROM and the SHA1 key in the hardware? > > > Remember, the issue is intent. If you do that for legitimate reasons, > such as technical limitations, industrial economic motives, etc, > you're probably fine. But if you do that for the purpose of > restraining users' freedoms, then you're going against the intent (and > quite likely the letter) of the license. Tivo does it for fully legitimate reasons as well: the only way it can be in the PVR business (and the only way it can employ and pay free software developers) is if it given a license to certain content. Those same users you are trying to "protect" are demanding this content! One condition of that content license is that the Tivo protects the downloaded content (such as pay-per-view movies). That same content, i'm sad to say, the same users who you are trying to "protect", would very much like to watch in a pay-per-view fashion, just without the 'pay' bit. I dont agree with content policies like that, but your demonization of Tivo is royally misplaced. Tivo has two choices: either it gives users the content they want to watch, or it goes out of business. Is that legitimate enough of a reason to restrict the hardware? If you want to make a difference you shouldnt attempt to screw with Tivo, they are clearly the _victims_ of the content industry. For example you are apparently very capable of sending 'content' to lkml in the form of dozens of long emails. How about using that energy for a Creative Commons project? How about helping Mugshot become more popular? Putting Tivo out of business (or forcing Tivo over to Windows CE) does not make this world more free one iota - to the contrary! > Remember, the issue is intent. [...] Furthermore, there's no need for your patronizing tone here, and there's certainly no need to "remember" me of any issues. I very much know what i replied to. Here's the original quote of what you wrote: > > by your argument, the user has some "right to modify the software", > > on that piece of hardware it bought which had free software on it, > > correct? > > Yes. [...] your "Yes" was not qualified at all via " Yes, except for restriction that are 'well-intentioned' ". your "Yes" led to clearly absurd results, and now that i've pointed out a few specific examples of that absurdity, you, instead of conceding that i might have a point or two, are now trying to change your "Yes" answer to "Yes, but ...". Shame on you! furthermore, even going along with this newly found argument of yours, your new, refined position leads to absurd results just as much. Firstly, who are you to dictate the design of the hardware (which was created independently of any GNU code) to behavior that you consider "legitimate"? What gives you this false sense of entitlement? Secondly, who is going to decide what "legitimate" is. Is the FSF the new Police of Morality, which enforces that GNU software is only used on hardware that has limitations that the FSF considers "legitimate"? Ingo - 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/