linux-kernel - Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

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 11:02:43 -0700 (PDT)
From:	david@...g.hm
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	David Greaves <david@...eaves.com>,
	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>,
	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, Linus Torvalds wrote:

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

in fact there was news in the last week or two about a law in Germany that 
does exactly this. it outlaws all programs that can be used for hacking 
systems.

David Lang

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