What the Licence Demands of a Kit, the Vendor ID, and Whether to Write New Firmware

6.1 What this volume is, and is not

It is a reading of the licence texts and the repositories’ own files, as they bear on this firmware. It is not legal advice. Decision D11 makes the licences binding for this project because kits may be sold; the legal treatment of the whole kit (trademarks and trade dress, 3D-model licences, product safety, shipping batteries) belongs to Licensing, IP and Kits, which is planned. Open-Source Firmware Vol 1 §1.12 and Vol 7 §7.9 set out the licences of OpenFIRE as published; this volume adds what a modified firmware in a sold product owes.

6.2 The licences inside one binary

Read from each file’s header at v6.2 (19 October 2026):

Table 1 — Read from each file's header at v6.2 (19 October 2026)

Component	Header	Licence
OpenFIREmain/ (the sketch)	That One Seong, 2025	LGPL
libraries/OpenFIREPosition	Samco 2024, Mike Lynch 2021 (the perspective code also credits 88hcsif 2021 and Stéphane Duchesneau 2008)	LGPL
libraries/DFRobotIRPositionEx	DFRobot 2016, Mike “Prow” Lynch 2021	LGPL
libraries/TinyUSB_Devices	derived from Arduino LLC’s keyboard and mouse code (2015) and Peter Barrett (2011)	LGPL
libraries/LightgunButtons	Mike Lynch, 2021	GPL, “either version 3 of the License, or” any later
boards/OpenFIREshared.h (submodule)	That One Seong, 2025	GPL-3.0 or later
Adafruit NeoPixel (submodule)	Adafruit	LGPL-3.0 (GitHub’s licence field)
Adafruit SSD1306, GFX (submodules)	Adafruit, 2012	BSD (“Software License Agreement (BSD License)“)
Adafruit BusIO (submodule)	Adafruit	MIT
The repository’s LICENSE	—	LGPL-2.1

One correction to the published dive. Open-Source Firmware names OpenFIREshared.h as the GPL file compiled into the LGPL firmware. There is a second: the button library, LightgunButtons, is GPL-3.0-or-later in its own header. The conclusion does not change (a binary containing GPL code is distributed under the GPL), but it removes any thought that the GPL could be avoided by rewriting the one shared header.

How LGPL and GPL code combine. LGPL-2.1 section 3 provides the route: “You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library … (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.)” So the LGPL parts can be carried under GPL-3.0 with the GPL parts, and the firmware as built, OpenFIRE’s or the fork’s, is distributed as a GPL-3.0 work. The section adds that once the change is made “in a given copy, it is irreversible for that copy”; nothing is lost by it here, since the GPL parts already set the terms.

What the GPL does not restrict. Section 4: “You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.” A kit can be sold at a profit. What cannot be done is to sell it while keeping the firmware’s source from the buyer, or forbidding the buyer from sharing it.

6.3 When the obligations start

The licence’s trigger is “convey”: “any kind of propagation that enables other parties to make or receive copies”. Its definition of “propagate” excludes “executing it on a computer or modifying a private copy”. So:

Table 2 — The licence's trigger is "convey": "any kind of propagation that enables other parties to make or receive copies". Its definition of "propagate" excludes "executing it on a computer or modifying a private copy". So

Situation	Conveying?	Owes
The fork built and run on the bench, in the private repository	No: a private copy, modified and run	nothing
A UF2 handed to a friend, or a gun lent or given away	Yes	the source of that build, to that person
A kit or a built gun sold	Yes	sections 5 and 6, below, and the User Product rule (6.5)
The UF2 offered for download	Yes	equivalent access to the source in the same place

This is why decision D12 and the GPL do not collide: the firmware is private while it is on the bench, and becomes source-available to each recipient the moment a copy leaves the house. It does not have to become public. The GPL requires the source to go to those who receive the binary, and allows each of them to pass it on.

6.4 What a kit must carry

Section 5, the modified source. A modified version must “carry prominent notices stating that you modified it, and giving a relevant date”; must carry notices “that it is released under this License”; and the whole must be licensed “as a whole, under this License to anyone who comes into possession of a copy”. For the fork that means a notice in the README and in each changed file’s header naming the change and the date, the upstream copyright lines kept, and the GPL-3.0 text included.

Section 6, the binary. The firmware ships as object code in a physical product, so section 6 applies. The options that fit a kit:

Table 3 — Section 6, the binary. The firmware ships as object code in a physical product, so section 6 applies. The options that fit a kit

