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: <200706141944.21280.rob@landley.net>
Date:	Thu, 14 Jun 2007 19:44:19 -0400
From:	Rob Landley <rob@...dley.net>
To:	Alexandre Oliva <aoliva@...hat.com>
Cc:	Robin Getz <rgetz@...ckfin.uclinux.org>,
	"Daniel Hazelton" <dhazelton@...er.net>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>, "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>, mingo@...e.hu
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

On Thursday 14 June 2007 13:46:40 Alexandre Oliva wrote:
> On Jun 14, 2007, Robin Getz <rgetz@...ckfin.uclinux.org> wrote:
> > On Thu 14 Jun 2007 01:07, Alexandre Oliva pondered:
> >> then maybe the small
> >> company could have been more careful about the regulations.  There are
> >> various ways to prevent these changes that don't involve imposing
> >> restrictions of modification on any software in the device, all the
> >> way from hardware-constrained output power to hardware-verified
> >> authorized configuration parameters.
> >
> > As a person pretty familiar with the hardware in these types of
> > devices - this just isn't practical.
>
> I actually left out the most obvious one: store the program in ROM.
> Is that not practical?
>
> You're claiming that adding hardware locks and chains and bolts,
> implemented with help from the loader software, is simpler than just
> using ROM?

As far as I know, I'm the first one who brought up the "the current GPLv3 
draft forbids burning your code into ROM, you idiots" argument back before 
Bruce Perens cost the BusyBox project my services over this very issue.  (Not 
that I didn't lock the license of that down to v2 and chase him away before I 
left, I was just too disgusted to ever again contribute to a project he'd 
named.  Yeah, I hold a grudge.)

Although it's kind of amusing to watch you attempt to dictate terms to 
hardware manufacturers, the answer to your question is "yes".  Having flash 
is sometimes simpler and cheaper than having ROM.  It means you don't have to 
burn a new mask to bump the firmware revision (especially on a low-volume 
production run, where "low volume" here is tens or hundreds of thousands 
instead of millions).  It makes the thing a lot more field serviceable (you 
can upgrade the firmware without a chip puller).  It means one physical chip 
can give you both read-only and persistent writeable storage.   And flash 
chips produced in high enough unit volumes honestly can be cheaper than a 
custom ROM, pricing in semiconductors is all about unit volume.

> Well, then, ok: do all that loader and hardware signature-checking
> dancing, sign the image, store it in the machine, and throw the
> signing key away.  This should be good for the highly-regulated areas
> you're talking about.  And then, since you can no longer modify the
> program, you don't have to let the user do that any more.  Problem
> solved.

A) Does that actually satisfy the terms of GPLv3?  If so, can't they just wait 
until they get sued and destroy the keys then?

B) There are actually manufacturers who would be happy with your straw man.  
Lots of companies in the far east produce products that infringe on patents 
from 30 different competitors, and rather than try to license everything 
(which isn't even always possible) they spin off a shell company (or nested 
series thereof), design and manufacture a product, sell a production run of 
them into the distribution channel, and then dissolve the shell company 
before the inventory hits retailers.  But the time anybody is in a position 
to take an enforcement action, the company to take the action against is 
gone.  (Who are you going to sue, customers who bought the devices?  The 
distributors who bought the inventory in good faith, and will then refuse to 
distribute any of YOUR product if you attack 'em?)  There's always the 
possibility that somebody will sit down and follow the paper trail back to 
the parent company (through the multiple legal jurisdictions where nobody 
speaks english), but since they're likely as not to destroy this kind of info 
_anyway_ while burying their trail...

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