Thanks Greg. https://github.com/apache/nuttx/pull/19600 imports mknxflat only: the thunk generator, its two skeletons and its header. ldnxflat is not imported; NuttX keeps calling it from buildroot. So the elf2flt lineage you flag in ldelflib doesn't reach any of it, and I found no elf2flt, uClinux, XFLAT or GPL text in the five files.
They are BSD-3-Clause, copyright you and Cadenux. Could you state on the PR that both grant them to the ASF under Apache-2.0? Your ICLA covers your own copyright; the Cadenux line is the part that needs you on the record. I would then relicense the headers to match binfmt/libnxflat. On the PIC base: yes, -mpic-register=r9, but the firmware has to reserve r9 as well, REG_PIC in irq.h is arch code, and the NXFLAT thunks name the register as a string. Best Regards Marco Casaroli On Mon, Aug 3, 2026 at 3:52 PM Gregory Nutt <[email protected]> wrote: > This is a little complicated. I will just list some issues: > > > 1. > Cadenux was a business that I owned (with partners) about 2002 > 2. > NXFLAT is at > https://github.com/patacongo/buildroot/tree/main/toolchain/nxflat > 3. > XFLAT is GPL (see https://sourceforge.net/projects/xflat/) or at least > derives from GPL sources. > 4. > Ldelflib is proprietary owned by Cadenux and myself. I can grant anything > that derives from it to Apache. In fact, anything that has my copyright > (or, I assume the Cadenux copyright) can be given to the ASF (with my > permission). > 5. > Complications: (1) Ldelfib derives from elf2flt which was part of > uClinux-dev making those BSD licenses suspect. If the comments are > accurate. (2) That was 24 years ago. My recollections of licensing details > is more that just hazy. > 6. > I used to have a policy of acknowledge every person who influenced the > code development even though they were not actually copy holds. This > policy confused a lot of people. > 7. > The licensing is complicated. I have no personal issues with granting > that code to the ASF if it is possible to sanitize the licensing. > > I don't think I added anything that you don't already know. > > OT: Isn't the PIC base a compiler command line argument? I don't recall. > > ________________________________ > From: Marco C. <[email protected]> > Sent: Monday, August 3, 2026 1:59 AM > To: [email protected] <[email protected]> > Cc: [email protected] <[email protected]> > Subject: NuttX: importing mknxflat into the Apache tree — licence > confirmation? > > Hi Greg, > > I have a licensing question about the NXFLAT toolchain and I would value > your confirmation, since you are the copyright holder. I have asked it on > the pull request so the answer is on the record: > https://github.com/apache/nuttx/pull/19600#issuecomment-5164283980 > > The short version: that PR moves the ARM PIC base register from r10 to r9, > which breaks NXFLAT silently, because mknxflat bakes the register into the > import thunks it generates as add ip,ip,sl. While the tool lives outside > the NuttX repository it can drift out of step with the kernel, so the PR > brings it in-tree as tools/nxflat/. > > The files taken are mknxflat.c and the two dyncall_skeleton.def templates > from the buildroot NXFLAT toolchain. Each carries a BSD-3-Clause header > naming you and Cadenux LLC, and notes that the code derives from XFLAT's > ldelflib. The containing repository's COPYING is GPL-2.0, so rather than > assume the per-file grant governs, I would rather hear it from you: is > BSD-3 the operative licence for those three files, and are you content for > them to live in an Apache-2.0 repository with their headers intact? > > I have deliberately left ldnxflat alone. It carries an explicit > GPL-2.0-or-later notice and descends from elf2flt with roughly ten > copyright holders going back to 1996, so NXFLAT will continue to need it > from buildroot as it does today. > > The only substantive change to the imported code is dropping the libbfd > dependency, which was only ever used to open the file and enumerate > symbols; the tool now reads the ELF symbol table directly. The generated > thunk files are byte-identical to what the current tool produces, for both > ARM and Thumb-2. > > A reply on the list would be ideal so the answer is archived alongside the > change, but whatever is easiest for you is fine. > > Thanks very much, > Marco Casaroli >
