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

[Detlev Zundel]

Hi Mike,

>> >> > but when customers absolutely state their requirements are secure boot
>> >> > and the ability to lock their hardware so no one else can run things,
>> >> > then i'm not about to argue with them.  their response is simply
>> >> > "fine, we'll move on to the next guy who will satisfy our
>> >> > requirements".
>> >>
>> >> It is your decision if you don't want to even understand your customers
>> >> needs.
>> >
>> > wrong, we've actually done the opposite.  we know what they want to do
>> > and it is doable with GPLv2.  it is not doable with GPLv3.
>>
>> From what I read, I do not get this impression.  "Locking people out" is
>> not a ulterior motive but the outcome of a perceived threat to a
>> business model.  It was this business model that I wanted to get a clear
>> picture of.  It seems I cannot get any more informatino here.
>
> locking down a machine is part of due diligence as well when it comes to 
> certification.  not taking measures to prevent uncertified code from running 
> is a legal liability for companies.

An aircraft is also a certified product - won't you think?  Do you
believe that an airline carrier ships its planes to the manufacturer if
they need to replace a screw?  Obviously there must be ways to ensure
certification even in such cases.  Why should those methods not be
applicable to other fields as well?  

It is this "certification is only possible like we say" attitude which I
seriously question.

> you can chalk these use cases up as "perceived threads to a business
> model" all you like.  many customers arent going to change because of
> your opinion, and while you may not business with them, i dont have a
> problem with doing it.

Sure, you're decision.  Although I cannot read it from what you wrote,
if you do business knowingly entering grey areas of licensing questions
(like writing closed source drivers for the Linux kernel), there is a
pretty good chance that one could go to court for "gross negligence".

This is not a joke.  Here in Germany lawyers actually evaluated if a
manager can get sued for "gross negligence" when deploying Free Software
in a company because of the "everybody can change the software" aspect.

>> > yes, there are cases of ingrained perceptions about how to accomplish
>> > something and GPLv3 blocks those methods.  but again, it is *your* choice
>> > to attempt to educate people here, it is not the automatic burden of
>> > people to champion the GNU cause for you.
>>
>> What kind of axe do you have to grind here?  We (as a project) were
>> asked about our stance to move to GPLv3 which is a perfectly good
>> question to pose.  All I want to do is collect facts - your allegation
>> that I want other people to carry a "burden" shows me that this way will
>> bear no more fruit.
>
> i wasnt directing all of these comments directly at you.  i dont know
> you nor do i care.

Yep, thanks for the confirmation.

>> >> > they arent generally trying to lock out people who just want to toy,
>> >> > they're targeting people who want to clone their hardware or
>> >> > functionality to create knockoffs or they're trying to guarantee lock
>> >> > down so they can get certified (like medical devices).
>> >>
>> >> How does GPLv3 vs. GPLv2 touch the "we will get cloned" question?  Maybe
>> >> I do not see the obvious here, but sourcecode to binaries under either
>> >> license must be available, so what's the difference?
>> >
>> > if you dont have the decryption keys, you cant read the end program. 
>> > having access to the u-boot source doesnt matter.
>>
>> Having access to the physical device will.  How long do you think will
>> it take to get broken into?  Unfortunately physics do not follow wishes
>> of companies as seen over and over in the past.
>
> and companies understand that.  i never said locking the device is a 100% 
> guarantee to prevent cloning -- nothing in life is 100%.  it does however 
> significantly make it harder to reverse engineer a black box that is wiggling 
> pins than it is to disassemble code and memory.  the companies i work with are 
> concerned with delaying clones for most of that product generation's life 
> span, not eternity.  if the clone comes in after the company has gotten their 
> fair share out of it, then that's fine by them.  clones are an unfortunate 
> aspect of commercial life.  without the secure boot aspect, people are able to 
> create knockoffs with enough turn around time to do quite a bit of damage to 
> the product's life span.

It's not the first time I hear this mantra.  Can you give me some facts
to back this up?

>> > i personally dont have a problem with people locking their hardware.
>> > that is their choice and the GPLv2 allows them that freedom.
>>
>> You have a strange definition of freedom - for you it is limited to the
>> provider of the devices not to the users of the devices.  I guess this
>> is what this all boils down to.
>
> no, i have a definition of freedom you cant cope with.

Oh, I can cope with this definition for sure.  It is rather misleading
to attach it to the word "freedom" however.

> what i choose to do with my time and code i write is absolutely my
> choice.  i have no problem people taking my code and doing whatever
> they want with it -- that's why i release to public domain.
>
>> > hell, i wouldnt have a problem with a public domain u-boot.  people
>> > dont use GPLv3 because it is a "superior" license from a technical
>> > perspective, they use it because they want to *restrict* how others
>> > use their code.
>>
>> Are you standing on your head typing this?  You actually want to allow
>> a few people to _massively_ restrict all the rest.  I cannot follow
>> here.
>
> and it's funny you cant cope with this simple concept.  your code,
> your time, your choice.  my code, my time, my choice.  

Again, no problem coping with this concept if put in these words.  Just
don't use "restriction" or "freedom" then.

> if people take my work i give away freely and "massively restrict the
> rest", then i dont have a problem with that.

So we are in accord after all - I don't want my work to be used in this
way.  Simple ;)

Cheers
  Detlev

-- 
If you currently have a 32-bit UNIX system, you are advised to
trade it in for a 64-bit one sometime before the year 2106.
 -- Andrew S. Tanenbaum: Modern Operating Systems, 2nd Edition
--
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