flashrom licensing

[Carl-Daniel Hailfinger]

Hi,

I wanted to add support for the TotalPhase Cheetah to flashrom, but I
have to use the proprietary driver library for that. I'm not aware of
any free alternative to that driver, so there may be a conflict with the
GPL.

If the Cheetah driver library is considered to be a system library, the
GPL allows linking against that library.

If the Cheetah driver library is not considered to be a system library,
I need to add an exception for that library to my Cheetah external
flasher driver. However, since my driver would be part of flashrom, I
have no idea if I would have to get permission from all flashrom authors
for that exception. The GPL FAQ of the FSF mentions that simply adding a
free software wrapper above the proprietary library is not sufficient,
but having process separation (calling another program via the command
line) would be OK. Since external flasher drivers have to maintain
state, this essentially means I'd have to add shared memory or socket
trickery, resulting in slow, buggy and unreadable code.

One of the possible solutions would be to say that driver libraries for
external hardware which are already installed before installing flashrom
are considered to be system libraries.

(The problem is that the Cheetah driver library has internally
conflicting licenses, some of which suggest linking GPL code against it
is not allowed. I (or maybe someone with more leverage) will try to
address this with TotalPhase.)

Regards,
Carl-Daniel

[Peter Stuge]

Carl-Daniel Hailfinger wrote:
> I wanted to add support for the TotalPhase Cheetah to flashrom, but
> I have to use the proprietary driver library for that. I'm not
> aware of any free alternative to that driver, so there may be a
> conflict with the GPL.

There would be no issue, if flasher drivers were not linked with
flashrom, but rather separate processes implementing a well-defined
interface. Maybe you remember the discussion about flashrom plugins.
> If the Cheetah driver library is considered to be a system library,
> the GPL allows linking against that library.

Cheetah is not essential for the system where flashrom is running so
I do not think that can be argumented successfully.

//Peter

[Carl-Daniel Hailfinger]

On 24.06.2009 15:54, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
> > I wanted to add support for the TotalPhase Cheetah to flashrom, but
> > I have to use the proprietary driver library for that. I'm not
> > aware of any free alternative to that driver, so there may be a
> > conflict with the GPL.
>
> There would be no issue, if flasher drivers were not linked with
> flashrom, but rather separate processes implementing a well-defined
> interface.

Maybe. Each driver would have to be a separate process with no common
code or the same problem would just be moved to the common code of the
drivers.
> Maybe you remember the discussion about flashrom plugins.

Sorry, I can't remember that discussion and a search turned up empty. If
you have a subject line or date, I'll gladly reread that discussion.
> > If the Cheetah driver library is considered to be a system library,
> > the GPL allows linking against that library.
>
> Cheetah is not essential for the system where flashrom is running so
> I do not think that can be argumented successfully.

True. Now if the Cheetah drivers were shipped by default on some Linux
distributions, they'd fit the FSF definition of system libraries. Oh well.

Anyway, since we have FT4232H flasher support, the Cheetah is
non-essential anyway.

Regards,
Carl-Daniel

[ron minnich]

you might want to restart this discussion on the new list :-)

Sorry, could not resist, licensing issues are the bane of my life :-)

ron

[Peter Stuge]

Carl-Daniel Hailfinger wrote:
> Each driver would have to be a separate process with no common code
> or the same problem would just be moved to the common code of the
> drivers.

That common code could have a different license than flashrom itself.
> > Maybe you remember the discussion about flashrom plugins.
>
> Sorry, I can't remember that discussion and a search turned up
> empty. If you have a subject line or date, I'll gladly reread that
> discussion.

No single thread, my comments were late last year.

Message-ID: 
Subject: Re: [coreboot] LPCflasher Wiki Page

Message-ID: 
Subject: Re: [coreboot] Dynamic detection of Parallel Port

Message-ID: 
Subject: Re: [coreboot] Yet another idea of an SPI flash chip programmer
> Anyway, since we have FT4232H flasher support, the Cheetah is
> non-essential anyway.

I assume it's a tool someone uses. It would be nice to support it.

This will not be the last time this problem comes up.

Finally it allows flashrom to not care about libusb or libftdi.

//Peter

[Carl-Daniel Hailfinger]

On 24.06.2009 16:36, Peter Stuge wrote:
> That common code could have a different license than flashrom itself.

True. However, if we reuse common code, we still have to get permission
from all copyright holders. The less code it is, the better.
> No single thread, my comments were late last year.
>
> [...]

Thanks, will read them.
> Carl-Daniel Hailfinger wrote
> > Anyway, since we have FT4232H flasher support, the Cheetah is
> > non-essential anyway.
>
> I assume it's a tool someone uses. It would be nice to support it.

True.

Regards,
Carl-Daniel

[Richard Smith]

Carl-Daniel Hailfinger wrote:
> (The problem is that the Cheetah driver library has internally
> conflicting licenses, some of which suggest linking GPL code against it
> is not allowed. I (or maybe someone with more leverage) will try to
> address this with TotalPhase.)

If you never ship a binary then there's no problem.  I don't have any 
issues against Cheetah support having to be enabled via a compile switch 
  and a recompile by the user.  The user has to go download and install 
the Cheetah libraries anyway so there's always a manual step.

If such time as someone with a commercial interest wants to distribute a 
flashrom binary then they can work with TotalPhase.

Unfortunately, the Cheetah requires a hardware modification to be useful 
as a 3.3V programmer [1] so unless TotalPhase re-spins the hardware I 
would not recommend it.

Of course this is probably not going to be the last time this issue 
comes up if you start trying to add support for commercial programmers 
so dealing with it now may be useful.

[1] The cheetah has inputs/outputs that are 3.3V safe but the target 
power is 5V only.  3.6V is available on the hardware board and you can 
modify it such that the target output uses that rather than 5V.  For 
OLPC our SPI part is ok with 3.6V but other parts might not be.  A small 
regulator would be necessary for those parts.

I've fed my comments back to TotalPhase but from the response I don't 
get the feeling it will change anytime soon.