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]
Date:	Fri, 15 Jun 2007 10:18:32 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Greaves <david@...eaves.com>
cc:	Daniel Hazelton <dhazelton@...er.net>,
	Michael Gerdau <mgd@...hnosis.de>,
	Alexandre Oliva <aoliva@...hat.com>,
	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>, mingo@...e.hu
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3



On Fri, 15 Jun 2007, David Greaves wrote:
> 
> Surely it's more:
>   bad == go away and don't use future improvements to our software anymore
> please.
> ??

Well, with the understanding that I don't think that what Tivo did was bad 
in the first place, let me tackle that question *anyway*.

The answer is: Not necessarily.

Some people can be "bad" for the community. They may simply be disruptive 
and not productive at all. They may troll the mailing lists without 
actually ever doing something good, or they may do other "bad" things.

In fact, let's make it *very* specific: let's say that the bad person is a 
cracker, and specializes in finding security holes, and writing exploits 
for them, and selling those exploits to spammers.

Most of us might agree that that is a "bad" person for the community, no?

Now, by your own logic, let's look at what that means for the license. 
Should we write into our copyright license that you cannot try to find 
security holes? Would that be a good addition to the GPLv2?

Now, I stated that in a way where the answer is obvious: that would be a 
*horrible* addition to the GPLv2. I think everybody can agree on that. It  
would be really stupid to say "you cannot look for security holes" just 
because *some* people who do it are bad.

Now, think about that for a moment, and then go back to your question 
about whether Tivo is bad for the community, and whether being bad for the 
community should mean that the license should be written to say "go away 
and don't use future improvements to our software".

See where I'm trying to take you?

I think that even people who *do* think that what Tivo did was "bad", 
should think very deeply about the issue whether you should try to lock 
out "bad uses" in your license. Yes, the answer may be "yes, you should". 
But I'm arguing that the answer _may_ also be: "No, you shouldn't, becasue 
it turns out that you might lock out _good_ people too".

So in my cracker/spammer example, by trying to lock out the bad people, 
the obvious (and _stupid_ - don't get me wrong, I'm not at *all* 
suggesting anything like that should ever be done) license addition of 
"don't expose security problems" actually just causes more problems than 
it solves (if it solves anything at all - really bad people don't actually 
tend to even care about the license!).

It makes it harder for *valid* uses of security problem discovery. It 
makes it potentially illegal to try to do security research. And don't 
tell me stupid licenses and laws like that don't happen: people really 
*do* make these kinds of shortsighted decisions, to "protect" themselves 
from bad people.

I personally think that the same is true of the GPLv3 anti-tivoization 
clauses. Even if you don't like Tivo, you may well recognize that there 
are lots of *other* reasons for lock-down. Maybe you hate Tivo, and the 
RIAA and the MPAA. Fine. What about the FCC? Or what about secure 
terminals? What about any number of *other* reasons to use validated 
kernel images?

Now, I cannot speak for Alan Cox (he can speak damn well for himself), but 
I think Alan is an example of a person who actually really detests what 
Tivo did. But I also am pretty sure that he's also quite smart enough to 
see that the GPLv3 anti-tivoization clauses may stop *other* uses that he 
doesn't dislike and he doesn't think are "wrong", and even though he 
dislikes what Tivo does, as far as I know, I think his stance on the GPLv3 
is that it's actually wrong for Linux.

See? You don't actually have to like Tivo to see downsides to trying to 
stop them. Because these kinds of things have consequences *outside* of 
just stopping Tivo.

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