Free Software, GNU, and the Four Freedoms

Free software is software whose users have meaningful legal permission to control the program: to use it, examine it, change it, and share it. The word free here concerns liberty, not price. A program may be obtainable at no charge yet remain proprietary if its license forbids copying, reverse engineering, modification, or redistribution. Conversely, a business can charge for a copy of free software, support, hosting, media, or customization. This distinction—often compressed as “free as in freedom, not free as in beer”—is central to the GNU Project and the Free Software Foundation (FSF).

Sharing came before the proprietary default

Early computing did not operate under one timeless licensing model. In university, government, and industrial research settings of the 1950s through 1970s, users commonly received source code with hardware or exchanged it through user groups. Software was often treated as a service, an adjunct to hardware, or a research result. The practice was uneven: contracts, trade secrets, and copyright still existed, and access was often limited to institutions able to afford mainframes. Yet programmers could frequently inspect and adapt the systems on which they worked.

That environment changed as software became a separately valuable product. In the late twentieth century, vendors increasingly distributed binaries under restrictive contracts and withheld source code. This was a gradual commercial and legal shift rather than the result of one announcement, and proprietary licensing was not invented in one event. Collaborative programming did not vanish: Unix laboratories, academic networks, vendor exchanges, and later BSD communities continued to share code in particular settings. The change mattered because ordinary users increasingly lacked permission to repair, study, or redistribute the tools that mediated their work.

Unix is useful background but not a substitute for this history. Its portable C implementation and culture of small tools helped circulate ideas and source among licensed sites; its commercial licensing also showed how availability of source could be limited by terms. GNU would aim at compatibility with Unix-like interfaces without being a version of AT&T Unix. “GNU’s Not Unix” is deliberately recursive and signals both that practical compatibility and legal independence.

Stallman, the GNU Project, and the FSF

Richard Stallman announced the GNU Project in September 1983, proposing to build a complete free Unix-compatible operating system. His account of the announcement identifies a practical motive: users should be able to cooperate rather than be prevented from helping one another. In 1985 he founded the Free Software Foundation to support that work and the broader ethical case for user freedom. The project was not the beginning of shared source or collaborative development. Its distinctive contribution was a sustained, explicitly political and legal program to make a complete, freely usable system available under durable rights.

The project attacked the operating-system problem piece by piece. GNU Emacs became both a programmable editor and a community around extensions. The GNU C Compiler, later GCC, provided a high-quality compiler that could target many architectures. GNU also developed the C library, Bash shell, debugger, make and build tools, text-processing programs, and the familiar “core utilities” such as ls, cp, sort, and grep. Such programs could run on existing Unix systems while also forming the userland of a future GNU system. Their importance was cumulative: a kernel alone cannot provide a practical development environment, and a compiler alone does not make a complete operating system.

GNU’s intended kernel was the Hurd, a set of servers built on the Mach microkernel. It was ambitious and remained under development for far longer than early plans anticipated. By the early 1990s, GNU had much of a usable userland but no widely deployed production kernel to complete the system. When Linux, a separate kernel started by Linus Torvalds, was relicensed under GPL version 2 in 1992, it could be combined with GNU components. Many people call resulting distributions “Linux”; “GNU/Linux” identifies the combination more precisely. That naming discussion should not obscure the engineering fact: distributions also contain work from Linux kernel developers, GNU, BSD projects, X.Org, package maintainers, hardware vendors, and many others.

The four freedoms

The FSF expresses free software through four freedoms, numbered from zero because programmers commonly start counting there. They apply to recipients of the program and are permissions granted by copyright holders through a license, rather than a promise that every user can exercise every freedom equally easily.

  1. Freedom 0: run the program as one wishes, for any purpose. A license that restricts commercial use, fields of endeavor, or particular kinds of users fails this freedom.
  2. Freedom 1: study how the program works and change it so it does one’s computing as one wishes. Access to source code is a necessary precondition, but source availability by itself is not enough if the license bars modification or use of modifications.
  3. Freedom 2: redistribute copies so one can help others. The freedom permits charging for distribution as well as giving copies away.
  4. Freedom 3: distribute copies of modified versions, allowing a community to benefit from improvements. Source code is again necessary in practice, and the license must permit the distribution.

The freedoms describe what the license allows, not an assurance of usability, security, accessibility, documentation, or governance. A technically difficult project can be free software. Nor does the definition require that every change be accepted upstream, that maintainers be unpaid, or that a project use a particular version-control service. It is possible to exercise freedom 3 by maintaining a fork. It is also possible for a developer to retain copyright while licensing a work as free software; copyright is the mechanism that makes a license’s permissions and conditions enforceable.

