ARCTIC dual-licenses its Linux fan driver for the BSDs

ARCTIC is changing the license on its Linux fan controller driver from GPLv2+ alone to GPLv2+ and BSD-2-Clause together. Phoronix reported the change on September 13, 2026, and says it has landed in the hwmon-next branch for the Linux 7.4 kernel. The point is to let systems that avoid the GNU GPL use the same code.

The driver is called arctic_fan_controller in the kernel tree. It sits in hwmon, the subsystem that handles hardware monitoring, meaning temperatures, voltages and fan speeds. The hardware is a USB device that controls desktop case fans, and Phoronix puts its price at $8.99.

Why a second license changes anything

A license is permission, and the two here grant it on different terms. The GPL requires anyone who distributes changed code to publish their changes under the same license. BSD-2-Clause asks only that you keep the copyright notice, and it lets a company ship a modified version without releasing the source.

Dual licensing means the file carries both, and whoever uses it picks one. Nothing is taken away from Linux, which keeps the GPL as before. What changes is who else can start from this code.

Phoronix puts the goal plainly. The change will help anyone who wants "to bring this fan controller driver to the BSDs," the report says. It names "other platforms where preferring something other than the GNU GPL" as well. FreeBSD, OpenBSD and NetBSD all avoid pulling GPL code into their base systems, so a GPL-only driver is effectively a blank page for them.

The hardware behind the driver

The device itself is modest. ARCTIC's user manual says it drives up to 10 fans, connects to a motherboard USB 2.0 header, and needs SATA power. Fans start at a 40% duty cycle, the setting that decides how fast they spin, on a scale of 0 to 255. The manual lists Linux 7.2 as the minimum kernel version and says the unit does not support hot-swapping.

Open Source For You reported in July 2026 that the controller offers 10 independent channels, adjusts each one separately, and reports fan speed once per second. Its account of hot-plugging differs from the manual's line on hot-swapping, and the two sources use different words for what may be different behaviors. Treat the manual as the authority on the shipping product.

What stands out is the order of events. ARCTIC "did not use community-developed drivers," Open Source For You wrote. The company "developed the Linux driver internally and submitted it to be included in the mainline Linux kernel before releasing this product." The driver was upstream before customers could buy the hardware.

What this means for developers

Copy the sequencing, not just the license. Getting a driver merged before the product ships means every review comment arrives while the firmware can still change. Vendors who ship first and upstream later end up defending decisions they can no longer reverse.

Read the license header rather than assuming. A dual-licensed kernel file is still rare, and a SPDX-License-Identifier line with two entries is the only reliable signal. If you are porting a Linux driver to a BSD, that line decides whether you can start at all.

Push for dual licensing when you write vendor code yourself. If you work at a hardware company, the cost of adding BSD-2-Clause at submission time is a line in a header. The cost of adding it later is tracking down every contributor for permission.

Do not read it as a shift in the kernel. This is one vendor's choice about its own file, not a change in Linux policy. It is the same practical pattern seen when Intel ships its own NPU driver updates on its own schedule. The interesting part is that a consumer accessory maker thought about BSD users at all, at a price under ten dollars.