Open source refers to software whose source code is made publicly available under a license that grants specific legal permissions — typically the right to view, use, modify, and redistribute the code, sometimes with conditions attached. The critical word here is license. Simply being able to see a project’s code — which is true of every public repository on GitHub — does not automatically make it open source. Open source is a legal and licensing concept, not just a visibility setting.

The open-source movement grew out of a belief, dating back to the free software movement of the 1980s pioneered by figures like Richard Stallman, that software should be collaboratively improvable rather than locked away as a black box. The specific term “open source” was coined in 1998 as a more business-friendly framing of these same ideas, emphasizing practical benefits — faster bug discovery through many eyes reviewing the code, collaborative innovation across organizational boundaries, and reduced duplication of effort — alongside the original philosophical commitment to user freedom.

On GitHub specifically, this philosophy found its natural home: a platform built around Pull Requests and public visibility made it dramatically easier for strangers around the world to propose improvements to a project they’d never have had access to under older, closed development models.

flowchart TD
    A["Public Repository
(anyone can view/clone)"] --> D{Has a LICENSE file?}
    D -->|Yes, e.g. MIT, Apache-2.0, GPL| E["Legally Open Source
(use/modify/redistribute permitted)"]
    D -->|No license file| F["Source-Available Only
(viewable, but all rights reserved by default)"]
    E --> G["Pull Requests from
outside contributors"]
    G --> H["Maintainer Review
on GitHub"]
    H --> I["Merged into
main project"]
    

What an interviewer may ask: “If a public GitHub repository has no LICENSE file, can you legally copy code from it into your own project?” The safe, technically correct answer is no — under default copyright law, the author retains all rights, and “public” does not imply “permission to reuse.”

A software license is a legal instrument built on top of copyright law. By default, the moment someone writes original code, copyright law automatically grants them exclusive rights over it — nobody else may legally copy, modify, or redistribute it without permission. An open-source license is the author proactively waiving some of those exclusive rights, in writing, for anyone who receives the software. Different licenses waive different amounts of control, which is why “open source” isn’t one single set of rules but a spectrum of related agreements, each with its own specific terms around attribution, modification, and redistribution.

Open-source security is often described through the phrase “many eyes make bugs shallow” — the idea that with source code visible to thousands of independent reviewers, vulnerabilities get discovered and patched faster than in closed systems where only a small internal team can look. In practice, this holds true for actively maintained, widely used projects, but it has a real limit: many open-source projects are maintained by just one or two volunteers, meaning the “many eyes” assumption doesn’t always apply, and a critical vulnerability can sit undiscovered for years, as happened with the widely publicized Heartbleed vulnerability in OpenSSL.

GitHub adds tooling on top of this reality: Dependabot automatically scans a project’s open-source dependencies for known vulnerabilities and opens Pull Requests to update them, and secret scanning checks for accidentally exposed credentials in public repositories — both meaningfully reducing the practical risk of relying on open-source code at scale.