Your company is building a closed-source network appliance and is choosing an operating-system base. How does FreeBSD's permissive licence change that decision compared with a Linux base, and what does choosing permissive cost you?

## What the licences actually require FreeBSD's base system is distributed under the two-clause BSD licence. The obligation is essentially attribution: retain the copyright notice and the disclaimer. You may modify the kernel, modify the userland, link whatever you like against it, ship it inside a sealed box, and publish nothing. The project has actively pushed licence purity in base — most visibly by replacing GCC with Clang/LLVM as the default compiler in base, a change motivated in part by wanting to avoid GPLv3-licensed components in a shipped base system. The Linux kernel is GPLv2. Distributing a binary obliges you to make available the complete corresponding source for the kernel and for works derived from it, under the same licence. A typical Linux userland then adds a mixture of GPL, LGPL and permissive components, each with its own obligations — LGPL, for instance, generally requires that a user be able to relink against a modified library. ## Why this matters for an appliance specifically An appliance is a product you *distribute*, which is the trigger for copyleft obligations. Three consequences follow. **Where your differentiating code can live.** If your value is in kernel-space code — a packet-forwarding fast path, a storage engine hooked into the VFS — GPLv2 makes shipping it closed extremely awkward. Out-of-tree kernel modules that are closed source occupy a long-argued legal grey zone, and kernel developers are openly hostile to them. On a BSD base, kernel-space modification is simply yours. This single point explains most FreeBSD appliance choices; publicly documented examples include Juniper's Junos and Netflix's OpenConnect content-delivery appliances. **Compliance as an engineering process, not a one-off.** A Linux appliance is entirely shippable — thousands are shipped — but you must maintain a written offer or a source distribution, track exactly which versions of which components each firmware image contains, and reproduce that source on request for years. That means a software bill of materials, a licence-scanning step in CI, and someone accountable. It is a staffing cost, not a legal impossibility. **Design pressure on architecture.** On Linux, teams keep proprietary logic in userland processes talking to the kernel through stable interfaces, which is usually good architecture anyway. On FreeBSD that pressure is absent — which is freedom, and also the loss of a discipline that was doing you a favour. ## What permissive costs **No reciprocity.** Copyleft's purpose is to force improvements back into the commons. A permissive licence lets a competitor, a chip vendor or your own supplier take the base, improve it, and ship it closed. If your strategy depends on an ecosystem of contributions converging, permissive works against you. **Hardware enablement.** Vendors write and upstream Linux drivers first, sometimes only. New NICs, accelerators and storage controllers land on Linux months or years earlier, and on some hardware never arrive at all on FreeBSD. For an appliance shipping specific chosen silicon this can be a non-issue; for a product that must run on whatever the customer bought, it is decisive. **Ecosystem gravity.** Container runtimes, orchestration, observability agents, vendor SDKs and CI images target Linux. FreeBSD provides a Linux binary compatibility layer, but treating it as a general escape hatch is a mistake — it is for specific binaries, not for a Linux-shaped ecosystem. **People and support.** The hiring pool for deep FreeBSD skills is a fraction of the Linux pool, and commercial support offerings are far fewer. That is an ongoing operational risk that outlives the initial architecture decision. ## How to actually make the call Order the questions by weight: Does our differentiating code have to live in kernel space? Does our hardware have first-class support on the candidate base? Can we staff and support this for the product's life? What does the compliance process cost per release? Only then: which licence fits our distribution model? If the answers say Linux, the licence is a manageable process cost, not a blocker. If your value is genuinely in the kernel and your hardware is well supported, FreeBSD's coherent base system, jails and integrated ZFS often matter as much to the decision as the licence does. ## What a weak answer looks like Treating GPL as though it forbids commercial or closed products, or treating permissive as unambiguously "more free for business" while ignoring the reciprocity you give up and the ecosystem you leave behind. A principal-level answer names the obligations precisely, places the licence among the other constraints rather than above them, and is honest that the hiring and hardware questions usually dominate.