[U-Boot] SWUpdate - U-Boot environment library dependency

[Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>]

On Wednesday, November 21, 2018, Stefano Babic <sbabic@denx.de> wrote:

> Hi Marek,
>
> On 21/11/18 15:31, Marek Vasut wrote:
> > On 11/21/2018 10:20 AM, Wolfgang Denk wrote:
> >> Dear Stefano,
> >
> > Hi,
> >
> >> In message <96836cc1-e4bb-a2a2-05ac-056053b4c426@denx.de> you wrote:
> >>>
> >>> I would like to see the library under LGPL instead of GPL2, too, and I
> >>> raised this issue when I started SWUpdate, but I was not very active to
> >>> promote this. Tom, Wolfgang, is there chances to switch license ?
> >>
> >> Relicensing requires permission from all who contributed to that
> >> code.
> >>
> >> Consider mine as granted.
> >>
> >> But someone hat to invest the efforts to analyze the code so we
> >> know who to ask, and then collect all the permissions...
> >>
> >>> A env library is very welcomed by many customers, because they could
> >>> integrate it in their application if license allows it.
> >>
> >> Agreed.
> >
> > Then again, U-Boot environment structure is trivial, crc, flags, data,
> > there is no complexity involved. There is probably some complexity in
> > the backing store access stuff (MTD, block devs, legacy stuff), but that
> > should either use some MTD utils libs, basic block access primitives or
> > be given a once-over and possibly be dropped.
> >
> > I think prototyping a library from scratch that's LGPL would be a few
> > days' work and the benefit would be tremendous all over.
>
>
> I confess I had the same idea - why not ignore the code in tools/env
> (they have also some drawbacks, see the locking mechanism in my previous
> e-mail) and start with a new library from scratch ? Then LGPL is not an
> issue anymore, it is a new development. And I already took this way for
> "grubenv" (I had to, grubenv is not license compatible).
>
> But something in my head is telling me that this is not else as a fork
> of u-boot (ok, a partial fork, just tools/env). And if the U-Boot
> community decides to follow other ways for the environment, the "forked"
> project aka "new library" should follow. But yes, I guess it is easier,
> and I agree with you this is just a few days work.


Once you had this new lgpl library, would it be a big problem to backport
it to the U-Boot tree? Wouldn't that also ensure future commiters accept
the lgpl license when adding their new code?

Simon