[flashrom] LGPL

Rolette, James (Jay) rolette at hp.com
Thu Apr 26 17:35:24 CEST 2012

Hi Carl-Daniel,

> some time ago I looked into adding VxWorks support to flashrom, but I
> couldn't find any VxWorks user who was interested in that.

There are a couple of main use-cases for embedded systems (probably more):

1) Programming parts during manufacturing.  For this one, I wouldn't see a need for a VxWorks version of flashrom.  More likely to use pre-programmed parts or program them in an ICT fixture.

2) Updating programmable parts in the field (cameras, blu-ray/dvd players, AVRs, switches/routers, etc.).  If they are running an RTOS, you frequently don't have separate memory spaces or "normal" OS processes.  With flashrom being GPLv2, unless the embedded system is also GPL, it makes it difficult (at best) to use.

That might be part of the reason that you didn't find any VxWorks user interested in it.

> I don't know anything about VxWorks internals, so my suggestions may be
> a bit off. If this is just about linking flashrom against the standard
> VxWorks system C library, the GPLv2 system library exception looks like
> it would fit the bill without any need for license changes:
> http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs . That
> said, I'm not a lawyer and this does not constitute legal advice. The
> FSF may have an opinion

I'm coming at it from the other way...  It's not a question of being able to get flashrom to work in VxWorks.  The problem I have is being able to use flashrom without tainting (sorry, not trying to be derogatory) proprietary code that isn't GPL that is running in a flat memory space RTOS.

Not trying to leach.  More than willing to contribute to the project (add support for programmable parts we are using that aren't already supported, help build out libflashrom, etc.).  Just looking for a license that is compatible with my needs.  LGPL would achieve that.

>> libflashrom is really what we'd be more interested in, but looks too early
>> for that.  Might be something we could help build if we can work out the
>> licensing issues
> libflashrom is still in its infancy as you correctly observed. The idea
> behind libflashrom was to allow multiple GUIs for flashrom without
> having to ship a modified copy of flashrom as part of the GUI. The
> current libflashrom interface is just a convenient way to allow two
> slightly different CLIs for flashrom (the default one and the variant
> used by Google in their devices). We are working on cleaning up the
> flashrom codebase to make the libflashrom code more self-contained and
> more library-like (i.e. no exit(1) calls), but that will take time in
> absence of any serious advanced libflashrom users. I'd be happy to help
> with designing a proper libflashrom interface, but such an endeavour
> will need time to be done the right way.

With the right license, it could be used for a lot more than just multiple GUI support :)

>> Given how common programmable parts are in embedded
>> systems, seems like LGPL would end up netting more contributions from
>> companies as they add support for the parts they are using on their designs
>> Although I'm sure I'm not bringing up anything you guys haven't discussed.
> I know that some vendors use flashrom internally for
> manufacturing/repair/..., but they don't distribute flashrom to their
> customers.

For embedded programmable parts, it's not really about giving flashrom to end-customers to run directly.  It's more about integrating the capability into the normal firmware/OS update mechanism.

> Kontron and Google have contributed directly to flashrom, and some
> hardware manufacturers (Nuvoton and ITE) have contributed code via
> Google. Some flash chip vendors have offered samples and/or datasheets.
> That's pretty much all the manufacturer involvement we've seen in the
> last 10 years since flashrom development started.
> I haven't seen any requests for alternative flashrom licensing since I
> started working on flashrom in 2006. Due to that, I doubt a switch to
> LGPL would result in a sizable number of contributions from companies.

Fair enough.  It looks a bit like a self-fulfilling prophecy to me.  With GPL, it fences out many companies from being able to contribute.

I appreciate the time you took to respond.  I figured it was at least worth asking the question since it looked like a way for us all to gain something.  I'd be happy to answer any questions if I haven't explained my case clearly or if there is any interest in continuing a discussion about LGPL.


More information about the flashrom mailing list