Open-source software is software whose source code is made available under a license permitting users to use, study, modify, and redistribute it. Its defining feature is not merely public access to code, but the permissions accompanying that code. The Open Source Initiative (OSI) maintains the widely used Open Source Definition, which establishes criteria for qualifying licenses. Open-source software may be developed collaboratively or by a single organization, and may be supplied commercially or without charge. (opensource.org)
Definition and boundaries
The Open Source Definition requires access to the preferred form of a program for modification, permission to create and distribute derived works, and freedom to redistribute the software. Licenses must not discriminate against people, groups, or fields of activity; commercial use therefore cannot be excluded. They must also be technology-neutral and cannot require unrelated software distributed alongside the program to adopt the same license. (opensource.org)
These requirements distinguish open source from source-available software, whose code can be inspected but whose license may restrict modification, redistribution, or particular uses. They also distinguish it from freeware, which describes software available at no monetary cost without necessarily granting source access or modification rights. A publicly readable repository does not, by itself, establish open-source permissions. (opensource.org)
Free software substantially overlaps with open-source software. The Free Software Foundation defines it through four freedoms: running a program for any purpose, studying and changing it, redistributing copies, and distributing modified versions. The terminology reflects different emphases: the free-software movement foregrounds user freedom, whereas the open-source label historically emphasized practical collaboration and adoption. “Free and open-source software,” abbreviated FOSS, encompasses both traditions. (gnu.org)
Historical development
Sharing and collaboratively improving software predates the expression “open source.” An important institutional development was the GNU Project, which began implementation in January 1984 with the goal of producing a free operating system. Its work established a continuing framework for developing and distributing software with user freedoms. (gnu.org)
The open-source label was proposed at a meeting in Palo Alto, California, on February 3, 1998, following Netscape’s announcement that it would release browser source code. The OSI was founded later that month. Its definition adapted the Debian Free Software Guidelines, adopted by Debian in 1997, removing references specific to that distribution. This connected the new terminology to an existing licensing framework rather than creating software sharing from nothing. (opensource.org)
Licensing models
Open-source licensing operates within copyright rather than necessarily abolishing it. Authors or other rights holders grant specified permissions while retaining ownership. License conditions can include preserving attribution, reproducing license notices, or supplying source code when distributing covered software. Different licenses impose different obligations. (gnu.org)
Two broad families are commonly distinguished:
- Permissive licenses allow covered code to be incorporated into software distributed under other terms, including proprietary terms, subject to conditions such as attribution. Examples include the MIT License, BSD licenses, and the Apache License. Apache License 2.0 also contains explicit patent licensing provisions. (opensource.org)
- Copyleft licenses require covered derivative works, when distributed, to preserve specified freedoms. The GNU General Public License (GPL) is a prominent example. Copyleft does not generally require every private modification to be published, nor does merely distributing independent programs together automatically place them all under the same license. (gnu.org)
The GNU Affero General Public License extends source-sharing requirements to certain uses of modified software over a network. Consequently, software operated as a service can raise different licensing questions from software delivered as copies. Permission to use code also does not automatically confer permission to use the original project’s trademarks or branding. (opensource.org)
Development and governance
Collaborative projects commonly organize work around a repository, issue reports, proposed changes, tests, and review by maintainers. Contributions extend beyond programming to documentation, translation, testing, and bug reporting. Contribution guidelines define coding conventions, review expectations, communication channels, and procedures for reporting problems. Public availability of code does not oblige maintainers to accept every proposed change. (docs.github.com)
A fork is a separately developed version derived from an existing project. Open-source permissions enable such development under the applicable license. Some projects also use contributor agreements to establish their rights to distribute submitted material; these agreements are distinct from the license governing recipients’ use of the software. (opensource.org)
Commerce and security
Open source is compatible with commercial activity. Businesses can sell copies, customization, maintenance, support, warranties, and other services. Recipients retain the redistribution rights granted by the license, so charging for delivery does not convert the underlying software into proprietary software. Revenue arrangements and licensing permissions are separate aspects of a product. (opensource.org)
Source availability permits inspection, but does not establish that software is secure. Cybersecurity depends on development practices, review, maintenance, and vulnerability management. OpenSSF’s security tools assess projects through controls and automated checks rather than treating an open-source license as evidence of security. Dependencies also matter: vulnerabilities in third-party components can affect the software incorporating them, while outdated dependencies may preserve known defects. (baseline.openssf.org)