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]

Message-ID: <or8xafxxhu.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Tue, 19 Jun 2007 21:47:41 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Daniel Hazelton <dhazelton@...er.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@....linux.org.uk>,
	Bernd Schmidt <bernds_cb1@...nline.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ingo Molnar <mingo@...e.hu>, 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

On Jun 19, 2007, Daniel Hazelton <dhazelton@...er.net> 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@...dhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@...d.ic.unicamp.br, gnu.org}
-
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/