On Thu, Jun 18, 2009 at 11:46 AM, Jean-Christophe PLAGNIOL-VILLARDplagnioj@jcrosoft.com wrote:

On 16:51 Thu 18 Jun     , Wolfgang Denk wrote:

...

Hello,

I was asked about relicensing U-Boot as GPLv3:

I'm not for the GPLv3 I've the same opinion as Linus Torvald

And as we share a lot's of code with Linux we should continue and not use the GPLv3 at all

Isn't there a practical consideration too? Since copyright assignment isn't required on u-boot contributions, you would have to track down all of the contributors and get their permission for the licensing change. Mozilla had to do this when they changed their license and it took them two years to find everyone. Linus has stated that tracking down all of the contributors to the kernel is virtually impossible.

Please also note that we have code that is GPLv2 Only 1nd I do known a lot of firms that will stop to use and dev under U-Boot if we switch to the v3

so I'm against it

Best Regards, J. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Hello Richard,

There's only one thing about U-Boot that doesn't seem so good:

U-Boot is GPLv2 (sometimes "or later").

To have some parts which are GPLv2 only is unfortunate.

This is due to us many times (re-)using Linux drivers inside U-Boot.

Also this is one of the objections worded on the mailing list, namely that such a cooperation will be impossible in the future if U-Boot moves to GPLv3.

As a base for reasonable discussion, I think we need to evaluate those claims and back them up by actual figures. Only then the real effort needed to move and the potential loss of "code immigration" can be estimated.

Is there any chance of convincing those authors to change that?

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.

A common theme in the embedded community is the fear of "getting copied by cheap labor countries" - which should not be the case here, but I cannot say for sure.

I believe that without discussing this question seriously with all its implications we will not get enough momentum to even start defining the work for a switch.

We should also start to actively inform the regularly appearing people on this mailing list complaining that they cannot get the source code to U-Boot of "device xyz" that with a GPLv2 U-Boot this may become a theoretical question in the future when they cannot install the changed binary anymore.

Cheers Detlev

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

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

Hi Matthew,

thanks for the explanation.

...

Don't you mistake "security" for "authenticity"?

In this context, I believe both terms are interchangeable and effectively mean the same thing.

This is generally not true. These concepts have well defined meanings. I can have a secure communicatins channel with someone I did not authenticate. Also I can have a non-secure communications channel with someone who authenticated himself by some means to me.

It is secure because only authenticated code is allowed to be executed, thus another step to avoid piracy, hacking of conditional access systems etc.

Running only authenticated code does *not* ensure security, no matter how much this is wished for.

But no matter, I now understand that "security" seems to mean "data can only be handled in the way intended by the owners of the data" which is a different concept to me.

Cheers Detlev

Hi Mike,

On Wednesday 24 June 2009 12:45:38 Detlev Zundel wrote:

...

...

It is secure because only authenticated code is allowed to be executed, thus another step to avoid piracy, hacking of conditional access systems etc.

Running only authenticated code does *not* ensure security, no matter how much this is wished for.

But no matter, I now understand that "security" seems to mean "data can only be handled in the way intended by the owners of the data" which is a different concept to me.

you ignored my simple straightforward example where both authenticity and security is provided. cpu only loads signed u-boot -- authenticity. u-boot only loads encrypted signed binaries -- security and authenticity. since the binaries stay inside of the CPU, for all practical (and then some) purposes, the decrypted binary will never be discovered from this system.

Obviously we differ in what "security" means. Where I used security as an attribute of a communications channel which seems to be a popular interpretation in computer science, you interpret "security" to mean "not discoverable from outside the device". The latter interpretation is used in the DRM systems trying to rub off the good annotations of "security" onto those systems - but still it is not synonymous to "security" for me.

So by definition, an authenticated, encrypted (and non-discoverable binary) can still use non-secure communications channels. Those things are orthogonal and actually I do not know why we argue about that anyway because it is beside the point of this thread.

and unless you're lumping data and code together under the term "data", that part is also incorrect.

Code is data for sure. Using higher level languages like e.g. Lisp, this should be extremely clear.

Cheers Detlev

Hi Mike,

you really should use the standard terms of the trade then, otherwise you will just keep confusing people.

I will not bother discussing this anymore with you but rather leave it up to the reader to decide on who is confusing.

Cheers Detlev

Richard,

Richard Stallman wrote:

Embedded systems using core soc silicon from a number of manufacturers
have started to use what is known as 'secure boot'. This is typically the
case in applications which utilise conditional access system software to
protect content. The emphasis on using secure boot is largely driven by
the conditional access industry itself.

The principal purpose of these products is to restrict the public's freedom. So it is natural that their means involve restricting our freedom too.

You are right in many cases, but on the other hand especially in the embedded market there are lots of systems which should definitivly NOT boot every code provided. Just some examples:

- automotive control units: Think about cars being on the highway with many fancy features built into their electronics (from their owners), which unfortunately are a security risk for the owner and others on the road. If a major accident is caused by modified car control software, who will be sued in the first run? The owner (already dead?)? Or the car manufacturer who made the system open to changes from everyone?

- medical equipment: Think what nice features could be implemented into these many machines located in the emergency room... Accessible to any person who comes by.

My personal believe is that there are many examples of embedded systems, that should only execute software that has been carefully tested.

And I don't like the idea to see this area as non-compatible with free software like U-Boot, Linux and others.

wkr,

Thomas.

In DefectiveByDesign.org we organize protests against such devices. They don't deserve help.

In this context, I believe both terms are interchangeable and effectively
mean the same thing. It is secure because only authenticated code is
allowed to be executed, thus another step to avoid piracy, 

If that is meant to refer to sharing of copies of published works, please don't call that "piracy". That is a propaganda term which is used to spread the assumption that sharing is bad. See http://www.gnu.org/philosophy/words-to-avoid.html. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

On Thursday 25 June 2009 19:29:26 Richard Stallman wrote:

- automotive control units: Think about cars being on the highway with
many fancy features built into their electronics (from their owners),
which unfortunately are a security risk for the owner and others on the
road.

I don't think cars depend on software for safety as such. If a computer breaks down, the engine mail run badly -- but if you run out of gas, it might stop entirely. You can still steer the car.

If someday cars do have computers whose proper functioning is necessary for safety, we could use airplanes as a policy example. If you own a small plane, you are free to change it, but you need to get the change inspectied for airworthiness.

this is pure wishful thinking. people personally modifying software in their car are not going to go get it recertified.

- medical equipment: Think what nice features could be implemented into
these many machines located in the emergency room... Accessible to any
person who comes by.

Being free to change your copy of a program does not mean you must let anyone and everyone change your copy. For instance, the code on my netbook is all free software, but it is not generally accessible to anyone but me.

none of your scenarios are applicable to the issues Thomas raised. public safety is significantly more important than a handful of hackers here. i'm not going to knowingly subject myself to a medical device that emits radiation (e.g. x-ray machine) that allows anyone to modify it. that sucker had better be locked down to prevent any uncertified (e.g. signed) software modifications. companies that have access to the hardware capabilities to prevent this (i.e. secure boot) and dont implement it are blatantly negligent. -mike

Richard,

Richard Stallman wrote:

- automotive control units: Think about cars being on the highway with
many fancy features built into their electronics (from their owners),
which unfortunately are a security risk for the owner and others on the
road.

I don't think cars depend on software for safety as such. If a computer breaks down, the engine mail run badly -- but if you run out of gas, it might stop entirely. You can still steer the car.

You are only concentrating on the motor control. I am not sure about the technical skill of the American automotive industry (grin, grin), but at least in Europe SOME cars already have some safety functions based on computer systems for good reason.

If someday cars do have computers whose proper functioning is necessary for safety, we could use airplanes as a policy example. If you own a small plane, you are free to change it, but you need to get the change inspectied for airworthiness.

Right. The car owner must. But what happens if he doesn't? After a major accident, will the lawyers really sue the car owner? Or the company who let the car owner tinker around in the ECU?

Keep in mind that for most car owners, it is much easier to understand the safety aspects of a mechanical modification of the car than all safety aspects of a SW modification.

- medical equipment: Think what nice features could be implemented into
these many machines located in the emergency room... Accessible to any
person who comes by.

Being free to change your copy of a program does not mean you must let anyone and everyone change your copy. For instance, the code on my netbook is all free software, but it is not generally accessible to anyone but me.

Just out of curiousity: Which percentage of that SW is already GPLv3?

wkr, Thomas.

On Thu, 25 Jun 2009, Mike Frysinger wrote:

On Wednesday 24 June 2009 20:59:11 Richard Stallman wrote:

...

Embedded systems using core soc silicon from a number of

manufacturers

...

have started to use what is known as 'secure boot'. This is

typically

...

the case in applications which utilise conditional access system

software

...

to protect content. The emphasis on using secure boot is largely

driven by

...

the conditional access industry itself.

The principal purpose of these products is to restrict the public's freedom. So it is natural that their means involve restricting our freedom too.

it sure is nice to make generalities as it makes your resulting argument so much easier to digest. the companies ive worked with could give two sh*ts about end customers tinkering with their products. they're interested in keeping their product secure from other people in their respective industry and from malicious tampering for regulation/safety purposes.

I would like to add that sometimes regulations EXPLICITELY require secure boot. No product can be approved without it. And this does not have anything to do with public's freedom. Just one example is gambling industry which I happen to work right now. Nobody cares about cloning or public's freedom here. What they care about is that nobody can cheat on those nice shiny machines that sometimes let a lucky person to win a multimillion jackpot.

--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

On Thu, 25 Jun 2009, Jean-Christian de Rivaz wrote:

ksi@koi8.net a ?crit :

...

