Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hi all,

Following the recent discussion in the thread “Early feedback on RZ/V2H
port and RZ FSP HAL dependency”, I would like to suggest applying the same
idea discussed there to existing vendor HAL dependencies: hosting them
under github.com/NuttX, while keeping them separate from the ASF
repositories. This proposal is aligned with some opinions shared there.

A practical example is esp-hal-3rdparty. I recently opened a very small fix
there:

https://github.com/espressif/esp-hal-3rdparty/pull/15

The PR is still open without Espressif review. Interestingly, the technical
feedback so far came from Laczen, a NuttX contributor who is not part of
Espressif.

This illustrates the issue when NuttX depends on a vendor repository but
the vendor is temporarily unavailable to maintain or review it.

Would it make sense to move esp-hal-3rdparty, and potentially similar
vendor HAL repositories, under github.com/NuttX, with vendor maintainers
when available but NuttX committers retaining the ability to review and
maintain them when necessary?

Best regards,

*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

We can also draw an analogy with applications whose core code is maintained
in external repositories, such as Dropbear. If we already fetch code from
external repositories, why shouldn't we do the same for HALs?

Em qui., 22 de out. de 2026 às 13:19, Alan C. Assis <ac...@gmail.com>
escreveu:

> Hi Nathan,
>
> I was just thinking about it: if we could accept the HAL being under the
> vendor repository, why couldn't we allow it to be at another GitHub
> repository account?
>
> It won't be considered under ASF, but at least it will be at a place where
> we can eventually help users if the vendor abandons us.
>
> BR,
>
> Alan
>
> On Wed, Oct 21, 2026 at 11:24 AM Nathan Hartman <ha...@gmail.com>
> wrote:
>
> > On Wed, Oct 21, 2026 at 8:35 AM Alan C. Assis <ac...@gmail.com> wrote:
> > (snip)
> >
> > > My suggestion is: HALs that can't be hosted at ASF should be hosted at
> > > github.com/NuttX/HALS/vendor-hal-name (or any other github account
> under
> > > the control of the NuttX community).
> >
> >
> > I thought Justin just explained:
> >
> > On Tue, Oct 20, 2026 at 8:24 PM Justin Mclean <jm...@apache.org>
> wrote:
> > (snip)
> >
> > > github.com/NuttX is not controlled by the ASF, so it is not “under our
> > > control”. Code the project maintains must be housed in ASF
> repositories,
> > > see https://infra.apache.org/project-repo-policy.html. That rules out
> > > NuttX committers maintaining vendor HALs there.
> >
> >
> > If third parties want to create repositories of things that can work with
> > NuttX, that's their choice and that's great, but it can't be considered
> > part of *this* project and it can't be presented as "NuttX" or
> > github.com/NuttX. As Justin explained, when *this* project hosts
> > something,
> > it needs to be hosted at the ASF, in ASF repositories.
> >
>


-- 

*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

["Alan C. Assis" <ac...@gmail.com>]

Hi Nathan,

I was just thinking about it: if we could accept the HAL being under the
vendor repository, why couldn't we allow it to be at another GitHub
repository account?

It won't be considered under ASF, but at least it will be at a place where
we can eventually help users if the vendor abandons us.

BR,

Alan

On Wed, Oct 21, 2026 at 11:24 AM Nathan Hartman <ha...@gmail.com>
wrote:

> On Wed, Oct 21, 2026 at 8:35 AM Alan C. Assis <ac...@gmail.com> wrote:
> (snip)
>
> > My suggestion is: HALs that can't be hosted at ASF should be hosted at
> > github.com/NuttX/HALS/vendor-hal-name (or any other github account under
> > the control of the NuttX community).
>
>
> I thought Justin just explained:
>
> On Tue, Oct 20, 2026 at 8:24 PM Justin Mclean <jm...@apache.org> wrote:
> (snip)
>
> > github.com/NuttX is not controlled by the ASF, so it is not “under our
> > control”. Code the project maintains must be housed in ASF repositories,
> > see https://infra.apache.org/project-repo-policy.html. That rules out
> > NuttX committers maintaining vendor HALs there.
>
>
> If third parties want to create repositories of things that can work with
> NuttX, that's their choice and that's great, but it can't be considered
> part of *this* project and it can't be presented as "NuttX" or
> github.com/NuttX. As Justin explained, when *this* project hosts
> something,
> it needs to be hosted at the ASF, in ASF repositories.
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

["Alan C. Assis" <ac...@gmail.com>]

Hi Nathan,

If that is the case, I suggest we don't accept this option because we know
the consequences.

Since this is an open-source project, if companies want to use their HAL
internally (behind closed doors), they should maintain the entire fork
themselves.

This way, users won't complain to us about not getting their code submitted
to the vendor HAL and the vendor never merges it.

BR,

Alan

On Wed, Oct 21, 2026 at 11:24 AM Nathan Hartman <ha...@gmail.com>
wrote:

> On Wed, Oct 21, 2026 at 8:35 AM Alan C. Assis <ac...@gmail.com> wrote:
> (snip)
>
> > My suggestion is: HALs that can't be hosted at ASF should be hosted at
> > github.com/NuttX/HALS/vendor-hal-name (or any other github account under
> > the control of the NuttX community).
>
>
> I thought Justin just explained:
>
> On Tue, Oct 20, 2026 at 8:24 PM Justin Mclean <jm...@apache.org> wrote:
> (snip)
>
> > github.com/NuttX is not controlled by the ASF, so it is not “under our
> > control”. Code the project maintains must be housed in ASF repositories,
> > see https://infra.apache.org/project-repo-policy.html. That rules out
> > NuttX committers maintaining vendor HALs there.
>
>
> If third parties want to create repositories of things that can work with
> NuttX, that's their choice and that's great, but it can't be considered
> part of *this* project and it can't be presented as "NuttX" or
> github.com/NuttX. As Justin explained, when *this* project hosts
> something,
> it needs to be hosted at the ASF, in ASF repositories.
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Nathan Hartman <ha...@gmail.com>]

On Wed, Oct 21, 2026 at 8:35 AM Alan C. Assis <ac...@gmail.com> wrote:
(snip)

> My suggestion is: HALs that can't be hosted at ASF should be hosted at
> github.com/NuttX/HALS/vendor-hal-name (or any other github account under
> the control of the NuttX community).


I thought Justin just explained:

On Tue, Oct 20, 2026 at 8:24 PM Justin Mclean <jm...@apache.org> wrote:
(snip)

> github.com/NuttX is not controlled by the ASF, so it is not “under our
> control”. Code the project maintains must be housed in ASF repositories,
> see https://infra.apache.org/project-repo-policy.html. That rules out
> NuttX committers maintaining vendor HALs there.


If third parties want to create repositories of things that can work with
NuttX, that's their choice and that's great, but it can't be considered
part of *this* project and it can't be presented as "NuttX" or
github.com/NuttX. As Justin explained, when *this* project hosts something,
it needs to be hosted at the ASF, in ASF repositories.

RE: Proposal: host vendor HAL repositories under github.com/NuttX

[Binh Nguyen <bi...@renesas.com>]

Hi,

Thanks for the discussion and clarification.

Since there is currently no consensus on a new model for vendor HALs, we will follow the existing approach used by Espressif and Realtek.

We believe following an existing precedent is the most practical way for us to move forward with our contribution.

We look forward to continuing to contribute to the NuttX community.

Thanks,
Binh

Re: Proposal: host vendor HAL repositories under github.com/NuttX

["Alan C. Assis" <ac...@gmail.com>]

Hi Alin,

I completely agree with these suggestions!

I just want to enforce that "HAL maintained outside ASF" doesn't main
maintained under Vendor repository, otherwise we will face the same issues
we saw recently.

BR,

Alan

On Wed, Oct 21, 2026 at 9:58 AM Alin Jerpelea <je...@gmail.com> wrote:

> Hi Alan,
>
> @Justin Mclean <ju...@classsoftware.com> thanks for the clarification
>
> I think that we should encourage this order and start a vote regarding
> updating the documentation to help vendors decide.
>
> option 1: preferred way ->create the native NuttX port which can be
> maintained by community (including vendor representatives with CLA) under
> the project repo.. This option provides *compatibility, compliance, *and
> ensures *long term maintenance* from vendor and community
> option 2: approved way ->vedor signs SGA and move vendor HAL under ASF.
> This option provides *compliance*, and ensures *long term maintenance* from
> vendor and community
> option 3: HAL maintained outside ASF should be mentioned in documentation
> but treated like every other Open Source component that NuttX imports (Ex:
> machine learning). it is supported but *we can not guaranty or verify the
> quality or compliance*.
>
> In my option *this approach prioritizes availability and community* without
> adding extra burden on the project or making promises that we can not keep
> if the vendor decides to abandon the HAL
>
> Best regards
> Alin
>
>
>
>
> On Wed, Oct 21, 2026 at 2:35 PM Alan C. Assis <ac...@gmail.com> wrote:
>
> > Hi Binh,
> >
> > I think option 2 (Vendor-hosted HAL) is an issue for NuttX, because if
> the
> > vendor stops contributing, users won't be able to get their PR integrated
> > into the HAL, this is a situation we realize recently we can face very
> > easily.
> >
> > My suggestion is: HALs that can't be hosted at ASF should be hosted at
> > github.com/NuttX/HALS/vendor-hal-name (or any other github account under
> > the control of the NuttX community).
> >
> > You forgot option 3: create the native port. In fact, people from Renesas
> > USA are doing it righ now (RA4 and RA8 were integrated this way). This is
> > the preferred way.
> >
> > BR,
> >
> > Alan
> >
> > On Tue, Oct 20, 2026 at 11:28 PM Binh Nguyen <binh.nguyen.xw@renesas.com
> >
> > wrote:
> >
> > > Hi all,
> > >
> > > I think we may have enough information to start evaluating what a
> > > reasonable model for supporting vendor HALs in NuttX should look like.
> > >
> > > Based on the discussion, I see two possible models:
> > >
> > > 1. ASF-hosted HAL: Vendor provides an SGA and completes ASF IP
> clearance;
> > > the HAL is maintained under ASF/NuttX while the vendor retains rights
> to
> > > its original code.
> > >
> > > 2. Vendor-hosted HAL: Vendor retains and maintains the HAL in its own
> > > repository, with NuttX integrating and supporting it externally.
> > >
> > > Could we evaluate whether either or both of these models could work for
> > > NuttX, so that we can move forward with official vendor HAL support?
> > >
> > >
> > > Thanks,
> > > Binh
> > >
> > > -----Original Message-----
> > > From: Justin Mclean <jm...@apache.org>
> > > Sent: Tuesday, October 20, 2026 6:24 PM
> > > To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> > > Subject: Re: Proposal: host vendor HAL repositories under
> > github.com/NuttX
> > >
> > > Hi,
> > >
> > > A few points in this thread about ASF policy need correcting.
> > >
> > > A software grant (SGA) is a licence, not a transfer of ownership.
> > > Espressif would keep the copyright and could keep using and licensing
> the
> > > HAL however it likes. The ASF does not become the sole owner. From
> > > https://www.apache.org/licenses/: "In all cases, contributors retain
> > full
> > > rights to use their original contributions for any other purpose
> outside
> > of
> > > Apache while providing the ASF and its projects the right to distribute
> > and
> > > build upon their work within Apache."
> > >
> > > Espressif's CCLA is not enough on its own. It covers contributions from
> > > its listed employees, not an existing code base developed outside the
> > ASF.
> > > Bringing esp-hal-3rdparty into an ASF repository needs a software grant
> > > from Espressif and IP clearance, see
> > > https://incubator.apache.org/ip-clearance/. The PMC does the paperwork
> > > and the Incubator approves it by lazy consensus. The PMC also needs to
> > > check the licences of any third-party code inside the HAL.
> > >
> > > github.com/NuttX is not controlled by the ASF, so it is not "under our
> > > control". Code the project maintains must be housed in ASF
> repositories,
> > > see https://infra.apache.org/project-repo-policy.html. That rules out
> > > NuttX committers maintaining vendor HALs there.
> > >
> > > Thanks,
> > > Justin
> > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Alin Jerpelea <je...@gmail.com>]

Hi Alan,

@Justin Mclean <ju...@classsoftware.com> thanks for the clarification

I think that we should encourage this order and start a vote regarding
updating the documentation to help vendors decide.

option 1: preferred way ->create the native NuttX port which can be
maintained by community (including vendor representatives with CLA) under
the project repo.. This option provides *compatibility, compliance, *and
ensures *long term maintenance* from vendor and community
option 2: approved way ->vedor signs SGA and move vendor HAL under ASF.
This option provides *compliance*, and ensures *long term maintenance* from
vendor and community
option 3: HAL maintained outside ASF should be mentioned in documentation
but treated like every other Open Source component that NuttX imports (Ex:
machine learning). it is supported but *we can not guaranty or verify the
quality or compliance*.

In my option *this approach prioritizes availability and community* without
adding extra burden on the project or making promises that we can not keep
if the vendor decides to abandon the HAL

Best regards
Alin




On Wed, Oct 21, 2026 at 2:35 PM Alan C. Assis <ac...@gmail.com> wrote:

> Hi Binh,
>
> I think option 2 (Vendor-hosted HAL) is an issue for NuttX, because if the
> vendor stops contributing, users won't be able to get their PR integrated
> into the HAL, this is a situation we realize recently we can face very
> easily.
>
> My suggestion is: HALs that can't be hosted at ASF should be hosted at
> github.com/NuttX/HALS/vendor-hal-name (or any other github account under
> the control of the NuttX community).
>
> You forgot option 3: create the native port. In fact, people from Renesas
> USA are doing it righ now (RA4 and RA8 were integrated this way). This is
> the preferred way.
>
> BR,
>
> Alan
>
> On Tue, Oct 20, 2026 at 11:28 PM Binh Nguyen <bi...@renesas.com>
> wrote:
>
> > Hi all,
> >
> > I think we may have enough information to start evaluating what a
> > reasonable model for supporting vendor HALs in NuttX should look like.
> >
> > Based on the discussion, I see two possible models:
> >
> > 1. ASF-hosted HAL: Vendor provides an SGA and completes ASF IP clearance;
> > the HAL is maintained under ASF/NuttX while the vendor retains rights to
> > its original code.
> >
> > 2. Vendor-hosted HAL: Vendor retains and maintains the HAL in its own
> > repository, with NuttX integrating and supporting it externally.
> >
> > Could we evaluate whether either or both of these models could work for
> > NuttX, so that we can move forward with official vendor HAL support?
> >
> >
> > Thanks,
> > Binh
> >
> > -----Original Message-----
> > From: Justin Mclean <jm...@apache.org>
> > Sent: Tuesday, October 20, 2026 6:24 PM
> > To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> > Subject: Re: Proposal: host vendor HAL repositories under
> github.com/NuttX
> >
> > Hi,
> >
> > A few points in this thread about ASF policy need correcting.
> >
> > A software grant (SGA) is a licence, not a transfer of ownership.
> > Espressif would keep the copyright and could keep using and licensing the
> > HAL however it likes. The ASF does not become the sole owner. From
> > https://www.apache.org/licenses/: "In all cases, contributors retain
> full
> > rights to use their original contributions for any other purpose outside
> of
> > Apache while providing the ASF and its projects the right to distribute
> and
> > build upon their work within Apache."
> >
> > Espressif's CCLA is not enough on its own. It covers contributions from
> > its listed employees, not an existing code base developed outside the
> ASF.
> > Bringing esp-hal-3rdparty into an ASF repository needs a software grant
> > from Espressif and IP clearance, see
> > https://incubator.apache.org/ip-clearance/. The PMC does the paperwork
> > and the Incubator approves it by lazy consensus. The PMC also needs to
> > check the licences of any third-party code inside the HAL.
> >
> > github.com/NuttX is not controlled by the ASF, so it is not "under our
> > control". Code the project maintains must be housed in ASF repositories,
> > see https://infra.apache.org/project-repo-policy.html. That rules out
> > NuttX committers maintaining vendor HALs there.
> >
> > Thanks,
> > Justin
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

["Alan C. Assis" <ac...@gmail.com>]

Hi Binh,

I think option 2 (Vendor-hosted HAL) is an issue for NuttX, because if the
vendor stops contributing, users won't be able to get their PR integrated
into the HAL, this is a situation we realize recently we can face very
easily.

My suggestion is: HALs that can't be hosted at ASF should be hosted at
github.com/NuttX/HALS/vendor-hal-name (or any other github account under
the control of the NuttX community).

You forgot option 3: create the native port. In fact, people from Renesas
USA are doing it righ now (RA4 and RA8 were integrated this way). This is
the preferred way.

BR,

Alan

On Tue, Oct 20, 2026 at 11:28 PM Binh Nguyen <bi...@renesas.com>
wrote:

> Hi all,
>
> I think we may have enough information to start evaluating what a
> reasonable model for supporting vendor HALs in NuttX should look like.
>
> Based on the discussion, I see two possible models:
>
> 1. ASF-hosted HAL: Vendor provides an SGA and completes ASF IP clearance;
> the HAL is maintained under ASF/NuttX while the vendor retains rights to
> its original code.
>
> 2. Vendor-hosted HAL: Vendor retains and maintains the HAL in its own
> repository, with NuttX integrating and supporting it externally.
>
> Could we evaluate whether either or both of these models could work for
> NuttX, so that we can move forward with official vendor HAL support?
>
>
> Thanks,
> Binh
>
> -----Original Message-----
> From: Justin Mclean <jm...@apache.org>
> Sent: Tuesday, October 20, 2026 6:24 PM
> To: dev@nuttx.apache.org <de...@nuttx.apache.org>
> Subject: Re: Proposal: host vendor HAL repositories under github.com/NuttX
>
> Hi,
>
> A few points in this thread about ASF policy need correcting.
>
> A software grant (SGA) is a licence, not a transfer of ownership.
> Espressif would keep the copyright and could keep using and licensing the
> HAL however it likes. The ASF does not become the sole owner. From
> https://www.apache.org/licenses/: "In all cases, contributors retain full
> rights to use their original contributions for any other purpose outside of
> Apache while providing the ASF and its projects the right to distribute and
> build upon their work within Apache."
>
> Espressif's CCLA is not enough on its own. It covers contributions from
> its listed employees, not an existing code base developed outside the ASF.
> Bringing esp-hal-3rdparty into an ASF repository needs a software grant
> from Espressif and IP clearance, see
> https://incubator.apache.org/ip-clearance/. The PMC does the paperwork
> and the Incubator approves it by lazy consensus. The PMC also needs to
> check the licences of any third-party code inside the HAL.
>
> github.com/NuttX is not controlled by the ASF, so it is not "under our
> control". Code the project maintains must be housed in ASF repositories,
> see https://infra.apache.org/project-repo-policy.html. That rules out
> NuttX committers maintaining vendor HALs there.
>
> Thanks,
> Justin
>