Option (GPL-3.0 §6)	What it requires	Fit
6a — source on “a durable physical medium customarily used for software interchange” with the product	a USB stick or card in the box	Works; adds a part and a cost to every kit
6b — “a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model”, to provide the source on a medium at cost “or (2) access to copy the Corresponding Source from a network server at no charge”	a printed offer in the box; a server that keeps the source available for at least three years	Proposed: cheapest per kit; the release’s source archive (Volume 4 §4.8) is exactly what goes on the server
6d — when the binary is offered for download, “equivalent access to the Corresponding Source in the same way through the same place”	the source beside every downloadable UF2	Applies on top of 6b once firmware updates are offered for download

What “Corresponding Source” includes. “All the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.” For the fork: the tree at the release tag, every submodule at its recorded commit, the build script and the recorded compile line (Volume 4 §4.5). Generally available tools used unmodified, such as arduino-cli and the published core, are excluded by the definition, but naming their exact versions in the manifest is what makes the source usable.

The authors’ requests, which are not licence terms (Open-Source Firmware Vol 1): keep the OpenFIRE name and the credits to That One Seong, Samuel Ballantyne and Mike Lynch; do not fork to rebrand; make OpenFIRE’s use clear in the product; raise “third-party commercial sales of OpenFIRE-enabled products” in the repository’s Discussions or by email; and never charge for the firmware itself (“if you have been charged any amount to use OpenFIRE, you have been scammed”). A kit priced for its hardware, with the firmware free and its source offered, satisfies all of them. Talking to the team first is also the practical route to the vendor ID question (6.6).

6.5 A kit is a User Product

GPL-3.0 adds a rule for “User Products”: “(1) a ‘consumer product’, which means any tangible personal property which is normally used for personal, family, or household purposes”, with “doubtful cases … resolved in favor of coverage.” A light gun for home gaming is plainly one. When object code is conveyed in a User Product with a transfer of possession, the source “must be accompanied by the Installation Information”: “any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source”. The requirement falls away only “if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM)”.

For an RP2040 gun this is easy to satisfy. The chip’s boot ROM presents a USB drive when BOOTSEL is held at power-up, and any UF2 copied to it is flashed (Open-Source Firmware Vol 4); the App can also reboot a docked gun into that mode. Nothing is locked, so the Installation Information is the build instructions plus the flashing procedure, both of which are in the release already. Two design rules keep it that way:

• The BOOTSEL button stays reachable, or there is a documented way to enter the bootloader without opening the gun (the App’s reboot command works only while the firmware runs).
• The Pico 2’s signed boot is never enabled. Raspberry Pi lists for the RP2350 “Optional boot signing, enforced by on-chip mask ROM, with key fingerprint in OTP”. A kit that switched it on would have to hand buyers the signing key under this clause, or stop them from running modified firmware, which the licence forbids. The plan leaves it off.

The licence is explicit that this does not oblige support: the requirement “does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient”.

6.6 The USB vendor ID

Decision D24: keep OpenFIRE’s 0xF143 now; obtain an assigned vendor ID before any kit sale. 0xF143 is OpenFIRE’s choice; it does not appear in the public usb.ids list (version 2026.06.26, checked again on 19 October 2026), and who, if anyone, holds it from the USB-IF was not established. The App’s port search keeps only serial ports whose vendor ID is 0xF143, and MiSTer and QMamehook find the gun by it and by the “OpenFIRE” name (Open-Source Firmware Vol 6 §6.5). So the ID question is two questions: which ID a kit may use, and what has to change so the tools still find the gun.

Table 4 — 6.6 The USB vendor ID

Route	Cost (2026-10-19)	Terms, quoted	Breaks	Fit
Keep 0xF143	none	not the project’s ID; status unknown	nothing	Bench and personal guns (D24). Not for sale without TeamOpenFIRE’s agreement
Ask TeamOpenFIRE	none	their README invites commercial sellers to raise it	depends on the answer	First step: the authors already ask kit sellers to contact them, and they own the code that filters by ID
A product ID under Raspberry Pi’s 0x2E8A	not stated on the page	”The USB-IF have given Raspberry Pi permission to sub-license the USB product ID values for its vendor ID (0x2E8A) since they are to be used on a common silicon component which will be used within a customer’s product (the RP2040 silicon)”; for HID and CDC devices “we can create a standard PID to cover devices with that particular interface combination”	App, MiSTer and QMamehook until each is taught the new ID	Proposed if TeamOpenFIRE has no arrangement: free or cheap, and the gun is an RP2040 product
pid.codes, under 0x1209	no fee stated	requires “Licensed under a recognized open source or open source hardware license”, a “Publicly available source code repository” and, for hardware, “modifiable PCB design files (schematics and layout)“	as above	Only if the carrier’s design files are published; conflicts with D12 until then
A vendor ID from the USB-IF	”The Vendor ID is US$6,000” one-off, or membership at “US$5,000” a year, which includes one	the company’s own ID; the USB logo only for licensees whose products pass compliance testing	as above	Only at volume; a large fixed cost for a small kit