On Thu, 25 Jun 2009, Mike Frysinger wrote:

...

On Wednesday 24 June 2009 20:59:11 Richard Stallman wrote:

...

The principal purpose of these products is to restrict the

public's

...

...

...

freedom. So it is natural that their means involve restricting

our

...

...

...

freedom too.

it sure is nice to make generalities as it makes your resulting

argument

...

...

so much easier to digest. the companies ive worked with could give

two

...

...

sh*ts about end customers tinkering with their products. they're interested in keeping their product secure from other people in their

respective

...

...

industry and from malicious tampering for regulation/safety

purposes.

...

I would like to add that sometimes regulations EXPLICITELY require

secure

...

boot. No product can be approved without it. And this does not have

anything

...

to do with public's freedom. Just one example is gambling industry

which I

...

happen to work right now. Nobody cares about cloning or public's

freedom

...

here. What they care about is that nobody can cheat on those nice

shiny

...

machines that sometimes let a lucky person to win a multimillion

jackpot.

Please point out precisely the regulations that require secure boot. Should be trivial as regulations are by definition public.

Do you happen to know what "Google" is?

This is our Nevada regulations:

http://gaming.nv.gov/stats_regs.htm

I failed to understand how a secure booted machine can be updated by the manufacturer to fix a bug for example, but not by a customer.

The manufacturer can _NOT_ update his machine at will. _EACH AND EVERY_ change goes through the same approval process.

And one more hint--external hackers is _NOT_ the primary concern here. The most important task is to make cheating by casino _EMPLOYEES_ as difficult as it's possible.

--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

On Thu, 25 Jun 2009, Jean-Christian de Rivaz wrote:

ksi@koi8.net a ?crit :

...

...

Please point out precisely the regulations that require secure boot. Should be trivial as regulations are by definition public.

Do you happen to know what "Google" is?

Yes, thanks :-)

For example this document have the term "secure boot": http://www.dcg.virginia.gov/supplier/sup-rules/standards.shtm The wording is this one: "D. Electronic Bingo [...] 3. [...] Security measures that may be employed to comply with these provisions include, but are not limited to the use of dongles, digital signature comparison hardware and software; secure boot loaders, encryption, and key and callback password systems."

The term "secure boot" is listed as a possibility, not as a requirement.

Now I don't have the time to parse every possible document that Google propose. This is why I politely ask a precise example, as I was under the impression that some peoples know very well this subject.

...

This is our Nevada regulations:

http://gaming.nv.gov/stats_regs.htm

I don't have the time to parse all the documents listed at this URL, but I downloaded the one I suspect is the more relevant: http://gaming.nv.gov/stats_regs/reg14_tech_stnds.pdf And I cannot found "secure boot" into it.

Are you looking for a precise phrase?

...

...

I failed to understand how a secure booted machine can be updated by

the

...

...

manufacturer to fix a bug for example, but not by a customer.

The manufacturer can _NOT_ update his machine at will. _EACH AND

EVERY_

...

change goes through the same approval process.

Still, technically the hardware have only two possibility:

1. it can be reprogrammed.
2. it can't be reprogrammed.

If 1), I dont' see how the a boot loader can't be replaced by a less secure one and let boot anything.

if 2), there is not point as nobody can possibly make any update, so the firmware don't have to be secured.

You are trying to make sense out of the regulations. It doesn't work this way. If regulations say "one must use a screwdriver with a red handle on this screw" one must use the red screwdriver. No matter if it makes sense or not. If you feel it's bullshit you should fight for the regulation to change that is a very long (years, not months) and very difficult process. In the meantime you _MUST_ use that red screwdriver.

Then you should read not only technical part but also a procedural one on how approvals are given. You must persuade the Commision to give you an approval. And they give them at their discretion. And you can NOT sue them.

Finally don't forget that your employees all want to get their salary paid and that comes from your business revenues. No approval == No business. Good luck fighting regulations.

--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

On Thu, 25 Jun 2009, Jean-Christian de Rivaz wrote:

ksi@koi8.net a ?crit :

...

On Thu, 25 Jun 2009, Jean-Christian de Rivaz wrote:

...

ksi@koi8.net a ?crit :

...

...

Please point out precisely the regulations that require secure

boot.

...

...

...

...

Should be trivial as regulations are by definition public.

Do you happen to know what "Google" is?

Yes, thanks :-)

For example this document have the term "secure boot": http://www.dcg.virginia.gov/supplier/sup-rules/standards.shtm The wording is this one: "D. Electronic Bingo [...] 3. [...] Security measures that may be employed to comply with these provisions include, but are not limited to the use of dongles,

digital

...

...

signature comparison hardware and software; secure boot loaders, encryption, and key and callback password systems."

The term "secure boot" is listed as a possibility, not as a

requirement.

...

...

Now I don't have the time to parse every possible document that

Google

...

...

propose. This is why I politely ask a precise example, as I was

under

...

...

the impression that some peoples know very well this subject.

...

This is our Nevada regulations:

http://gaming.nv.gov/stats_regs.htm

I don't have the time to parse all the documents listed at this URL,

but

...

...

I downloaded the one I suspect is the more relevant: http://gaming.nv.gov/stats_regs/reg14_tech_stnds.pdf And I cannot found "secure boot" into it.

Are you looking for a precise phrase?

I want to look deeper into the subject. I think that if a regulation make a technical point as a requirement, then it must more or less describe the technical point so that it can be implemented is a way it work as expected. As an engineer, I think that a "secure boot" is only a buzz word: if the system can be physically modified, it can't be secured. If it can't be physically modified, then you don't need a secure boot.

It is not just technical measures; it is a complex of them and different operating procedures.

When you hit a jackpot the machine should be immediately stopped (hang) in that state and nobody should touch it. Then a controller comes into the scene. He pulls all the EPROM chips from the machine and checks them with MD5 or whatever is approved and checks every single piece of programmable hardware with some procedure approved for this particular model. That would not prevent a cheating casino employee from replacing some EPROM chip (or whatever) with his own one but it will NOT allow for stuffing the original one back once the jackpot is hit so the cheating will be detected.

That's only one example...

...

...

...

...

I failed to understand how a secure booted machine can be

updated by

...

...

the

...

...

manufacturer to fix a bug for example, but not by a customer.

The manufacturer can _NOT_ update his machine at will. _EACH AND

EVERY_

...

change goes through the same approval process.

Still, technically the hardware have only two possibility:

1. it can be reprogrammed.
2. it can't be reprogrammed.

If 1), I dont' see how the a boot loader can't be replaced by a less secure one and let boot anything.

if 2), there is not point as nobody can possibly make any update, so

the

...

...

firmware don't have to be secured.

You are trying to make sense out of the regulations. It doesn't work

this

...

way. If regulations say "one must use a screwdriver with a red handle

on

...

this screw" one must use the red screwdriver. No matter if it makes

sense or

...

not. If you feel it's bullshit you should fight for the regulation to

change

...

that is a very long (years, not months) and very difficult process. In

the

...

meantime you _MUST_ use that red screwdriver.

Then you should read not only technical part but also a procedural one

on

...

how approvals are given. You must persuade the Commision to give you

an

...

approval. And they give them at their discretion. And you can NOT sue

them.

In this second part, I don't make reference to regulation. I only talk about the technical problem of reprogramming a system.

Ah, that's absolutely orthogonal issue... We do NOT do something stupid from engineering standpoint because it makes sense (and quite often it doesn't) but because the regulations and the Commission's understanding of them requires that.

Yes, many of those are stupid and outdated but they do a good job anyways; there is not that much cheating in our casinos.

...

Finally don't forget that your employees all want to get their salary

paid

...

and that comes from your business revenues. No approval == No

business. Good

...

luck fighting regulations.

Why do you think I want to fight regulation ? I actually be more concerned about understanding how a proprietary hidden piece of code into u-boot can possibly make a system satisfy a security regulation.

It is not just hardware/software. The latter is only a part of solution. It is NOT the machine that pays that jackpot, it is real humans. There is no way to make the system unbreakable and impossible to cheat on. That's why an additional layer of security is being able to DETECT that system had been cheated on.

--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

On Thu, 25 Jun 2009, Jean-Christian de Rivaz wrote:

ksi@koi8.net a ?crit :

...

...

...

...

I downloaded the one I suspect is the more relevant: http://gaming.nv.gov/stats_regs/reg14_tech_stnds.pdf And I cannot found "secure boot" into it.

Are you looking for a precise phrase?

I want to look deeper into the subject. I think that if a regulation make a technical point as a requirement, then it must more or less describe the technical point so that it can be implemented is a way

it

...

...

work as expected. As an engineer, I think that a "secure boot" is

only a

...

...

buzz word: if the system can be physically modified, it can't be secured. If it can't be physically modified, then you don't need a secure boot.

It is not just technical measures; it is a complex of them and

different

...

operating procedures.

Yes, I known that. But here we specifically talk about u-boot. You still failed to show a description of how u-boot can be modified to secure a system and why this must be a hidden proprietary code.

...

...

...

...

...

> I failed to understand how a secure booted machine can be

updated by

...

...

the

...

> manufacturer to fix a bug for example, but not by a

customer.

...

...

...

...

...

The manufacturer can _NOT_ update his machine at will. _EACH

AND

...

...

...

...

EVERY_

...

change goes through the same approval process.

Still, technically the hardware have only two possibility:

1. it can be reprogrammed.
2. it can't be reprogrammed.

If 1), I dont' see how the a boot loader can't be replaced by a

less

...

...

...

...

secure one and let boot anything.

if 2), there is not point as nobody can possibly make any

update, so

...

...

the

...

...

firmware don't have to be secured.

[...]

...