The FSF treats software freedom as a social issue because software increasingly controls communication, work, research, and civic life. On that view, dependence on a vendor’s permission is a problem even where the vendor supplies an excellent product without charge. Others place more emphasis on development efficiency, reliability, market adoption, or practical access to source. Those debates are real, but they should not turn “free software” into a vague synonym for collaborative coding or gratis downloads.

Copyright permissions and copyleft

Absent permission, copyright normally reserves copying, distribution, and preparation of derivative works to the rightsholder. Free-software licenses grant broad permissions in advance. Some do so with few continuing conditions; others use copyleft, a strategy associated with GNU. Copyleft grants recipients the right to modify and redistribute covered work, while requiring a distributor of a modified covered work to pass on corresponding freedoms under the same license. It is not an assertion that copyright has disappeared. It uses copyright’s exclusive rights to prevent a distributor from taking a shared program private when distributing derivatives.

The GNU General Public License (GPL) is the best-known copyleft license. GPL version 1 appeared in 1989, version 2 in 1991, and version 3 in 2007. Exact obligations depend on the version and facts. Broadly, when someone conveys a GPL-covered program or a work based on it, the GPL requires preservation of notices and license terms and requires corresponding source under the license. A firm may sell GPL-covered software, charge for warranty or support, and use it internally. The central distribution trigger means merely modifying a program for private internal use is different from conveying copies to another party. The actual license text, not a slogan, controls.

GPLv3 addresses issues that were less prominent in 1991, including explicit patent provisions, “anti-tivoization” installation-information requirements for certain user products, and compatibility mechanisms. GPLv2 and GPLv3 are distinct licenses and are not automatically compatible: code marked “GPL-2.0-only” cannot simply be relicensed as GPLv3. SPDX identifiers help projects record this distinction, for example GPL-2.0-only, GPL-2.0-or-later, and GPL-3.0-or-later. A short header is useful evidence of intent, but it does not replace reviewing the applicable license and provenance of all included code.

A practical distribution question

Consider a company that changes a GPL command-line tool and sends binaries to customers. Its obligations are not satisfied by saying that the original source is somewhere online: recipients need the corresponding source for the version conveyed, including the scripts and material needed to generate, install, and run it as the license defines. Whether a plugin, library, container image, firmware bundle, or network service forms a derivative or combined work can be fact-specific. Engineers should identify the license version, read its defined terms, preserve notices, and obtain qualified advice for a release decision rather than guess from an internet checklist.

Copyleft is not equivalent to hostility to commerce. Red Hat and many consultancies built businesses around support, integration, subscriptions, training, and engineering while distributing copyleft software. Nor is it a guarantee that a project will receive contributions or avoid forks. It establishes a reciprocal rule for distribution; communities still need maintainers, review, funding, release engineering, and respectful governance.

Freedom, source, and control beyond the license

Source code access is indispensable for studying and modifying a program, but practical control may be constrained by hardware signatures, online dependencies, cloud APIs, trademarks, data formats, or a missing build toolchain. GPLv3’s installation-information provision addresses one limited class of device-lockdown situations; it does not solve every dependency on a service. Conversely, a project hosted on a corporate platform can be free software if recipients retain the license rights and can obtain source, though concentration may create practical risks. The legal definition and the operational reality should be discussed separately.

“Free software” also does not mean public domain. A public-domain work may have no copyright restrictions, while a GPL work remains copyrighted and conditioned. It does not mean freeware, shareware, source-available software, or “open core.” A source-available license may permit reading but prohibit commercial use, competing services, redistribution, or derivatives; any such restriction can prevent it from meeting the four freedoms. Clear labels spare users from assuming rights that a license does not grant.

Enduring significance

GNU’s achievement was infrastructural and conceptual. Its tools made it possible to compile, debug, script, and administer systems without relying on a proprietary Unix vendor, and its licensing supplied a durable vocabulary for reciprocal sharing. The Hurd’s delayed maturity did not erase that achievement; the GNU/Linux systems assembled with the Linux kernel made the userland’s value visible to many millions of users. At the same time, neither GNU nor Linux alone explains modern free software: BSD lineages, language communities, distributions, standards bodies, companies, and volunteers all shaped the ecosystem.

For readers evaluating software today, the most useful habit is precision. Ask which license and version apply; whether source is actually available; what rights apply to copies and modifications; and whether technical dependencies frustrate those rights in practice. Free software makes a claim about the user’s freedom. It is not a promise of zero price, universal agreement, or effortless collaboration.

References