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

[Marek Vasut]

On 11/21/2018 04:31 PM, Simon Goldschmidt wrote:
> 
> 
> On Wednesday, November 21, 2018, Stefano Babic <sbabic at denx.de
> <mailto:sbabic at 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 at denx.de
>     <mailto:96836cc1-e4bb-a2a2-05ac-056053b4c426 at 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?

Maybe it can be part of the U-Boot tree and the old env tools can just
be migrated over, make them a husk which calls the new lib .

-- 
Best regards,
Marek Vasut