> -----Original Message-----
> From: Nathan Hartman <hartman.nat...@gmail.com>
> Sent: Monday, May 25, 2020 12:00 AM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
>
> 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.
>
So the question is where should we put the "glue code"?
1.Put to apps/external/ directly
2.Put to a new git(e.g. apache-nuttx-external.git)
3.Put to some folders under apps by catalog(e.g. apps/crypto/mbedtls)
I prefer item 1 or item 2 personally.
> 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 Apache, that sometimes ASF does allow to mirror well-known FOSS tools.
> So we'll have to look at that.
>
Before ASF host this tools, we have to keep them on https://bitbucket.org/nuttx
or https://github.com/nuttx.
> Nathan
