37
Arjun’s Systems Brief: FreeBSD 16 just killed the last piece of GPL code in its base system. The dialog utility is gone, the GNU subtree is deleted, and the entire OS core now runs on pure BSD licensing. I spent the last few days digging through the Phabricator tickets, the GitHub commits, and the mailing list threads to figure out what this actually changes for Linux sysadmins. Here is the take on why this matters more than the headlines suggest, and where it does not change a single thing.
FreeBSD 16 Retires All GPL Code From Its Base System
On July 7, 2026, FreeBSD developer Dag-Erling Smørgrav committed a change that had been in the works for months. The commit message was blunt: “With GNU diff and cdialog gone, this is now an empty shell.” With that single push, the entire GNU subtree was deleted from the FreeBSD source tree. No GPL code remains in the base system. Zero.
I have been tracking BSD licensing politics for years, and honestly, I did not think this day would come this cleanly. The Phabricator ticket (D55424) was opened on February 21, 2026, and the community discussion that followed was one of the most civil and well-reasoned debates I have seen in open source. The Phoronix article from July 14 hit 96 comments and counting, which tells you this struck a nerve.
But here is the thing: most of the commentary focuses on the symbolic victory. What I want to dig into is what this actually changes in practice for people who run Linux, people who run FreeBSD, and people who straddle both worlds.
What Exactly Was Removed From FreeBSD 16
Let me break down the specifics because the details matter here. Three components were retired from the FreeBSD base system:
dialog was the last GNU GPL-licensed software sitting in the base system. This is the ncurses-based dialog utility that provides text-based user interfaces for shell scripts. FreeBSD’s installer (bsdinstall) had already transitioned to bsddialog four years ago, so dialog was effectively orphaned. The Phabricator review explicitly states: “This is the last remaining piece of GPL software in the base system.”
dpv, libdpv, and libfigpar were the last consumers of dialog. dpv (dialog pipeline viewer) was a progress bar utility that I personally used extensively. It provided throughput metrics during long operations, and it was genuinely useful. The dpv maintainer (Drew Dies Teske) pushed to keep it in base, but ultimately agreed to move it to ports. The code is being extracted to the freebsd/dpv GitHub repository with full commit history preserved.
The GNU subtree itself (the gnu/ directory containing COPYING, COPYING.LIB, and all associated build infrastructure) was deleted in a separate commit by dag-erling on July 7. The commit touched 20 files, removing 905 lines and adding only 11. The README.md was updated to remove the reference to the gnu directory entirely.
Pro Tip: If you are running FreeBSD 14 or 15 and you use dpv in scripts, you will need to install it from ports after upgrading to 16. The dpv source is being migrated to GitHub (github.com/freebsd/dpv) and will be available as a port. Plan your migration now rather than discovering the missing utility during a critical upgrade.
Why License Purity Matters More Than You Think
I spent a decade working with embedded systems before I moved into storage infrastructure, and I can tell you from hard experience that license contamination is not an academic concern. When a commercial product ships with GPL code in its core, the legal team gets involved. Compliance teams audit. Engineers get pulled into meetings about what can and cannot be distributed. It is a real cost, and it is one that FreeBSD just eliminated from its base system.
The 4.4BSD license that FreeBSD uses is functionally equivalent to the modern BSD license. It is permissive, it allows proprietary modification and distribution, and it does not carry the “viral”copyleft provisions that make GPL problematic for commercial embedders. With dialog removed, the entire FreeBSD base system (kernel, userland, libraries, system utilities) is now covered exclusively by this permissive license.
For companies building network appliances, storage arrays, or embedded systems on FreeBSD, this is a genuine compliance simplification. You no longer need to track GPL obligations for the base system. The ports tree still contains GPL software, but that is a separate installation step with clear separation.
What This Does NOT Change About ZFS
Let me address the elephant in the room immediately because I see this confusion in every thread about BSD licensing: ZFS on Linux is not affected by this change. Not one bit. If you are running ZFS on Linux, my storage deep dive on LVM, mdadm, and ZFS RAID covers the setup in detail, and nothing in that guide changes because of FreeBSD 16.
ZFS uses the CDDL (Common Development and Distribution License), which is a completely separate license from both the GPL and the BSD license. OpenZFS is the same codebase on both Linux and FreeBSD, and it has always been CDDL-licensed on both platforms. FreeBSD retiring GPL code from its base has zero impact on ZFS licensing.
The CDDL was specifically chosen by Sun Microsystems (now Oracle) for ZFS because it provides patent protection that the GPL does not. This is a deliberate design decision, not an oversight. If you are evaluating ZFS for a project, the licensing question is: CDDL on both platforms, unchanged by FreeBSD 16.
What FreeBSD 16 does change is the licensing landscape around ZFS. With the base system now pure BSD, the only license friction point for ZFS on FreeBSD is the CDDL itself. On Linux, ZFS faces the additional complication of being CDDL code interacting with a GPL kernel, which is why the legal compatibility question has never been fully resolved. I covered this tension in my storage deep dives before, and it remains one of the most nuanced licensing situations in open source.
Insight: The CDDL was designed to be “GPL-compatible” in the sense that CDDL code can be combined with GPL code in a single work, but the reverse is not true. This one-way compatibility is intentional: it protects ZFS from being absorbed into the GPL ecosystem while allowing ZFS to use GPL components. The result is that ZFS on Linux exists in a legal gray zone that ZFS on FreeBSD does not.
How BSD-Linux Driver Sharing Actually Works Despite License Differences
This is the part of the story that most people miss, and it is the part I find most interesting. FreeBSD just went 100% GPL-free in its base, yet it continues to port Linux kernel drivers. How does that work legally?
The answer is the drm-kmod project. FreeBSD maintains a port of the Linux kernel’s Direct Rendering Manager (DRM) subsystem, which provides graphics driver support for AMD Radeon and Intel integrated graphics. As of June 2026, FreeBSD’s drm-kmod has been updated to track Linux 6.12 LTS. This is a substantial body of GPL code running on FreeBSD.
The key distinction is that drm-kmod is not part of the FreeBSD base system. It is installed separately via the ports/pkg system, similar to how you would install any other third-party package. The GPL code exists in the ports tree, not in the base. This separation is what makes it legally permissible: the base system remains pure BSD, and the GPL driver code is a separate, optional installation.
I find this model genuinely elegant. It means FreeBSD gets access to the latest open-source graphics drivers without contaminating its base system with GPL obligations. For end users, the practical result is the same: you get working AMD and Intel graphics on FreeBSD. For commercial integrators, the legal picture is cleaner: the base is pure BSD, and you choose whether to pull in the GPL drivers.
The same model applies to AMD ROCm, which a FreeBSD Foundation intern is currently working to port. The compute stack would be installed via ports, not baked into base. This is the pattern, and it works.
Why It Matters: The ports separation model is not just a licensing workaround. It is a genuine architectural advantage. When graphics drivers are a separate package, upgrading them does not require rebuilding or recertifying the entire base system. For enterprise deployments, this means driver updates can be deployed on a different schedule than OS patches, reducing the blast radius of changes.
When to Use FreeBSD vs Linux in 2026
I get asked this constantly, and my answer has not changed much even with the FreeBSD 16 news. The licensing milestone reinforces existing strengths rather than creating new ones.
Choose FreeBSD when: You are building a network appliance or firewall. FreeBSD’s network stack is still superior for packet filtering and routing workloads. You are building a storage system and want native ZFS without the CDDL-GPL tension (see my Linux NAS build guide for the ZFS side of things). You need license purity for a commercial product and your legal team wants a clean base system. You are running a mail server or DNS server where FreeBSD’s jail-based virtualization gives you lightweight isolation without the overhead of full containers.
Choose Linux when: You need broad hardware support. Linux wins here by a mile, and FreeBSD 16 does not change that equation. You are running GPU compute workloads (CUDA, ROCm). The ecosystem is Linux-first, and porting efforts are still maturing. You need a desktop environment. FreeBSD’s desktop story is improving (the installer now has a KDE option), but Linux is still the practical choice. You are deploying in cloud-native environments. Kubernetes, Docker, and the entire CNCF ecosystem assumes Linux.
My personal bias: I run FreeBSD on my home NAS and firewall, and Linux on everything else. The NAS runs ZFS natively, and the firewall runs pf. Both workloads are where FreeBSD shines. For my development workstations and cloud deployments, Linux is the obvious choice. This is not a religious position. It is an engineering one.
The Bigger Picture: BSD-Linux Cooperation in 2026
What I find most encouraging about the FreeBSD 16 story is not the licensing purity itself, but what it represents about the relationship between BSD and Linux development. These two ecosystems share more code than most people realize.
FreeBSD ports Linux kernel drivers through drm-kmod. Linux distributions ship OpenZFS, which shares its codebase with FreeBSD. NVIDIA provides proprietary driver packages for FreeBSD. An intern at the FreeBSD Foundation is porting AMD ROCm. The two communities collaborate on hardware support, security practices, and infrastructure tooling.
The licensing differences are real, but they are not barriers to cooperation. They are boundaries that define exactly how code flows between the ecosystems. BSD code can flow into GPL projects freely (the licenses are one-way compatible in that direction). GPL code can flow into BSD projects through the ports separation model. The result is a healthy, productive relationship that benefits users of both platforms.
FreeBSD 16 going GPL-free in its base does not change this dynamic. If anything, it clarifies it. The base system is BSD. The ports tree is a mix. Everyone understands the rules. That clarity is worth more than the symbolic victory.
Worth Knowing: The FreeBSD 4.4BSD license was updated in 1999 to remove the advertising clause requirement. The original clause required products to display “This product includes software developed by the University of California, Berkeley.” The 1999 update dropped this requirement, making the license even more permissive than its original form. FreeBSD’s license is now functionally identical to the modern BSD 2-Clause license.
FAQ: FreeBSD 16 GPL Retirement
Does this affect ZFS on Linux? No. ZFS uses the CDDL license, which is separate from both GPL and BSD. This change only affects the FreeBSD base system.
Can I still install GPL software on FreeBSD? Yes. The ports tree contains thousands of GPL packages. The change only removes GPL code from the base system.
Will FreeBSD 16 break my existing setup? If you use dpv in scripts, you will need to install it from ports. Otherwise, the transition should be transparent for most users.
When does FreeBSD 16.0 release? Expected December 2027. The GPL-free changes are already in the 16-CURRENT development branch.
Does this make FreeBSD more commercially friendly? It simplifies compliance for commercial products built on the FreeBSD base system. The base is now 100% permissively licensed.
Does Linux plan any similar moves? No. The Linux kernel is GPL, and that is a fundamental part of its identity. Linux and FreeBSD have different licensing philosophies, and that is fine.
The Bottom Line
FreeBSD 16 retiring all GPL code from its base system is a meaningful milestone, but not for the reasons most headlines suggest. It is not about winning a licensing war. It is about clarity. The FreeBSD base system is now unambiguously permissively licensed. Commercial integrators can build on it without tracking GPL obligations. The ports tree remains a separate, well-understood boundary for GPL software. And theBSD-Linux cooperation model continues to work because it was never about licenses matching. It was about practical collaboration across a shared ecosystem.
If you are a Linux sysadmin, the main takeaway is this: the ZFS licensing situation on Linux is unchanged, FreeBSD’s graphics driver support continues to improve through the drm-kmod ports model, and the two ecosystems are closer than the license headers suggest. If you have been actively evaluating FreeBSD for a production storage or networking workload, the licensing story just got noticeably cleaner. That is genuinely worth something tangible for production environments.