Ah, that's absolutely orthogonal issue... We do NOT do something

stupid from

...

engineering standpoint because it makes sense (and quite often it

doesn't)

...

but because the regulations and the Commission's understanding of them requires that.

Yes, many of those are stupid and outdated but they do a good job

anyways;

...

there is not that much cheating in our casinos.

You seem to agree that a "secure boot" is maybe not more that only a marketing word...

No, this does not have the same strict meaning as "#6-32x1/2" slotted head steel zinc plated machine screw." It is a set of different features. Here is e.g. a Freescale's whitepaper on one of their SoCs:

http://www.freescale.com/files/32bit/doc/white_paper/IMX31SECURITYWP.pdf

[...]

...

...

Why do you think I want to fight regulation ? I actually be more concerned about understanding how a proprietary hidden piece of code into u-boot can possibly make a system satisfy a security

regulation.

...

It is not just hardware/software. The latter is only a part of

solution. It

...

is NOT the machine that pays that jackpot, it is real humans. There is

no

...

way to make the system unbreakable and impossible to cheat on. That's

why an

...

additional layer of security is being able to DETECT that system had

been

...

cheated on.

So why using open source at all if you think that hidden code is a way to make a system more secure ? It highly not consistent !

Who is talking about hidden code? It can be open source. And quite often it is. And most of that code, BTW, is written by the people who are paid to do it. If you want to make us drop U-Boot and write our own firmware no problems, that's just additional job security for us. But don't expect all those people to do anything on U-Boot and forget about their contributions.

--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

I would like to add that sometimes regulations EXPLICITELY require secure boot. No product can be approved without it. And this does not have anything to do with public's freedom. Just one example is gambling industry which I happen to work right now.

Gambling machines for casinos are not consumer products, so GPLv3's requirement to deliver installation information does not apply to them.

I can assure you that today If we switch the V2 to the v3 we will lose a lot of customers

Are the users of U-Boot usually customers? That term normally refers to people that buy a commercial product or service.

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

I have a computer on which I can install any code I choose. I don't think that is a security flaw.

On the contrary, if only one company can install a new version, that is a grave security flaw for me as a user.

If I use a GPLv3 bootloader in a medical tool, a car, Point of payment terminal, Military System, etc... it is a grave security flaw. I'm not sure that you will be very happy if someone can modify the Firmware freely. As you may loose money to be killed and at the extrem kill millions of people.

There is no need to exaggerate. Millions of people modify cars physically, and it is not a dangerous practice.

If you buy a car, or a medical tool for my own use, you deserve to be able to change the software in it, just as you can change it physically.

The other systems that you speak of are not consumer products, so this requirement in GPLv3 does not apply to them.

I do not think the v3 is a benefit. I'll never accept the concept to an opensource licence that will force me to use a software in a specific way that someone will choose for me as do the v3. It will be freedom kill.

You seem to be worried about something you haven't described clearly. I think you're afraid of shadows, but since you have not described them clearly, I really don't know.

All I can say is that no version of the GPL was meant to be an open source license. Thinking of it in terms of "open source" will tend to be an obstacle to understanding it.

Hi Jean-Christophe,

On 00:50 Fri 26 Jun , Richard Stallman wrote:

...

If I use a GPLv3 bootloader in a medical tool, a car, Point of payment terminal,
Military System, etc... it is a grave security flaw.
I'm not sure that you will be very happy if someone can modify the Firmware
freely. As you may loose money to be killed and at the extrem kill millions
of people.

There is no need to exaggerate. Millions of people modify cars physically, and it is not a dangerous practice.

It is.

...

If you buy a car, or a medical tool for my own use, you deserve to be able to change the software in it, just as you can change it physically.

Certanly not when you use your car your are also on the public domain (road) so it your car have a system faillure you can kill yourself and kill other people. Remember that you are not allow to modify your car as your wish there is law that will forbiden you to do this in a lot' of country.

It seems that you have very strong interests on the software side, which need to be considered separately, but here you are really distorting actual reality. As this example is likely best known to everybody, I'll comment on this one - it seems currently too much work without a prospect of any gain to comment on everything.

Of course you can modify your own car. This is *not* forbidden - why do you claim such a thing? Heck you can even attach a rocket to it *as long* as you don't use the car on public streets. If you do, all you got to do is to get your modifications approved. No big deal, go to a <insert favorite car brand here> meeting and look at the cars there.

I can even build my own car from scratch and get it certified.

Although I wanted to restrict myself to cars - it's the same with planes. It is common practice for example to modify glider planes (increasing wing span for example to be more competitive today) for which the manufacturer even *does not exist* any more today. Admittedly this is some work to get it certified, but it is doable by a private person for sure, I personally know some.

Actually I can even build my own *plane* and still get it certified (this is not uncommon).

Cheers Detlev

Wouldn't it make sense to add a paragraph to the GPL, stating that a company using GPL software in their system must also provide all that documentation to their customers? Only then the SW modification can be properly done?

It is not possible for a software license to require this in general. It may be possible to require this in the case where the software is delivered with a product. For GPLv4, we could think about whether this is a good idea. But we are not yet working on a GPLv4.

Don't forget that a proper test area is also needed, which can simulate all kind of street conditions. For ABS/Airbag you may also need a crash test environment including soem sample cars to try thigns out.

Without access to these, you will not be able to prove proper system behaviour to the certification authorities.

I don't know what standards they use. If certification is hard to get, that may discourage people from changing this software. Whether that is a good or a bad outcome, I am not sure. If the certification is indeed necessary, and done reasonably, I suppose the outcome is good.

Be that as it may, it does not excuse letting manufacturers restrict the users for their own purposes.

So once again I think GPLv3 for U-Boot would avoid using it in many possible applications, which would be a loss for the project and its users.

It is important for free software users to remember that they are giving the users something, not vice versa. If people use U-Boot, that is their gain; if they don't use it, that is their loss.

During my work on GCC and other programs, companies often asked me to weaken the license and in exchange we would get "more use" of the program. I respond to them, "More use of the program is just a subgoal; the main goal is to give more users freedom."

Sometimes companies say that they would put a lot of effort into improving a program if the developers change the license. But they do not necessarily contribute much if the developer caves. In effect they are asking to buy a license change on credit and won't even sign an IOU.

Detlev Zundel schrieb:

Hi Jean-Christophe,

...

On 00:50 Fri 26 Jun , Richard Stallman wrote:

...

If I use a GPLv3 bootloader in a medical tool, a car, Point of payment terminal,
Military System, etc... it is a grave security flaw.
I'm not sure that you will be very happy if someone can modify the Firmware
freely. As you may loose money to be killed and at the extrem kill millions
of people.

There is no need to exaggerate. Millions of people modify cars physically, and it is not a dangerous practice.

It is.

...

If you buy a car, or a medical tool for my own use, you deserve to be able to change the software in it, just as you can change it physically.

Certanly not when you use your car your are also on the public domain (road) so it your car have a system faillure you can kill yourself and kill other people. Remember that you are not allow to modify your car as your wish there is law that will forbiden you to do this in a lot' of country.

It seems that you have very strong interests on the software side, which need to be considered separately, but here you are really distorting actual reality. As this example is likely best known to everybody, I'll comment on this one - it seems currently too much work without a prospect of any gain to comment on everything.

Of course you can modify your own car. This is *not* forbidden - why do you claim such a thing? Heck you can even attach a rocket to it *as long* as you don't use the car on public streets. If you do, all you got to do is to get your modifications approved. No big deal, go to a <insert favorite car brand here> meeting and look at the cars there.

I can even build my own car from scratch and get it certified.

Although I wanted to restrict myself to cars - it's the same with planes. It is common practice for example to modify glider planes (increasing wing span for example to be more competitive today) for which the manufacturer even *does not exist* any more today. Admittedly this is some work to get it certified, but it is doable by a private person for sure, I personally know some.

Actually I can even build my own *plane* and still get it certified (this is not uncommon).

Cheers Detlev

On 17:35 Fri 26 Jun , Richard Stallman wrote:

> The other systems that you speak of are not consumer products, so this
> requirement in GPLv3 does not apply to them.
in a Point of payment terminal it does not apply are sure?

I am sure. Those are not consumer products. They are made for businesses only.

Wrong, as example your cell phone can be a part of the PPT, and your also have product on the market that allow you to use a PPT at home instead of just write your credit card number on a website. So your definition of consumer produts is dangerous and will not fit at all because you can not known what we can create

> You seem to be worried about something you haven't described clearly.
> I think you're afraid of shadows, but since you have not described
> them clearly, I really don't know.
as example with the v3 you force me to give you my private key that I use
to protect the product this is not acceptable

To deny the key to the user is not acceptable. It makes the software non-free, and gives the developer power over the user that nobody should have.

Certanly not, it will make the product not hackable certanly not the software non-free.

Best Regards, J.

Hi Mike,

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.

It seems so clear for you, but it isn't for me - where is this net loss for them, what exactly do they loose?

customers arent going to appear because your business is now pushing GPLv3 instead of GPLv2, but they will certainly disappear.

Why will they disappear?

Cheers Detlev

Hi Mike,

On Wednesday 24 June 2009 05:12:01 Detlev Zundel 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.

It seems so clear for you, but it isn't for me - where is this net loss for them, what exactly do they loose?

...

customers arent going to appear because your business is now pushing GPLv3 instead of GPLv2, but they will certainly disappear.

Why will they disappear?

if you want to push your agenda on your customers (i'm assuming you actually have some and arent just here for fun), that's your business.

Is it possible that you jump to conslusions here? All we - on a regular basis - do is to talk to our customers until we understand what the customer needs. Then we think about how this can or cannot be done with the help of Free Software. After all nobody is forcing anyone to use Free Software and for some customer wishes Free Software may simply be not a legal option, so what?

In this process it is common that customers have incomplete information about Free Software in general and not well-articulated fears making them jump to premature conclusions (e.g. "we need a closed source Linux kernel driver") which would prevent us from doing development for them. At this point it is extremely important to learn about the reasoning of the customer and then clearing up confusion probably leading to revisiting the question of using Free Software.

Essentially I can only remember one customer in the last years who did not go further at the time after learning that we would not develop a non-GPL kernel module. Incidentally this customer is now back on our doorstep because the market effectively forces him to use a GNU/Linux system from a feature perspective. This time around closed sources kernel modules are not even on the agenda anymore.

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. I surely do and this is what I try to understand in this thread.

I admit that I did not think this through completely, but how much of this "no one else can run things" is actually connected to the bootloader? U-Boot itself will not be handling "prime content" I guess. Those "secure boot" you talk about - what is it exactly and what are the potential attack vectors of it? Are there vectors besides the bootloader? If so, how does a "non-supporting" bootloader make the situation any worse?

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?

that's my practical standpoint from my job experience -- GPLv3 will cause a u- boot fork and the net result is not beneficial to anyone.

You must have a very good crystal ball. Maybe if my crystal ball was that good I did not need to ask questions.

my completely personal standpoint is the same -- do not use the GPLv3.

Ok, somehow this was already clear to me.

On the other hand I also do believe that for a project which is here simply because of the benefits of the GPL, we should spend some time thinking this through and then base the decision of the project on a sound basis. Handwaving arguments do not help much here, so thanks for your input.

Cheers Detlev

Hi Mike,

On Wednesday 24 June 2009 09:17:50 Detlev Zundel wrote:

...

...

if you want to push your agenda on your customers (i'm assuming you actually have some and arent just here for fun), that's your business.

Is it possible that you jump to conslusions here? All we - on a regular basis - do is to talk to our customers until we understand what the customer needs. Then we think about how this can or cannot be done with the help of Free Software. After all nobody is forcing anyone to use Free Software and for some customer wishes Free Software may simply be not a legal option, so what?

In this process it is common that customers have incomplete information about Free Software in general and not well-articulated fears making them jump to premature conclusions (e.g. "we need a closed source Linux kernel driver") which would prevent us from doing development for them. At this point it is extremely important to learn about the reasoning of the customer and then clearing up confusion probably leading to revisiting the question of using Free Software.

Essentially I can only remember one customer in the last years who did not go further at the time after learning that we would not develop a non-GPL kernel module. Incidentally this customer is now back on our doorstep because the market effectively forces him to use a GNU/Linux system from a feature perspective. This time around closed sources kernel modules are not even on the agenda anymore.

and that's your prerogative. how you choose to run your business has no bearing at all on how other people choose to run their businesses.

All I said is that we have a pretty good idea of what is legal and what isn;t and that we will not start work in an area where we belive we could actually be liable by law. How you come to the conclusion that this is "prerogative" completely escapes me. Are you sure that you are interested in what I say?

...

...

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.

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.

...

...

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.

...

On the other hand I also do believe that for a project which is here simply because of the benefits of the GPL, we should spend some time thinking this through and then base the decision of the project on a sound basis. Handwaving arguments do not help much here, so thanks for your input.

except that licensing choice is just as much practical considerations (can XYZ be done with the GPLv3) as it is personal choice. it dictates how we choose to *let* other people utilize the code.

Licensing ceases to be a personal choice when it is a community project.

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.

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.

Cheers Detlev

> 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, it is "let the device providers and the users who have *chosen* to use those devices sort it out themselves, *I'm* not restricting anyone".

More precisely stated, it's "I'm not restricting anyone, and if someone else is, I don't care." The difference here is between defending freedom and standing aside while it gets lost.

Leaving the powerful few and the weak divided many to "sort it out" is predictably likely to lead to bad results. (That is why consumer protection law exists -- because a market without regulation is dangerous. This is also why financial industry regulation exists, and if the powerful had not sabotaged it, we wouldn't have the current economic downturn.)

On Wednesday 24 June 2009 12:34:40 Detlev Zundel wrote:

...

On Wednesday 24 June 2009 09:17:50 Detlev Zundel wrote:

...

...

if you want to push your agenda on your customers (i'm assuming you actually have some and arent just here for fun), that's your business.

Is it possible that you jump to conslusions here? All we - on a regular basis - do is to talk to our customers until we understand what the customer needs. Then we think about how this can or cannot be done with the help of Free Software. After all nobody is forcing anyone to use Free Software and for some customer wishes Free Software may simply be not a legal option, so what?

In this process it is common that customers have incomplete information about Free Software in general and not well-articulated fears making them jump to premature conclusions (e.g. "we need a closed source Linux kernel driver") which would prevent us from doing development for them. At this point it is extremely important to learn about the reasoning of the customer and then clearing up confusion probably leading to revisiting the question of using Free Software.

Essentially I can only remember one customer in the last years who did not go further at the time after learning that we would not develop a non-GPL kernel module. Incidentally this customer is now back on our doorstep because the market effectively forces him to use a GNU/Linux system from a feature perspective. This time around closed sources kernel modules are not even on the agenda anymore.

and that's your prerogative. how you choose to run your business has no bearing at all on how other people choose to run their businesses.

All I said is that we have a pretty good idea of what is legal and what isn;t and that we will not start work in an area where we belive we could actually be liable by law. How you come to the conclusion that this is "prerogative" completely escapes me. Are you sure that you are interested in what I say?

i think you are interpreting the word incorrectly. it is your prerogative -- your right -- to run your business however you want.

...

...

...

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

...

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. if the GNU project wants people to use the GPLv3 and people have a perception of it being crap, then it's their problem to address it.

...

...

...

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.

...

...

On the other hand I also do believe that for a project which is here simply because of the benefits of the GPL, we should spend some time thinking this through and then base the decision of the project on a sound basis. Handwaving arguments do not help much here, so thanks for your input.

except that licensing choice is just as much practical considerations (can XYZ be done with the GPLv3) as it is personal choice. it dictates how we choose to *let* other people utilize the code.

Licensing ceases to be a personal choice when it is a community project.

that is plain wrong. it is always a personal choice and by advocating it in a community setting, you're pushing your personal choices on others. i want to stay with the GPL-2 -- i am pushing my personal preference on others. you want to move to the GPL-3 -- you are pushing your personal preference on others.

...

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. 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. if people take my work i give away freely and "massively restrict the rest", then i dont have a problem with that. -mike

On Thursday 25 June 2009 07:04:07 Detlev Zundel wrote:

...

...

...

...

...

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.

whether you question this attitude doesnt matter. you arent a lawyer in general, you arent a lawyer for these companies, and you arent indemnifying them. their legal review says that it's a requirement, so it is now a requirement for the software. anything beyond that is irrelevant.

...

...

...

...

...

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 dont know what kind of "facts" you're looking for. i didnt make this scenario up, it was described to me by a customer in the US and their experience with Chinese cloners. i'm not going to give customer information or name names if that's what you want. -mike

On Thursday 25 June 2009 10:20:47 Detlev Zundel wrote:

...

...

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

i dont know what kind of "facts" you're looking for. i didnt make this scenario up, it was described to me by a customer in the US and their experience with Chinese cloners. i'm not going to give customer information or name names if that's what you want.

Well, the problem with "facts" is that I like them to be backed up. I don't know whether I should believe this mantra until I have seen actual products and/or figures. If you don't need this - fine, your choice.

well g'luck with that. you're going to have to find a customer yourself or find someone who *hasnt* signed a NDA. -mike

On Friday 26 June 2009 04:25:42 Detlev Zundel wrote:

...

On Thursday 25 June 2009 10:20:47 Detlev Zundel wrote:

...

...

...

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

i dont know what kind of "facts" you're looking for. i didnt make this scenario up, it was described to me by a customer in the US and their experience with Chinese cloners. i'm not going to give customer information or name names if that's what you want.

Well, the problem with "facts" is that I like them to be backed up. I don't know whether I should believe this mantra until I have seen actual products and/or figures. If you don't need this - fine, your choice.

well g'luck with that. you're going to have to find a customer yourself or find someone who *hasnt* signed a NDA.

... n ) Proof by intimidation n+1) Proof by vigorous handwaving n+2) Proof by obfuscation n+3) Proof by wishful citation n+4) Proof by vehement assertion n+5) Proof not available without NDA

