Hi Alin, I think Xiang, Greg and Binh are right to suggest keeping it at github.com/NuttX
Only NuttX's PMCs and Committers have write access to this repository, so I don't think this is a concern. ASF wants to own everything, to have control and legal rights over everything, but that is a vendor HAL. Similarly, ARM shouldn't give away its CMSIS-DSP ownership to ASF if we decide to integrate it into a chip here. BR, Alan On Fri, Sep 25, 2026 at 3:24 AM Alin Jerpelea <[email protected]> wrote: > Hi Binh, > > unfortunately I tend to disagree with point 2 > hosting outside ASF in my opinion is not an option from a supply chain and > management perspective > I think that from a manufacturer point of view will be more secure to have > all components under ASF, maintained by committers and under project's by > PMC > ASF already provides the user management and the needed infrastructure for > this git ensuring proper proper resources so that it does not become a > concern. > > My suggestion is to try and speak with management so that they understand > the long therm benefits of hosting the HAL under ASF > > Best regards > Alin Jerpelea > > On Fri, Sep 25, 2026 at 8:07 AM Binh Nguyen <[email protected]> > wrote: > > > Hi all, > > > > Thanks for keeping the discussion going, let me share my thoughts on the > > open points. > > > > 1. License (Gregory's question): Renesas FSP is BSD 3-Clause, so it's > > Apache-2.0 compatible, licensing shouldn't be the blocker here. For > > reference Zephyr accepts the same kind of thing for their vendor HALs, > e.g. > > hal_stm32, hal_nxp etc are also BSD/Apache-2.0 style, hosted separately > > from the core zephyr repo. > > > > 2. Hosting: Agree with Xiang here, not proposing an SGA to donate the > code > > to ASF, FSP stays Renesas-owned. What we want is just a repo under > > github.com/NuttX, outside the ASF-governed tree, same idea as Zephyr > > keeping vendor HAL modules in separate repos under their org instead of > > inside zephyrproject-rtos/zephyr. Solves Gregory's ownership/donation > > concern and still gives NuttX committers real access instead of us just > > pointing at an external fork. > > > > 3. Code quality: to be specific about which part is which - the > adaptation > > layer (drivers interfaces, board/arch integration, Kconfig, build glue) > > would follow NuttX coding style and pass NuttX CI like any other code, > > that's what NuttX committers review. The FSP source itself we'd keep > mostly > > as-is, rewriting it to match NuttX style kind of defeats the point of > > reusing it and just forks us from upstream. > > > > 4. Maintenance risk: I can't promise Renesas will maintain it forever, > > companies change priorities, we've all seen that happen. What I can say > is > > if that happens, the repo and history stay on github.com/NuttX, > community > > keeps full access and can just keep maintaining it themselves, no vendor > > lock-in on the repo itself. Not that different from what already happens > > when someone abandons a board they contributed. > > > > 5. On native (Matteo's question): honestly the main reason we'd rather > not > > go full native is duplicated effort - we'd be rewriting driver logic that > > already exists and is maintained in our HAL, which we also use for Zephyr > > on the same board. Keeping two separate low-level implementations going > > long term is a real cost for us, and errata/new device support would > still > > need tracking twice. > > > > Happy to provide any further detail needed to support a formal vote on > > this. > > > > Best Regards, > > Binh Nguyen > > > > >