RE: Proposal: host vendor HAL repositories under github.com/NuttX

[Binh Nguyen <bi...@renesas.com>]

Hi all,

I think we may have enough information to start evaluating what a reasonable model for supporting vendor HALs in NuttX should look like.

Based on the discussion, I see two possible models:

1. ASF-hosted HAL: Vendor provides an SGA and completes ASF IP clearance; the HAL is maintained under ASF/NuttX while the vendor retains rights to its original code.

2. Vendor-hosted HAL: Vendor retains and maintains the HAL in its own repository, with NuttX integrating and supporting it externally.

Could we evaluate whether either or both of these models could work for NuttX, so that we can move forward with official vendor HAL support?


Thanks,
Binh

-----Original Message-----
From: Justin Mclean <jm...@apache.org>
Sent: Tuesday, October 20, 2026 6:24 PM
To: dev@nuttx.apache.org <de...@nuttx.apache.org>
Subject: Re: Proposal: host vendor HAL repositories under github.com/NuttX

Hi,

A few points in this thread about ASF policy need correcting.

A software grant (SGA) is a licence, not a transfer of ownership. Espressif would keep the copyright and could keep using and licensing the HAL however it likes. The ASF does not become the sole owner. From https://www.apache.org/licenses/: "In all cases, contributors retain full rights to use their original contributions for any other purpose outside of Apache while providing the ASF and its projects the right to distribute and build upon their work within Apache."

Espressif's CCLA is not enough on its own. It covers contributions from its listed employees, not an existing code base developed outside the ASF. Bringing esp-hal-3rdparty into an ASF repository needs a software grant from Espressif and IP clearance, see https://incubator.apache.org/ip-clearance/. The PMC does the paperwork and the Incubator approves it by lazy consensus. The PMC also needs to check the licences of any third-party code inside the HAL.

github.com/NuttX is not controlled by the ASF, so it is not "under our control". Code the project maintains must be housed in ASF repositories, see https://infra.apache.org/project-repo-policy.html. That rules out NuttX committers maintaining vendor HALs there.

Thanks,
Justin

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Gregory Nutt <sp...@gmail.com>]

________________________________
From: Justin Mclean <jm...@apache.org>
Sent: Tuesday, October 20, 2026 6:24 PM
To: dev@nuttx.apache.org <de...@nuttx.apache.org>
Subject: Re: Proposal: host vendor HAL repositories under github.com/NuttX

Hi,

A few points in this thread about ASF policy need correcting.

Thanks for the clarification about ownership.  I think I am the one who injected that word into the conversation.

A software grant (SGA) is a licence, not a transfer of ownership. Espressif would keep the copyright and could keep using and licensing the HAL however it likes. The ASF does not become the sole owner. From https://www.apache.org/licenses/: “In all cases, contributors retain full rights to use their original contributions for any other purpose outside of Apache while providing the ASF and its projects the right to distribute and build upon their work within Apache.”

Espressif’s CCLA is not enough on its own. It covers contributions from its listed employees, not an existing code base developed outside the ASF. Bringing esp-hal-3rdparty into an ASF repository needs a software grant from Espressif and IP clearance, see https://incubator.apache.org/ip-clearance/. The PMC does the paperwork and the Incubator approves it by lazy consensus. The PMC also needs to check the licences of any third-party code inside the HAL.

Would this set the Copyright holder to the ASF?  If so then would any version used by the vendor necessarily be a different version, no under the ASF repository, with a different copyright?

Or do you mean this would be 3rd part code retained in the NuttX repository under the vendor's license?

github.com/NuttX is not controlled by the ASF, so it is not “under our control”. Code the project maintains must be housed in ASF repositories, see https://infra.apache.org/project-repo-policy.html. That rules out NuttX committers maintaining vendor HALs there.

""Vendor HALs" being what?  A version of the HAL with vendor's copyright?  Or a version of the HAL maintained outside of the NuttX repository.

Greg

PS:  Its been awhile, I hope things have good with you.  I am glad to see you involved.  I will stop injecting misinformation.

Thanks,
Justin

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Justin Mclean <jm...@apache.org>]

Hi,

A few points in this thread about ASF policy need correcting.

A software grant (SGA) is a licence, not a transfer of ownership. Espressif would keep the copyright and could keep using and licensing the HAL however it likes. The ASF does not become the sole owner. From https://www.apache.org/licenses/: “In all cases, contributors retain full rights to use their original contributions for any other purpose outside of Apache while providing the ASF and its projects the right to distribute and build upon their work within Apache.”

Espressif’s CCLA is not enough on its own. It covers contributions from its listed employees, not an existing code base developed outside the ASF. Bringing esp-hal-3rdparty into an ASF repository needs a software grant from Espressif and IP clearance, see https://incubator.apache.org/ip-clearance/. The PMC does the paperwork and the Incubator approves it by lazy consensus. The PMC also needs to check the licences of any third-party code inside the HAL.

github.com/NuttX is not controlled by the ASF, so it is not “under our control”. Code the project maintains must be housed in ASF repositories, see https://infra.apache.org/project-repo-policy.html. That rules out NuttX committers maintaining vendor HALs there.

Thanks,
Justin

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Matteo Golin <ma...@gmail.com>]

Could you please link to the PR, Felipe?

Best,
Matteo

On Tue, Sep 29, 2026, 2:29 a.m. Michal Lenc <mi...@seznam.cz> wrote:

> That's quite a weird approach. You find a bug in their codebase, but
> they won't merge the fix because of the discussion unrelated to the
> issue you fixed. To be honest, I see this as an argument for the
> independence of 3rd part repositories we can't (at least partially)
> control.
>
> Michal
>
> On 9/29/26 01:23, Felipe Moura Oliveira wrote:
> > Hi all,
> >
> > Just to bring this to your attention: on my recent PR to
> esp-hal-3rdparty,
> > an Espressif employee commented stating that support is paused until the
> > ongoing governance discussions are resolved.
> >
> > Best regards,
> >
> >
> > *--Felipe Moura de Oliveira*
> > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> >
> > On Mon, 28 Sep 2026 at 10:35 Felipe Moura Oliveira <mo...@gmail.com>
> > wrote:
> >
> >> Hi all,
> >>
> >> Following the recent discussion in the thread “Early feedback on RZ/V2H
> >> port and RZ FSP HAL dependency”, I would like to suggest applying the
> same
> >> idea discussed there to existing vendor HAL dependencies: hosting them
> >> under github.com/NuttX, while keeping them separate from the ASF
> >> repositories. This proposal is aligned with some opinions shared there.
> >>
> >> A practical example is esp-hal-3rdparty. I recently opened a very small
> >> fix there:
> >>
> >> https://github.com/espressif/esp-hal-3rdparty/pull/15
> >>
> >> The PR is still open without Espressif review. Interestingly, the
> >> technical feedback so far came from Laczen, a NuttX contributor who is
> not
> >> part of Espressif.
> >>
> >> This illustrates the issue when NuttX depends on a vendor repository but
> >> the vendor is temporarily unavailable to maintain or review it.
> >>
> >> Would it make sense to move esp-hal-3rdparty, and potentially similar
> >> vendor HAL repositories, under github.com/NuttX, with vendor
> maintainers
> >> when available but NuttX committers retaining the ability to review and
> >> maintain them when necessary?
> >>
> >> Best regards,
> >>
> >> *--Felipe Moura de Oliveira*
> >> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> >>
>
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hi Matteo,

Sorry for the delay in replying. Here is the link as requested:
https://github.com/espressif/esp-hal-3rdparty/pull/15

I am willing to make the adjustments suggested by Laczen, but I am
currently unsure if doing so will lead to it being merged.

Unfortunately, it is a frustrating situation. My solution depends on power
consumption, and I am improving what I can, but I ran into this issue which
seems to be tied to the Espressif HAL.

Best regards,


Em ter., 29 de set. de 2026 às 10:39, Tiago Medicci Serrano <
tiago.medicci@gmail.com> escreveu:

> Hi Matteo,
>
> Currently, only NuttX is using
> https://github.com/espressif/esp-hal-3rdparty.
> <
> https://github.com/espressif/esp-hal-3rdparty/pull/15#issuecomment-5874233033
> >
> The
> reason why freezing is necessary is explained better here
> <
> https://github.com/espressif/esp-hal-3rdparty/pull/15#issuecomment-5890483460
> >
> .
>
> Best,
>
> Em ter., 29 de set. de 2026 às 10:10, Matteo Golin <matteo.golin@gmail.com
> >
> escreveu:
>
> > Hello Tiago,
> >
> > Thanks for the clarification and link. May I ask why the freezing is
> > technically necessary for the transition? Is it due to potential future
> > merge conflict issues or something else? I was under the impression that
> > several other projects are using this HAL, and that the freezing might
> also
> > cause them some issues.
> >
> > Best,
> > Matteo
> >
> > On Tue, Sep 29, 2026 at 8:31 AM Tiago Medicci Serrano <
> > tiago.medicci@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Just to make it clear: the freezing (the comment can be seen here
> > > <
> > >
> >
> https://github.com/espressif/esp-hal-3rdparty/pull/15#issuecomment-5874233033
> > > >)
> > > is technically necessary to ease the transition. We've also stopped
> > > automatic sync so it doesn't create conflicts with existing versions.
> So,
> > > it isn't for the bad, but for the good of the community.
> > >
> > > We hope the transition can come fast. We've been discussing the best
> > > options for that.
> > >
> > > Best regards,
> > >
> > >
> > > Em ter., 29 de set. de 2026 às 03:29, Michal Lenc <
> michallenc@seznam.cz>
> > > escreveu:
> > >
> > > > That's quite a weird approach. You find a bug in their codebase, but
> > > > they won't merge the fix because of the discussion unrelated to the
> > > > issue you fixed. To be honest, I see this as an argument for the
> > > > independence of 3rd part repositories we can't (at least partially)
> > > > control.
> > > >
> > > > Michal
> > > >
> > > > On 9/29/26 01:23, Felipe Moura Oliveira wrote:
> > > > > Hi all,
> > > > >
> > > > > Just to bring this to your attention: on my recent PR to
> > > > esp-hal-3rdparty,
> > > > > an Espressif employee commented stating that support is paused
> until
> > > the
> > > > > ongoing governance discussions are resolved.
> > > > >
> > > > > Best regards,
> > > > >
> > > > >
> > > > > *--Felipe Moura de Oliveira*
> > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > > >
> > > > > On Mon, 28 Sep 2026 at 10:35 Felipe Moura Oliveira <
> > > moura.fmo@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >> Following the recent discussion in the thread “Early feedback on
> > > RZ/V2H
> > > > >> port and RZ FSP HAL dependency”, I would like to suggest applying
> > the
> > > > same
> > > > >> idea discussed there to existing vendor HAL dependencies: hosting
> > them
> > > > >> under github.com/NuttX, while keeping them separate from the ASF
> > > > >> repositories. This proposal is aligned with some opinions shared
> > > there.
> > > > >>
> > > > >> A practical example is esp-hal-3rdparty. I recently opened a very
> > > small
> > > > >> fix there:
> > > > >>
> > > > >> https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > > >>
> > > > >> The PR is still open without Espressif review. Interestingly, the
> > > > >> technical feedback so far came from Laczen, a NuttX contributor
> who
> > is
> > > > not
> > > > >> part of Espressif.
> > > > >>
> > > > >> This illustrates the issue when NuttX depends on a vendor
> repository
> > > but
> > > > >> the vendor is temporarily unavailable to maintain or review it.
> > > > >>
> > > > >> Would it make sense to move esp-hal-3rdparty, and potentially
> > similar
> > > > >> vendor HAL repositories, under github.com/NuttX, with vendor
> > > > maintainers
> > > > >> when available but NuttX committers retaining the ability to
> review
> > > and
> > > > >> maintain them when necessary?
> > > > >>
> > > > >> Best regards,
> > > > >>
> > > > >> *--Felipe Moura de Oliveira*
> > > > >> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > > >>
> > > >
> > > >
> > >
> >
>


-- 

*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tiago Medicci Serrano <ti...@gmail.com>]

Hi Matteo,

Currently, only NuttX is using
https://github.com/espressif/esp-hal-3rdparty.
<https://github.com/espressif/esp-hal-3rdparty/pull/15#issuecomment-5874233033>
The
reason why freezing is necessary is explained better here
<https://github.com/espressif/esp-hal-3rdparty/pull/15#issuecomment-5890483460>
.

Best,

Em ter., 29 de set. de 2026 às 10:10, Matteo Golin <ma...@gmail.com>
escreveu:

> Hello Tiago,
>
> Thanks for the clarification and link. May I ask why the freezing is
> technically necessary for the transition? Is it due to potential future
> merge conflict issues or something else? I was under the impression that
> several other projects are using this HAL, and that the freezing might also
> cause them some issues.
>
> Best,
> Matteo
>
> On Tue, Sep 29, 2026 at 8:31 AM Tiago Medicci Serrano <
> tiago.medicci@gmail.com> wrote:
>
> > Hi,
> >
> > Just to make it clear: the freezing (the comment can be seen here
> > <
> >
> https://github.com/espressif/esp-hal-3rdparty/pull/15#issuecomment-5874233033
> > >)
> > is technically necessary to ease the transition. We've also stopped
> > automatic sync so it doesn't create conflicts with existing versions. So,
> > it isn't for the bad, but for the good of the community.
> >
> > We hope the transition can come fast. We've been discussing the best
> > options for that.
> >
> > Best regards,
> >
> >
> > Em ter., 29 de set. de 2026 às 03:29, Michal Lenc <mi...@seznam.cz>
> > escreveu:
> >
> > > That's quite a weird approach. You find a bug in their codebase, but
> > > they won't merge the fix because of the discussion unrelated to the
> > > issue you fixed. To be honest, I see this as an argument for the
> > > independence of 3rd part repositories we can't (at least partially)
> > > control.
> > >
> > > Michal
> > >
> > > On 9/29/26 01:23, Felipe Moura Oliveira wrote:
> > > > Hi all,
> > > >
> > > > Just to bring this to your attention: on my recent PR to
> > > esp-hal-3rdparty,
> > > > an Espressif employee commented stating that support is paused until
> > the
> > > > ongoing governance discussions are resolved.
> > > >
> > > > Best regards,
> > > >
> > > >
> > > > *--Felipe Moura de Oliveira*
> > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > >
> > > > On Mon, 28 Sep 2026 at 10:35 Felipe Moura Oliveira <
> > moura.fmo@gmail.com>
> > > > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> Following the recent discussion in the thread “Early feedback on
> > RZ/V2H
> > > >> port and RZ FSP HAL dependency”, I would like to suggest applying
> the
> > > same
> > > >> idea discussed there to existing vendor HAL dependencies: hosting
> them
> > > >> under github.com/NuttX, while keeping them separate from the ASF
> > > >> repositories. This proposal is aligned with some opinions shared
> > there.
> > > >>
> > > >> A practical example is esp-hal-3rdparty. I recently opened a very
> > small
> > > >> fix there:
> > > >>
> > > >> https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > >>
> > > >> The PR is still open without Espressif review. Interestingly, the
> > > >> technical feedback so far came from Laczen, a NuttX contributor who
> is
> > > not
> > > >> part of Espressif.
> > > >>
> > > >> This illustrates the issue when NuttX depends on a vendor repository
> > but
> > > >> the vendor is temporarily unavailable to maintain or review it.
> > > >>
> > > >> Would it make sense to move esp-hal-3rdparty, and potentially
> similar
> > > >> vendor HAL repositories, under github.com/NuttX, with vendor
> > > maintainers
> > > >> when available but NuttX committers retaining the ability to review
> > and
> > > >> maintain them when necessary?
> > > >>
> > > >> Best regards,
> > > >>
> > > >> *--Felipe Moura de Oliveira*
> > > >> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > >>
> > >
> > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Matteo Golin <ma...@gmail.com>]

Hello Tiago,

Thanks for the clarification and link. May I ask why the freezing is
technically necessary for the transition? Is it due to potential future
merge conflict issues or something else? I was under the impression that
several other projects are using this HAL, and that the freezing might also
cause them some issues.

Best,
Matteo

On Tue, Sep 29, 2026 at 8:31 AM Tiago Medicci Serrano <
tiago.medicci@gmail.com> wrote:

> Hi,
>
> Just to make it clear: the freezing (the comment can be seen here
> <
> https://github.com/espressif/esp-hal-3rdparty/pull/15#issuecomment-5874233033
> >)
> is technically necessary to ease the transition. We've also stopped
> automatic sync so it doesn't create conflicts with existing versions. So,
> it isn't for the bad, but for the good of the community.
>
> We hope the transition can come fast. We've been discussing the best
> options for that.
>
> Best regards,
>
>
> Em ter., 29 de set. de 2026 às 03:29, Michal Lenc <mi...@seznam.cz>
> escreveu:
>
> > That's quite a weird approach. You find a bug in their codebase, but
> > they won't merge the fix because of the discussion unrelated to the
> > issue you fixed. To be honest, I see this as an argument for the
> > independence of 3rd part repositories we can't (at least partially)
> > control.
> >
> > Michal
> >
> > On 9/29/26 01:23, Felipe Moura Oliveira wrote:
> > > Hi all,
> > >
> > > Just to bring this to your attention: on my recent PR to
> > esp-hal-3rdparty,
> > > an Espressif employee commented stating that support is paused until
> the
> > > ongoing governance discussions are resolved.
> > >
> > > Best regards,
> > >
> > >
> > > *--Felipe Moura de Oliveira*
> > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > >
> > > On Mon, 28 Sep 2026 at 10:35 Felipe Moura Oliveira <
> moura.fmo@gmail.com>
> > > wrote:
> > >
> > >> Hi all,
> > >>
> > >> Following the recent discussion in the thread “Early feedback on
> RZ/V2H
> > >> port and RZ FSP HAL dependency”, I would like to suggest applying the
> > same
> > >> idea discussed there to existing vendor HAL dependencies: hosting them
> > >> under github.com/NuttX, while keeping them separate from the ASF
> > >> repositories. This proposal is aligned with some opinions shared
> there.
> > >>
> > >> A practical example is esp-hal-3rdparty. I recently opened a very
> small
> > >> fix there:
> > >>
> > >> https://github.com/espressif/esp-hal-3rdparty/pull/15
> > >>
> > >> The PR is still open without Espressif review. Interestingly, the
> > >> technical feedback so far came from Laczen, a NuttX contributor who is
> > not
> > >> part of Espressif.
> > >>
> > >> This illustrates the issue when NuttX depends on a vendor repository
> but
> > >> the vendor is temporarily unavailable to maintain or review it.
> > >>
> > >> Would it make sense to move esp-hal-3rdparty, and potentially similar
> > >> vendor HAL repositories, under github.com/NuttX, with vendor
> > maintainers
> > >> when available but NuttX committers retaining the ability to review
> and
> > >> maintain them when necessary?
> > >>
> > >> Best regards,
> > >>
> > >> *--Felipe Moura de Oliveira*
> > >> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > >>
> >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tiago Medicci Serrano <ti...@gmail.com>]