Now, wait a minute, I think we have an original new entry here to this list ;)

basically you're making the assertion that (1) i just made all of this sh*t up, (2) i'm basically a liar, and (3) i must be making these claims because i think this discussion is "fun". rather than providing funny little lists, why dont you come straight out and call someone a filthy liar. frankly, you can kiss my ass.

i attempted to provide real world experience with the information i'm allowed, and apparently that wasnt "good enough" for you, how convenient for your little crusade to control the usage of others. -mike

On Friday 26 June 2009 09:56:21 Detlev Zundel wrote:

...

On Friday 26 June 2009 04:25:42 Detlev Zundel wrote:

...

...

On Thursday 25 June 2009 10:20:47 Detlev Zundel wrote:

...

...

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

i dont know what kind of "facts" you're looking for. i didnt make this scenario up, it was described to me by a customer in the US and their experience with Chinese cloners. i'm not going to give customer information or name names if that's what you want.

Well, the problem with "facts" is that I like them to be backed up. I don't know whether I should believe this mantra until I have seen actual products and/or figures. If you don't need this - fine, your choice.

well g'luck with that. you're going to have to find a customer yourself or find someone who *hasnt* signed a NDA.

... n ) Proof by intimidation n+1) Proof by vigorous handwaving n+2) Proof by obfuscation n+3) Proof by wishful citation n+4) Proof by vehement assertion n+5) Proof not available without NDA

