Yes, we can reuse github.com/nuttx to host the 3rd party library which stop the active development. But It's better to host the library by the different git to keep the full history for each project.
> -----Original Message----- > From: Alan Carvalho de Assis <acas...@gmail.com> > Sent: Monday, May 25, 2020 8:01 PM > To: dev@nuttx.apache.org > Subject: Re: mbedtls > > I completely agree on that! > > Also I think it is important to have a copy of each thirdparty project at > nuttx-apps-external to avoid they disappear from the Internet. > > BR, > > Alan > > On 5/25/20, Abdelatif Guettouche <abdelatif.guettou...@gmail.com> wrote: > > I think we should avoid apps/external. People use it for their own > > app, putting more code there would mess up their versioning control. > > A separate folder would be more convenient (whatever its name is > > "3rdparty", "thirdparty", "glue", etc.) > > > > On Mon, May 25, 2020, 08:23 Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > > > >> Yes, item 4 is also good enough. To reduce the git repo number and > >> simplify the finding, I think that item 1 and 4 is better than other. > >> > >> > -----Original Message----- > >> > From: Takashi Yamamoto <yamam...@midokura.com.INVALID> > >> > Sent: Monday, May 25, 2020 2:55 PM > >> > To: dev@nuttx.apache.org > >> > Subject: Re: mbedtls > >> > > >> > On Mon, May 25, 2020 at 3:41 PM Xiang Xiao > >> > <xiaoxiang781...@gmail.com> > >> wrote: > >> > > > >> > > > >> > > > >> > > > -----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. > >> > > >> > 4. similar to 1, but put them to a new directory, say apps/glues, > >> > to > >> avoid conflicting with the existing apps/external users. > >> > > >> > > > >> > > > 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 > >> > > > >> > >> > >