Raspberry Pi’s list notes that a separate product ID is usually needed only “because Windows uses the product ID to select a vendor-specific driver”, and that devices on a shared ID can still be identified by their manufacturer, product and serial strings. The OpenFIRE gun is HID plus CDC serial with standard drivers, so a shared standard PID under 0x2E8A, identified by its “OpenFIRE” strings, is plausible. Whatever ID is chosen, the App’s port filter and MiSTer’s detection must accept it; the tidy way is a small change upstream to accept a list of IDs, which is a natural first contribution once D10’s reporting begins.

Whether Raspberry Pi’s sub-licence covers RP2350 products as well as RP2040 ones was not confirmed from its terms (the page names the RP2040).

6.7 Borrowing from the ESP32 port: a licence caution

Volume 2 takes several functions from Alessandro Satanassi’s ESP32 port (the calibration map, the index fix, the PixArt driver). The port’s repository is LGPL-2.1. But two of its files that correspond to GPL originals in TeamOpenFIRE’s tree carry the port author’s own copyright and an LGPL notice: its OpenFIREshared.h (“@copyright alessandro-satanassi … 2026 / @copyright GNU Lesser General Public License”, while the TeamOpenFIRE original is That One Seong’s, GPL-3.0-or-later) and its LightgunButtons (likewise, against Mike Lynch’s GPL original). The port’s OpenFIREshared.h keeps the original’s comments word for word, including “Any new non-btn slots should ideally be added at the bottom, above the ‘count’ line”, so it is derived from the GPL file, not written fresh.

For this fork it changes little, because the fork is distributed under GPL-3.0 anyway. The rule is simply: anything borrowed from the port that derives from a GPL original is treated as GPL-3.0 and credited to the original authors as well as the port’s. The PixArt driver is the port author’s own work under the LGPL and has no such question. Whether to mention the header question to the port’s author is the owner’s call; D10 defers upstream contact generally.

6.8 Should the project write its own firmware?

The question deserves a straight answer, not a reflex. A clean-sheet firmware would have real advantages:

• Licence freedom. Code written from scratch can be licensed however the project likes, including closed. A competitor who buys one kit would not get the fork’s improvements with it.
• An architecture built for this gun. Two regulated stages, a port state machine, an IMU bridge and an analog trigger are bolted onto OpenFIRE’s structure; new firmware could be designed around them, with host-testable modules from the start (Volume 5).
• No merge burden. Nothing to carry across upstream releases.

Against that, what it would have to replace, measured at v6.2:

Table 5 — Against that, what it would have to replace, measured at v6.2

What a rewrite replaces	Size or dependency
The firmware itself	about 9,950 lines: the sketch’s 6,849 plus the four in-tree libraries
The shared board and protocol header	890 lines, and the contract the App depends on
The configuration App	a Qt program for Windows and Linux; without it, every user setting needs a new tool
MiSTer support	merged into MiSTer’s main binary, keyed to the 0xF143 ID, the “OpenFIRE ” name and the M0x9 command
Force-feedback hooks	MAMEHooker, QMamehook and The Hook Of The Reaper speak OpenFIRE’s serial dialect
The field record	three releases of fixes from a community of users; the four-point square tracking traces back through Prow Enhanced and SAMCO

Re-implementing the protocols is possible: a protocol is not copyrightable in the way code is, and MiSTer’s detection is a published behaviour. But writing new code to match an interface while reading GPL source that implements it invites the question of whether the new code is a derivative, which is exactly the question a kit seller does not want; a clean re-implementation would need to work from the documented behaviour, not the source. And the gun would lose the App, which is most of OpenFIRE’s ease of use for a buyer.

The honest assessment: for a gun built by two people and possibly sold in small numbers, the fork wins clearly today. The licence cost of the fork is that buyers get the source, which the project has already accepted by choosing OpenFIRE (OF-1). The engineering cost is the merge work of Volume 4, which is small while upstream releases a few times a year and has been idle for six months.