Now, wait a minute, I think we have an original new entry here to this list ;)

basically you're making the assertion that (1) i just made all of this sh*t up, (2) i'm basically a liar, and (3) i must be making these claims because i think this discussion is "fun". rather than providing funny little lists, why dont you come straight out and call someone a filthy liar.

I am not repsonsible for what you read into my mails. I never made such assertions.

Jon Stewart summed up this position fairly well with an example. I'm not saying your mother is a whore.....I'm just saying, isnt it interesting that she has money. And I dont know what she does during the day. -mike

On Friday 26 June 2009 11:11:06 Detlev Zundel wrote:

Mike Frysinger vapier@gentoo.org writes:

...

Jon Stewart summed up this position fairly well with an example. I'm not saying your mother is a whore.....I'm just saying, isnt it interesting that she has money. And I dont know what she does during the day.

You are disqualifying yourself here. Go on if you like, I will not join you on this level anymore.

i'm pretty sure you missed the point completely. review the structure, not the content. -mike

On Thursday 25 June 2009 10:41:13 Detlev Zundel wrote:

...

...

...

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

whether you question this attitude doesnt matter. you arent a lawyer in general, you arent a lawyer for these companies, and you arent indemnifying them. their legal review says that it's a requirement, so it is now a requirement for the software. anything beyond that is irrelevant.

Now was this so hard? This is actually an important fact that it is a legal requirement for a company - thanks.

As a quick web research did not help, if this is a legal requirement, then can you point me to the law which requires such a thing?

nothing personal, but ...

(1) you still arent a lawyer (2) i never said there was a law that stated this (3) i did say "their legal team came to the conclusion that ..."

the law and your interpretation of it is irrelevant. customers are viewing this as a requirement and thus it's the same thing. if you think there is an image problem, then feel free to assist the GNU project in an "awareness" campaign. i work in the practical realm. -mike

On Friday 26 June 2009 04:21:15 Detlev Zundel wrote:

...

On Thursday 25 June 2009 10:41:13 Detlev Zundel wrote:

...

...

...

...

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

whether you question this attitude doesnt matter. you arent a lawyer in general, you arent a lawyer for these companies, and you arent indemnifying them. their legal review says that it's a requirement, so it is now a requirement for the software. anything beyond that is irrelevant.

Now was this so hard? This is actually an important fact that it is a legal requirement for a company - thanks.

As a quick web research did not help, if this is a legal requirement, then can you point me to the law which requires such a thing?

nothing personal, but ...

(1) you still arent a lawyer (2) i never said there was a law that stated this (3) i did say "their legal team came to the conclusion that ..."

the law and your interpretation of it is irrelevant.

Wow, the law is irrelevant. I give up. You repeatedly claim stuff without backing anything up. There is nothing more I can gain from this discussion, so I let it rest.

why not try keeping up with the thread instead of taking things out of context. the point of this subthread was that the software people doing the work are told to do XYZ by their legal team. thus it is a software requirement irregardless of anything else.

plus, the law in these areas is hardly ever clear. it may state one thing, and yet there are precedences that take it a different way. or the laws have no precedence at all (which is fairly typical with open source) in which case lawyers are often very conservative. after all, their screw up here could easily cost a company 6 or 7 figures if not worse penalties.

your demand of black and white conformance in a pure gray legal world is completely unrealistic. -mike

As Mike has stated - we work on many devices who's products would fall under the GPL 3's User Products category - who's manufactures have told us "No GPL3".

Would you like to describe one such product? All the product types discussed so far are outside the category of User Products. The laws you cites also seem to apply to things which are not User Products.

They have this right - the right to use the software - or the right to choose something else. They have indicated they will exercise this right - so far - I believe them.

If a company seeks to restrict users like you and me, I strongly hope my software does not help them.

Portable hand held medical devices - such as Glucometers. They fall into both categories. They are medical devices, who's "bad" software could cause a user to give them selves too much insulin (hypoglycemia -> pass out -> seizure -> death), or too little insulin (Hyperglycaemia -> stupor -> coma -> death).

That would be a good reason for the user not to change the software in this device. However, that does not mean he should be stopped.

After all, the user could also change the circuitry in the device, if he is inclined to do so. That too could make it give bad readings. So what? We do not need a nanny state stopping people from going out of their way to take risks. Warning them is enough.

They are marketted, and purchased by end consumers (Amazon shows 115 results in their search), and I would think that would make them fall into the "User Products".

These are indeed User Products, and the user who buys them should have control over what they do.

I hope that you can respect my choice - and not try to convince me or others that your choices are superior to mine.

If your mind is made up, I will not pointlessly annoy you by trying to convince you. I will continue trying to convince others.

In 1983, almost everyone thought my ideas were foolish, but I did not let that stop me, so now we have the GNU/Linux operating system.

> That would be a good reason for the user not to change the software in > this device. However, that does not mean he should be stopped.

The FDA disagrees :)

Governments often oppose people's freedom. That is why fighting for freedom is hard.

They add requirements to ensure they detect faulty devices. It is a fact of physics that flash devices go bad over time - I'm sure even you appreciate the ability to know if something in your devices is the image that you thought it is, and doesn't have bit errors.

That sounds like a good feature. But if it is done in a way that permits the manufacturer to change the software after sale, then it can be done in a way that permits the owner to change the software too.

All the "circuitry" are integrated circuits. There are very few (none) external components to modify. Test strips are connected directly to the measurement IC, and the measurement IC is connected directly the the processor.

I did not know that. Thank you for the information.

While I probably would not want to change my glucometer, the practice of designing hardware so that people cannot change it is becoming more and more of a threat to our freedom in general.

If a product is required to be locked down by a certifying authority, (whom ever that may be), they can't use GPL3 code.

If the users' freedom is protected by GPLv3, the certifying authority that attacks users' freedom blocks the use of this code.

While I recognize that developers who get in the middle of this battle did not cause the battle, I will not surrender the fight just for their sake.

This really has nothing to do with tivoization, since in the Tivo case - they had no greater certification authority - and were just trying to restrict people's use.

These companies (if I understand the facts correctly from what people have said here) are doing the same thing to the user that tivo does, so it is equally wrong. The wrong is not in their motive, it is in what they do.

Suppose there were an official certification authority for video players. (Hollywood could probably buy such a law if it wanted to; Obama would be glad to sign it.) Would that make the tivo ok? Obviously not.

Thus, the existence of a certification authority does not alter the concluisions about the ethical issue of tivoization.

I support effective steps to protect safety for the users of medical devices. But, as I've explained above, that does not require tivoization, so it does not excuse tivoization either.

I can't see how someone can deny access to the network, while still allowing anyone's software to be run on the device, without some sort of key system in the networking hardware - is that what you had in mind?

This is aimed at cell phone networks: it recognizes they are allowed to make the network refuse to talk to a phone if the users's changes cause the phone to screw up the network.

Graeme Russ wrote:

On Wed, Jul 1, 2009 at 9:46 PM, Richard Stallmanrms@gnu.org wrote:

...

I can't see how someone can deny access to the network, while still allowing anyone's software to be run on the device, without some sort of key system in the networking hardware - is that what you had in mind?

This is aimed at cell phone networks: it recognizes they are allowed to make the network refuse to talk to a phone if the users's changes cause the phone to screw up the network.

Interesting, you allow the hardware & software designer to apply restrictions on the end user because their changes could 'screw up a network' but do not believe that the same restrictions apply when the changes could 'kill the user'

The network restriction makes an explicit distinction at an ownership boundary.

The network statement quoted by Robin is:

From the GPL3:

...

...

Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

Note that the network is owned by the service provider, *not* the end user. The end user is free to modify his gadget to his heart's content, but the service provider is *also* free to disallow that modified gadget from interacting with his (the service provider's) network. In other words, the modification permissiveness boundary matches the ownership boundary.

Mapping this concept to the gaming world, I would say that gaming machine owners should be allowed the freedom to modify a gaming machine, but the casino (governmental regulatory agency) would also be free to disallow paying out any winnings to that machine. Public access to the modified machine should not be allowed because that crosses the ownership boundary. IOW, if *you* game the machine, *you* can play to *your* heart's content, but but the gaming (in both senses) is bounded at the machine's boundary and the ownership boundary.

Mapping this to the medical world, you should be free to modify the firmware in medical devices 1) that you own and 2) are only used by yourself, as owner. Beyond that, there are already enough disclaimers that adding another disclaimer "if you rewrite this firmware, you could kill yourself" would be simple to add. Percentage-wise, it would probably add 1% to the pages of disclaimers already present.

There are already innumerable ways of harming (many ways fatally) oneself with medicines and medical equipment and these are already (theoretically) exhaustively listed. When I pick up a subscription from a pharmacy, I am forced to wait for the pharmacist to make sure I "understand" the pages of how I could do myself great bodily harm and *literally* sign a document that I was instructed in the dangers. Add a firmware modification disclaimer and you are all set... theoretically.

The classic warning sticker example is stepladders: http://www.michigan.gov/documents/cis_wsh_cet0403_103227_7.pdf Note that there is no interlock to prevent you from using the stepladder as a straight ladder or from using it on uneven slopes. <tongueincheek> Stepladder safety interlocks could be created - just think how much the world would save in emergency room costs if we eradicated stepladder injuries. </tongueincheek>

A related classic: http://1.bp.blogspot.com/_XEQbaTzjzsw/SGDiFJSSyyI/AAAAAAAAB5o/0NbNlsZI_5o/s320/unsafe+ladder+on+truck.jpg

[snip]

