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 > >
