The GPL: Paradoxes in Free Software

A Design with Contradictory Restrictions

The GPL prevents a distributor from taking a covered work, conveying a modified or combined version, and withholding the corresponding source under incompatible terms. Merely running GPL software or placing independent programs on the same system does not trigger that result. The obligation attaches to covered derivative or combined works and to distribution, which makes the precise boundary important.

Static versus dynamic linking is not a general escape hatch. The GNU GPL FAQ treats both forms as combination when GPL-covered code is linked with other modules. Linux adds implementation-specific rules: proprietary modules taint the kernel, and the loader refuses to link them against EXPORT_SYMBOL_GPL() symbols, as documented in the kernel licensing rules. Copyright law still determines whether a particular component is derivative, so the article does not reduce that legal question to one technical linking method.

The Dichotomy Between Philosophy and Practice

The GPL aligns freedom with enforceable reciprocity. That protects downstream recipients, but it also prevents some combinations with code whose terms cannot be satisfied alongside the relevant GPL version. BSD and MIT code can normally enter a GPL-covered combined work; the reverse distribution cannot discard the GPL obligations that already cover the GPL code.

The disagreement is therefore about which freedom the license should prioritize. Copyleft protects every recipient's access to source and modification rights. Permissive licensing gives each recipient broader authority to redistribute derivatives under proprietary terms. Neither model is restriction-free; they impose different obligations on the distributor.

The Impact on Collaboration and Business Development

The GPL does not prohibit commercial use, private modification, or selling copies. Its business constraint appears when a company conveys a covered work and must provide corresponding source under the license. Companies that need proprietary derivatives therefore prefer permissive terms or negotiate a separate license with the copyright holders.

LLVM demonstrates the alternative clearly. Its Apache 2.0 license with LLVM exceptions permits proprietary derivatives while preserving notices and a patent grant. That policy has supported collaboration among vendors and community contributors without source-release reciprocity. It proves that permissive licensing can sustain a major shared toolchain; it does not prove that every project would receive the same contributions without copyleft.

Toward an Ethic of Sharing Without Coercion

My critique favors voluntary reciprocity over mandatory reciprocity. A permissive license allows cooperation across open and proprietary systems and lets each downstream author choose how to license new code. The cost is equally concrete: a recipient can improve the software, distribute the result, and withhold those improvements from the public. Copyleft prevents that outcome.

The licensing decision should follow the intended guarantee. Choose the GPL when every distributed derivative must preserve source access; choose a permissive license when broad integration and downstream licensing freedom take priority. Clear project governance, review, and contributor relationships matter under either model.

Conclusions

The GPL reliably protects reciprocity when covered works are distributed, and that is its central achievement. The same mechanism rules out integrations whose licensing terms cannot coexist with those obligations. I prefer permissive licensing when collaboration across those boundaries matters more than compelling downstream source release. That conclusion rests on a choice between explicit legal guarantees, not on the false claim that the GPL forbids business or all proprietary software.