Best regards, gvb

Robin Getz sez,

This is in no way trying to interperate the GPL3 for others (that is for lawyers to do) - but just a question from an interested developer - to me - it seems like tivo all over again. All Tivo needs to do is just make the network a piece of their application - and they have an out...

I have an example using gambling machines. Say I have a friend Don Drakulich who runs a small peep show empire and has bought a five hundred slot machines from a defunct Los Vegas Casino. Don Drakulich thinks of himself as and honest businessman, meaning he has free and clear title to these machines having bought them at an auction. And why he plans on repurposing them as adult video peep show consoles.

They're perfect being based on slightly modified open source dev board running Linux. But however they have 'secure boot' so he can't modify the software so that they can legally be used in his peep show booths.

But then again because his software developer has contacts with a board assembly house, he is able to get the secure boot processors replaced at a mere cost of $20 per unit or $10,000 for the lot. No big deal.

So it sounds to me that secure boot has merely annoyed honset guys like Don. And not even slowed down the Serbian Mafia because they have a couple of their software guys working for a slot machine manufacturer.

But you're made it hard for someone who casually comes into possession of a slot machine to re-purpose it as say a video jukebox.

Also if anyone is still reading at this point I'll say this having worked on industrial controls that can both kill people or cause expensive damage to machines, equipment and product. The general trend is that the safety monitoring system must be separate from the command and control system.

IE, the PLC can try to turn on the $100,000 vacuum pump when the oil level is too low, but the safety interlock won't let the pump turn on. That's the world I come out of and it's why I find all of the GPL-V3 will negative impact product safety arguements lacking. And why I can assure you that none of the people involved in those industries care about the GPL.

And I'll say this, if you are primarily relying on a piece of software to prevent injury or death you really need to rethink what you are doing. For a good example of what can happen one can view this US Chemical Safety Board report on a accident that occurred at at facility involving controls that I personally worked on.

http://www.chemsafety.gov/investigations/detail.aspx?SID=30

Matt Harper. Tehama Wireless.

On Thu 2 Jul 2009 09:56, Richard Stallman pondered:

> Access to a network may be denied when the modification itself
> materially and adversely affects the operation of the network
> or violates the rules and protocols for communication across
> the network. 

The way I read that is that it is the unit you are on will have it's
radio off,

I think you have misinterpreted those words. Denying a user or a machine access to a network means cutting off communication in the network, not altering the machine.

If the cell phone operator's "rule" says that operating of a modified device should not effect non-modified devices in close proximity (jamming - which I think meets the "materially and adversely affects the operation of the network" statement) - in a TDMA network (like GSM is) - the only way to enforce that rule - is on the client side - not on the network side. There is nothing on the network side you can do to stop that that I'm aware of.

I'm aware that most devices today separate the datapump and the application processor, but this doesn't seem to be the trend - the trend is run both on the same CPU (as it decreases the cost).

This clause is not an exception to the requirement for installation information. Cell phones must offer installation information just like other User Products.

Right - but the cell phone provider should have the ability to alter the state of the device (not allow the radio to be turned on), so it can't "adversely affects the operation of the network" - shouldn't they?

Or is this where one person's freedom (the ability to modify their phone, and turn it into a jamming device), is more important than the freedom of everyone else to actually use their phones on the same network. (Which actually - wouldn't be a completely bad idea - when I have been standing near someone talking too loud into their phone in a public place, I often wish for a jam the network app on my phone :)

On Thu 2 Jul 2009 12:11, Larry Johnson pondered:

In the United States, most radio transmitters must be type accepted (certified) by the Federal Communications Commission. Modification voids the type acceptance, so operating a modified mobile phone on its original frequencies would be illegal regardless of what the phone company's rules say. However, no certification is necessary for transmitters operated according to the rules for the Amateur Radio Service. Thus, an licensed amateur could legally use a modified mobile phone, provided it transmitted on frequencies allocated for amateur radio and met the other requirements for amateur operation, including not causing harmful interference to other services.

Assuming that the _licensed_ amateur could modify the phone enough that it _could_ operate on frequencies allocated for amateur use.

The only thing that would be potentially close is a European GSM phone:

Rx Tx E-GSM-900 880.0–915.0 925.0–960.0 MHz R-GSM-900 876.0–915.0 921.0–960.0 MHz T-GSM-900 870.4–876.0 915.4–921.0 MHz

& the US amateur band at 902 - 928 MHz.

I don't think any of the CDMA phones are close enough to the amateur bands to have a hope of working - but I'm not as familiar with CDMA as GSM.

Robin Getz a écrit :

On Thu 2 Jul 2009 09:56, Richard Stallman pondered:

...

This clause is not an exception to the requirement for installation information. Cell phones must offer installation information just like other User Products.

Right - but the cell phone provider should have the ability to alter the state of the device (not allow the radio to be turned on), so it can't "adversely affects the operation of the network" - shouldn't they?

Or is this where one person's freedom (the ability to modify their phone, and turn it into a jamming device), is more important than the freedom of everyone else to actually use their phones on the same network. (Which actually - wouldn't be a completely bad idea - when I have been standing near someone talking too loud into their phone in a public place, I often wish for a jam the network app on my phone :)

An operator can only deny the access to his network. It can't *legaly* modify the user device without the user agreement. A user is *technically* free to modify a device to do what he want. But it can't *legaly* emit a signal not in conformance to the relevant regulations. There is a lot of them in the case of the a GSM/3G device: http://www.3gpp.mobi/specifications

Jean-Christian de Rivaz

Richard,

Richard Stallman wrote:

While I probably would not want to change my glucometer, the practice of designing hardware so that people cannot change it is becoming more and more of a threat to our freedom in general.

Can you be a bit more specific on this? Which devices are you aware of, that use GPLv2 code and avoid an update? Except the once we were discussing here where it is questionable wheter the user actual should refrain from doing so, like medical devices and safety critical devices?

We heard about Tivo, but what other devices are there? Or are we talking about a possibility which has already outworn itself (like DRM media, which seem to be getting more and more unpolular)?

wkr, Thomas.

On Thu, Jul 2, 2009 at 9:56 AM, Richard Stallmanrms@gnu.org wrote:

about a possibility which has already outworn itself (like DRM media,    which seem to be getting more and more unpolular)?

I wish we could regard DRM as a fading threat.  In music we see a retreat from DRM, but in e-books the threat is increasing.

I hope that our campaign against DRM is succeeding in building opposition.  See DefectiveByDesign.org if you want to participate.

You'd make me happy if I was able to access cable TV signals I have paid for without DRM. I can't stand having to rent cable boxes everywhere for the sole purpose of decoding DRM that I don't want.

---

U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

You'd make me happy if I was able to access cable TV signals I have paid for without DRM.

I think it is not quite correct to call cable scrambling DRM. DRM restricts the use of data you have a copy of. Cable scrambling prevents you from getting the data if you do not pay for the descrambler; however, as far as I know, once you do have the descrambler, and do get the data, it does not seriously impede your use of the data.

So this is more akin to buying a copy than to DRM. When I speak of abolishing DRM, it doesn't include this.

With the advent of CI+ for DVB (the european-originated version of digital TV meanwhile used in several parts of the world), the cable operators have the possibility to only allow descrambling by CI+ capable receivers/descrambling modules. However, to be CI+ compliant, all receivers and descrambling modules have to be certified and have to authenticate against each other to prevent CI+-compliant operation if this authentication fails.

Cable decoders as such are not DRM, but CI+ is DRM.

Products designed to meet this specification are an attack on people's freedom. Making these products is inexcusable. People should protest them, not buy them.

Needless to mention that you have to prove secure boot to get CI+ certification (and thus a valid certificate).

There's much more to this, but I hope you get the idea.

I get the idea: the plan is simply evil. It is designed to subjugate users. The reason for the installation info requirements in GPLv3 is so that our software cannot be used for this.

Governments which have passed such laws are the enemies of their citizens. Fighting back against the companies which make these products is the first step for the citizens to reconquer their own countries. DRM systems like this ought to be illegal.

On Fri, Jul 03, 2009 at 09:47:20AM -0400, Richard Stallman wrote:

You'd make me happy if I was able to access cable TV signals I have
paid for without DRM.

I think it is not quite correct to call cable scrambling DRM. DRM restricts the use of data you have a copy of. Cable scrambling prevents you from getting the data if you do not pay for the descrambler; however, as far as I know, once you do have the descrambler, and do get the data, it does not seriously impede your use of the data.

It requires that I use a specific tuner, whereas unscrambled channels allow me to use any tuner (including one built into the TV, VCR, DVR, etc). Often this tuner must be rented from the cable company on a per-TV basis, in addition to the cost of subscribing to the channels -- and channel changing from a DVR must happen via a sluggish and sometimes error-prone infrared interface.

It's not as bad as full DRM, sure, but it's more annoying than if they'd just filtered out the unsubscribed channels.

-Scott

On Tue 30 Jun 2009 15:12, Richard Stallman pondered:

That is great - and I applaud your efforts. I think that the work
you are doing is valuable, and the contributions you have made have
been critically important to the free and closed software developments
that people to today. 

If you mean that my work has contrubuted to non-free software developments, I am not proud of that. It is not a good thing that people develop or use non-free software.

Not to go down a rat hole - but as a normal part of development of non-free software, people use emacs, gcc, and gdb all the time - you aren't proud of the contributions you made to those projects?

I was trying to say that your efforts have changed the face of computing in general, in both that it has created the "free" and "non-free" software software categories, and helped inform users of their freedoms they should be expecting.

To use someone else's words - an IDC 2006 study "Open Source in Global Software: Market Impact, Disruption, and Business Models" described free software and open source as "the most significant all-encompassing and long-term trend that the software industry has seen since the early 1980s" and found that over 70 percent of all developers are leveraging open-source and free software.