Hi,

Just to make it clear: the freezing (the comment can be seen here
<https://github.com/espressif/esp-hal-3rdparty/pull/15#issuecomment-5874233033>)
is technically necessary to ease the transition. We've also stopped
automatic sync so it doesn't create conflicts with existing versions. So,
it isn't for the bad, but for the good of the community.

We hope the transition can come fast. We've been discussing the best
options for that.

Best regards,


Em ter., 29 de set. de 2026 às 03:29, Michal Lenc <mi...@seznam.cz>
escreveu:

> That's quite a weird approach. You find a bug in their codebase, but
> they won't merge the fix because of the discussion unrelated to the
> issue you fixed. To be honest, I see this as an argument for the
> independence of 3rd part repositories we can't (at least partially)
> control.
>
> Michal
>
> On 9/29/26 01:23, Felipe Moura Oliveira wrote:
> > Hi all,
> >
> > Just to bring this to your attention: on my recent PR to
> esp-hal-3rdparty,
> > an Espressif employee commented stating that support is paused until the
> > ongoing governance discussions are resolved.
> >
> > Best regards,
> >
> >
> > *--Felipe Moura de Oliveira*
> > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> >
> > On Mon, 28 Sep 2026 at 10:35 Felipe Moura Oliveira <mo...@gmail.com>
> > wrote:
> >
> >> Hi all,
> >>
> >> Following the recent discussion in the thread “Early feedback on RZ/V2H
> >> port and RZ FSP HAL dependency”, I would like to suggest applying the
> same
> >> idea discussed there to existing vendor HAL dependencies: hosting them
> >> under github.com/NuttX, while keeping them separate from the ASF
> >> repositories. This proposal is aligned with some opinions shared there.
> >>
> >> A practical example is esp-hal-3rdparty. I recently opened a very small
> >> fix there:
> >>
> >> https://github.com/espressif/esp-hal-3rdparty/pull/15
> >>
> >> The PR is still open without Espressif review. Interestingly, the
> >> technical feedback so far came from Laczen, a NuttX contributor who is
> not
> >> part of Espressif.
> >>
> >> This illustrates the issue when NuttX depends on a vendor repository but
> >> the vendor is temporarily unavailable to maintain or review it.
> >>
> >> Would it make sense to move esp-hal-3rdparty, and potentially similar
> >> vendor HAL repositories, under github.com/NuttX, with vendor
> maintainers
> >> when available but NuttX committers retaining the ability to review and
> >> maintain them when necessary?
> >>
> >> Best regards,
> >>
> >> *--Felipe Moura de Oliveira*
> >> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> >>
>
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Michal Lenc <mi...@seznam.cz>]

That's quite a weird approach. You find a bug in their codebase, but 
they won't merge the fix because of the discussion unrelated to the 
issue you fixed. To be honest, I see this as an argument for the 
independence of 3rd part repositories we can't (at least partially) control.

Michal

On 9/29/26 01:23, Felipe Moura Oliveira wrote:
> Hi all,
>
> Just to bring this to your attention: on my recent PR to esp-hal-3rdparty,
> an Espressif employee commented stating that support is paused until the
> ongoing governance discussions are resolved.
>
> Best regards,
>
>
> *--Felipe Moura de Oliveira*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> On Mon, 28 Sep 2026 at 10:35 Felipe Moura Oliveira <mo...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> Following the recent discussion in the thread “Early feedback on RZ/V2H
>> port and RZ FSP HAL dependency”, I would like to suggest applying the same
>> idea discussed there to existing vendor HAL dependencies: hosting them
>> under github.com/NuttX, while keeping them separate from the ASF
>> repositories. This proposal is aligned with some opinions shared there.
>>
>> A practical example is esp-hal-3rdparty. I recently opened a very small
>> fix there:
>>
>> https://github.com/espressif/esp-hal-3rdparty/pull/15
>>
>> The PR is still open without Espressif review. Interestingly, the
>> technical feedback so far came from Laczen, a NuttX contributor who is not
>> part of Espressif.
>>
>> This illustrates the issue when NuttX depends on a vendor repository but
>> the vendor is temporarily unavailable to maintain or review it.
>>
>> Would it make sense to move esp-hal-3rdparty, and potentially similar
>> vendor HAL repositories, under github.com/NuttX, with vendor maintainers
>> when available but NuttX committers retaining the ability to review and
>> maintain them when necessary?
>>
>> Best regards,
>>
>> *--Felipe Moura de Oliveira*
>> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hi all,

Just to bring this to your attention: on my recent PR to esp-hal-3rdparty,
an Espressif employee commented stating that support is paused until the
ongoing governance discussions are resolved.

Best regards,


*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

On Mon, 28 Sep 2026 at 10:35 Felipe Moura Oliveira <mo...@gmail.com>
wrote:

> Hi all,
>
> Following the recent discussion in the thread “Early feedback on RZ/V2H
> port and RZ FSP HAL dependency”, I would like to suggest applying the same
> idea discussed there to existing vendor HAL dependencies: hosting them
> under github.com/NuttX, while keeping them separate from the ASF
> repositories. This proposal is aligned with some opinions shared there.
>
> A practical example is esp-hal-3rdparty. I recently opened a very small
> fix there:
>
> https://github.com/espressif/esp-hal-3rdparty/pull/15
>
> The PR is still open without Espressif review. Interestingly, the
> technical feedback so far came from Laczen, a NuttX contributor who is not
> part of Espressif.
>
> This illustrates the issue when NuttX depends on a vendor repository but
> the vendor is temporarily unavailable to maintain or review it.
>
> Would it make sense to move esp-hal-3rdparty, and potentially similar
> vendor HAL repositories, under github.com/NuttX, with vendor maintainers
> when available but NuttX committers retaining the ability to review and
> maintain them when necessary?
>
> Best regards,
>
> *--Felipe Moura de Oliveira*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Matteo Golin <ma...@gmail.com>]

Thank you Tiago and Felipe for the clarification! I misunderstood who was
using the esp-hal-3rdparty repository; I thought it was shared by multiple
projects, hence the vendor preference for an external HAL.

Just so I can understand, the `esp-hal-3rdparty` repository is a public
facing version of an internal HAL repository to collect contributions from
the public (?), and it is the version used only for NuttX?

   - Are there other public-facing versions of the same internal HAL used
   by other projects? Ex: does Zephyr have a similar repository for
   contributing their own patches?
   - Once patches are merged into `esp-hal-3rdparty` (or the corresponding
   repository for other projects like Zephyr), my understanding from your
   linked comment is that there is an Espressif auto-sync tool internally that
   syncs these patches with the private, internal HAL repository?
   - Does "push-based" repository just mean that pushes to the
   `esp-hal-3rdparty` get synced to some internal repo (not necessarily on
   GitHub, but on some internal version control)?

I am also still not fully clear why the freeze helps prevent technical
issues. Is it:

   - To potentially save work of converting the external `esp-hal-3rdparty`
   repo to a NuttX-owned repository?
   - Because the specific PR in question would cause version conflicts with
   the internal HAL repository?
   - Because a NuttX-owned repository would no longer be compatible with
   the internal sync tool, and thus patches applied to NuttX would have to be
   manually back-ported to the internal HAL repository so other projects (i.e.
   Zephyr) can benefit?
   - Some other reason?

If it's the first reason, my suggestion would be to continue merging
patches under the assumption that there will not be a change. I don't
necessarily think that the NuttX will reach an agreement on this topic
soon, and freezing patches in the meantime will cause more issues instead.
I think if NuttX decides to require some governance over external HALs,
that transition can be reasonably expected to be slow and we would have
good-faith collaboration with the affected vendors to help ease that
transition.

Thank you again for the transparency, I understand that this is probably
causing some headaches for you and Espressif.

Matteo

On Tue, Sep 29, 2026 at 11:12 AM Tomek CEDRO <to...@cedro.info> wrote:

> On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> <mo...@gmail.com> wrote:
> >
> > Hi all,
> >
> > Following the recent discussion in the thread “Early feedback on RZ/V2H
> > port and RZ FSP HAL dependency”, I would like to suggest applying the
> same
> > idea discussed there to existing vendor HAL dependencies: hosting them
> > under github.com/NuttX, while keeping them separate from the ASF
> > repositories. This proposal is aligned with some opinions shared there.
> >
> > A practical example is esp-hal-3rdparty. I recently opened a very small
> fix
> > there:
> >
> > https://github.com/espressif/esp-hal-3rdparty/pull/15
> >
> > The PR is still open without Espressif review. Interestingly, the
> technical
> > feedback so far came from Laczen, a NuttX contributor who is not part of
> > Espressif.
> >
> > This illustrates the issue when NuttX depends on a vendor repository but
> > the vendor is temporarily unavailable to maintain or review it.
> >
> > Would it make sense to move esp-hal-3rdparty, and potentially similar
> > vendor HAL repositories, under github.com/NuttX, with vendor maintainers
> > when available but NuttX committers retaining the ability to review and
> > maintain them when necessary?
> >
> > Best regards,
> >
> > *--Felipe Moura de Oliveira*
> > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> I am still opponent of any external HAL/SDK in NuttX, it only brings
> problems in the long run, but if this particular HAL is already here
> we may try to experiment with it (and only this one for now) under
> github.com/nuttx umbrella to see if this approach would really solve
> any problems or add new problems. Time will tell and we can always
> fallback to the current vendor provided and controlled HAL if that
> approach fails for any reason?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Matteo Golin <ma...@gmail.com>]

Hi Ahmed,

Could you copy that suggestion to the thread here where we're discussing
the format for HAL interfaces?
https://www.mail-archive.com/dev@nuttx.apache.org/msg15150.html
That way your suggestion doesn't get lost in this unrelated thread.

Best,
Matteo

On Tue, Sep 29, 2026 at 12:40 PM Ahmed Ashraf <a....@gmail.com>
wrote:

> Hi all,
>
> I’m relatively new to the discussion, but I was wondering if we could also
> consider an approach similar to how Zephyr handles vendor HALs.
>
> Instead of introducing a universal adapter between NuttX and every vendor
> HAL, perhaps the boundary could simply be:
>
> Generic NuttX API
>                  |
>     NuttX driver
>       /.                 \
>    native      vendor HAL
>       \                   /
>         hardware
>
> The driver would integrate only the functionality that NuttX actually needs
> from the vendor HAL. For simple peripherals, the driver could use a native
> implementation directly, while more complex platforms could reuse the
> vendor HAL.
>
> The vendor HAL itself could remain an external, version-pinned dependency
> managed by the NuttX build system.
>
> This seems to avoid the need to implement and maintain a general-purpose
> adapter for an entire vendor SDK, while still allowing NuttX to benefit
> from existing vendor implementations.
>
> Zephyr uses a similar principle: vendor HALs can remain external modules,
> while the Zephyr drivers provide the integration with the generic Zephyr
> APIs.
>
> I’m curious what others think about this approach, especially regarding the
> amount of integration and long-term maintenance work compared with
> maintaining the HAL under the NuttX umbrella.
>
> Best regards,
> Ahmed
>
> On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:
>
> > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > <mo...@gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > Following the recent discussion in the thread “Early feedback on RZ/V2H
> > > port and RZ FSP HAL dependency”, I would like to suggest applying the
> > same
> > > idea discussed there to existing vendor HAL dependencies: hosting them
> > > under github.com/NuttX, while keeping them separate from the ASF
> > > repositories. This proposal is aligned with some opinions shared there.
> > >
> > > A practical example is esp-hal-3rdparty. I recently opened a very small
> > fix
> > > there:
> > >
> > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > >
> > > The PR is still open without Espressif review. Interestingly, the
> > technical
> > > feedback so far came from Laczen, a NuttX contributor who is not part
> of
> > > Espressif.
> > >
> > > This illustrates the issue when NuttX depends on a vendor repository
> but
> > > the vendor is temporarily unavailable to maintain or review it.
> > >
> > > Would it make sense to move esp-hal-3rdparty, and potentially similar
> > > vendor HAL repositories, under github.com/NuttX, with vendor
> maintainers
> > > when available but NuttX committers retaining the ability to review and
> > > maintain them when necessary?
> > >
> > > Best regards,
> > >
> > > *--Felipe Moura de Oliveira*
> > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> >
> > I am still opponent of any external HAL/SDK in NuttX, it only brings
> > problems in the long run, but if this particular HAL is already here
> > we may try to experiment with it (and only this one for now) under
> > github.com/nuttx umbrella to see if this approach would really solve
> > any problems or add new problems. Time will tell and we can always
> > fallback to the current vendor provided and controlled HAL if that
> > approach fails for any reason?
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tomek CEDRO <to...@cedro.info>]

Unless the vote is updated.. and I think it will because Tiago and
Espressif proposition fulfills all requests from the community
mentioned in all these HAL related threads :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

On Sat, Oct 3, 2026 at 12:56 AM Felipe Moura Oliveira
<mo...@gmail.com> wrote:
>
> As I remember I saw at least one -1. It is enough to reject the proposal.
> Am I wrong ?
>
>
>
> *--Felipe Moura de Oliveira*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> On Fri, 2 Oct 2026 at 21:43 Gregory Nutt <sp...@gmail.com> wrote:
>
> >
> > The last remaining question here is whether it is okay to Apache to
> > accept such donation. If yes then we can create
> > apache/nuttx-hal-espressif repo and work on it just as any other
> > apache/nuttx-* repo. I guess this hal needs to be a separate repo
> > because Espressif still want to have local clone for validation /
> > development.
> >
> > That is an option if and if the HAL is granted to the ASF.  Otherwise,
> > what you suggesting might be prohibited by the ASF.  I would have to do
> > more research to understand that fully.
> >
> >
> >

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

As I remember I saw at least one -1. It is enough to reject the proposal.
Am I wrong ?



*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

On Fri, 2 Oct 2026 at 21:43 Gregory Nutt <sp...@gmail.com> wrote:

>
> The last remaining question here is whether it is okay to Apache to
> accept such donation. If yes then we can create
> apache/nuttx-hal-espressif repo and work on it just as any other
> apache/nuttx-* repo. I guess this hal needs to be a separate repo
> because Espressif still want to have local clone for validation /
> development.
>
> That is an option if and if the HAL is granted to the ASF.  Otherwise,
> what you suggesting might be prohibited by the ASF.  I would have to do
> more research to understand that fully.
>
>
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Xiang Xiao <xi...@gmail.com>]

It is better to let chip vendors choose whether to donate HAL to ASF or
host HAL on github.com/NuttX.
The community prefers Host with ASF, but accepts with NuttX.

Thanks
Xiang

On Sat, Oct 3, 2026 at 9:29 AM Felipe Moura Oliveira <mo...@gmail.com>
wrote:

> Hi all,
>
> Way back, Espressif introduced the esp-hal-3rdparty repository for NuttX,
> and here we are today. A few weeks ago, Tiago mentioned that Espressif
> would follow whatever direction the community suggested, but now they are
> proposing a specific path.
>
> If we follow this approach, where does that leave us regarding other
> vendors? My concern is that NuttX might become too tightly coupled with
> Espressif.
>
> That said, I understand the points made and won't push this further.
>
> Best regards,
>
>
> *--Felipe Moura de Oliveira*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> On Fri, 2 Oct 2026 at 22:13 Tomek CEDRO <to...@cedro.info> wrote:
>
> > On Sat, Oct 3, 2026 at 12:43 AM Gregory Nutt <sp...@gmail.com>
> wrote:
> > > The last remaining question here is whether it is okay to Apache to
> > > accept such donation. If yes then we can create
> > > apache/nuttx-hal-espressif repo and work on it just as any other
> > > apache/nuttx-* repo. I guess this hal needs to be a separate repo
> > > because Espressif still want to have local clone for validation /
> > > development.
> > >
> > > That is an option if and if the HAL is granted to the ASF.  Otherwise,
> > what you suggesting might be prohibited by the ASF.  I would have to do
> > more research to understand that fully.
> >
> > Yes exactly Tiago underlined that several times that they will
> > "donate" their HAL to ASF so it becomes apache/nuttx-hal-espressif and
> > the whole community is more involved.. this is very honorable step
> > from Espressif and they again seem to pave the way for HAL integration
> > in NuttX in the least painful possible way.. at the same time taking
> > care of software supply chain :-)
> >
> > Most of the raised issues should be solved that way:
> > 1. Code ownership and supply chain security.
> > 2. Community involvement in faster PR processing.
> > 3. We should have more control and impact on the HAL quality and
> > availability.
> > 4. HAL is under the NuttX umbrella just as proposed "Zephyr Umbrella
> > Way" (also proposed by Renesas).
> >
> > I guess ASF should not have problem with accepting such aleady Apache
> > 2.0 licensed code. Maybe only ICLAs should be obtained from all
> > existing authors?
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hi all,

Way back, Espressif introduced the esp-hal-3rdparty repository for NuttX,
and here we are today. A few weeks ago, Tiago mentioned that Espressif
would follow whatever direction the community suggested, but now they are
proposing a specific path.

If we follow this approach, where does that leave us regarding other
vendors? My concern is that NuttX might become too tightly coupled with
Espressif.

That said, I understand the points made and won't push this further.

Best regards,


*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

On Fri, 2 Oct 2026 at 22:13 Tomek CEDRO <to...@cedro.info> wrote:

> On Sat, Oct 3, 2026 at 12:43 AM Gregory Nutt <sp...@gmail.com> wrote:
> > The last remaining question here is whether it is okay to Apache to
> > accept such donation. If yes then we can create
> > apache/nuttx-hal-espressif repo and work on it just as any other
> > apache/nuttx-* repo. I guess this hal needs to be a separate repo
> > because Espressif still want to have local clone for validation /
> > development.
> >
> > That is an option if and if the HAL is granted to the ASF.  Otherwise,
> what you suggesting might be prohibited by the ASF.  I would have to do
> more research to understand that fully.
>
> Yes exactly Tiago underlined that several times that they will
> "donate" their HAL to ASF so it becomes apache/nuttx-hal-espressif and
> the whole community is more involved.. this is very honorable step
> from Espressif and they again seem to pave the way for HAL integration
> in NuttX in the least painful possible way.. at the same time taking
> care of software supply chain :-)
>
> Most of the raised issues should be solved that way:
> 1. Code ownership and supply chain security.
> 2. Community involvement in faster PR processing.
> 3. We should have more control and impact on the HAL quality and
> availability.
> 4. HAL is under the NuttX umbrella just as proposed "Zephyr Umbrella
> Way" (also proposed by Renesas).
>
> I guess ASF should not have problem with accepting such aleady Apache
> 2.0 licensed code. Maybe only ICLAs should be obtained from all
> existing authors?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tomek CEDRO <to...@cedro.info>]

