#### # # # # #### # # #### # # ####
# # ## # # # # # # # # # # #
# # # # # # #### # # # #### ####
# ### # # # # # # # # # # # #
# # # ## # # # # # # # # # # # #
#### # # #### #### #### #### # # ####
reasons the gnu project and the gpl are hostile to freedom, choice, and good engineering.
you cannot link (statically or dynamically) gpl libraries into your program unless the whole program is also gpl. this is deliberate. it forces your code under the same license, bans itself from most corporate codebases, and makes accidental contamination a real legal risk for startups and anyone doing due diligence. the viral clause turns every dependency into a potential landmine. once gpl code touches your project the license spreads outward and you lose the ability to ship under any other terms. this is not protection of freedom. it is forced conversion of every downstream work.
the fsf claims both static and dynamic linking create a combined work that must be gpl. courts have never settled it. the lgpl and classpath exceptions exist only because the plain gpl is too aggressive for libraries. every project that touches gpl code lives under lingering legal uncertainty. lawyers treat gpl linkage as high risk. the result is that competent engineering teams simply avoid the entire family of licenses rather than gamble on future court rulings. uncertainty is not a feature of free software. it is a tax on everyone else.
glibc is full of non-standard extensions that other c libraries (musl, etc.) do not implement. software that relies on them assumes everyone must use glibc. glibc is also hostile to clean static linking. the result is soft lock-in: programs that only work inside the gnu ecosystem. the same pattern appears in other gnu tools. non-portable flags, non-posix behavior, and glibc-specific assumptions slowly make the rest of the unix world second-class. portability is sacrificed so that the gnu stack remains the default.
gnu tools are frequently bloated, macro-heavy, and needlessly complex. coreutils, the info system, and many other components accumulate features for decades with little regard for simplicity or auditability. alternative implementations exist because people got tired of the gnu versions. the source trees are full of autoconf spaghetti, generated files, and decades of accumulated special cases. reading or modifying the code often requires understanding layers of historical cruft that no longer serve a clear purpose. simplicity was never a design goal.
the original goal was a complete free operating system. the hurd kernel is still not production-ready after more than thirty years. linux became the actual kernel; gnu spent years arguing about the name instead. the project demonstrates a pattern of grand ambition followed by endless redesign, political fights, and failure to ship. while the rest of the world built usable systems, the hurd remained a research curiosity that never matured into something people could rely on.
it did nothing against saas and cloud. companies dump source “over the wall” with no maintenance. it does not create goodwill or participation. enforcement is selective and resource-heavy. the license cannot force people to be good citizens of the community. the original promise that copyleft would produce a growing commons of reciprocal contribution largely failed. many of the most successful free projects abandoned or never adopted strong copyleft because the social and legal costs outweighed the benefits.
it tries to close the saas loophole and ends up treated as radioactive by most developers and companies. few serious projects use it. many organizations ban it outright. the agpl turns network use into a distribution trigger and creates even more legal ambiguity. the result is that the license is avoided rather than embraced. it solved a theoretical problem by creating a practical one that most of the industry simply refuses to touch.
the gpl is deliberately incompatible with many other free licenses. combining code becomes legal work instead of engineering work. the ecosystem fragments into “gpl only” or “permissive only.” developers waste time on license compatibility matrices instead of writing code. the fsf treats incompatibility as a feature that pressures others to relicense, but the actual effect is that gpl code is quarantined and left out of many useful combinations.
legal risk and viral terms push companies and many individual developers toward mit, apache, and bsd. the modern open source world largely moved on for this reason. the gpl’s reputation for aggression and unpredictability means that competent legal teams default to rejecting it. the license that was supposed to protect freedom became a reason to avoid entire classes of software.
in the name of freedom the gpl removes the freedom to choose another license, the freedom to keep modifications private when distributing binaries, and (under the fsf view) the freedom to dynamically link without triggering copyleft. conditioned freedom is not the same as actual choice. the project defines freedom in a narrow, highly specific way and then treats any other definition as illegitimate. users who want different tradeoffs are told they are simply wrong about what freedom means.
the fsf and gnu project have been dominated for decades by a single personality and rigid ideology. criticism is often treated as heresy. several maintainers and major organizations have distanced themselves. internal culture has repeatedly prioritized purity tests and personal loyalty over technical results or broad participation. the result is an organization that many capable people simply refuse to work with.
insisting that the system must be called “gnu/linux” and treating anyone who says “linux” as an enemy is pure branding politics. the kernel that actually runs is linux. the userland can be replaced. decades of lecturing the world about nomenclature did nothing to improve the software and only reinforced the image of a movement more interested in ideological victory than useful systems.
the gnu project pushed the info system as a superior replacement for man pages. the result is a parallel documentation format that almost nobody prefers, that is awkward to search, and that forces users into a separate tool. man pages remain the practical standard. the insistence on info is another example of gnu deciding that its way is better and expecting everyone else to adapt.
the project has a long record of treating useful but imperfect solutions as morally suspect. proprietary firmware, non-free drivers, and pragmatic compromises are denounced even when they are the only way to make hardware work. the stance produces pure systems that run on a shrinking set of supported hardware while the rest of the world ships products that actually function for users.
for years gcc development was slowed by internal politics, resistance to modern compiler techniques, and hostility toward competitors. the rise of llvm/clang happened in part because a clean, modular, permissively licensed alternative was needed. gnu’s response was often ideological rather than technical. the compiler that was once the flagship free tool lost ground because the project prioritized control over rapid improvement.
emacs is powerful and has devoted users, but it also became a sprawling, self-contained world that reinvented large parts of the operating system inside a single process. the culture around it often treats complexity and elisp as virtues rather than tradeoffs. for many developers the cost of the ecosystem outweighs the benefits, which is why simpler and more focused editors continue to gain ground.
gpl enforcement has often been selective, high-profile, and driven by ideology rather than consistent principle. small projects and individuals can face aggressive demands while large companies with resources negotiate quiet settlements. the process creates fear and compliance theater more than it creates a healthy commons. many developers simply decide the license is not worth the risk of future legal attention.
the gnu project has historically treated dual licensing and commercial use of free software with suspicion or hostility. other projects have used dual licensing successfully to fund development while keeping the code free. gnu’s preference for purity over sustainable funding models left many of its own projects under-resourced and dependent on sporadic donations and volunteer time.
the broader free software culture associated with the fsf has repeatedly alienated contributors through rigid social norms, public shaming, and an us-versus-them worldview. talented people who disagree on secondary issues are often driven out. the result is a smaller, more homogeneous group that is less capable of building and maintaining the large, complex systems the original vision required.
distributed version control, continuous integration, permissive licensing, and rapid iteration became the norm in successful open source. large parts of the gnu world remained attached to older workflows, centralized control, and license purity. the gap between how successful projects actually work and how the fsf thinks they should work continues to widen.
you do not have to accept gnu tools or the gpl ecosystem.
(c) 2026 vextoly