In any movement - there needs to be the golden standard - that is unwavering in its ethics and standards. Not everyone likes that standard - but it needs to be there.

On Wed 1 Jul 2009 07:45, Richard Stallman pondered:

Not to go down a rat hole - but as a normal part of development of
non-free software, people use emacs, gcc, and gdb all the time - 
you aren't proud of the contributions you made to those projects?

Yes, I am, but not because they help proprietary software.

http://www.fsf.org/licensing/licenses/gpl-faq.html#CanIUseGPLToolsForNF

As it happens, Bison can also be used to develop non-free programs. This is because we decided to explicitly permit the use of the Bison standard parser program in Bison output files without restriction. We made the decision because there were other tools comparable to Bison which already permitted use for non-free programs.

If you aren't happy that they help proprietary software - why not change the license to make it so? You recently had the chance to do that with the gcc runtime libraries - but you (or the FSF/GCC steering committee) also decided not to.

http://www.fsf.org/licensing/licenses/gcc-exception-faq.html

However, the FSF decided long ago to allow developers to use GCC's libraries to compile any program, regardless of its license.

[snip]

We decided to permit this because forbidding it seemed likely to backfire, and because using small libraries to limit the use of GCC seemed like the tail wagging the dog.

I don't understand the how on one hand there is the "uncompromising attitude on ethical issues" (at least according to wikipedia) - but the FSF decides the practical considerations for other projects - "the tail wagging the dog".

How is the certification authority issue - whether is is a cell carrier (which the GPL3 says is an acceptable certification authority) and the FDA (which the GPL3 does not say is acceptable) determine when something is the tail or the dog?

I just don't understand the difference?

-Robin

Maybe you should be working with these types of certification authorities, rather than individual developers?

I would be glad to do so. I have no contacts in the FDA, and I am not so famous that mere mention of my name would make them pay attention. But maybe some of these developers could introduce me to someone useful to talk with. If you know them, would you like to try?

I'm sure that you could get a meeting with Ms Hamburg or Aneesh Chopra before I could

Who are they? Can you tell me how to contact them?

http://www.fda.gov/AboutFDA/CommissionersPage/default.htm

I will send mail to fetch that page.

If I see any chance of discussing this with them, I will at that point want to read the relevant certifications so that I can speak with them fully briefed.

Aneesh Chopra was Virginia s Fourth Secretary of Technology, and has recently been sworn in as the Federal CTO.

I doubt I could get an appointment with such a high-ranked "public servant" without help from a high-ranked public master (businessman). But we can try.

On Thursday 25 June 2009 19:29:47 Richard Stallman wrote:

  if the GNU project wants people to use the GPLv3 and people have
a perception of it being crap, then it's their problem to address
it.

I don't think there is much danger of that. Many software packages use GPLv3 and are appreciated by many users.

But there is a deeper point to make. The substance of what we do is our own responsibility, but others' "perception" of it is more directly their responsibility than ours. When we face an ethical issue, we should think about what is right and then do it. We should not back down merely because of disparagement from those who disagree.

then i guess since u-boot is already doing what is right, this thread is a big waste of time -mike

On Saturday 27 June 2009 16:07:36 Richard Stallman wrote:

then i guess since u-boot is already doing what is right, this thread
is a big waste of time

I hope the main developers of U-Boot will conclude that it is right to move to GPLv3.

guess that depends on what you're defining as "main developers". if you look at the statistics of people who are actually doing the majority of the work, many have chimed in that they do not wish to move to the GPL-3. if your assumption is that the "noisy" people in this thread arent doing any real work wrt u-boot contributions, you're sorely mistaken. -mike

On Wednesday 24 June 2009 20:59:47 Richard Stallman wrote:

  their response is simply "fine, we'll move on to the next=
=20
guy who will satisfy our requirements".

When people offer to use my programs if I relax the license requirements, my respose to them is, "If you don't use my software, that's your loss."

feel free to go write your own bootloader then. or improve grub2 such that it can actually compete with u-boot. then you may make these statements all you like. -mike

On Thu, Jun 25, 2009 at 12:48:12PM -0400, Chris Morgan wrote:

These kind of snide comments don't address the point and it really bugs me, just like the typical political response of "if you don't like 'x' then move to another country".

Actually, it's more like repeatedly telling a telemarketer, "Sorry, I'm not interested."

-Scott

On Wed, Jun 24, 2009 at 11:09:49AM +0200, Detlev Zundel wrote:

...

nand_ecc.c is an exception, which not only has the "or later" language but also has an exception that makes it non-viral.

Why do you refer to one of the most important aspects of the effectiveness of the GPL as being viral? GPLd software neither attacks nor infects software so the wording is actively misleading.

I was referring to the "if you link me in, the entire project must be under my terms" clause. I refer to it as viral because that is the typical terminology for this sort of license -- so named because it can lead to software being licensed under GPL that otherwise wouldn't have been just so it can be combined with existing GPL software, and then yet more software licenses under GPL so it can link with *that* software (now devoid of the original code whose author explicitly chose GPL), etc.

Whether it is a good thing is a matter of personal opinion, which I was trying to keep out of that e-mail.

Looks like I failed. :-)

...

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.

Actually I want to understand why people fear to "loose business" with GPLv3. What is the exact scenario that is so threatening? Unless this is understood, it is hard to argue in any way.

U-boot contributor A wants to sell hardware to customer B, who wants secure boot, or for any other reason does not want to involve themselves in GPL3. I'm not going to provide names, but this is not hypothetical. If nobody wanted to do the things that GPLv3 prevents, there wouldn't be a GPLv3. :-)

U-boot goes GPLv3. A has a choice to continue developing on mainline u-boot, in which case one of these happens:

1. A develops *another* bootloader in parallel (possibly based on old GPLv2 u-boot) for customer B, 2. B develops (or acquires) their own firmware, or 3. B buys hardware from someone else who provides non-GPL3 firmware.

#2 seems unlikely if #3 is a reasonable option -- and if A is going to do #1, why wouldn't they develop *only* that non-GPL3 firmware if it is a superset of usefulness to A (who doesn't particularly care about the GPL3 agenda)? In other words, a fork.

-Scott

Hi Jon,

There is an enormous practical consideration stopping the licensing change. u-boot has not required copyright assignment. This means that every single person that has contributed code to u-boot needs to give their permission for the change.

This is not correct. People who wrote code under "GPLv2 or later" licenses would not need to be queried. The project could use the sources under a later version.

Cheers Detlev

Hi Jon,

On Wed, Jun 24, 2009 at 12:56 PM, Detlev Zundeldzu@denx.de wrote:

...

Hi Jon,

...

There is an enormous practical consideration stopping the licensing change. u-boot has not required copyright assignment. This means that every single person that has contributed code to u-boot needs to give their permission for the change.

This is not correct.  People who wrote code under "GPLv2 or later" licenses would not need to be queried.  The project could use the sources under a later version.

There is a mix of GPLv2 or later and GPLv2 code. You will have to sort which license applies.

Sure.

Let's hope nobody modified a GPL v2 header in any file to say "GPL v2 or later". That would open a giant can of worms.

We can trace with through the version control - it is doable.

This is a giant administrative nightmare. The effort for doing this exceeds the effort require to write a new boot loader. Require copyright assignment on the new boot loader and then the license can be easily changed.

How do you arrive at this conclusion? I rather say that if one was to seriously try this it can be done in a few weeks/months by one or two persons. The FSF offered to help track down people even.

Reimplementing the current U-Boot code base is orders of magnitude away from this.

Cheers Detlev

> The NAND subsystem is from Linux and is GPL v2 only, as is the > u-boot-specific NAND code in drivers/mtd/nand.

Ok, thanks for that info. Subtracting the drivers this is ~5k LOC, right?

