Detecting exploding batteries, part 2

[Richard Hughes]

On Mon, 2006-09-25 at 11:46 -0400, David Zeuthen wrote:
> Hi,
> 
> In general... a very good idea.
> 
> On Sun, 2006-09-24 at 21:20 +0100, Richard Hughes wrote:
> > Attached is a patch to add three new keys:
> > 
> > battery.fault.perhaps_faulty
> > battery.fault.oem_vendor
> > battery.fault.website
> 
> Suggest to not to use the word 'fault', it's guaranteed to piss off some
> entities.. some with huge legal teams.

Agree.

> What we're really interested in... is whether the battery is recalled
> from the manufacturer. In fact, this is not specific to batteries at
> all, suggest 
> 
>  info.is_recalled  (bool)
>  info.recall.oem_url_link_text (string) # e.g. Dell Battery Return Program
>  info.recall.oem_url_link_target        # e.g. https://www.dellbatteryprogram.com/

Yes, this is better.

> (please fix up the wording as needed, E is my 2nd language, thanks)
> 
> And that's it. I don't think g-p-m or whoever consumes this information
> should be making assumptions about the recall. E.g. instead of this
> (well meaning) notification
> 
>  http://people.freedesktop.org/~hughsient/temp/battery_explode.png
> 
> that has lots of connotations and words OEM's don't really want the user
> to see..... you'd just ought to provide this kind of notification
> 
>      /\
>     /  \
>  +--    ---------------------------------------------------------------
>  | Your battery is being recalled.                                    |
>  |                                                                    |
>  | The battery in [your computer|UPS] is recalled by the manufacturer |
>  | and you may be at risk. For more information visit this web site   |
>  |                                                                    |
>  |  [link to manufacturer]                                            |
>  |                                                                    |
>  | [ ] Don't remind me about this again                               |
>  +---------------------------------------------------------------------

Looks sane, and probably easier to translate :-)

> So.. how about having a separate project / tarball with this? Whether
> distributors will use this is an interesting question, it's a grey area
> with potential legal issues (what happens if the battery explodes and we
> failed to show a notification) and business issues (OS vendors have
> partnerships with vendors of faulty batteries).
> 
> So, there's a bit of legwork figuring out whether there is an interest
> for this tarball.. I can ask around at Red Hat to get some legal input,
> please contact me off-list about this.

Will do.

> If there is interest (and I hope there is!), I urge you to create a
> freedesktop.org project (no good name comes to mind except
> "hardware-recall") and work with the OEM's - ideally they will
> contribute data to this on an ongoing basis. It's in their own best
> interestest IMNSHO but then again IANAL and there are probably
> significant business interest for them to keep a lid on things. Then
> again, maybe they will do the very right thing and be public about this.

I'm not sure that would work. Who would install hardware-recall? If it's
not installed by default then it's a non-starter.

> In short, it's a can of worms - a potential mine field including legal
> and business issues. Let's try to work those out.
> 
> Anyway, if we hopefully get interest OS vendors should just package up
> that tarball and ship it as an RPM or DEB. Then they can update it all
> they want.

Sure, I think that idea is sane. How to document the keys tho? We can't
add it to the xml in the hal tarball?

> > This patch depends on the previous patch to fix the value of
> > battery.model when it includes spaces.
> 
> Is this in master yet?

Nope, it probably needs someone to cast their eye over it (hint) and
give me the good to go.

Thanks,

Richard.