Newlib license complexity

[jrvanwhy]

libtock-c depends on newlib. The newlib codebase contains code under many different licenses, including the GPL and LGPL. Because newlib's codebase is large (over 6000 source files), this poses a challenge for closed-source projects that want to utilize libtock-c. In particular:

• Depending on a codebase (specifically, the newlib source tarball) that contains many GPL-licensed files makes it difficult for closed-source projects to verify they are in compliance with the GPL.
• Depending on a library with LGPL components in a statically-linked environment makes it difficult for closed-source projects to verify they are in compliance with the LGPL.

Perhaps there is an alternative C library we can migrate to that is under licenses more similar to libtock-c's Apache-2.0 OR MIT licensing?

[alistair23]

picolib should solve the license issues and there is #305 adding support to libtock-c

[alistair23]

#305 only adds RISC-V support though. ARM support is trickier with the position independent requirements, but it probably wouldn't be too hard to do

[jrvanwhy]

picolib looks great, with one possible catch. It contains a single AGPL file, and Google is not a fan of the AGPL: https://opensource.google/documentation/reference/using/agpl-policy

If Tock wants to go with picolib, I'll want to ask around internally to make sure that I'm not replacing one challenge with another.

[hudson-ayers]

examples/ble-uart and examples/rf233 both seem to contain code licensed under different licenses as well

[bradjc]

Would it help if we did:

tar -xzf picolib-1.8.5.tar.xz
rm picolibc-1.8.5/scripts/GeneratePicolibcCrossFile.sh
... continue on with building

in our picolib build script?