Hi Jay,
some time ago I looked into adding VxWorks support to flashrom, but I couldn't find any VxWorks user who was interested in that.
Am 25.04.2012 15:29 schrieb Rolette, James (Jay):
[...] The reason I'm asking about LGPL is that I'm interested in porting flashrom to VxWorks and using it in an embedded system. Historically we've written our own custom code for programming the various programmable parts we use and it makes more sense to work with something like flashrom if possible. More than happy to contribute back our changes, but need the license to be something we can use in a system with flat memory space, etc.
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
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.
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. 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.
Regards, Carl-Daniel
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.
Regards, Jay
-
Carl-Daniel Hailfinger -
Rolette, James (Jay)