tock
Newlib license complexity
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?
picolib should solve the license issues and there is https://github.com/tock/libtock-c/pull/305 adding support to libtock-c
https://github.com/tock/libtock-c/pull/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
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.
examples/ble-uart and examples/rf233 both seem to contain code licensed under different licenses as well
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?
