On Fri, May 22, 2020 at 9:18 AM Alan Carvalho de Assis <acas...@gmail.com> wrote:
> Hi Daniel, > > Yes, I think an option is to create an apps/thirdparty folder to > follow with Xiang idea. I like the idea of glue code. There are many libraries out there which people may want to use with NuttX, and we can't/shouldn't fork them all and stick them in our codebase. Not only would that be a problem for Apache (because Apache doesn't make "hostile forks" and licensing) but from a technical/management point it creates a bigger maintenance burden on us to manually track upstream and bring updates into NuttX. It is better to work with upstream libraries as-is, and make only the custom glue code that consists of Kconfig, Make.defs, etc. The glue code will belong to us and will be Apache licensed. The 3rd party library stays separate and is not in our repository. Only if the user activates a 3rd party library, the glue code will (1) download or clone it, if needed, and (2) integrate it into the NuttX build system. If a port to NuttX requires patching the 3rd party code, whoever does the porting should upstream the changes back to the 3rd party project. If the 3rd party project doesn't accept the changes, the patch can be part of our glue code. In any case, we will only need to maintain the glue, not the whole project, and the glue will be Apache licensed so we aren't stepping on anyone's toes. I think it's a good general solution for integrating 3rd party code. I think glue code will even allow to make GNU licensed 3rd party code integrations, because the glue code is ours, and the GNU code is not downloaded or used unless the user specifically wants it. One more thing: I think the glue code should provide a way to customize the download location of the 3rd party code. So if a NuttX user is worried that the 3rd party code will disappear from the Internet, or if they want to customize the 3rd party code, they can keep their own local clone and provide that link to Kconfig. > Cheers, Nathan
