Free Software and Open Source: Shared Code, Different Historical Arguments

Free software and open source often describe the same program and license, but the terms do not come from the same historical campaign. The GNU movement made control over software an ethical question about users’ freedom. The open-source campaign, organized under that name in 1998, emphasized a license definition and the practical case for collaborative development, partly to communicate with businesses that resisted the word “free.” The overlap is substantial; treating the names as perfectly interchangeable or as unrelated technologies both distort the record.

Understanding the distinction also prevents a common modern mistake. Code being visible on a website does not by itself make it free software or open source. The license must grant meaningful permissions to use, inspect, modify, and redistribute it. “Source available” can mean only that a person may read code under restrictive conditions.

GNU began as a freedom project

Richard Stallman announced the GNU project in September 1983 and began working on it in January 1984. The aim was to build a complete Unix-compatible operating system that users could run, study, change, and share. GNU was a recursive acronym for “GNU’s Not Unix”: compatibility would make the system useful, while independently written code and licensing would make it free.

The Free Software Foundation was established in 1985 to support that work and the broader movement. GNU components eventually included compilers, libraries, shells, editors, and utilities. A complete production system also needed a kernel; in practice, GNU tools were widely combined with the Linux kernel after its appearance in the 1990s. That history is why GNU advocates often use the name GNU/Linux for the combined operating system, although naming remains contested in wider usage.

The Free Software Definition expresses four essential freedoms, numbered zero through three. Users must be free to run the program for any purpose; study how it works and change it, which requires source code; redistribute copies; and distribute modified versions. The unusual numbering reflects the addition of the freedom to run before a list that already had three items.

“Free” in this vocabulary refers to liberty, not price. A person may charge for distributing, supporting, or modifying free software. Conversely, a no-cost application can be nonfree when its license forbids inspection, modification, or redistribution. The contrast is about authority over computing, not whether a checkout page displays zero dollars.

Copyleft is a strategy, not the whole definition

GNU developed copyleft to preserve freedoms downstream. A strong copyleft license permits modification and redistribution but requires distributed derivatives to remain under the same license and to provide corresponding source under specified conditions. The GNU General Public License became the most prominent implementation: version 1 was published in 1989 and version 2 in 1991.

Copyleft is not synonymous with free software. Permissive licenses can also satisfy the four freedoms while allowing modified versions to be redistributed under proprietary terms. Free-software advocates may prefer copyleft because it prevents later distributors from removing recipients’ freedoms, but the underlying definition includes both licensing strategies when their grants qualify.

This distinction matters when discussing business. Neither free software nor open source prohibits commercial activity. Companies can sell copies, hardware, hosted service, integration, warranties, training, or support. A particular license may impose obligations when software is conveyed or distributed, but “commercial” and “proprietary” are not synonyms. The relevant question is what rights recipients receive.

The term “open source” arrived in a specific 1998 context

By the late 1990s, freely licensed programs had already been developed for decades under multiple traditions. Debian had published its Social Contract and Debian Free Software Guidelines in 1997. In January 1998, Netscape announced that it would release source code for its browser project. Participants looking to build broader commercial acceptance saw an opportunity for a new public campaign.

At a strategy meeting in Palo Alto in February, Christine Peterson proposed “open source.” The Open Source Initiative’s own history credits the group with adopting the term and describes Eric Raymond and Bruce Perens as founding OSI later that month. Netscape’s announcement was a catalyst, but the new label neither invented source sharing nor created all the licenses it grouped together.

The choice was rhetorical and strategic. “Free software” was frequently misunderstood as meaning no price, and its ethical confrontation with proprietary software could make corporate audiences defensive. Open-source advocates foregrounded reliability, peer review, rapid improvement, and lower barriers to adoption. That argument helped make collaborative development legible to managers and investors, although no single framing represents every person who uses either term.

The Open Source Definition is more than visible code

Bruce Perens adapted the Debian Free Software Guidelines into the Open Source Definition. It sets criteria that licenses must satisfy, including free redistribution, availability of source code, permission for derived works, and no discrimination against persons, groups, or fields of endeavor. Rights must attach without requiring an additional license, and terms must not be specific to one product or restrict unrelated software.

Those criteria explain why a public repository is insufficient. A vendor can publish source while allowing only noncommercial study, forbidding redistribution, restricting use in a particular industry, or reserving the right to revoke permission. Such terms may enable auditing or customization, but they fail one or more open-source criteria. Labels should follow the rights in the license, not the convenience of viewing the files.

OSI reviews licenses against its definition and maintains an approved list. The Free Software Foundation evaluates licenses from the perspective of its freedom definition and compatibility with GNU licenses. Their conclusions overlap extensively but are not guaranteed to match in every edge case, and compatibility is a separate question from whether each license independently qualifies. Two free or open-source components can have obligations that make combining and redistributing them difficult.

Shared artifacts do not erase different priorities

The GNU project describes free software as a matter of justice and user autonomy. Its argument asks whether people control the computing they depend on or whether a program’s proprietor controls them. Access to source is necessary because meaningful study and modification would otherwise be impossible, but source access serves the broader freedoms.

The open-source campaign commonly makes an empirical and institutional argument: allowing inspection, modification, and redistribution can produce better review, faster experimentation, reduced vendor dependence, and robust shared infrastructure. These benefits are not automatic. Public code can remain poorly maintained or insecure, and a large user base does not guarantee a large reviewer base. The model creates permission and opportunity for collaboration; it does not manufacture competent governance.

Many contributors find both arguments persuasive. They work together on kernels, languages, databases, and libraries under licenses recognized by both OSI and FSF. Others deliberately choose one vocabulary because they want to emphasize ethics or practical outcomes. Still others use “open source” as the familiar umbrella without endorsing every claim made by the organized movement.

Terms such as FOSS—free and open-source software—and FLOSS, which adds libre to avoid the price ambiguity, acknowledge the shared technical space without pretending the histories are identical. These umbrella names are useful in policies and surveys, but they do not resolve philosophical disagreements over whether practical quality or freedom is the primary reason to reject proprietary restrictions.

Licensing remains the operational test

Historical vocabulary matters most when it improves present decisions. Before adopting or distributing a dependency, a team should identify the exact license and version, preserve notices, understand source or attribution obligations, check compatibility with the larger work, and distinguish network use from distribution. A slogan such as “it’s on GitHub” answers none of those questions.

Free software and open source ultimately share a powerful operational fact: recipients receive enforceable permissions that proprietary defaults withhold. Their organized movements explain that fact differently and sometimes recommend different strategies for preserving it. Accurate language can recognize the common code, the common licenses, and the real collaboration while still preserving why GNU began in 1983 and why a separate open-source campaign was launched fifteen years later. Related: Netscape Announces It Will Open-Source Its Browser Code · The Term ‘Open Source’ Is Proposed and the OSI Forms in 1998