[U-Boot] U-book and GPLv3? (fwd)

[Detlev Zundel <dzu@denx.de>]

Hi Jean-Christophe,

> On 15:41 Tue 23 Jun     , Mike Frysinger wrote:
>> On Tuesday 23 June 2009 15:26:35 Scott Wood wrote:
>> > On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote:
>> > > Apart from the the above reasons, currently most people who voiced their
>> > > opinion (not too many right now) oppose the move.  The reasoning seems
>> > > to be that companies using U-Boot inside a commercial product consider
>> > > it to be "a neccessary precondition to only accept blessed firmware
>> > > upgrades" (my wording).  What motivates this argument is not completely
>> > > clear to me.  Maybe it is fear of being liable as a product vendor to
>> > > faulty sw upgrades.
>> >
>> > Regardless of what motivates it, people who sell hardware to such
>> > customers (and who also contribute to u-boot) may not want to risk losing
>> > that business by pushing GPLv3 on them.
>> 
>> indeed.  expecting businesses to push other peoples' agenda isnt realistic, 
>> especially when the conversation is pretty much a net customer loss for said 
>> businesses.  customers arent going to appear because your business is now 
>> pushing GPLv3 instead of GPLv2, but they will certainly disappear.
> 200% agree
> I can assure you that today If we switch the V2 to the v3 we will lose a lot of
> customers and soc that use secure boot as example which is not a progression but a
> problematic regression

What exactly is secure boot?

> And force to give the private key which use to sign the code is not reallist
> it's a security flaw

That's interesting to hear.  Where exactly is there "security" involved
and why should security be implementable by signed binaries only?  Does
that mean that for example I have *no secure* software on my computer
right now?  Don't you mistake "security" for "authenticity"?

> so U-Boot will close itself to a lots of business and customers

As you are not trying to give concrete examples, let me try to formulate
your "facts": U-Boot will not be usable within DRM systems.  Is that
what you are saying?

Cheers
  Detlev

-- 
0x2B | ~0x2B
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de