What would change the answer. Any of these is a trigger to revisit:

1. Upstream goes dormant for more than a year and the fork’s changes reach most of the hot files, so the fork is in effect a new firmware already.
2. The kit needs features OpenFIRE’s structure fights (a second camera, a different MCU family, a radio that the RP2040 line cannot host).
3. The owner decides the kit’s firmware must be closed. That cannot be met by any OpenFIRE derivative and would force a clean-sheet design from documented behaviour only.

6.9 Why this, and why not the others

FW-7, vendor ID route (proposed here): ask TeamOpenFIRE first; failing an arrangement, a standard product ID under Raspberry Pi’s 0x2E8A, with a small upstream change so the App and MiSTer accept it. Rejected for now: the USB-IF ID (US$6,000 against a small kit run); pid.codes (requires the carrier’s design files public, against D12); shipping 0xF143 unagreed (not the project’s ID).

FW-8, firmware route (proposed here):

Table 6 — FW-8, firmware route (proposed here)

Option	Verdict	Reason
Private fork of OpenFIRE v6.2 (OF-1)	Pick	Keeps the App, MiSTer and the hook programs; every proposed change fits its structure; the GPL cost is source to buyers, already accepted
Contribute everything upstream and ship stock releases	The long-term ideal; deferred by D10	The least work to maintain, but upstream must accept the changes and has been idle since April 2026
Fork the ESP32 port instead	Rejected for now (D30)	Pre-release (v7.0.0 rc5), changes daily; the right base only if the kit goes wireless on the ESP32-S3 (P-RE18)
Stock OpenFIRE plus a second microcontroller for the extras	Rejected	Keeps the main firmware unmodified, but the trigger, calibration and sequencing changes all live in the main firmware’s own loop; a co-processor cannot fix them
New firmware from scratch	Rejected now; triggers listed in 6.8	~10,000 lines plus the App and three host integrations to replace, for licence freedom the project has not asked for
A closed commercial firmware (GUN4IR, Blamcon and others)	Rejected	Their terms forbid commercial use or modification (Open-Source Firmware Vol 1)

6.10 What could not be verified

• Who holds vendor ID 0xF143 with the USB-IF, if anyone.
• Whether Raspberry Pi charges for, or limits, product IDs under 0x2E8A, and whether RP2350 products qualify; the page states neither.
• Whether the ESP32 port’s LGPL headers on GPL-derived files were an oversight or rest on permission from the original authors; nothing published says.
• Every reading here is of the licence texts and repository files; none has been reviewed by a lawyer, and the kit-level analysis waits for Licensing, IP and Kits.

Sources

1. Free Software Foundation, GNU General Public License, version 3, 29 June 2007, https://www.gnu.org/licenses/gpl-3.0.txt — sections 0, 1, 4, 5, 6 quoted; fetched 2026-10-19.
2. Free Software Foundation, GNU Lesser General Public License, version 2.1, February 1999, https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt — section 3 quoted; fetched 2026-10-19.
3. TeamOpenFIRE, OpenFIRE-Firmware v6.2: LICENSE, README.md, every library header, OpenFIREmain/OpenFIREDefines.h; OpenFIRE-Boards OpenFIREshared.h; OpenFIRE-App src/appserial.cpp — read 2026-10-19.
4. Adafruit, Adafruit_NeoPixel, Adafruit_SSD1306, Adafruit-GFX-Library, Adafruit_BusIO: licence fields and license.txt files through the GitHub API — read 2026-10-19.
5. Alessandro Satanassi, OpenFIRE-Firmware-ESP32: LICENSE, lightgun/src/boards/OpenFIREshared.h, lightgun/lib/LightgunButtons/, lightgun/lib/PixArt_PAJ7025/ — snapshot 2026-10-19.
6. USB Implementers Forum, “Getting a Vendor ID”, https://www.usb.org/getting-vendor-id — read 2026-10-19.
7. Raspberry Pi Ltd, raspberrypi/usb-pid README, https://github.com/raspberrypi/usb-pid — read 2026-10-19 (last commit 2026-10-16).
8. pid.codes, “How to get a PID”, https://pid.codes/howto/ — read 2026-10-19.
9. Linux USB ID repository, usb.ids, version 2026.06.26, http://www.linux-usb.org/usb.ids — checked 2026-10-19.
10. Raspberry Pi Ltd, RP2350 product page, https://www.raspberrypi.com/products/rp2350/ — security features quoted, read 2026-10-19.
11. Open-Source Firmware dive, Volumes 1, 4, 6, 7.