Permissive License

Permissive license is a class of open-source license that grants broad rights to use, modify, and redistribute software while imposing only minimal conditions — usually just preserving the original copyright notice and disclaiming warranty. Unlike copyleft, a permissive license does not require derivative works to be released under the same terms, so a downstream developer may incorporate the code into proprietary, closed-source products. The philosophy is maximum freedom for the immediate recipient, including the freedom to close the door behind them.

Common permissive licenses

The best-known examples are the MIT License, the BSD 2-Clause and 3-Clause licenses, and the Apache License 2.0. MIT is the minimalist's choice — a few paragraphs granting nearly everything. The BSD 3-Clause adds a non-endorsement clause forbidding use of the author's name to promote derived products. Apache 2.0 is the corporate-grade option: alongside the usual grants it provides an explicit patent license from every contributor and terminates that license for anyone who initiates patent litigation over the code — meaningful protection in hardware-adjacent fields where patents are live ammunition. All share the core trait that recipients may re-license derivatives freely, including under proprietary terms.

Where permissive licensing shows up in this ecosystem

Much of the open mining and Bitcoin world runs on permissive terms. Bitcoin Core itself is MIT-licensed — a deliberate choice to let anyone, including commercial vendors, build on the reference implementation without legal friction, maximising the consensus code's reach. The Bitaxe ecosystem leans on permissive and open-hardware licensing to encourage derivatives, and the result speaks for itself: a proliferation of variants, clones, and commercial spins that spread open mining hardware faster than any single project could. That is the permissive bet paying off — adoption as the goal, openness as the seed rather than the guarantee.

Compliance is refreshingly light but not zero. Keep the license text and copyright notices with the code; for Apache 2.0, preserve the NOTICE file and state significant changes; for BSD 3-Clause, do not imply the original authors endorse your product. A vendor shipping firmware built on permissive code owes the community nothing further legally — every improvement returned is a choice, which is precisely the point of the model and, depending on your goals, either its greatest strength or its structural flaw.

Trade-offs for mining projects

Permissive licensing maximises adoption: hardware vendors and tool authors can build on the code without inheriting reciprocal source-sharing duties, and integration into commercial firmware stacks is legally frictionless. The trade-off is that improvements need not flow back to the community, and a permissively licensed project can be forked into a closed product — the community keeps the original, but the polished derivative may be a black box. Mining has seen both halves of this story: permissive foundations have seeded genuinely open ecosystems, and they have also been absorbed into proprietary products whose enhancements never returned. Choosing between permissive and copyleft therefore depends on which risk a project fears more: obscurity or enclosure. For libraries, protocols, and reference designs meant to be everywhere, permissive terms usually win; for firmware whose entire purpose is keeping users in control of their machines, guaranteed downstream openness is often worth the adoption tax — which is the reasoning behind D-Central's own license choices across its projects.

Public-domain-equivalent dedications such as the Unlicense and CC0 sit one step further along the same axis, waiving even the attribution requirement.

For the reciprocal end of the spectrum, see copyleft above; for the patent-handling details that make Apache 2.0 the cautious enterprise pick, compare the Apache License 2.0 entry. Read the license before you build on the code — it is the constitution of every open project.