From Free Software to Open Source

“Open source” and “free software” describe a large overlapping body of licensed software, but they arose from different emphases. Free software, associated with the GNU Project and Free Software Foundation (FSF), frames the issue as users’ freedom to run, study, modify, and share programs. Open source frames it primarily through a licensing and development model: source availability coupled with rights that allow redistribution and derived works. In ordinary technical conversation the labels often identify the same projects—Linux, Firefox, Apache HTTP Server, and many programming languages—but their advocates may explain the value of those projects in different terms.

Collaboration did not begin in 1998

The phrase “open source” did not create collaborative programming. Before 1998, researchers exchanged programs and source through academic and professional networks; Unix source circulated among licensed institutions; the Berkeley Software Distribution developed in a university setting; user groups shared software; and the GNU Project had already spent more than a decade building a free Unix-compatible system. The Internet RFC process, public-domain and permissively licensed code, and free-software projects all predate the new label. Nor was all earlier source sharing unrestricted: institutional access, copyright, contracts, and hardware costs often limited who could participate.

What changed in 1998 was an organized campaign to use a new name and explain the model in terms likely to appeal to companies, managers, and a wider public. The Open Source Initiative (OSI) was founded that year by Eric S. Raymond and Bruce Perens. Its launch followed a meeting in Palo Alto in February and was tied to a conspicuous event: Netscape’s January 1998 announcement that it would make the source code for the Netscape Communicator browser available. Netscape’s later Mozilla codebase and community were important early tests of large, public Internet-era development, but they were not the origin of cooperative software creation.

The Debian influence

Bruce Perens had written the Debian Free Software Guidelines (DFSG) for the Debian Project’s social contract in 1997. The DFSG set out practical criteria for deciding which software belonged in Debian’s “main” distribution. When the OSI formed, the Open Source Definition (OSD) was initially derived from the DFSG with editorial changes. That lineage matters because the OSD was not invented from a blank slate and because it anchors “open source” in specific license terms rather than a marketing claim that a company happens to publish code.

The OSD requires, among other things, free redistribution; inclusion of source code; permission for derived works; integrity provisions that may require modified versions to use a different name or distribute patches; no discrimination against persons, groups, or fields of endeavor; distribution of rights to downstream recipients; license terms not tied to one product; no restriction on other software; and technology neutrality. Its field-of-endeavor rule is particularly revealing. A license that says “non-commercial only,” “not for military use,” or “not for competitors” may express a sincere policy preference, but it is not Open Source Definition–conformant because it restricts how recipients may use the program.

Debian still maintains the DFSG as its own policy, and the OSI maintains its own approval process and definition. Similar language does not make the organizations interchangeable. Debian is a distribution and community with archive policies; the OSI is a nonprofit stewarding the Open Source Definition and approving licenses. The FSF maintains a separate list and analysis of licenses it considers free. A license can be approved by the OSI and regarded as free by the FSF, but the criteria and institutional purposes are not identical.

Netscape and a new public argument

Netscape’s decision took place amid intense browser competition with Microsoft. Releasing source was partly an attempt to mobilize outside innovation and regain momentum, not a pure philosophical conversion. The original Netscape Public License and Mozilla Public License (MPL) arrangements evolved, and the Mozilla project eventually produced Firefox and other software through a distinct organization and codebase. The episode showed that source release could be strategically meaningful for a commercial firm, while also showing that source alone does not settle governance, trademark control, contributor rights, or whether a license meets a recognized definition.

Raymond’s essay “The Cathedral and the Bazaar,” based on observations including the Linux community, supplied a memorable contrast. It suggested that decentralized, frequent public releases and broad peer review could be an effective way to produce software. “Given enough eyeballs, all bugs are shallow,” often called Linus’s Law, is an aspirational heuristic rather than a security theorem. Review only works when qualified people can and do inspect changes, reproduce failures, fund maintenance, and act on reports. Widely visible vulnerabilities in widely used libraries are reminders that public source is an opportunity for audit, not an automatic audit.

The open-source campaign emphasized pragmatic benefits: faster iteration, vendor independence, reliability through review, ability to customize, and reduced barriers to adoption. This language helped firms see licenses such as the GPL, BSD licenses, MIT, Apache-2.0, and MPL as legitimate foundations for products and infrastructure rather than merely hobbyist arrangements. It also fit a period in which the web, commodity servers, and distributed version control made geographically dispersed collaboration increasingly practical. No single license or workflow caused this change; mailing lists, issue trackers, release practices, package repositories, foundations, employers, and volunteer labor each mattered.