On Sat, Oct 3, 2026 at 12:43 AM Gregory Nutt <sp...@gmail.com> wrote:
> The last remaining question here is whether it is okay to Apache to
> accept such donation. If yes then we can create
> apache/nuttx-hal-espressif repo and work on it just as any other
> apache/nuttx-* repo. I guess this hal needs to be a separate repo
> because Espressif still want to have local clone for validation /
> development.
>
> That is an option if and if the HAL is granted to the ASF.  Otherwise, what you suggesting might be prohibited by the ASF.  I would have to do more research to understand that fully.

Yes exactly Tiago underlined that several times that they will
"donate" their HAL to ASF so it becomes apache/nuttx-hal-espressif and
the whole community is more involved.. this is very honorable step
from Espressif and they again seem to pave the way for HAL integration
in NuttX in the least painful possible way.. at the same time taking
care of software supply chain :-)

Most of the raised issues should be solved that way:
1. Code ownership and supply chain security.
2. Community involvement in faster PR processing.
3. We should have more control and impact on the HAL quality and availability.
4. HAL is under the NuttX umbrella just as proposed "Zephyr Umbrella
Way" (also proposed by Renesas).

I guess ASF should not have problem with accepting such aleady Apache
2.0 licensed code. Maybe only ICLAs should be obtained from all
existing authors?

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Gregory Nutt <sp...@gmail.com>]

The last remaining question here is whether it is okay to Apache to
accept such donation. If yes then we can create
apache/nuttx-hal-espressif repo and work on it just as any other
apache/nuttx-* repo. I guess this hal needs to be a separate repo
because Espressif still want to have local clone for validation /
development.

That is an option if and if the HAL is granted to the ASF.  Otherwise, what you suggesting might be prohibited by the ASF.  I would have to do more research to understand that fully.

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tomek CEDRO <to...@cedro.info>]

Felipe: "The option to host 3rd-party code under Apache has already
been declined."

Declined by who? Quite the opposite. Tiago from Espressif stated they
can and even prefer to donate esp-hal-3rdparty to apache controlled
repo in order to assure software supply chain security as mentioned by
Alin.

The last remaining question here is whether it is okay to Apache to
accept such donation. If yes then we can create
apache/nuttx-hal-espressif repo and work on it just as any other
apache/nuttx-* repo. I guess this hal needs to be a separate repo
because Espressif still want to have local clone for validation /
development.

Your PR will be then reviewed also by NuttX committers. This is what
this whole HAL fuss is about right?

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

On Fri, Oct 2, 2026 at 11:57 PM Felipe Moura Oliveira
<mo...@gmail.com> wrote:
>
> Hi all,
>
> We have been discussing two options: one using a GitHub repository under
> the NuttX organization to host 3rd-party HALs, and another approach hosting
> 3rd-party code within Apache.
>
> The option to host 3rd-party code under Apache has already been declined.
>
> What about voting the option presented in this thread?
>
> Best regards,
>
>
> *--Felipe Moura de Oliveira*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> On Thu, 1 Oct 2026 at 13:11 Alan C. Assis <ac...@gmail.com> wrote:
>
> > Hi Tiago,
> >
> > Linux Foundation and the Apache Foundation have different mindsets
> > (philosophies).
> >
> > One is about money; the other is about ideology. These are part of the
> > three things that move people: money, ideology, or ego.
> >
> > So, LF doesn't care too much about ideology, they care about money and
> > always take advantage of it (each project becomes a paying foundation for
> > them).
> >
> > Please review the documentation regarding which licenses are allowed under
> > the Apache Foundation. An external vendor should not agree to give away
> > their IP or sign a SGA.
> >
> > Also, the Apache License is not interesting for some start-ups because if
> > you hold a patent and use Apache-licensed software you cannot issue that
> > patent against other companies using that software.
> >
> > In this case a HAL under the Apache License is a blocker for them.
> >
> > BR,
> >
> > Alan
> >
> > On Thu, Oct 1, 2026 at 12:43 PM Tiago Medicci Serrano <
> > tiago.medicci@gmail.com> wrote:
> >
> > > Hi All, just a few pinpoints:
> > >
> > > Felipe just mentioned:
> > >
> > > "Keeping them outside of Apache, I know that Espressif agrees"
> > >
> > >
> > > Actually, we prefer keeping it under ASF, at `
> > > github.com/apache/nuttx-hal-espressif`
> > <http://github.com/apache/nuttx-hal-espressif>
> > > <http://github.com/apache/nuttx-hal-espressif>. The license is already
> > > Apache 2.0.
> > >
> > > Binh's last message stated:
> > >
> > > Yes, Renesas supports keeping HAL Renesas outside the ASF.
> > > > It is similar to the model already supported for HAL Renesas in Zephyr,
> > > > with shared contribution and maintenance between the community and
> > > Renesas
> > > > code owners.
> > >
> > >
> > > There seems to be a misunderstanding about under ASF or not. It doesn't
> > > mean transferring the ownership. Actually, *Zephyr's HALs are under
> > > Zephyr's umbrella*. This is true for Espressif (
> > > https://github.com/zephyrproject-rtos/hal_espressif/) and seems to be
> > true
> > > for Renesas as well (https://github.com/zephyrproject-rtos/hal_renesas/
> > ).
> > > Both are under `github.com/zephyrproject-rtos`
> > <http://github.com/zephyrproject-rtos>
> > > <http://github.com/zephyrproject-rtos> (equivalently, Zephyr's
> > > umbrella, just like any other external modules).
> > >
> > > Just for the sake of comparison, they have clear rules about it:
> > > https://docs.zephyrproject.org/latest/contribute/external.html
> > >
> > > An OSI-compliant license is a prerequisite (so that it'd be the same for
> > `
> > > github.com/apache/nuttx-hal-<vendor>`). The goals, requirements, and
> > > processes aren't that different from Zephyr's in this case.
> > >
> > > Best regards,
> > >
> > >
> > > Em qua., 30 de set. de 2026 às 22:29, Binh Nguyen <
> > > binh.nguyen.xw@renesas.com> escreveu:
> > >
> > > > Hi all,
> > > >
> > > > Yes, Renesas supports keeping HAL Renesas outside the ASF.
> > > > It is similar to the model already supported for HAL Renesas in Zephyr,
> > > > with shared contribution and maintenance between the community and
> > > Renesas
> > > > code owners.
> > > >
> > > > Best Regards,
> > > > Binh Nguyen
> > > >
> > > > > From: Felipe Moura Oliveira <mo...@gmail.com>
> > > > > Sent: Thursday, October 1, 2026 2:24 AM
> > > > > To: dev@nuttx.apache.org
> > > > > Subject: Re: Proposal: host vendor HAL repositories under
> > > > github.com/NuttX
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Keeping them outside of Apache, I know that Espressif agrees, and I
> > > > believe Renesas and GigaDevice would as well.
> > > > > I can contact Holtek too and present this approach to them and try to
> > > > get support from them.
> > > > >
> > > > > Could the folks from Renesas and GigaDevice please confirm this?
> > > > >
> > > > > If so, we would already have a good starting point for this approach.
> > > > >
> > > > > Best regards,
> > > > >
> > > > >
> > > > > *--Felipe Moura de Oliveira*
> > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > > >
> > > > > On Wed, 30 Sep 2026 at 15:48 Alan C. Assis <ac...@gmail.com>
> > wrote:
> > > > >
> > > > > > I think Apache has many restrictions on what can be kept inside it.
> > > > > >
> > > > > > Also without the right information we cannot make a decision. For
> > > > > > instance, if IP donation and SGA are requirements, keeping the HAL
> > > > > > inside Apache is a blocker.
> > > > > >
> > > > > > For Espressif it is fine, because their license is already Apache
> > and
> > > > > > they have already signed the SGA in the past.
> > > > > >
> > > > > > However, we need to consider how we will handle vendors who cannot
> > > > > > comply for some reason.
> > > > > >
> > > > > > BR,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 30, 2026 at 3:02 PM Gregory Nutt <sp...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > +1 for Alin idea to have HAL under Apache license and umbrella in
> > > > > > > +order
> > > > > > to
> > > > > > > keep coherent and secure SBOM..
> > > > > > >
> > > > > > > I believe this would require an IP Clearance and possibly an SGA.
> > > > > > >
> > > > > > > "IP
> > > > > > > clearance<https://incubator.apache.org/ip-clearance/index.html>
> > is
> > > > used to import code bases from outside Apache for future development
> > > > > > > here."   https://www.apache.org/legal/resolved.html#category-x
> > > > > > >
> > > > > > > The above statement seems to exactly describe the in-tree HAL
> > case.
> > > > > > > Basically, the ASF will not accept the legal liabilities of
> > simply
> > > > > > > taking some one else's code and hosting it in a project
> > repository
> > > > > > > with no legal licensing  documentation, especially if it is a
> > > > > > > substantial body of code that will be incorporated into the ASF
> > > > project.
> > > > > > >
> > > > > > > IP clearance details:
> > > > > > > https://in/
> > > > > > > cubator.apache.org
> > > %2Fip-clearance%2Findex.html&data=05%7C02%7Cbinh.n
> > > > > > > guyen.xw%40renesas.com
> > > %7C62ced57e55444f955c3508df1f28b5c4%7C53d82571
> > > > > > >
> > > da1947e49cb4625a166a4a2a%7C0%7C0%7C639263931847902603%7CUnknown%7CTW
> > > > > > >
> > > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> > > > > > >
> > > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XLXJ8KSIFNRpkL
> > > > > > > 6OZiyBJoC7IOB02Yq8LkZ9ZAhGPvQ%3D&reserved=0
> > > > > > >
> > > > > > > Alin is the expert on IP clearance and went through all of this
> > in
> > > > > > > the past.
> > > > > > >
> > > > > > > Using an external library in the link does not cause these
> > problems
> > > > > > > in my understanding.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Gregory Nutt <sp...@gmail.com>]

The option to host 3rd-party code under Apache has already been declined.

There is no problem using 3rd party code in the OS, provided (1) it has an approved open-source, license, and (2) it goes through IP clearance to eliminate legal risks to the ASF.

IP clearance is discussed here: https://incubator.apache.org/ip-clearance/

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hi all,

We have been discussing two options: one using a GitHub repository under
the NuttX organization to host 3rd-party HALs, and another approach hosting
3rd-party code within Apache.

The option to host 3rd-party code under Apache has already been declined.

What about voting the option presented in this thread?

Best regards,


*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

On Thu, 1 Oct 2026 at 13:11 Alan C. Assis <ac...@gmail.com> wrote:

> Hi Tiago,
>
> Linux Foundation and the Apache Foundation have different mindsets
> (philosophies).
>
> One is about money; the other is about ideology. These are part of the
> three things that move people: money, ideology, or ego.
>
> So, LF doesn't care too much about ideology, they care about money and
> always take advantage of it (each project becomes a paying foundation for
> them).
>
> Please review the documentation regarding which licenses are allowed under
> the Apache Foundation. An external vendor should not agree to give away
> their IP or sign a SGA.
>
> Also, the Apache License is not interesting for some start-ups because if
> you hold a patent and use Apache-licensed software you cannot issue that
> patent against other companies using that software.
>
> In this case a HAL under the Apache License is a blocker for them.
>
> BR,
>
> Alan
>
> On Thu, Oct 1, 2026 at 12:43 PM Tiago Medicci Serrano <
> tiago.medicci@gmail.com> wrote:
>
> > Hi All, just a few pinpoints:
> >
> > Felipe just mentioned:
> >
> > "Keeping them outside of Apache, I know that Espressif agrees"
> >
> >
> > Actually, we prefer keeping it under ASF, at `
> > github.com/apache/nuttx-hal-espressif`
> <http://github.com/apache/nuttx-hal-espressif>
> > <http://github.com/apache/nuttx-hal-espressif>. The license is already
> > Apache 2.0.
> >
> > Binh's last message stated:
> >
> > Yes, Renesas supports keeping HAL Renesas outside the ASF.
> > > It is similar to the model already supported for HAL Renesas in Zephyr,
> > > with shared contribution and maintenance between the community and
> > Renesas
> > > code owners.
> >
> >
> > There seems to be a misunderstanding about under ASF or not. It doesn't
> > mean transferring the ownership. Actually, *Zephyr's HALs are under
> > Zephyr's umbrella*. This is true for Espressif (
> > https://github.com/zephyrproject-rtos/hal_espressif/) and seems to be
> true
> > for Renesas as well (https://github.com/zephyrproject-rtos/hal_renesas/
> ).
> > Both are under `github.com/zephyrproject-rtos`
> <http://github.com/zephyrproject-rtos>
> > <http://github.com/zephyrproject-rtos> (equivalently, Zephyr's
> > umbrella, just like any other external modules).
> >
> > Just for the sake of comparison, they have clear rules about it:
> > https://docs.zephyrproject.org/latest/contribute/external.html
> >
> > An OSI-compliant license is a prerequisite (so that it'd be the same for
> `
> > github.com/apache/nuttx-hal-<vendor>`). The goals, requirements, and
> > processes aren't that different from Zephyr's in this case.
> >
> > Best regards,
> >
> >
> > Em qua., 30 de set. de 2026 às 22:29, Binh Nguyen <
> > binh.nguyen.xw@renesas.com> escreveu:
> >
> > > Hi all,
> > >
> > > Yes, Renesas supports keeping HAL Renesas outside the ASF.
> > > It is similar to the model already supported for HAL Renesas in Zephyr,
> > > with shared contribution and maintenance between the community and
> > Renesas
> > > code owners.
> > >
> > > Best Regards,
> > > Binh Nguyen
> > >
> > > > From: Felipe Moura Oliveira <mo...@gmail.com>
> > > > Sent: Thursday, October 1, 2026 2:24 AM
> > > > To: dev@nuttx.apache.org
> > > > Subject: Re: Proposal: host vendor HAL repositories under
> > > github.com/NuttX
> > > >
> > > > Hi all,
> > > >
> > > > Keeping them outside of Apache, I know that Espressif agrees, and I
> > > believe Renesas and GigaDevice would as well.
> > > > I can contact Holtek too and present this approach to them and try to
> > > get support from them.
> > > >
> > > > Could the folks from Renesas and GigaDevice please confirm this?
> > > >
> > > > If so, we would already have a good starting point for this approach.
> > > >
> > > > Best regards,
> > > >
> > > >
> > > > *--Felipe Moura de Oliveira*
> > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > >
> > > > On Wed, 30 Sep 2026 at 15:48 Alan C. Assis <ac...@gmail.com>
> wrote:
> > > >
> > > > > I think Apache has many restrictions on what can be kept inside it.
> > > > >
> > > > > Also without the right information we cannot make a decision. For
> > > > > instance, if IP donation and SGA are requirements, keeping the HAL
> > > > > inside Apache is a blocker.
> > > > >
> > > > > For Espressif it is fine, because their license is already Apache
> and
> > > > > they have already signed the SGA in the past.
> > > > >
> > > > > However, we need to consider how we will handle vendors who cannot
> > > > > comply for some reason.
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Sep 30, 2026 at 3:02 PM Gregory Nutt <sp...@gmail.com>
> > > wrote:
> > > > >
> > > > > >
> > > > > > +1 for Alin idea to have HAL under Apache license and umbrella in
> > > > > > +order
> > > > > to
> > > > > > keep coherent and secure SBOM..
> > > > > >
> > > > > > I believe this would require an IP Clearance and possibly an SGA.
> > > > > >
> > > > > > "IP
> > > > > > clearance<https://incubator.apache.org/ip-clearance/index.html>
> is
> > > used to import code bases from outside Apache for future development
> > > > > > here."   https://www.apache.org/legal/resolved.html#category-x
> > > > > >
> > > > > > The above statement seems to exactly describe the in-tree HAL
> case.
> > > > > > Basically, the ASF will not accept the legal liabilities of
> simply
> > > > > > taking some one else's code and hosting it in a project
> repository
> > > > > > with no legal licensing  documentation, especially if it is a
> > > > > > substantial body of code that will be incorporated into the ASF
> > > project.
> > > > > >
> > > > > > IP clearance details:
> > > > > > https://in/
> > > > > > cubator.apache.org
> > %2Fip-clearance%2Findex.html&data=05%7C02%7Cbinh.n
> > > > > > guyen.xw%40renesas.com
> > %7C62ced57e55444f955c3508df1f28b5c4%7C53d82571
> > > > > >
> > da1947e49cb4625a166a4a2a%7C0%7C0%7C639263931847902603%7CUnknown%7CTW
> > > > > >
> > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> > > > > >
> > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XLXJ8KSIFNRpkL
> > > > > > 6OZiyBJoC7IOB02Yq8LkZ9ZAhGPvQ%3D&reserved=0
> > > > > >
> > > > > > Alin is the expert on IP clearance and went through all of this
> in
> > > > > > the past.
> > > > > >
> > > > > > Using an external library in the link does not cause these
> problems
> > > > > > in my understanding.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

["Alan C. Assis" <ac...@gmail.com>]

Hi Tiago,

Linux Foundation and the Apache Foundation have different mindsets
(philosophies).

One is about money; the other is about ideology. These are part of the
three things that move people: money, ideology, or ego.

So, LF doesn't care too much about ideology, they care about money and
always take advantage of it (each project becomes a paying foundation for
them).

Please review the documentation regarding which licenses are allowed under
the Apache Foundation. An external vendor should not agree to give away
their IP or sign a SGA.

Also, the Apache License is not interesting for some start-ups because if
you hold a patent and use Apache-licensed software you cannot issue that
patent against other companies using that software.

In this case a HAL under the Apache License is a blocker for them.

BR,

Alan

On Thu, Oct 1, 2026 at 12:43 PM Tiago Medicci Serrano <
tiago.medicci@gmail.com> wrote:

