On Mon, May 25, 2020 at 1:00 AM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis > <acas...@gmail.com> wrote: > > Some months ago I suggested that NuttX could focus only in the kernel > > and we could create an external distribution using some build system > > like buildroot, yocto, etc. But as some people pointed, maybe a great > > strength of NuttX is to have everything integrated. > > That is a strength of NuttX, and it would be a shame to ruin it for no > technical reason and only because we can't find an acceptable way to > deal with licenses and where to keep code... > > ...which is why I think the "glue code" idea is best for 3rd party > code that we want to integrate. > > With "glue code": > * We do not have to copy 3rd party projects into our repository. > * We do not need external non-Apache-project repositories. > * We do not have to copy 3rd party projects into external > non-Apache-project repositories. > > All we do is develop "glue code" which comprises Kconfig files, > Make.defs files, and possibly patch files. Those would be developed by > us. Those would be part of Apache NuttX. Those would have the Apache > license. We would NOT copy any 3rd party projects into our > repositories. > > When users select those items in Kconfig, our build system will invoke > the "glue code" which will download/clone (if not already present) the > 3rd party project onto the user's machine and build that code as part > of their NuttX build. > > Our glue code could be smart: For example if a 3rd party library is > GPL, in our glue code, it would depend on "CONFIG_ALLOW_GPL_LICENSE" > or something like that. So the end user will have to decide if GPL is > suitable, and if yes, select to allow it, and then select whatever GPL > 3rd party code they want to have it built and included in their image. > > There is no problem with licensing with this approach. > > There are no hostile forks. > > There is no need to ask permission, SGAs, etc. because we are not > copying 3rd party code into our repositories. > > And you can integrate every FOSS project in the world with NuttX. > > Because: We are only developing glue code and we own the glue code. > > People can choose to activate it if they want to, or not. If they want > to, they accept the licenses of the 3rd party code that they will > download. > > The only concern I can see with this is: What happens if I, as a user > of NuttX, depend on external projects, and those external projects > disappear from the Internet. Well, the answer is that our glue code > should allow you to customize the download/clone location. So, as a > user of NuttX, you can create your own local clone of 3rd party code, > so that if the original disappears from the Internet, you have a copy. > That becomes the user's responsibility. We don't copy any 3rd party > code into our repositories. > > We do have to solve the issue of Kconfig. That has disappeared from > the Internet and we depend on it. We were told, before we joined
do we have some reasons not to switch to kconfiglib? > Apache, that sometimes ASF does allow to mirror well-known FOSS tools. > So we'll have to look at that. > > Nathan