Overlap and philosophical difference

For most well-known licenses, the two terms overlap substantially. GPL-covered programs are both free software and open source; so are programs under Apache-2.0, MIT, and many BSD licenses. This common ground is why the combined expression “free and open-source software” (FOSS or FLOSS) is often useful when discussing a shared ecosystem without choosing a philosophical label.

The difference is not simply vocabulary. Free-software advocates generally regard the ability to control one’s computing as an ethical requirement and are prepared to criticize proprietary software even when it is convenient or high quality. Open-source advocates often foreground the practical advantages of an open development method and an approved license, avoiding a moral claim about proprietary software as such. The FSF has argued that “open source” can miss the freedom issue; OSI voices have argued that a business-friendly, technically clear label can broaden adoption. Individual developers and organizations may endorse both views, only one, or neither.

Neither label guarantees a democratic project. A maintainer may reject patches; a company may own trademarks; a foundation may have formal voting rules; and a repository host may be centralized. Licenses determine permissions for code, not every aspect of community power. A fork is often legally possible under an open license, but it requires people, infrastructure, a name that does not infringe a trademark, and sustained maintenance. Conversely, paid engineers contribute extensively to projects commonly described as community-developed. Volunteer and corporate work coexist rather than forming opposite categories.

Licenses are the test, not a badge

“Open source” is sometimes misused for code that can be viewed but not reused, or for products with a public Git repository and restrictive terms. The OSD’s requirements make this distinction concrete. A source-available license may prohibit providing a competing hosted service, impose a revenue threshold, require a separate commercial agreement, or deny redistribution. Such terms may be lawful and commercially useful, but they do not satisfy the OSD. Similarly, a project can call itself “open” because it accepts external issues while keeping its code proprietary; openness of process and rights in code are separate questions.

Conversely, a project does not need to use a popular public forge to be open source. If recipients receive source and an OSI-approved license, the essential permissions travel with the software. In practice, reproducible builds, clear release tags, dependency manifests, accessible issue tracking, and responsive security processes make those rights more usable. They are good engineering and governance practices, not all conditions of the OSD.

License selection also involves compatibility. Combining code can create obligations that cannot all be fulfilled simultaneously. GPL versions, Apache-2.0’s patent terms, weak copyleft licenses such as the MPL, and proprietary dependencies require close reading. SPDX provides standardized identifiers and machine-readable license information, but an SPDX expression records a declared license; it does not prove that every file was correctly licensed or that the intended integration is compliant. Provenance and notices remain operational work.

Ecosystems after the naming campaign

After 1998, open-source development became central to operating systems, web servers, databases, cloud tooling, languages, scientific software, and mobile platforms. Linux distributions combine software under many licenses; Apache projects are governed through an established foundation model; Mozilla maintains a public codebase under MPL terms; and companies publish libraries that become shared infrastructure. Git, created in 2005 for Linux-kernel development, lowered the cost of distributed histories and branches, though it did not invent distributed collaboration. Package registries made reuse easier while also concentrating supply-chain and maintenance risk.

Institutional support grew alongside corporate involvement. The Apache Software Foundation, Eclipse Foundation, Linux Foundation, Software Freedom Conservancy, Debian, and language-specific foundations provide varied models for trademarks, fiscal sponsorship, governance, and releases. They should not be treated as one movement with one policy. Corporate sponsorship can fund security fixes and long-term maintenance, but can also influence priorities. A small, unpaid maintainer can be responsible for a dependency used by thousands of organizations. “Open” access does not solve the economics of care.

Modern debates include cloud services that modify software without distributing copies, license changes by vendors seeking to limit competitors, security disclosure, AI training and code provenance, and dependency-chain attacks. These are not evidence that the 1998 definition was irrelevant. They show why it is necessary to separate copyright permissions from business models, service operation, trademarks, data, and governance. The GNU Affero GPL addresses one network-use scenario with a source-offer requirement; other licenses do not. Readers should not infer that every program called open source imposes the same obligations.

Use terms carefully

A useful description names both the project and the license: “released under Apache-2.0,” “GPLv3-or-later,” or “MPL-2.0,” rather than merely “open.” It can then explain whether the point is user freedom, development practice, source availability, or community governance. The 1998 campaign changed the public language and institutional landscape of software licensing. It did not begin collaboration, erase free software’s prior work, or make all source-visible code open source. Its lasting contribution is a widely used definition and a pragmatic argument for rights that many earlier communities had already been practicing and defending.