> Hi All, just a few pinpoints:
>
> Felipe just mentioned:
>
> "Keeping them outside of Apache, I know that Espressif agrees"
>
>
> Actually, we prefer keeping it under ASF, at `
> github.com/apache/nuttx-hal-espressif`
> <http://github.com/apache/nuttx-hal-espressif>. The license is already
> Apache 2.0.
>
> Binh's last message stated:
>
> Yes, Renesas supports keeping HAL Renesas outside the ASF.
> > It is similar to the model already supported for HAL Renesas in Zephyr,
> > with shared contribution and maintenance between the community and
> Renesas
> > code owners.
>
>
> There seems to be a misunderstanding about under ASF or not. It doesn't
> mean transferring the ownership. Actually, *Zephyr's HALs are under
> Zephyr's umbrella*. This is true for Espressif (
> https://github.com/zephyrproject-rtos/hal_espressif/) and seems to be true
> for Renesas as well (https://github.com/zephyrproject-rtos/hal_renesas/).
> Both are under `github.com/zephyrproject-rtos`
> <http://github.com/zephyrproject-rtos> (equivalently, Zephyr's
> umbrella, just like any other external modules).
>
> Just for the sake of comparison, they have clear rules about it:
> https://docs.zephyrproject.org/latest/contribute/external.html
>
> An OSI-compliant license is a prerequisite (so that it'd be the same for `
> github.com/apache/nuttx-hal-<vendor>`). The goals, requirements, and
> processes aren't that different from Zephyr's in this case.
>
> Best regards,
>
>
> Em qua., 30 de set. de 2026 às 22:29, Binh Nguyen <
> binh.nguyen.xw@renesas.com> escreveu:
>
> > Hi all,
> >
> > Yes, Renesas supports keeping HAL Renesas outside the ASF.
> > It is similar to the model already supported for HAL Renesas in Zephyr,
> > with shared contribution and maintenance between the community and
> Renesas
> > code owners.
> >
> > Best Regards,
> > Binh Nguyen
> >
> > > From: Felipe Moura Oliveira <mo...@gmail.com>
> > > Sent: Thursday, October 1, 2026 2:24 AM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: Proposal: host vendor HAL repositories under
> > github.com/NuttX
> > >
> > > Hi all,
> > >
> > > Keeping them outside of Apache, I know that Espressif agrees, and I
> > believe Renesas and GigaDevice would as well.
> > > I can contact Holtek too and present this approach to them and try to
> > get support from them.
> > >
> > > Could the folks from Renesas and GigaDevice please confirm this?
> > >
> > > If so, we would already have a good starting point for this approach.
> > >
> > > Best regards,
> > >
> > >
> > > *--Felipe Moura de Oliveira*
> > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > >
> > > On Wed, 30 Sep 2026 at 15:48 Alan C. Assis <ac...@gmail.com> wrote:
> > >
> > > > I think Apache has many restrictions on what can be kept inside it.
> > > >
> > > > Also without the right information we cannot make a decision. For
> > > > instance, if IP donation and SGA are requirements, keeping the HAL
> > > > inside Apache is a blocker.
> > > >
> > > > For Espressif it is fine, because their license is already Apache and
> > > > they have already signed the SGA in the past.
> > > >
> > > > However, we need to consider how we will handle vendors who cannot
> > > > comply for some reason.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > >
> > > >
> > > > On Wed, Sep 30, 2026 at 3:02 PM Gregory Nutt <sp...@gmail.com>
> > wrote:
> > > >
> > > > >
> > > > > +1 for Alin idea to have HAL under Apache license and umbrella in
> > > > > +order
> > > > to
> > > > > keep coherent and secure SBOM..
> > > > >
> > > > > I believe this would require an IP Clearance and possibly an SGA.
> > > > >
> > > > > "IP
> > > > > clearance<https://incubator.apache.org/ip-clearance/index.html> is
> > used to import code bases from outside Apache for future development
> > > > > here."   https://www.apache.org/legal/resolved.html#category-x
> > > > >
> > > > > The above statement seems to exactly describe the in-tree HAL case.
> > > > > Basically, the ASF will not accept the legal liabilities of simply
> > > > > taking some one else's code and hosting it in a project repository
> > > > > with no legal licensing  documentation, especially if it is a
> > > > > substantial body of code that will be incorporated into the ASF
> > project.
> > > > >
> > > > > IP clearance details:
> > > > > https://in/
> > > > > cubator.apache.org
> %2Fip-clearance%2Findex.html&data=05%7C02%7Cbinh.n
> > > > > guyen.xw%40renesas.com
> %7C62ced57e55444f955c3508df1f28b5c4%7C53d82571
> > > > >
> da1947e49cb4625a166a4a2a%7C0%7C0%7C639263931847902603%7CUnknown%7CTW
> > > > >
> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> > > > >
> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XLXJ8KSIFNRpkL
> > > > > 6OZiyBJoC7IOB02Yq8LkZ9ZAhGPvQ%3D&reserved=0
> > > > >
> > > > > Alin is the expert on IP clearance and went through all of this in
> > > > > the past.
> > > > >
> > > > > Using an external library in the link does not cause these problems
> > > > > in my understanding.
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hi Tiago,

Thanks for the clarification.

I understand that Espressif prefers hosting under Apache, but would you
also accept hosting outside ASF (e.g. under github.com/NuttX), as suggested
previously?

I ask this to understand if hosting under Apache is a strict requirement or
simply a preference.

Best regards,


*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

On Thu, 1 Oct 2026 at 12:44 Tiago Medicci Serrano <ti...@gmail.com>
wrote:

> Hi All, just a few pinpoints:
>
> Felipe just mentioned:
>
> "Keeping them outside of Apache, I know that Espressif agrees"
>
>
> Actually, we prefer keeping it under ASF, at `
> github.com/apache/nuttx-hal-espressif`
> <http://github.com/apache/nuttx-hal-espressif>. The license is already
> Apache 2.0.
>
> Binh's last message stated:
>
> Yes, Renesas supports keeping HAL Renesas outside the ASF.
> > It is similar to the model already supported for HAL Renesas in Zephyr,
> > with shared contribution and maintenance between the community and
> Renesas
> > code owners.
>
>
> There seems to be a misunderstanding about under ASF or not. It doesn't
> mean transferring the ownership. Actually, *Zephyr's HALs are under
> Zephyr's umbrella*. This is true for Espressif (
> https://github.com/zephyrproject-rtos/hal_espressif/) and seems to be true
> for Renesas as well (https://github.com/zephyrproject-rtos/hal_renesas/).
> Both are under `github.com/zephyrproject-rtos`
> <http://github.com/zephyrproject-rtos> (equivalently, Zephyr's
> umbrella, just like any other external modules).
>
> Just for the sake of comparison, they have clear rules about it:
> https://docs.zephyrproject.org/latest/contribute/external.html
>
> An OSI-compliant license is a prerequisite (so that it'd be the same for `
> github.com/apache/nuttx-hal-<vendor>`). The goals, requirements, and
> processes aren't that different from Zephyr's in this case.
>
> Best regards,
>
>
> Em qua., 30 de set. de 2026 às 22:29, Binh Nguyen <
> binh.nguyen.xw@renesas.com> escreveu:
>
> > Hi all,
> >
> > Yes, Renesas supports keeping HAL Renesas outside the ASF.
> > It is similar to the model already supported for HAL Renesas in Zephyr,
> > with shared contribution and maintenance between the community and
> Renesas
> > code owners.
> >
> > Best Regards,
> > Binh Nguyen
> >
> > > From: Felipe Moura Oliveira <mo...@gmail.com>
> > > Sent: Thursday, October 1, 2026 2:24 AM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: Proposal: host vendor HAL repositories under
> > github.com/NuttX
> > >
> > > Hi all,
> > >
> > > Keeping them outside of Apache, I know that Espressif agrees, and I
> > believe Renesas and GigaDevice would as well.
> > > I can contact Holtek too and present this approach to them and try to
> > get support from them.
> > >
> > > Could the folks from Renesas and GigaDevice please confirm this?
> > >
> > > If so, we would already have a good starting point for this approach.
> > >
> > > Best regards,
> > >
> > >
> > > *--Felipe Moura de Oliveira*
> > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > >
> > > On Wed, 30 Sep 2026 at 15:48 Alan C. Assis <ac...@gmail.com> wrote:
> > >
> > > > I think Apache has many restrictions on what can be kept inside it.
> > > >
> > > > Also without the right information we cannot make a decision. For
> > > > instance, if IP donation and SGA are requirements, keeping the HAL
> > > > inside Apache is a blocker.
> > > >
> > > > For Espressif it is fine, because their license is already Apache and
> > > > they have already signed the SGA in the past.
> > > >
> > > > However, we need to consider how we will handle vendors who cannot
> > > > comply for some reason.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > >
> > > >
> > > > On Wed, Sep 30, 2026 at 3:02 PM Gregory Nutt <sp...@gmail.com>
> > wrote:
> > > >
> > > > >
> > > > > +1 for Alin idea to have HAL under Apache license and umbrella in
> > > > > +order
> > > > to
> > > > > keep coherent and secure SBOM..
> > > > >
> > > > > I believe this would require an IP Clearance and possibly an SGA.
> > > > >
> > > > > "IP
> > > > > clearance<https://incubator.apache.org/ip-clearance/index.html> is
> > used to import code bases from outside Apache for future development
> > > > > here."   https://www.apache.org/legal/resolved.html#category-x
> > > > >
> > > > > The above statement seems to exactly describe the in-tree HAL case.
> > > > > Basically, the ASF will not accept the legal liabilities of simply
> > > > > taking some one else's code and hosting it in a project repository
> > > > > with no legal licensing  documentation, especially if it is a
> > > > > substantial body of code that will be incorporated into the ASF
> > project.
> > > > >
> > > > > IP clearance details:
> > > > > https://in/
> > > > > cubator.apache.org
> %2Fip-clearance%2Findex.html&data=05%7C02%7Cbinh.n
> > > > > guyen.xw%40renesas.com
> %7C62ced57e55444f955c3508df1f28b5c4%7C53d82571
> > > > >
> da1947e49cb4625a166a4a2a%7C0%7C0%7C639263931847902603%7CUnknown%7CTW
> > > > >
> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> > > > >
> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XLXJ8KSIFNRpkL
> > > > > 6OZiyBJoC7IOB02Yq8LkZ9ZAhGPvQ%3D&reserved=0
> > > > >
> > > > > Alin is the expert on IP clearance and went through all of this in
> > > > > the past.
> > > > >
> > > > > Using an external library in the link does not cause these problems
> > > > > in my understanding.
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tiago Medicci Serrano <ti...@gmail.com>]

Hi All, just a few pinpoints:

Felipe just mentioned:

"Keeping them outside of Apache, I know that Espressif agrees"


Actually, we prefer keeping it under ASF, at `
github.com/apache/nuttx-hal-espressif`. The license is already Apache 2.0.

Binh's last message stated:

Yes, Renesas supports keeping HAL Renesas outside the ASF.
> It is similar to the model already supported for HAL Renesas in Zephyr,
> with shared contribution and maintenance between the community and Renesas
> code owners.


There seems to be a misunderstanding about under ASF or not. It doesn't
mean transferring the ownership. Actually, *Zephyr's HALs are under
Zephyr's umbrella*. This is true for Espressif (
https://github.com/zephyrproject-rtos/hal_espressif/) and seems to be true
for Renesas as well (https://github.com/zephyrproject-rtos/hal_renesas/).
Both are under `github.com/zephyrproject-rtos` (equivalently, Zephyr's
umbrella, just like any other external modules).

Just for the sake of comparison, they have clear rules about it:
https://docs.zephyrproject.org/latest/contribute/external.html

An OSI-compliant license is a prerequisite (so that it'd be the same for `
github.com/apache/nuttx-hal-<vendor>`). The goals, requirements, and
processes aren't that different from Zephyr's in this case.

Best regards,


Em qua., 30 de set. de 2026 às 22:29, Binh Nguyen <
binh.nguyen.xw@renesas.com> escreveu:

> Hi all,
>
> Yes, Renesas supports keeping HAL Renesas outside the ASF.
> It is similar to the model already supported for HAL Renesas in Zephyr,
> with shared contribution and maintenance between the community and Renesas
> code owners.
>
> Best Regards,
> Binh Nguyen
>
> > From: Felipe Moura Oliveira <mo...@gmail.com>
> > Sent: Thursday, October 1, 2026 2:24 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Proposal: host vendor HAL repositories under
> github.com/NuttX
> >
> > Hi all,
> >
> > Keeping them outside of Apache, I know that Espressif agrees, and I
> believe Renesas and GigaDevice would as well.
> > I can contact Holtek too and present this approach to them and try to
> get support from them.
> >
> > Could the folks from Renesas and GigaDevice please confirm this?
> >
> > If so, we would already have a good starting point for this approach.
> >
> > Best regards,
> >
> >
> > *--Felipe Moura de Oliveira*
> > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> >
> > On Wed, 30 Sep 2026 at 15:48 Alan C. Assis <ac...@gmail.com> wrote:
> >
> > > I think Apache has many restrictions on what can be kept inside it.
> > >
> > > Also without the right information we cannot make a decision. For
> > > instance, if IP donation and SGA are requirements, keeping the HAL
> > > inside Apache is a blocker.
> > >
> > > For Espressif it is fine, because their license is already Apache and
> > > they have already signed the SGA in the past.
> > >
> > > However, we need to consider how we will handle vendors who cannot
> > > comply for some reason.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > >
> > >
> > > On Wed, Sep 30, 2026 at 3:02 PM Gregory Nutt <sp...@gmail.com>
> wrote:
> > >
> > > >
> > > > +1 for Alin idea to have HAL under Apache license and umbrella in
> > > > +order
> > > to
> > > > keep coherent and secure SBOM..
> > > >
> > > > I believe this would require an IP Clearance and possibly an SGA.
> > > >
> > > > "IP
> > > > clearance<https://incubator.apache.org/ip-clearance/index.html> is
> used to import code bases from outside Apache for future development
> > > > here."   https://www.apache.org/legal/resolved.html#category-x
> > > >
> > > > The above statement seems to exactly describe the in-tree HAL case.
> > > > Basically, the ASF will not accept the legal liabilities of simply
> > > > taking some one else's code and hosting it in a project repository
> > > > with no legal licensing  documentation, especially if it is a
> > > > substantial body of code that will be incorporated into the ASF
> project.
> > > >
> > > > IP clearance details:
> > > > https://in/
> > > > cubator.apache.org%2Fip-clearance%2Findex.html&data=05%7C02%7Cbinh.n
> > > > guyen.xw%40renesas.com%7C62ced57e55444f955c3508df1f28b5c4%7C53d82571
> > > > da1947e49cb4625a166a4a2a%7C0%7C0%7C639263931847902603%7CUnknown%7CTW
> > > > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> > > > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XLXJ8KSIFNRpkL
> > > > 6OZiyBJoC7IOB02Yq8LkZ9ZAhGPvQ%3D&reserved=0
> > > >
> > > > Alin is the expert on IP clearance and went through all of this in
> > > > the past.
> > > >
> > > > Using an external library in the link does not cause these problems
> > > > in my understanding.
> > > >
> > > >
> > >
> >
>

RE: Proposal: host vendor HAL repositories under github.com/NuttX

[Binh Nguyen <bi...@renesas.com>]

Hi all,

Yes, Renesas supports keeping HAL Renesas outside the ASF.
It is similar to the model already supported for HAL Renesas in Zephyr, with shared contribution and maintenance between the community and Renesas code owners.

Best Regards,
Binh Nguyen

> From: Felipe Moura Oliveira <mo...@gmail.com>
> Sent: Thursday, October 1, 2026 2:24 AM
> To: dev@nuttx.apache.org
> Subject: Re: Proposal: host vendor HAL repositories under github.com/NuttX
>
> Hi all,
>
> Keeping them outside of Apache, I know that Espressif agrees, and I believe Renesas and GigaDevice would as well.
> I can contact Holtek too and present this approach to them and try to get support from them.
>
> Could the folks from Renesas and GigaDevice please confirm this?
>
> If so, we would already have a good starting point for this approach.
>
> Best regards,
>
>
> *--Felipe Moura de Oliveira*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> On Wed, 30 Sep 2026 at 15:48 Alan C. Assis <ac...@gmail.com> wrote:
>
> > I think Apache has many restrictions on what can be kept inside it.
> >
> > Also without the right information we cannot make a decision. For
> > instance, if IP donation and SGA are requirements, keeping the HAL
> > inside Apache is a blocker.
> >
> > For Espressif it is fine, because their license is already Apache and
> > they have already signed the SGA in the past.
> >
> > However, we need to consider how we will handle vendors who cannot
> > comply for some reason.
> >
> > BR,
> >
> > Alan
> >
> >
> >
> > On Wed, Sep 30, 2026 at 3:02 PM Gregory Nutt <sp...@gmail.com> wrote:
> >
> > >
> > > +1 for Alin idea to have HAL under Apache license and umbrella in
> > > +order
> > to
> > > keep coherent and secure SBOM..
> > >
> > > I believe this would require an IP Clearance and possibly an SGA.
> > >
> > > "IP
> > > clearance<https://incubator.apache.org/ip-clearance/index.html> is used to import code bases from outside Apache for future development
> > > here."   https://www.apache.org/legal/resolved.html#category-x
> > >
> > > The above statement seems to exactly describe the in-tree HAL case.
> > > Basically, the ASF will not accept the legal liabilities of simply
> > > taking some one else's code and hosting it in a project repository
> > > with no legal licensing  documentation, especially if it is a
> > > substantial body of code that will be incorporated into the ASF project.
> > >
> > > IP clearance details:
> > > https://in/
> > > cubator.apache.org%2Fip-clearance%2Findex.html&data=05%7C02%7Cbinh.n
> > > guyen.xw%40renesas.com%7C62ced57e55444f955c3508df1f28b5c4%7C53d82571
> > > da1947e49cb4625a166a4a2a%7C0%7C0%7C639263931847902603%7CUnknown%7CTW
> > > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> > > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XLXJ8KSIFNRpkL
> > > 6OZiyBJoC7IOB02Yq8LkZ9ZAhGPvQ%3D&reserved=0
> > >
> > > Alin is the expert on IP clearance and went through all of this in
> > > the past.
> > >
> > > Using an external library in the link does not cause these problems
> > > in my understanding.
> > >
> > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hi all,

Keeping them outside of Apache, I know that Espressif agrees, and I believe
Renesas and GigaDevice would as well.
I can contact Holtek too and present this approach to them and try to get
support from them.

Could the folks from Renesas and GigaDevice please confirm this?

If so, we would already have a good starting point for this approach.

Best regards,


*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

On Wed, 30 Sep 2026 at 15:48 Alan C. Assis <ac...@gmail.com> wrote:

> I think Apache has many restrictions on what can be kept inside it.
>
> Also without the right information we cannot make a decision. For instance,
> if IP donation and SGA are requirements, keeping the HAL inside Apache is a
> blocker.
>
> For Espressif it is fine, because their license is already Apache and they
> have already signed the SGA in the past.
>
> However, we need to consider how we will handle vendors who cannot comply
> for some reason.
>
> BR,
>
> Alan
>
>
>
> On Wed, Sep 30, 2026 at 3:02 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> >
> > +1 for Alin idea to have HAL under Apache license and umbrella in order
> to
> > keep coherent and secure SBOM..
> >
> > I believe this would require an IP Clearance and possibly an SGA.
> >
> > "IP clearance<https://incubator.apache.org/ip-clearance/index.html> is
> > used to import code bases from outside Apache for future development
> > here."   https://www.apache.org/legal/resolved.html#category-x
> >
> > The above statement seems to exactly describe the in-tree HAL case.
> > Basically, the ASF will not accept the legal liabilities of simply taking
> > some one else's code and hosting it in a project repository with no legal
> > licensing  documentation, especially if it is a substantial body of code
> > that will be incorporated into the ASF project.
> >
> > IP clearance details:
> > https://incubator.apache.org/ip-clearance/index.html
> >
> > Alin is the expert on IP clearance and went through all of this in the
> > past.
> >
> > Using an external library in the link does not cause these problems in my
> > understanding.
> >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

["Alan C. Assis" <ac...@gmail.com>]

I think Apache has many restrictions on what can be kept inside it.

Also without the right information we cannot make a decision. For instance,
if IP donation and SGA are requirements, keeping the HAL inside Apache is a
blocker.

For Espressif it is fine, because their license is already Apache and they
have already signed the SGA in the past.

However, we need to consider how we will handle vendors who cannot comply
for some reason.

BR,

Alan



On Wed, Sep 30, 2026 at 3:02 PM Gregory Nutt <sp...@gmail.com> wrote:

>
> +1 for Alin idea to have HAL under Apache license and umbrella in order to
> keep coherent and secure SBOM..
>
> I believe this would require an IP Clearance and possibly an SGA.
>
> "IP clearance<https://incubator.apache.org/ip-clearance/index.html> is
> used to import code bases from outside Apache for future development
> here."   https://www.apache.org/legal/resolved.html#category-x
>
> The above statement seems to exactly describe the in-tree HAL case.
> Basically, the ASF will not accept the legal liabilities of simply taking
> some one else's code and hosting it in a project repository with no legal
> licensing  documentation, especially if it is a substantial body of code
> that will be incorporated into the ASF project.
>
> IP clearance details:
> https://incubator.apache.org/ip-clearance/index.html
>
> Alin is the expert on IP clearance and went through all of this in the
> past.
>
> Using an external library in the link does not cause these problems in my
> understanding.
>
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Gregory Nutt <sp...@gmail.com>]

+1 for Alin idea to have HAL under Apache license and umbrella in order to
keep coherent and secure SBOM..

I believe this would require an IP Clearance and possibly an SGA.

"IP clearance<https://incubator.apache.org/ip-clearance/index.html> is used to import code bases from outside Apache for future development here."   https://www.apache.org/legal/resolved.html#category-x

The above statement seems to exactly describe the in-tree HAL case.  Basically, the ASF will not accept the legal liabilities of simply taking some one else's code and hosting it in a project repository with no legal licensing  documentation, especially if it is a substantial body of code that will be incorporated into the ASF project.

IP clearance details:  https://incubator.apache.org/ip-clearance/index.html

Alin is the expert on IP clearance and went through all of this in the past.

Using an external library in the link does not cause these problems in my understanding.

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tomek CEDRO <to...@cedro.info>]

On Wed, Sep 30, 2026, 10:43 Alin Jerpelea <je...@gmail.com> wrote:

> Hi,
>
> I am concerned about having HALS outside ASF because they can constitute a
> supply chain attack vector while
>  the lack of central user management can create friction between NuttX
> committers and vendor representatives
>
> I propose that we host the HALS under ASF in a separate repository
> nuttx-vendor-hals with same access and rules
> as we have for the whole project.
>
> This ensures that we have proper oversight, access management and security
> from ASF
>
> Best regards
> Alin
>


+1 for Alin idea to have HAL under Apache license and umbrella in order to
keep coherent and secure SBOM.. which is serious issue if you look how many
malware showed up in the npm js or even pip python packages recently.

HAL/SDK is the problem on its own. If we are looking for a solution let it
be correct right from start.

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Alin Jerpelea <je...@gmail.com>]

Hi Karel,

I do not have a clear picture on how different HALs will be maintained by
different vendors but at least we will have our community
to mediate and provide guidelines.

Regarding the license concern, the vendors can re-license the code to
Apache 2.0 or use a double license if it makes sense.

I am mostly looking at the Espressif case, which until now seems to be the
best option to start such initiative, experiment and
build guidelines for other other vendors.

Best regards
Alin

On Wed, Sep 30, 2026 at 11:02 AM Karel Kočí <cy...@email.cz> wrote:

> Hi,
>
> wouldn't there be a possibly issue of licenses? Is it enough for ASF
> hosting if
> license is Apache compatible? I might have missed info about that in
> previous
> mails.
>
> On topic of supply chain attacks. That is always issue when code is
> provided
> from outside and when it doesn't match the coding standards of core
> project.
> That is one of the reasons why I am insisting on having chips supported by
> HALs
> on different documented tier compared to the native ones.
>
> But we probably do not have to essentially move HALs them self. It should
> be
> enough to have verifiable way to get pinned version of HAL. That would be
> what
> nuttx-vendor-hals would be? Or what is your idea behind it?
>
> Best regards
> Karel
>
>
>
> On Wed 30 Sep 2026 10:42:32 AM , Alin Jerpelea wrote:
> > Hi,
> >
> > I am concerned about having HALS outside ASF because they can constitute
> a
> > supply chain attack vector while
> >  the lack of central user management can create friction between NuttX
> > committers and vendor representatives
> >
> > I propose that we host the HALS under ASF in a separate repository
> > nuttx-vendor-hals with same access and rules
> > as we have for the whole project.
> >
> > This ensures that we have proper oversight, access management and
> security
> > from ASF
> >
> > Best regards
> > Alin
> >
> > On Tue, Sep 29, 2026 at 10:39 PM Karel Kočí <cy...@email.cz> wrote:
> >
> > > Hi,
> > >
> > > I just want to point out that NuttX already has API that does that,
> lower
> > > and
> > > upper drivers. Upper driver is generic, lower is chip specific. API is
> not
> > > stable but it is generic.
> > >
> > > I am still convinced that NuttX should have native chips (without HAL)
> in
> > > repository and HAL supported chips as external integrations that are
> not
> > > fully
> > > tied to the merge and release cycle of NuttX. I still think that we
> should
> > > limit
> > > the need of core NuttX developers to understand every single HAL that
> > > could be,
> > > in some capacity, included and move that to dedicated maintainers
> > > (prefferably
> > > vendor supplied). That doesn't mean outside NuttX commiters reach, it
> > > means that
> > > most of the work would be done by dedicated developers with deeper
> > > knowledge of
> > > external source code (HAL) and not by NuttX developers improving
> drivers.
> > > Even
> > > if HAL supported chips would lag behing NuttX core.
> > >
> > > With regards
> > > Karel
> > >
> > >
> > > On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote:
> > > > Hi all,
> > > >
> > > > I’m relatively new to the discussion, but I was wondering if we could
> > > also
> > > > consider an approach similar to how Zephyr handles vendor HALs.
> > > >
> > > > Instead of introducing a universal adapter between NuttX and every
> vendor
> > > > HAL, perhaps the boundary could simply be:
> > > >
> > > > Generic NuttX API
> > > >                  |
> > > >     NuttX driver
> > > >       /.                 \
> > > >    native      vendor HAL
> > > >       \                   /
> > > >         hardware
> > > >
> > > > The driver would integrate only the functionality that NuttX actually
> > > needs
> > > > from the vendor HAL. For simple peripherals, the driver could use a
> > > native
> > > > implementation directly, while more complex platforms could reuse the
> > > > vendor HAL.
> > > >
> > > > The vendor HAL itself could remain an external, version-pinned
> dependency
> > > > managed by the NuttX build system.
> > > >
> > > > This seems to avoid the need to implement and maintain a
> general-purpose
> > > > adapter for an entire vendor SDK, while still allowing NuttX to
> benefit
> > > > from existing vendor implementations.
> > > >
> > > > Zephyr uses a similar principle: vendor HALs can remain external
> modules,
> > > > while the Zephyr drivers provide the integration with the generic
> Zephyr
> > > > APIs.
> > > >
> > > > I’m curious what others think about this approach, especially
> regarding
> > > the
> > > > amount of integration and long-term maintenance work compared with
> > > > maintaining the HAL under the NuttX umbrella.
> > > >
> > > > Best regards,
> > > > Ahmed
> > > >
> > > > On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:
> > > >
> > > > > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > > > > <mo...@gmail.com> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Following the recent discussion in the thread “Early feedback on
> > > RZ/V2H
> > > > > > port and RZ FSP HAL dependency”, I would like to suggest
> applying the
> > > > > same
> > > > > > idea discussed there to existing vendor HAL dependencies: hosting
> > > them
> > > > > > under github.com/NuttX, while keeping them separate from the ASF
> > > > > > repositories. This proposal is aligned with some opinions shared
> > > there.
> > > > > >
> > > > > > A practical example is esp-hal-3rdparty. I recently opened a very
> > > small
> > > > > fix
> > > > > > there:
> > > > > >
> > > > > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > > > >
> > > > > > The PR is still open without Espressif review. Interestingly, the
> > > > > technical
> > > > > > feedback so far came from Laczen, a NuttX contributor who is not
> > > part of
> > > > > > Espressif.
> > > > > >
> > > > > > This illustrates the issue when NuttX depends on a vendor
> repository
> > > but
> > > > > > the vendor is temporarily unavailable to maintain or review it.
> > > > > >
> > > > > > Would it make sense to move esp-hal-3rdparty, and potentially
> similar
> > > > > > vendor HAL repositories, under github.com/NuttX, with vendor
> > > maintainers
> > > > > > when available but NuttX committers retaining the ability to
> review
> > > and
> > > > > > maintain them when necessary?
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > *--Felipe Moura de Oliveira*
> > > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > > >
> > > > > I am still opponent of any external HAL/SDK in NuttX, it only
> brings
> > > > > problems in the long run, but if this particular HAL is already
> here
> > > > > we may try to experiment with it (and only this one for now) under
> > > > > github.com/nuttx umbrella to see if this approach would really
> solve
> > > > > any problems or add new problems. Time will tell and we can always
> > > > > fallback to the current vendor provided and controlled HAL if that
> > > > > approach fails for any reason?
> > > > >
> > > > > --
> > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > >
> > >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Gregory Nutt <sp...@gmail.com>]

There have been several questions about licensing of HALs.  The ASF 3rd pary license policy is here:

https://www.apache.org/legal/resolved.html
https://www.apache.org/legal/resolved.html#category-x

I haven't been following all of the discussion.  It has gotten long, redundant, and at times emotional.  I hope those references at least clarify what is permissible to include  or link into an ASF project

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Karel Kočí <cy...@email.cz>]

Hi,

wouldn't there be a possibly issue of licenses? Is it enough for ASF hosting if
license is Apache compatible? I might have missed info about that in previous
mails.

On topic of supply chain attacks. That is always issue when code is provided
from outside and when it doesn't match the coding standards of core project.
That is one of the reasons why I am insisting on having chips supported by HALs
on different documented tier compared to the native ones.

But we probably do not have to essentially move HALs them self. It should be
enough to have verifiable way to get pinned version of HAL. That would be what
nuttx-vendor-hals would be? Or what is your idea behind it?

Best regards
Karel



On Wed 30 Sep 2026 10:42:32 AM , Alin Jerpelea wrote:
> Hi,
> 
> I am concerned about having HALS outside ASF because they can constitute a
> supply chain attack vector while
>  the lack of central user management can create friction between NuttX
> committers and vendor representatives
> 
> I propose that we host the HALS under ASF in a separate repository
> nuttx-vendor-hals with same access and rules
> as we have for the whole project.
> 
> This ensures that we have proper oversight, access management and security
> from ASF
> 
> Best regards
> Alin
> 
> On Tue, Sep 29, 2026 at 10:39 PM Karel Kočí <cy...@email.cz> wrote:
> 
> > Hi,
> >
> > I just want to point out that NuttX already has API that does that, lower
> > and
> > upper drivers. Upper driver is generic, lower is chip specific. API is not
> > stable but it is generic.
> >
> > I am still convinced that NuttX should have native chips (without HAL) in
> > repository and HAL supported chips as external integrations that are not
> > fully
> > tied to the merge and release cycle of NuttX. I still think that we should
> > limit
> > the need of core NuttX developers to understand every single HAL that
> > could be,
> > in some capacity, included and move that to dedicated maintainers
> > (prefferably
> > vendor supplied). That doesn't mean outside NuttX commiters reach, it
> > means that
> > most of the work would be done by dedicated developers with deeper
> > knowledge of
> > external source code (HAL) and not by NuttX developers improving drivers.
> > Even
> > if HAL supported chips would lag behing NuttX core.
> >
> > With regards
> > Karel
> >
> >
> > On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote:
> > > Hi all,
> > >
> > > I’m relatively new to the discussion, but I was wondering if we could
> > also
> > > consider an approach similar to how Zephyr handles vendor HALs.
> > >
> > > Instead of introducing a universal adapter between NuttX and every vendor
> > > HAL, perhaps the boundary could simply be:
> > >
> > > Generic NuttX API
> > >                  |
> > >     NuttX driver
> > >       /.                 \
> > >    native      vendor HAL
> > >       \                   /
> > >         hardware
> > >
> > > The driver would integrate only the functionality that NuttX actually
> > needs
> > > from the vendor HAL. For simple peripherals, the driver could use a
> > native
> > > implementation directly, while more complex platforms could reuse the
> > > vendor HAL.
> > >
> > > The vendor HAL itself could remain an external, version-pinned dependency
> > > managed by the NuttX build system.
> > >
> > > This seems to avoid the need to implement and maintain a general-purpose
> > > adapter for an entire vendor SDK, while still allowing NuttX to benefit
> > > from existing vendor implementations.
> > >
> > > Zephyr uses a similar principle: vendor HALs can remain external modules,
> > > while the Zephyr drivers provide the integration with the generic Zephyr
> > > APIs.
> > >
> > > I’m curious what others think about this approach, especially regarding
> > the
> > > amount of integration and long-term maintenance work compared with
> > > maintaining the HAL under the NuttX umbrella.
> > >
> > > Best regards,
> > > Ahmed
> > >
> > > On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:
> > >
> > > > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > > > <mo...@gmail.com> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Following the recent discussion in the thread “Early feedback on
> > RZ/V2H
> > > > > port and RZ FSP HAL dependency”, I would like to suggest applying the
> > > > same
> > > > > idea discussed there to existing vendor HAL dependencies: hosting
> > them
> > > > > under github.com/NuttX, while keeping them separate from the ASF
> > > > > repositories. This proposal is aligned with some opinions shared
> > there.
> > > > >
> > > > > A practical example is esp-hal-3rdparty. I recently opened a very
> > small
> > > > fix
> > > > > there:
> > > > >
> > > > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > > >
> > > > > The PR is still open without Espressif review. Interestingly, the
> > > > technical
> > > > > feedback so far came from Laczen, a NuttX contributor who is not
> > part of
> > > > > Espressif.
> > > > >
> > > > > This illustrates the issue when NuttX depends on a vendor repository
> > but
> > > > > the vendor is temporarily unavailable to maintain or review it.
> > > > >
> > > > > Would it make sense to move esp-hal-3rdparty, and potentially similar
> > > > > vendor HAL repositories, under github.com/NuttX, with vendor
> > maintainers
> > > > > when available but NuttX committers retaining the ability to review
> > and
> > > > > maintain them when necessary?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > *--Felipe Moura de Oliveira*
> > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > >
> > > > I am still opponent of any external HAL/SDK in NuttX, it only brings
> > > > problems in the long run, but if this particular HAL is already here
> > > > we may try to experiment with it (and only this one for now) under
> > > > github.com/nuttx umbrella to see if this approach would really solve
> > > > any problems or add new problems. Time will tell and we can always
> > > > fallback to the current vendor provided and controlled HAL if that
> > > > approach fails for any reason?
> > > >
> > > > --
> > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > >
> >

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hi all,

I believe hosting HALs under the Apache umbrella is not viable, and I think
we already have a consensus on this. The ideal approach is to host them
under github.com/NuttX.

Regarding the vendor's responsibility to maintain the HAL: while vendors
can certainly contribute and review code, the community—being the main
stakeholder—can and should contribute as well.

Finally, there are different roles within our field: some developers focus
on applications, others on the kernel, and some on drivers. Since NuttX is
a complete RTOS that provides an end-to-end infrastructure, we should
encourage and recognize those who add support for new boards.

Best regards,


Em qua., 30 de set. de 2026 às 09:18, Alan C. Assis <ac...@gmail.com>
escreveu:

> Hi Alin,
>
> If the HAL is provided by an external vendor, the supply chain attack
> vector can occur regardless of where we host the code, since the original
> code originates from the vendor.
>
> I think the access to github.com/NuttX is at the same level as
> github/apache/nuttx, only NuttX PMCs and committers have write access to
> it.
>
> To host it at ASF, I think we need their agreement to host external code
> even when using different licenses (i.e. BSD, MIT, etc)
>
> BR,
>
> Alan
>
> On Wed, Sep 30, 2026 at 5:43 AM Alin Jerpelea <je...@gmail.com> wrote:
>
> > Hi,
> >
> > I am concerned about having HALS outside ASF because they can constitute
> a
> > supply chain attack vector while
> >  the lack of central user management can create friction between NuttX
> > committers and vendor representatives
> >
> > I propose that we host the HALS under ASF in a separate repository
> > nuttx-vendor-hals with same access and rules
> > as we have for the whole project.
> >
> > This ensures that we have proper oversight, access management and
> security
> > from ASF
> >
> > Best regards
> > Alin
> >
> > On Tue, Sep 29, 2026 at 10:39 PM Karel Kočí <cy...@email.cz> wrote:
> >
> > > Hi,
> > >
> > > I just want to point out that NuttX already has API that does that,
> lower
> > > and
> > > upper drivers. Upper driver is generic, lower is chip specific. API is
> > not
> > > stable but it is generic.
> > >
> > > I am still convinced that NuttX should have native chips (without HAL)
> in
> > > repository and HAL supported chips as external integrations that are
> not
> > > fully
> > > tied to the merge and release cycle of NuttX. I still think that we
> > should
> > > limit
> > > the need of core NuttX developers to understand every single HAL that
> > > could be,
> > > in some capacity, included and move that to dedicated maintainers
> > > (prefferably
> > > vendor supplied). That doesn't mean outside NuttX commiters reach, it
> > > means that
> > > most of the work would be done by dedicated developers with deeper
> > > knowledge of
> > > external source code (HAL) and not by NuttX developers improving
> drivers.
> > > Even
> > > if HAL supported chips would lag behing NuttX core.
> > >
> > > With regards
> > > Karel
> > >
> > >
> > > On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote:
> > > > Hi all,
> > > >
> > > > I’m relatively new to the discussion, but I was wondering if we could
> > > also
> > > > consider an approach similar to how Zephyr handles vendor HALs.
> > > >
> > > > Instead of introducing a universal adapter between NuttX and every
> > vendor
> > > > HAL, perhaps the boundary could simply be:
> > > >
> > > > Generic NuttX API
> > > >                  |
> > > >     NuttX driver
> > > >       /.                 \
> > > >    native      vendor HAL
> > > >       \                   /
> > > >         hardware
> > > >
> > > > The driver would integrate only the functionality that NuttX actually
> > > needs
> > > > from the vendor HAL. For simple peripherals, the driver could use a
> > > native
> > > > implementation directly, while more complex platforms could reuse the
> > > > vendor HAL.
> > > >
> > > > The vendor HAL itself could remain an external, version-pinned
> > dependency
> > > > managed by the NuttX build system.
> > > >
> > > > This seems to avoid the need to implement and maintain a
> > general-purpose
> > > > adapter for an entire vendor SDK, while still allowing NuttX to
> benefit
> > > > from existing vendor implementations.
> > > >
> > > > Zephyr uses a similar principle: vendor HALs can remain external
> > modules,
> > > > while the Zephyr drivers provide the integration with the generic
> > Zephyr
> > > > APIs.
> > > >
> > > > I’m curious what others think about this approach, especially
> regarding
> > > the
> > > > amount of integration and long-term maintenance work compared with
> > > > maintaining the HAL under the NuttX umbrella.
> > > >
> > > > Best regards,
> > > > Ahmed
> > > >
> > > > On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:
> > > >
> > > > > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > > > > <mo...@gmail.com> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Following the recent discussion in the thread “Early feedback on
> > > RZ/V2H
> > > > > > port and RZ FSP HAL dependency”, I would like to suggest applying
> > the
> > > > > same
> > > > > > idea discussed there to existing vendor HAL dependencies: hosting
> > > them
> > > > > > under github.com/NuttX, while keeping them separate from the ASF
> > > > > > repositories. This proposal is aligned with some opinions shared
> > > there.
> > > > > >
> > > > > > A practical example is esp-hal-3rdparty. I recently opened a very
> > > small
> > > > > fix
> > > > > > there:
> > > > > >
> > > > > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > > > >
> > > > > > The PR is still open without Espressif review. Interestingly, the
> > > > > technical
> > > > > > feedback so far came from Laczen, a NuttX contributor who is not
> > > part of
> > > > > > Espressif.
> > > > > >
> > > > > > This illustrates the issue when NuttX depends on a vendor
> > repository
> > > but
> > > > > > the vendor is temporarily unavailable to maintain or review it.
> > > > > >
> > > > > > Would it make sense to move esp-hal-3rdparty, and potentially
> > similar
> > > > > > vendor HAL repositories, under github.com/NuttX, with vendor
> > > maintainers
> > > > > > when available but NuttX committers retaining the ability to
> review
> > > and
> > > > > > maintain them when necessary?
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > *--Felipe Moura de Oliveira*
> > > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > > >
> > > > > I am still opponent of any external HAL/SDK in NuttX, it only
> brings
> > > > > problems in the long run, but if this particular HAL is already
> here
> > > > > we may try to experiment with it (and only this one for now) under
> > > > > github.com/nuttx umbrella to see if this approach would really
> solve
> > > > > any problems or add new problems. Time will tell and we can always
> > > > > fallback to the current vendor provided and controlled HAL if that
> > > > > approach fails for any reason?
> > > > >
> > > > > --
> > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > >
> > >
> >
>


-- 

*--Felipe Moura de Oliveira*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Nathan Hartman <ha...@gmail.com>]

I like the idea of tiers.

FreeBSD has had tiers for a long time. In FreeBSD, Tier 1 is fully
supported, Tier 2 is Developmental, Tier 3 is Experimental, Tier 4 is
Unsupported.

We have many architectures and I think it would be a good idea to have a
documented system of tiers. This will help document how complete and
well-supported an arch is under NuttX.

I can't offer input regarding the HAL adapters. It sounds like an
interesting idea, but I can't dig deeper into it right now.

Thanks,
Nathan

On Wed, Sep 30, 2026 at 9:25 AM Tiago Medicci Serrano <
tiago.medicci@gmail.com> wrote:

> Hi All,
>
> Thanks for the clarifying messages sent so far. After some internal
> discussions, we (Espressif) support hosting HAL under github.com/apache
> (ASF), just as Alin proposed.
>
> Just like Ahmed (mentioned by Matteo) said, this is how Zephyr does it:
> vendors' HALs are external repositories hosted by Zephyr. Vendors are
> maintainers along with other community members. The current
> github.com/espressif/esp-hal-3rdparty/ is already licensed under Apache
> 2.0, so we could create a PR in its repository hosted by Apache (which
> would be legally compatible). *The suggestion is to host at repositories
> like github.com/apache/`nuttx-hal- <http://github.com/apache/nuttx-hal->
> <http://github.com/apache/`nuttx-hal-
> <http://github.com/apache/nuttx-hal->><vendor>`*.
>
> Another interesting point of view from Ahmed (and, citing Karel as well):
> NuttX already has an API that separates the driver implementation from its
> commonly used interface: the lower-half driver. A good example of this is
> at arch/risc-v/src/common/espressif/esp_rmt.c
> <
> https://github.com/apache/nuttx/blob/master/arch/risc-v/src/common/espressif/esp_rmt.c
> >:
> its upper-half expects functions to be defined. Those functions were built
> using Espressif's HAL code, but the upper-half doesn't care about it.
>
> To address the concerns about NuttX native vs HAL-based implementations,
> NuttX can have both: nothing prevents attaching different lower-half
> drivers to the upper-half. A simple Kconfig option can select which
> implementation would be used. This allows the community to develop native
> implementations, while vendors can actively contribute to NuttX. We support
> vendors willing to contribute to NuttX to follow the same pattern.
>
> That being said, *the current `esp-hal-3rdparty` is frozen to enable the
> transition, depending only on the community's choice*. Its internals will
> be better explained in its README.md when migration occurs and community
> contributions will, of course, be very welcome.
>
> *We are willing to hear the following discussion and, whenever it's
> possible (ASAP), create the new repository and start the migration.*
> Best regards,
>
> Em qua., 30 de set. de 2026 às 09:18, Alan C. Assis <ac...@gmail.com>
> escreveu:
>
> > Hi Alin,
> >
> > If the HAL is provided by an external vendor, the supply chain attack
> > vector can occur regardless of where we host the code, since the original
> > code originates from the vendor.
> >
> > I think the access to github.com/NuttX is at the same level as
> > github/apache/nuttx, only NuttX PMCs and committers have write access to
> > it.
> >
> > To host it at ASF, I think we need their agreement to host external code
> > even when using different licenses (i.e. BSD, MIT, etc)
> >
> > BR,
> >
> > Alan
> >
> > On Wed, Sep 30, 2026 at 5:43 AM Alin Jerpelea <je...@gmail.com>
> wrote:
> >
> > > Hi,
> > >
> > > I am concerned about having HALS outside ASF because they can
> constitute
> > a
> > > supply chain attack vector while
> > >  the lack of central user management can create friction between NuttX
> > > committers and vendor representatives
> > >
> > > I propose that we host the HALS under ASF in a separate repository
> > > nuttx-vendor-hals with same access and rules
> > > as we have for the whole project.
> > >
> > > This ensures that we have proper oversight, access management and
> > security
> > > from ASF
> > >
> > > Best regards
> > > Alin
> > >
> > > On Tue, Sep 29, 2026 at 10:39 PM Karel Kočí <cy...@email.cz> wrote:
> > >
> > > > Hi,
> > > >
> > > > I just want to point out that NuttX already has API that does that,
> > lower
> > > > and
> > > > upper drivers. Upper driver is generic, lower is chip specific. API
> is
> > > not
> > > > stable but it is generic.
> > > >
> > > > I am still convinced that NuttX should have native chips (without
> HAL)
> > in
> > > > repository and HAL supported chips as external integrations that are
> > not
> > > > fully
> > > > tied to the merge and release cycle of NuttX. I still think that we
> > > should
> > > > limit
> > > > the need of core NuttX developers to understand every single HAL that
> > > > could be,
> > > > in some capacity, included and move that to dedicated maintainers
> > > > (prefferably
> > > > vendor supplied). That doesn't mean outside NuttX commiters reach, it
> > > > means that
> > > > most of the work would be done by dedicated developers with deeper
> > > > knowledge of
> > > > external source code (HAL) and not by NuttX developers improving
> > drivers.
> > > > Even
> > > > if HAL supported chips would lag behing NuttX core.
> > > >
> > > > With regards
> > > > Karel
> > > >
> > > >
> > > > On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote:
> > > > > Hi all,
> > > > >
> > > > > I’m relatively new to the discussion, but I was wondering if we
> could
> > > > also
> > > > > consider an approach similar to how Zephyr handles vendor HALs.
> > > > >
> > > > > Instead of introducing a universal adapter between NuttX and every
> > > vendor
> > > > > HAL, perhaps the boundary could simply be:
> > > > >
> > > > > Generic NuttX API
> > > > >                  |
> > > > >     NuttX driver
> > > > >       /.                 \
> > > > >    native      vendor HAL
> > > > >       \                   /
> > > > >         hardware
> > > > >
> > > > > The driver would integrate only the functionality that NuttX
> actually
> > > > needs
> > > > > from the vendor HAL. For simple peripherals, the driver could use a
> > > > native
> > > > > implementation directly, while more complex platforms could reuse
> the
> > > > > vendor HAL.
> > > > >
> > > > > The vendor HAL itself could remain an external, version-pinned
> > > dependency
> > > > > managed by the NuttX build system.
> > > > >
> > > > > This seems to avoid the need to implement and maintain a
> > > general-purpose
> > > > > adapter for an entire vendor SDK, while still allowing NuttX to
> > benefit
> > > > > from existing vendor implementations.
> > > > >
> > > > > Zephyr uses a similar principle: vendor HALs can remain external
> > > modules,
> > > > > while the Zephyr drivers provide the integration with the generic
> > > Zephyr
> > > > > APIs.
> > > > >
> > > > > I’m curious what others think about this approach, especially
> > regarding
> > > > the
> > > > > amount of integration and long-term maintenance work compared with
> > > > > maintaining the HAL under the NuttX umbrella.
> > > > >
> > > > > Best regards,
> > > > > Ahmed
> > > > >
> > > > > On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info>
> wrote:
> > > > >
> > > > > > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > > > > > <mo...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Following the recent discussion in the thread “Early feedback
> on
> > > > RZ/V2H
> > > > > > > port and RZ FSP HAL dependency”, I would like to suggest
> applying
> > > the
> > > > > > same
> > > > > > > idea discussed there to existing vendor HAL dependencies:
> hosting
> > > > them
> > > > > > > under github.com/NuttX, while keeping them separate from the
> ASF
> > > > > > > repositories. This proposal is aligned with some opinions
> shared
> > > > there.
> > > > > > >
> > > > > > > A practical example is esp-hal-3rdparty. I recently opened a
> very
> > > > small
> > > > > > fix
> > > > > > > there:
> > > > > > >
> > > > > > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > > > > >
> > > > > > > The PR is still open without Espressif review. Interestingly,
> the
> > > > > > technical
> > > > > > > feedback so far came from Laczen, a NuttX contributor who is
> not
> > > > part of
> > > > > > > Espressif.
> > > > > > >
> > > > > > > This illustrates the issue when NuttX depends on a vendor
> > > repository
> > > > but
> > > > > > > the vendor is temporarily unavailable to maintain or review it.
> > > > > > >
> > > > > > > Would it make sense to move esp-hal-3rdparty, and potentially
> > > similar
> > > > > > > vendor HAL repositories, under github.com/NuttX, with vendor
> > > > maintainers
> > > > > > > when available but NuttX committers retaining the ability to
> > review
> > > > and
> > > > > > > maintain them when necessary?
> > > > > > >
> > > > > > > Best regards,
> > > > > > >
> > > > > > > *--Felipe Moura de Oliveira*
> > > > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0
> >
> > > > > >
> > > > > > I am still opponent of any external HAL/SDK in NuttX, it only
> > brings
> > > > > > problems in the long run, but if this particular HAL is already
> > here
> > > > > > we may try to experiment with it (and only this one for now)
> under
> > > > > > github.com/nuttx umbrella to see if this approach would really
> > solve
> > > > > > any problems or add new problems. Time will tell and we can
> always
> > > > > > fallback to the current vendor provided and controlled HAL if
> that
> > > > > > approach fails for any reason?
> > > > > >
> > > > > > --
> > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > >
> > > >
> > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tiago Medicci Serrano <ti...@gmail.com>]

