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: <20070615212905.GB4996@elte.hu>
Date:	Fri, 15 Jun 2007 23:29:05 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexandre Oliva <aoliva@...hat.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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>
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3


* Alexandre Oliva <aoliva@...hat.com> 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@...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