Two ways of dealing with ths include (1) contacting the developers and asking then to relicense, and (2) writing a replacement (it's not that big).

The FSF can't offer to rewrite it, but we could halp find any developers who are now difficult to contact.

This is due to us many times (re-)using Linux drivers inside U-Boot.

This won't stop you from making sure all of U-Boot (aside from these drivers) says "GPLv2 or later". Also, you can talk with the developers of the drivers that you need, or might need, to ask them to release their drivers GPLv2+.

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 they mean is they think these companies want to tivoize it. I don't know whether that is true. For discussion, let's suppose it is true.

It has no impact whatsoever on making U-boot support GPLv2+.

However, it means that moving to GPLv3+ means a decision about values. Is it good for companies to use your program to deny the users' freedom? Or is it better to defend users' freedom by saying no to those companies? If a company seeks softwart with which to restrict users, would you rather tell them "Please do it with my program" or "I don't want to share the responsibility for what you are doing?"

Is popularity the most important value?

We should also start to actively inform the regularly appearing people on this mailing list complaining that they cannot get the source code to U-Boot of "device xyz" that with a GPLv2 U-Boot this may become a theoretical question in the future when they cannot install the changed binary anymore.

Exactly!

On Friday 19 June 2009 04:40:59 Detlev Zundel wrote:

...

I was asked about relicensing U-Boot as GPLv3:

From: Richard Stallman rms@gnu.org Subject: U-book and GPLv3? To: Wolfgang Denk wd@denx.de Date: Thu, 18 Jun 2009 09:17:28 -0400

I really enjoy the name U-boot. What are the advantages of U-boot over PMON?

Have you considered moving U-boot to "GPLv3-or-later"?

---

I know that we have had similar discussions before (see for example http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/24029), but I would like to take the chance and re-poll what the community's opinion about this is.

For what it's worth, I would appreciate moving to GPLv3. Sparing details, my reasoning is the following. Basically I think most people appreciate the GPL for what it means in pratical terms:

* the freedom to use the software for any purpose,
* the freedom to change the software to suit your needs,
* the freedom to share the software with your friends and neighbors,
* and
* the freedom to share the changes you make.

Obviously the second item here will become void if vendor lockout of updates becomes common. So what will be left of the essential freedoms? I can study the code, I can modify it, but I am not allowed to run it. Excellent.

and this is why i dislike the GPLv3. the GPLv2 was all about the source, so the conversation between developers and everyone else was "you can take my source and modify it all you want, but i want to see the changes". sounds fair.

GPLv3 (ignoring the fix for the loophole with web applications) adds *nothing* to this premise. instead, it's used as an ideological club such that the conversation is now "i have all these ideas about how software should and shouldnt be utilized, so if you want to use my software, you too now have to subscribe to my way of thinking and you have to show me the changes".

so what does moving from GPLv2 to GPLv3 gain us in terms of protections ? nothing. it does however allow us to restrict the people who want to use u- boot to using it in only ways we've "blessed". that's plain wrong in my eyes and none of our business in the first place.

I think it is not a coincidence that devices which can be updated with arbitrary firmware sells pretty good in the meantime. Who buys routers capable of running OpenWRT because of their original firmware?

then let your wallet/politicians do the talking. i certainly do -- i avoid purchasing any music/games encumbered with DRM, or companies that employ such methods. but i'm above going around and forcing people to think the way i do with licenses. -mike

On Sat, 27 Jun 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:

...

and this is why i dislike the GPLv3. the GPLv2 was all about the

source, so

...

the conversation between developers and everyone else was "you can

take my

...

source and modify it all you want, but i want to see the changes".

sounds

...

fair.

GPLv3 (ignoring the fix for the loophole with web applications) adds

*nothing*

...

to this premise. instead, it's used as an ideological club such that

the

...

conversation is now "i have all these ideas about how software should

and

...

shouldnt be utilized, so if you want to use my software, you too now

have to

...

subscribe to my way of thinking and you have to show me the changes".

so what does moving from GPLv2 to GPLv3 gain us in terms of

protections ?

...

nothing. it does however allow us to restrict the people who want to

use u-

...

boot to using it in only ways we've "blessed". that's plain wrong in

my eyes

...

and none of our business in the first place.

...

I think it is not a coincidence that devices which can be updated

with

...

...

arbitrary firmware sells pretty good in the meantime. Who buys

routers

...

...

capable of running OpenWRT because of their original firmware?

then let your wallet/politicians do the talking. i certainly do -- i

avoid

...

purchasing any music/games encumbered with DRM, or companies that

employ such

...

methods. but i'm above going around and forcing people to think the

way i do

...

with licenses.

agreed with Mike.

Second that.

--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

On Mon, Jun 29, 2009 at 4:56 PM, Arno Fischera.f.dns@novotech.co.at wrote:

In article Pine.LNX.4.64ksi.0906271550150.14063@home-gw.koi8.net, ksi@koi8.net says...

...

On Sat, 27 Jun 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:

...

...

and this is why i dislike the GPLv3.  the GPLv2 was all about the

source, so

...

the conversation between developers and everyone else was "you can

take my

...

source and modify it all you want, but i want to see the changes".

sounds

...

fair.

GPLv3 (ignoring the fix for the loophole with web applications) adds

*nothing*

...

to this premise.  instead, it's used as an ideological club such that

the

...

conversation is now "i have all these ideas about how software should

and

...

shouldnt be utilized, so if you want to use my software, you too now

have to

...

subscribe to my way of thinking and you have to show me the changes".

so what does moving from GPLv2 to GPLv3 gain us in terms of

protections ?

...

nothing.  it does however allow us to restrict the people who want to

use u-

...

boot to using it in only ways we've "blessed".  that's plain wrong in

my eyes

...

and none of our business in the first place.

...

I think it is not a coincidence that devices which can be updated

with

...

...

arbitrary firmware sells pretty good in the meantime.   Who buys

routers

...

...

capable of running OpenWRT because of their original firmware?

then let your wallet/politicians do the talking.  i certainly do -- i

avoid

...

purchasing any music/games encumbered with DRM, or companies that

employ such

...

methods.  but i'm above going around and forcing people to think the

way i do

...

with licenses.

...

agreed with Mike.

Second that.

---

---

• KSI@home    KOI8 Net  < >  The impossible we do immediately.

Third that.

Arno: I thought only "main developers" could state their opinion regarding this? You don't seem to be that according to git-log.

Detlev: If one-line patch contributers are allowed to vote (which may not be fair), my vote goes for GPLv3. Keep fighting for freedom ;-)

---

U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Hi Frank,

Arno: I thought only "main developers" could state their opinion regarding this? You don't seem to be that according to git-log.

Detlev: If one-line patch contributers are allowed to vote (which may not be fair), my vote goes for GPLv3. Keep fighting for freedom ;-)

We're not holding a formal vote here - reread the beginning - Wolfgang wrote:

I know that we have had similar discussions before (see for example http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/24029), but I would like to take the chance and re-poll what the community's opinion about this is.

The fact that you read this mailing list is probably a good proof that you both are part of the U-Boot community, so actually I appreciate both inputs.

Thanks Detlev

Dear Haavard Skinnemoen,

In message 20090707135141.7979827c@hskinnemoen-d830 you wrote:

While I think fighting for extensible and "hackable" hardware is good, I think a software license is the wrong way to go about it. Let's stick to the proven model of GPLv2: You can use my software if I get to use your improvements. Trying to impose restrictions on this model in order

The point is that GPLv2 results in situations where you cannot use and modify your own software any more because it is "protected" and any versions you build don't run.

Best regards,

Wolfgang Denk

Dear Haavard,

In message 20090707155005.2e4a4d6d@hskinnemoen-d830 you wrote:

...

The point is that GPLv2 results in situations where you cannot use and modify your own software any more because it is "protected" and any versions you build don't run.

But this is a problem with the _hardware_, not the software. I think placing restrictions on the hardware design is way outside the scope of a software license.

I'm only talking about software (code and data) here. If I cannot change (or just rebuild) the (Free!) software any more because to actually run it I need some secret data (like a signature) then this is still a software problem. One that can be prevented by releasing the software under adequate licensing terms.

In my experience, the most popular AVR-based boards are the ones that not only allow the firmware to be replaced freely, but which actively encourage modification by making lots of signals available through expansion headers. This kind of "hackability" can never be enforced through any kind of software license.

Agreed. Hardware should be hackable, too :-) (which includes documentation where you don't have to sell your soul and sign NDAs that are plain evil).

Best regards,

Wolfgang Denk

On Tue, Jul 7, 2009 at 10:43 AM, Wolfgang Denkwd@denx.de wrote:

Dear Haavard,

In message 20090707155005.2e4a4d6d@hskinnemoen-d830 you wrote:

...

...

The point is that GPLv2 results in situations where  you  cannot  use and modify your own software any more because it is "protected" and any versions you build don't run.

But this is a problem with the _hardware_, not the software. I think placing restrictions on the hardware design is way outside the scope of a software license.

I'm only talking about software (code and data)  here.  If  I  cannot change  (or  just  rebuild)  the (Free!) software any more because to actually run it I need some secret data (like a signature) then  this is  still  a software problem. One that can be prevented by releasing the software under adequate licensing terms.

...

In my experience, the most popular AVR-based boards are the ones that not only allow the firmware to be replaced freely, but which actively encourage modification by making lots of signals available through expansion headers. This kind of "hackability" can never be enforced through any kind of software license.

Agreed.  Hardware  should  be  hackable,  too  :-)  (which   includes documentation  where  you  don't have to sell your soul and sign NDAs that are plain evil).

I agree -- all ATMs, voting machines, slot machines, electricity meters, traffic lights, navigation systems, safety interlocks, etc should be hackable. I'm sure that no idiot teenager is going to change the firmware and allow an unsuspecting person to use the device.

Best regards,

Wolfgang Denk

-- DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de ######## This message was made from 100% recycled electrons. ######## _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

On Thursday 25 June 2009 14:46:10 Thomas Doerfler wrote:

which operating systems, that get typically booted using U-Boot are already under GPL3?

I know that the license of the Boot Loader has nothing to do with the license of the booted software, what is the "political benefit" to put the boot loader under GPLv3, when the major OS of the software (e.g. linux) are under GPLv2?

typically the operating systems that u-boot would load are in the opposite licensing direction, i.e. BSD or commercial variants none of which require releasing any real details let alone restrict usage. i'm not aware of any OS that is under the GPL-3. ironically, it seems even GNU/Hurd is GPL-2. -mike

Files without a copyright notice and a license notice are a legal problem.

Legally, every file is copyrighted. If there's no copyright notice, that just means it gives no info about who the copyright holder is.

The lack of a license notice is a problem. If the file is trivial, just a few lines, maybe it does not matter. But otherwise, if there is no license, that means it doesn't give people permission to copy or change or redistribute the file. Perhaps even the U-boot developers don't have this permission.

Hi Jerry,

thanks a lot for your work of analyzing the current situation - I appreciate that very much.

I did *not* analyze the files for complexity and appropriateness of copyright/license information in the file. That should be done regardless of the results of the GPLv3 debate and the files that should have copyright/license information in their headers need to be either fixed or replaced.

Yes indeed - it has become more than clear that we have to get clean on this front now, regardless of any licensing changes.

Everyone who wants to help on this front is invited to do so. Hopefully git can help us track down people if we need to. If it turns out to be of help, I can surely dig up the last CVS repository before the conversion to git.

Cheers Detlev