Hi All,

Thanks for the clarifying messages sent so far. After some internal
discussions, we (Espressif) support hosting HAL under github.com/apache
(ASF), just as Alin proposed.

Just like Ahmed (mentioned by Matteo) said, this is how Zephyr does it:
vendors' HALs are external repositories hosted by Zephyr. Vendors are
maintainers along with other community members. The current
github.com/espressif/esp-hal-3rdparty/ is already licensed under Apache
2.0, so we could create a PR in its repository hosted by Apache (which
would be legally compatible). *The suggestion is to host at repositories
like github.com/apache/`nuttx-hal-
<http://github.com/apache/`nuttx-hal-><vendor>`*.

Another interesting point of view from Ahmed (and, citing Karel as well):
NuttX already has an API that separates the driver implementation from its
commonly used interface: the lower-half driver. A good example of this is
at arch/risc-v/src/common/espressif/esp_rmt.c
<https://github.com/apache/nuttx/blob/master/arch/risc-v/src/common/espressif/esp_rmt.c>:
its upper-half expects functions to be defined. Those functions were built
using Espressif's HAL code, but the upper-half doesn't care about it.

To address the concerns about NuttX native vs HAL-based implementations,
NuttX can have both: nothing prevents attaching different lower-half
drivers to the upper-half. A simple Kconfig option can select which
implementation would be used. This allows the community to develop native
implementations, while vendors can actively contribute to NuttX. We support
vendors willing to contribute to NuttX to follow the same pattern.

That being said, *the current `esp-hal-3rdparty` is frozen to enable the
transition, depending only on the community's choice*. Its internals will
be better explained in its README.md when migration occurs and community
contributions will, of course, be very welcome.

*We are willing to hear the following discussion and, whenever it's
possible (ASAP), create the new repository and start the migration.*
Best regards,

Em qua., 30 de set. de 2026 às 09:18, Alan C. Assis <ac...@gmail.com>
escreveu:

> Hi Alin,
>
> If the HAL is provided by an external vendor, the supply chain attack
> vector can occur regardless of where we host the code, since the original
> code originates from the vendor.
>
> I think the access to github.com/NuttX is at the same level as
> github/apache/nuttx, only NuttX PMCs and committers have write access to
> it.
>
> To host it at ASF, I think we need their agreement to host external code
> even when using different licenses (i.e. BSD, MIT, etc)
>
> BR,
>
> Alan
>
> On Wed, Sep 30, 2026 at 5:43 AM Alin Jerpelea <je...@gmail.com> wrote:
>
> > Hi,
> >
> > I am concerned about having HALS outside ASF because they can constitute
> a
> > supply chain attack vector while
> >  the lack of central user management can create friction between NuttX
> > committers and vendor representatives
> >
> > I propose that we host the HALS under ASF in a separate repository
> > nuttx-vendor-hals with same access and rules
> > as we have for the whole project.
> >
> > This ensures that we have proper oversight, access management and
> security
> > from ASF
> >
> > Best regards
> > Alin
> >
> > On Tue, Sep 29, 2026 at 10:39 PM Karel Kočí <cy...@email.cz> wrote:
> >
> > > Hi,
> > >
> > > I just want to point out that NuttX already has API that does that,
> lower
> > > and
> > > upper drivers. Upper driver is generic, lower is chip specific. API is
> > not
> > > stable but it is generic.
> > >
> > > I am still convinced that NuttX should have native chips (without HAL)
> in
> > > repository and HAL supported chips as external integrations that are
> not
> > > fully
> > > tied to the merge and release cycle of NuttX. I still think that we
> > should
> > > limit
> > > the need of core NuttX developers to understand every single HAL that
> > > could be,
> > > in some capacity, included and move that to dedicated maintainers
> > > (prefferably
> > > vendor supplied). That doesn't mean outside NuttX commiters reach, it
> > > means that
> > > most of the work would be done by dedicated developers with deeper
> > > knowledge of
> > > external source code (HAL) and not by NuttX developers improving
> drivers.
> > > Even
> > > if HAL supported chips would lag behing NuttX core.
> > >
> > > With regards
> > > Karel
> > >
> > >
> > > On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote:
> > > > Hi all,
> > > >
> > > > I’m relatively new to the discussion, but I was wondering if we could
> > > also
> > > > consider an approach similar to how Zephyr handles vendor HALs.
> > > >
> > > > Instead of introducing a universal adapter between NuttX and every
> > vendor
> > > > HAL, perhaps the boundary could simply be:
> > > >
> > > > Generic NuttX API
> > > >                  |
> > > >     NuttX driver
> > > >       /.                 \
> > > >    native      vendor HAL
> > > >       \                   /
> > > >         hardware
> > > >
> > > > The driver would integrate only the functionality that NuttX actually
> > > needs
> > > > from the vendor HAL. For simple peripherals, the driver could use a
> > > native
> > > > implementation directly, while more complex platforms could reuse the
> > > > vendor HAL.
> > > >
> > > > The vendor HAL itself could remain an external, version-pinned
> > dependency
> > > > managed by the NuttX build system.
> > > >
> > > > This seems to avoid the need to implement and maintain a
> > general-purpose
> > > > adapter for an entire vendor SDK, while still allowing NuttX to
> benefit
> > > > from existing vendor implementations.
> > > >
> > > > Zephyr uses a similar principle: vendor HALs can remain external
> > modules,
> > > > while the Zephyr drivers provide the integration with the generic
> > Zephyr
> > > > APIs.
> > > >
> > > > I’m curious what others think about this approach, especially
> regarding
> > > the
> > > > amount of integration and long-term maintenance work compared with
> > > > maintaining the HAL under the NuttX umbrella.
> > > >
> > > > Best regards,
> > > > Ahmed
> > > >
> > > > On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:
> > > >
> > > > > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > > > > <mo...@gmail.com> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Following the recent discussion in the thread “Early feedback on
> > > RZ/V2H
> > > > > > port and RZ FSP HAL dependency”, I would like to suggest applying
> > the
> > > > > same
> > > > > > idea discussed there to existing vendor HAL dependencies: hosting
> > > them
> > > > > > under github.com/NuttX, while keeping them separate from the ASF
> > > > > > repositories. This proposal is aligned with some opinions shared
> > > there.
> > > > > >
> > > > > > A practical example is esp-hal-3rdparty. I recently opened a very
> > > small
> > > > > fix
> > > > > > there:
> > > > > >
> > > > > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > > > >
> > > > > > The PR is still open without Espressif review. Interestingly, the
> > > > > technical
> > > > > > feedback so far came from Laczen, a NuttX contributor who is not
> > > part of
> > > > > > Espressif.
> > > > > >
> > > > > > This illustrates the issue when NuttX depends on a vendor
> > repository
> > > but
> > > > > > the vendor is temporarily unavailable to maintain or review it.
> > > > > >
> > > > > > Would it make sense to move esp-hal-3rdparty, and potentially
> > similar
> > > > > > vendor HAL repositories, under github.com/NuttX, with vendor
> > > maintainers
> > > > > > when available but NuttX committers retaining the ability to
> review
> > > and
> > > > > > maintain them when necessary?
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > *--Felipe Moura de Oliveira*
> > > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > > >
> > > > > I am still opponent of any external HAL/SDK in NuttX, it only
> brings
> > > > > problems in the long run, but if this particular HAL is already
> here
> > > > > we may try to experiment with it (and only this one for now) under
> > > > > github.com/nuttx umbrella to see if this approach would really
> solve
> > > > > any problems or add new problems. Time will tell and we can always
> > > > > fallback to the current vendor provided and controlled HAL if that
> > > > > approach fails for any reason?
> > > > >
> > > > > --
> > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > >
> > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

["Alan C. Assis" <ac...@gmail.com>]

Hi Alin,

If the HAL is provided by an external vendor, the supply chain attack
vector can occur regardless of where we host the code, since the original
code originates from the vendor.

I think the access to github.com/NuttX is at the same level as
github/apache/nuttx, only NuttX PMCs and committers have write access to it.

To host it at ASF, I think we need their agreement to host external code
even when using different licenses (i.e. BSD, MIT, etc)

BR,

Alan

On Wed, Sep 30, 2026 at 5:43 AM Alin Jerpelea <je...@gmail.com> wrote:

> Hi,
>
> I am concerned about having HALS outside ASF because they can constitute a
> supply chain attack vector while
>  the lack of central user management can create friction between NuttX
> committers and vendor representatives
>
> I propose that we host the HALS under ASF in a separate repository
> nuttx-vendor-hals with same access and rules
> as we have for the whole project.
>
> This ensures that we have proper oversight, access management and security
> from ASF
>
> Best regards
> Alin
>
> On Tue, Sep 29, 2026 at 10:39 PM Karel Kočí <cy...@email.cz> wrote:
>
> > Hi,
> >
> > I just want to point out that NuttX already has API that does that, lower
> > and
> > upper drivers. Upper driver is generic, lower is chip specific. API is
> not
> > stable but it is generic.
> >
> > I am still convinced that NuttX should have native chips (without HAL) in
> > repository and HAL supported chips as external integrations that are not
> > fully
> > tied to the merge and release cycle of NuttX. I still think that we
> should
> > limit
> > the need of core NuttX developers to understand every single HAL that
> > could be,
> > in some capacity, included and move that to dedicated maintainers
> > (prefferably
> > vendor supplied). That doesn't mean outside NuttX commiters reach, it
> > means that
> > most of the work would be done by dedicated developers with deeper
> > knowledge of
> > external source code (HAL) and not by NuttX developers improving drivers.
> > Even
> > if HAL supported chips would lag behing NuttX core.
> >
> > With regards
> > Karel
> >
> >
> > On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote:
> > > Hi all,
> > >
> > > I’m relatively new to the discussion, but I was wondering if we could
> > also
> > > consider an approach similar to how Zephyr handles vendor HALs.
> > >
> > > Instead of introducing a universal adapter between NuttX and every
> vendor
> > > HAL, perhaps the boundary could simply be:
> > >
> > > Generic NuttX API
> > >                  |
> > >     NuttX driver
> > >       /.                 \
> > >    native      vendor HAL
> > >       \                   /
> > >         hardware
> > >
> > > The driver would integrate only the functionality that NuttX actually
> > needs
> > > from the vendor HAL. For simple peripherals, the driver could use a
> > native
> > > implementation directly, while more complex platforms could reuse the
> > > vendor HAL.
> > >
> > > The vendor HAL itself could remain an external, version-pinned
> dependency
> > > managed by the NuttX build system.
> > >
> > > This seems to avoid the need to implement and maintain a
> general-purpose
> > > adapter for an entire vendor SDK, while still allowing NuttX to benefit
> > > from existing vendor implementations.
> > >
> > > Zephyr uses a similar principle: vendor HALs can remain external
> modules,
> > > while the Zephyr drivers provide the integration with the generic
> Zephyr
> > > APIs.
> > >
> > > I’m curious what others think about this approach, especially regarding
> > the
> > > amount of integration and long-term maintenance work compared with
> > > maintaining the HAL under the NuttX umbrella.
> > >
> > > Best regards,
> > > Ahmed
> > >
> > > On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:
> > >
> > > > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > > > <mo...@gmail.com> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Following the recent discussion in the thread “Early feedback on
> > RZ/V2H
> > > > > port and RZ FSP HAL dependency”, I would like to suggest applying
> the
> > > > same
> > > > > idea discussed there to existing vendor HAL dependencies: hosting
> > them
> > > > > under github.com/NuttX, while keeping them separate from the ASF
> > > > > repositories. This proposal is aligned with some opinions shared
> > there.
> > > > >
> > > > > A practical example is esp-hal-3rdparty. I recently opened a very
> > small
> > > > fix
> > > > > there:
> > > > >
> > > > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > > >
> > > > > The PR is still open without Espressif review. Interestingly, the
> > > > technical
> > > > > feedback so far came from Laczen, a NuttX contributor who is not
> > part of
> > > > > Espressif.
> > > > >
> > > > > This illustrates the issue when NuttX depends on a vendor
> repository
> > but
> > > > > the vendor is temporarily unavailable to maintain or review it.
> > > > >
> > > > > Would it make sense to move esp-hal-3rdparty, and potentially
> similar
> > > > > vendor HAL repositories, under github.com/NuttX, with vendor
> > maintainers
> > > > > when available but NuttX committers retaining the ability to review
> > and
> > > > > maintain them when necessary?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > *--Felipe Moura de Oliveira*
> > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > > >
> > > > I am still opponent of any external HAL/SDK in NuttX, it only brings
> > > > problems in the long run, but if this particular HAL is already here
> > > > we may try to experiment with it (and only this one for now) under
> > > > github.com/nuttx umbrella to see if this approach would really solve
> > > > any problems or add new problems. Time will tell and we can always
> > > > fallback to the current vendor provided and controlled HAL if that
> > > > approach fails for any reason?
> > > >
> > > > --
> > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > >
> >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Alin Jerpelea <je...@gmail.com>]

Hi,

I am concerned about having HALS outside ASF because they can constitute a
supply chain attack vector while
 the lack of central user management can create friction between NuttX
committers and vendor representatives

I propose that we host the HALS under ASF in a separate repository
nuttx-vendor-hals with same access and rules
as we have for the whole project.

This ensures that we have proper oversight, access management and security
from ASF

Best regards
Alin

On Tue, Sep 29, 2026 at 10:39 PM Karel Kočí <cy...@email.cz> wrote:

> Hi,
>
> I just want to point out that NuttX already has API that does that, lower
> and
> upper drivers. Upper driver is generic, lower is chip specific. API is not
> stable but it is generic.
>
> I am still convinced that NuttX should have native chips (without HAL) in
> repository and HAL supported chips as external integrations that are not
> fully
> tied to the merge and release cycle of NuttX. I still think that we should
> limit
> the need of core NuttX developers to understand every single HAL that
> could be,
> in some capacity, included and move that to dedicated maintainers
> (prefferably
> vendor supplied). That doesn't mean outside NuttX commiters reach, it
> means that
> most of the work would be done by dedicated developers with deeper
> knowledge of
> external source code (HAL) and not by NuttX developers improving drivers.
> Even
> if HAL supported chips would lag behing NuttX core.
>
> With regards
> Karel
>
>
> On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote:
> > Hi all,
> >
> > I’m relatively new to the discussion, but I was wondering if we could
> also
> > consider an approach similar to how Zephyr handles vendor HALs.
> >
> > Instead of introducing a universal adapter between NuttX and every vendor
> > HAL, perhaps the boundary could simply be:
> >
> > Generic NuttX API
> >                  |
> >     NuttX driver
> >       /.                 \
> >    native      vendor HAL
> >       \                   /
> >         hardware
> >
> > The driver would integrate only the functionality that NuttX actually
> needs
> > from the vendor HAL. For simple peripherals, the driver could use a
> native
> > implementation directly, while more complex platforms could reuse the
> > vendor HAL.
> >
> > The vendor HAL itself could remain an external, version-pinned dependency
> > managed by the NuttX build system.
> >
> > This seems to avoid the need to implement and maintain a general-purpose
> > adapter for an entire vendor SDK, while still allowing NuttX to benefit
> > from existing vendor implementations.
> >
> > Zephyr uses a similar principle: vendor HALs can remain external modules,
> > while the Zephyr drivers provide the integration with the generic Zephyr
> > APIs.
> >
> > I’m curious what others think about this approach, especially regarding
> the
> > amount of integration and long-term maintenance work compared with
> > maintaining the HAL under the NuttX umbrella.
> >
> > Best regards,
> > Ahmed
> >
> > On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:
> >
> > > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > > <mo...@gmail.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Following the recent discussion in the thread “Early feedback on
> RZ/V2H
> > > > port and RZ FSP HAL dependency”, I would like to suggest applying the
> > > same
> > > > idea discussed there to existing vendor HAL dependencies: hosting
> them
> > > > under github.com/NuttX, while keeping them separate from the ASF
> > > > repositories. This proposal is aligned with some opinions shared
> there.
> > > >
> > > > A practical example is esp-hal-3rdparty. I recently opened a very
> small
> > > fix
> > > > there:
> > > >
> > > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > > >
> > > > The PR is still open without Espressif review. Interestingly, the
> > > technical
> > > > feedback so far came from Laczen, a NuttX contributor who is not
> part of
> > > > Espressif.
> > > >
> > > > This illustrates the issue when NuttX depends on a vendor repository
> but
> > > > the vendor is temporarily unavailable to maintain or review it.
> > > >
> > > > Would it make sense to move esp-hal-3rdparty, and potentially similar
> > > > vendor HAL repositories, under github.com/NuttX, with vendor
> maintainers
> > > > when available but NuttX committers retaining the ability to review
> and
> > > > maintain them when necessary?
> > > >
> > > > Best regards,
> > > >
> > > > *--Felipe Moura de Oliveira*
> > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > >
> > > I am still opponent of any external HAL/SDK in NuttX, it only brings
> > > problems in the long run, but if this particular HAL is already here
> > > we may try to experiment with it (and only this one for now) under
> > > github.com/nuttx umbrella to see if this approach would really solve
> > > any problems or add new problems. Time will tell and we can always
> > > fallback to the current vendor provided and controlled HAL if that
> > > approach fails for any reason?
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Karel Kočí <cy...@email.cz>]

Hi,

I just want to point out that NuttX already has API that does that, lower and
upper drivers. Upper driver is generic, lower is chip specific. API is not
stable but it is generic.

I am still convinced that NuttX should have native chips (without HAL) in
repository and HAL supported chips as external integrations that are not fully
tied to the merge and release cycle of NuttX. I still think that we should limit
the need of core NuttX developers to understand every single HAL that could be,
in some capacity, included and move that to dedicated maintainers (prefferably
vendor supplied). That doesn't mean outside NuttX commiters reach, it means that
most of the work would be done by dedicated developers with deeper knowledge of
external source code (HAL) and not by NuttX developers improving drivers. Even
if HAL supported chips would lag behing NuttX core.

With regards
Karel


On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote:
> Hi all,
> 
> I’m relatively new to the discussion, but I was wondering if we could also
> consider an approach similar to how Zephyr handles vendor HALs.
> 
> Instead of introducing a universal adapter between NuttX and every vendor
> HAL, perhaps the boundary could simply be:
> 
> Generic NuttX API
>                  |
>     NuttX driver
>       /.                 \
>    native      vendor HAL
>       \                   /
>         hardware
> 
> The driver would integrate only the functionality that NuttX actually needs
> from the vendor HAL. For simple peripherals, the driver could use a native
> implementation directly, while more complex platforms could reuse the
> vendor HAL.
> 
> The vendor HAL itself could remain an external, version-pinned dependency
> managed by the NuttX build system.
> 
> This seems to avoid the need to implement and maintain a general-purpose
> adapter for an entire vendor SDK, while still allowing NuttX to benefit
> from existing vendor implementations.
> 
> Zephyr uses a similar principle: vendor HALs can remain external modules,
> while the Zephyr drivers provide the integration with the generic Zephyr
> APIs.
> 
> I’m curious what others think about this approach, especially regarding the
> amount of integration and long-term maintenance work compared with
> maintaining the HAL under the NuttX umbrella.
> 
> Best regards,
> Ahmed
> 
> On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:
> 
> > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> > <mo...@gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > Following the recent discussion in the thread “Early feedback on RZ/V2H
> > > port and RZ FSP HAL dependency”, I would like to suggest applying the
> > same
> > > idea discussed there to existing vendor HAL dependencies: hosting them
> > > under github.com/NuttX, while keeping them separate from the ASF
> > > repositories. This proposal is aligned with some opinions shared there.
> > >
> > > A practical example is esp-hal-3rdparty. I recently opened a very small
> > fix
> > > there:
> > >
> > > https://github.com/espressif/esp-hal-3rdparty/pull/15
> > >
> > > The PR is still open without Espressif review. Interestingly, the
> > technical
> > > feedback so far came from Laczen, a NuttX contributor who is not part of
> > > Espressif.
> > >
> > > This illustrates the issue when NuttX depends on a vendor repository but
> > > the vendor is temporarily unavailable to maintain or review it.
> > >
> > > Would it make sense to move esp-hal-3rdparty, and potentially similar
> > > vendor HAL repositories, under github.com/NuttX, with vendor maintainers
> > > when available but NuttX committers retaining the ability to review and
> > > maintain them when necessary?
> > >
> > > Best regards,
> > >
> > > *--Felipe Moura de Oliveira*
> > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> >
> > I am still opponent of any external HAL/SDK in NuttX, it only brings
> > problems in the long run, but if this particular HAL is already here
> > we may try to experiment with it (and only this one for now) under
> > github.com/nuttx umbrella to see if this approach would really solve
> > any problems or add new problems. Time will tell and we can always
> > fallback to the current vendor provided and controlled HAL if that
> > approach fails for any reason?
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Ahmed Ashraf <a....@gmail.com>]

Hi all,

I’m relatively new to the discussion, but I was wondering if we could also
consider an approach similar to how Zephyr handles vendor HALs.

Instead of introducing a universal adapter between NuttX and every vendor
HAL, perhaps the boundary could simply be:

Generic NuttX API
                 |
    NuttX driver
      /.                 \
   native      vendor HAL
      \                   /
        hardware

The driver would integrate only the functionality that NuttX actually needs
from the vendor HAL. For simple peripherals, the driver could use a native
implementation directly, while more complex platforms could reuse the
vendor HAL.

The vendor HAL itself could remain an external, version-pinned dependency
managed by the NuttX build system.

This seems to avoid the need to implement and maintain a general-purpose
adapter for an entire vendor SDK, while still allowing NuttX to benefit
from existing vendor implementations.

Zephyr uses a similar principle: vendor HALs can remain external modules,
while the Zephyr drivers provide the integration with the generic Zephyr
APIs.

I’m curious what others think about this approach, especially regarding the
amount of integration and long-term maintenance work compared with
maintaining the HAL under the NuttX umbrella.

Best regards,
Ahmed

On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <to...@cedro.info> wrote:

> On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> <mo...@gmail.com> wrote:
> >
> > Hi all,
> >
> > Following the recent discussion in the thread “Early feedback on RZ/V2H
> > port and RZ FSP HAL dependency”, I would like to suggest applying the
> same
> > idea discussed there to existing vendor HAL dependencies: hosting them
> > under github.com/NuttX, while keeping them separate from the ASF
> > repositories. This proposal is aligned with some opinions shared there.
> >
> > A practical example is esp-hal-3rdparty. I recently opened a very small
> fix
> > there:
> >
> > https://github.com/espressif/esp-hal-3rdparty/pull/15
> >
> > The PR is still open without Espressif review. Interestingly, the
> technical
> > feedback so far came from Laczen, a NuttX contributor who is not part of
> > Espressif.
> >
> > This illustrates the issue when NuttX depends on a vendor repository but
> > the vendor is temporarily unavailable to maintain or review it.
> >
> > Would it make sense to move esp-hal-3rdparty, and potentially similar
> > vendor HAL repositories, under github.com/NuttX, with vendor maintainers
> > when available but NuttX committers retaining the ability to review and
> > maintain them when necessary?
> >
> > Best regards,
> >
> > *--Felipe Moura de Oliveira*
> > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> I am still opponent of any external HAL/SDK in NuttX, it only brings
> problems in the long run, but if this particular HAL is already here
> we may try to experiment with it (and only this one for now) under
> github.com/nuttx umbrella to see if this approach would really solve
> any problems or add new problems. Time will tell and we can always
> fallback to the current vendor provided and controlled HAL if that
> approach fails for any reason?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Proposal: host vendor HAL repositories under github.com/NuttX

[Tomek CEDRO <to...@cedro.info>]

On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
<mo...@gmail.com> wrote:
>
> Hi all,
>
> Following the recent discussion in the thread “Early feedback on RZ/V2H
> port and RZ FSP HAL dependency”, I would like to suggest applying the same
> idea discussed there to existing vendor HAL dependencies: hosting them
> under github.com/NuttX, while keeping them separate from the ASF
> repositories. This proposal is aligned with some opinions shared there.
>
> A practical example is esp-hal-3rdparty. I recently opened a very small fix
> there:
>
> https://github.com/espressif/esp-hal-3rdparty/pull/15
>
> The PR is still open without Espressif review. Interestingly, the technical
> feedback so far came from Laczen, a NuttX contributor who is not part of
> Espressif.
>
> This illustrates the issue when NuttX depends on a vendor repository but
> the vendor is temporarily unavailable to maintain or review it.
>
> Would it make sense to move esp-hal-3rdparty, and potentially similar
> vendor HAL repositories, under github.com/NuttX, with vendor maintainers
> when available but NuttX committers retaining the ability to review and
> maintain them when necessary?
>
> Best regards,
>
> *--Felipe Moura de Oliveira*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>

I am still opponent of any external HAL/SDK in NuttX, it only brings
problems in the long run, but if this particular HAL is already here
we may try to experiment with it (and only this one for now) under
github.com/nuttx umbrella to see if this approach would really solve
any problems or add new problems. Time will tell and we can always
fallback to the current vendor provided and controlled HAL if that
approach fails for any reason?

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info