libpayload for ARM with sprinklings of GPL and coreboot code sharing

[mrnuke]

I'll try to be short.

 * Usually, ARM payloands need to use SoC specific drivers to access storage 	
	devices.
 * Sometimes coreboot implements the same drivers.

Proposal:
 * Share these drivers between coreboot and libpayload.
 * libpayload is BSD. Have a "[ ] Enable GPL features" config option which 	
	"unlocks" the GPL'd drivers from coreboot.
 * libpayload core remains BSD.
 * coreboot drivers are available to GPL users of libpayload
 * Both the licensing of libpayload-core and coreboot is maintained/respected
 * Makes maintenance easier
 * Makes libpayload relevant in the ARM space

Alex

libpayload for ARM with sprinklings of GPL and coreboot code sharing

[Peter Stuge]

mrnuke wrote:
> * Share these drivers between coreboot and libpayload.
> * libpayload is BSD. Have a "[ ] Enable GPL features" config option which 	
>   "unlocks" the GPL'd drivers from coreboot.
> * libpayload core remains BSD.

The other way around would also be possible.


//Peter

libpayload for ARM with sprinklings of GPL and coreboot code sharing

[mrnuke]

On Friday, March 21, 2014 01:13:59 AM Peter Stuge wrote:
> mrnuke wrote:
> > * Share these drivers between coreboot and libpayload.
> > * libpayload is BSD. Have a "[ ] Enable GPL features" config option which
> >
> > "unlocks" the GPL'd drivers from coreboot.
> >
> > * libpayload core remains BSD.
>
> The other way around would also be possible.

The problem is that some things on ARM we will either tale from uboot and/or 
linux, like I did with the MMC driver for cubieboard. So BSD is not an option 
in such cases.

Alex

libpayload for ARM with sprinklings of GPL and coreboot code sharing

[Patrick Georgi]

Am Donnerstag, den 20.03.2014, 17:57 -0500 schrieb mrnuke:
> * Share these drivers between coreboot and libpayload.
> Make them BSD-l, like cbfs-core.
> * libpayload core remains BSD.
> "with strings attached" - I'd like to avoid that.

If you need SoC drivers, the *BSDs have their share of drivers, too.
Typically of a better quality than the Linux ones (but less battle
tested).


Patrick

libpayload for ARM with sprinklings of GPL and coreboot code sharing

[Stefan Reinauer]

* Patrick Georgi <[e-mail]> [140321 18:38]:
> Am Donnerstag, den 20.03.2014, 17:57 -0500 schrieb mrnuke:
> > * Share these drivers between coreboot and libpayload.
> > Make them BSD-l, like cbfs-core.
> > * libpayload core remains BSD.
> > "with strings attached" - I'd like to avoid that.

Nice pun. It's actually the string functions that are GPLed in the ARM
port right now. D'uh.
> If you need SoC drivers, the *BSDs have their share of drivers, too.
> Typically of a better quality than the Linux ones (but less battle
> tested).

Is there any single BSD licensed payload out there? That's using
libpayload? The work around of stuffing drivers into depthcharge is
really, really unfortunate because it causes unnecessary duplication

Stefan

libpayload for ARM with sprinklings of GPL and coreboot code sharing

[Patrick Georgi]

Am 2014-03-25 05:36, schrieb Stefan Reinauer:
> Is there any single BSD licensed payload out there? That's using
> libpayload? The work around of stuffing drivers into depthcharge is
> really, really unfortunate because it causes unnecessary duplication
> I think I (and you) ported some libpayload code into corebootPkg. Maybe 
> we need to split things up a bit?

"coreboot support code" (ie coreboot tables, cbfs and the like) should 
probably remain as flexible as possible.
flash writing may well be GPL. (and ideally comes from libflashrom)


Patrick

libpayload for ARM with sprinklings of GPL and coreboot code sharing

[Stefan Reinauer]

* mrnuke <[e-mail]> [140320 23:57]:
> Proposal:
>  * Share these drivers between coreboot and libpayload.
>  * libpayload is BSD. Have a "[ ] Enable GPL features" config option which 	
>   "unlocks" the GPL'd drivers from coreboot.
>  * libpayload core remains BSD.
>  * coreboot drivers are available to GPL users of libpayload
>  * Both the licensing of libpayload-core and coreboot is maintained/respected
>  * Makes maintenance easier
>  * Makes libpayload relevant in the ARM space

In the chromium repo we've had an effort to replace the GPLed ARM parts
with BSD licensed counterparts.

For stuff we wrote from scratch double licensing is easy, but certainly
some drivers we'd like to use from other projects (like u-boot) are a
lot of work to be rewritten.
For ChromeOS firmware we tried working around that by bundling the
drivers with depthcharge (the payload) because it's GPL.

I don't really know of any non-GPLed users of libpayload, so definitely
relicensing libpaylod might be on the table.

In the short term having a GPL enabling Kconfig seems like an option.
Or we take the effort of rewriting those pieces BSD licensed. The
question is: Is there anybody out there caring enough about non-GPLed
payloads to put in the effort.

Stefan