What Is Open Source Software

You use Linux, Firefox, VS Code, and Git every day without paying a dime. Someone tells you it's all "open source" and you naturally assume open source means free. That makes sense — except it's not quite accurate, and the difference matters when you start working professionally with software.

What open source actually means

Open source is about access to source code, not price.

Software is considered open source when the source code is publicly available and you have legal permission to read, modify, and redistribute it. The Open Source Initiative (OSI) maintains a list of licenses that qualify as open source — currently over 80 approved licenses.

What determines whether software is open source is not the price charged for it, but the terms of the license. Software can be open source and cost money. Software can be free and not be open source (Windows is free to download in many scenarios — you cannot see the source code).

The concept was formally established in 1998 with the creation of the OSI, but it predates that. The free software movement led by Richard Stallman in the 80s and the GNU project already advocated for code access on more radical philosophical grounds. Open source emerged as a more pragmatic version of the same principle — focused on practical development benefits rather than freedom as a moral value.

The main licenses (and what each one allows)

A license is not a bureaucratic detail — it defines what you can and cannot do with the code.

MIT

The simplest and most permissive. You can use, copy, modify, distribute, sublicense, and sell without restrictions, as long as you include the original copyright notice. React, jQuery, Rails, and hundreds of other popular libraries use MIT.

Copyright (c) 2024 Author Name

Permission is hereby granted, free of charge, to any person obtaining a copy...

Almost anything goes. No obligation to publish your modified code.

Apache 2.0

More detailed than MIT. Adds explicit protection against patent litigation — contributors automatically grant a patent license to the project. Kubernetes, Android (partially), and many Apache Foundation projects use this license.

The practical difference from MIT is mainly the patent clause. For common use, the behavior is similar.

GPL (and its variants)

The GPL (GNU General Public License) is the most well-known copyleft license. Copyleft means that any software incorporating GPL code must be distributed with the same source code and under the same license. The freedom "infects" derivative work.

This has serious implications for commercial software: if you include GPL code in a closed product you distribute to customers, you are required to distribute that product's source code. Linux uses GPL v2. Git uses GPL v2.

Important variants:

• LGPL (Lesser GPL): a milder version — you can use the library in proprietary software as long as you don't modify the library itself
• AGPL (Affero GPL): extends the obligation to network use — even without "distributing" the software (like a SaaS), you must make the source code available

BSD

A family of permissive licenses, similar to MIT. BSD 2-Clause is practically equivalent to MIT. BSD 3-Clause adds one restriction: you cannot use the project name to endorse your derived products without permission.

PostgreSQL uses the PostgreSQL License, which is BSD-style.

Open source is not a synonym for free

This myth is worth repeating with concrete examples:

MongoDB was open source (AGPL) and charged for enterprise support. In 2018, it switched to SSPL — a license created by the company itself, not approved by the OSI, which requires anyone offering MongoDB as a service to also publish the entire infrastructure's code. AWS kept offering MongoDB as a service without publishing the code → MongoDB created the new license precisely to force the issue.

Red Hat Enterprise Linux (RHEL) is built on GPL code (Linux, etc.). The code is open source. The product — with support, certifications, guarantees — costs money. You can download the source code and compile it yourself (that's what CentOS did, and what Rocky Linux and AlmaLinux do today). But the packaged product with support has a price tag.

GitLab has a Community Edition (MIT) and a paid Enterprise Edition with extra features. Same model many projects adopt: open source core, proprietary extensions.

HashiCorp (Terraform, Vault, Consul) migrated from MPL 2.0 to BSL (Business Source License) in 2023 — which is not open source by the OSI definition. Competitors who monetized Terraform as a service prompted the creation of the OpenTofu fork.

The pattern repeats: the company uses open source to grow and build a community, then closes what it needs to protect from cloud competition.

How open source sustains itself financially

If anyone can use it for free, how does the project pay the bills?

Dual licensing: offers a permissive license for personal and open source use, and a commercial license for businesses. MySQL does this (GPL for open source, commercial license for proprietary software).

Open core: the application's core is open source, enterprise features are proprietary. GitLab, Metabase, Sentry follow this model.

Support and services: sells the product as SaaS or sells support, consulting, and training. Red Hat was the classic case for decades.

Donations and foundations: projects like Linux, Python, Apache, and Rust rely on non-profit foundations that receive corporate sponsorship. Companies sponsor because they depend on the software.

Hiring contributors: large companies (Google, Meta, Microsoft, Stripe) pay engineers to contribute to open source projects they depend on — React, Go, TypeScript, V8, etc. The code is open source, but the work is paid.

Contributing to open source projects

The basic contribution workflow is standard across most projects hosted on GitHub or GitLab:

# 1. Fork the repository to your account
# 2. Clone the fork locally
git clone https://github.com/your-username/project-name.git

# 3. Create a branch for your change
git checkout -b fix/typo-in-readme

# 4. Make the change, commit, and push to your fork
git commit -m "fix: typo in contributing guide"
git push origin fix/typo-in-readme

# 5. Open a Pull Request on the original repository

Before contributing something substantial, check:

• The CONTRIBUTING.md file — most projects have specific instructions
• Open issues — there may already be a discussion about the problem
• The project's code of conduct
• Whether the license is compatible with what you want to do

Contributions don't have to be code. Documentation, translations, tests, issue triage — it all counts and is generally easier to start with.

Frequently asked questions

Can I use MIT code in a closed commercial project?

Yes. The MIT license allows use in proprietary software with no obligation to open your code. You need to include the original copyright notice in your product, but you can close the rest. Always check the specific license — some projects combine multiple licenses for different parts.

What happens if I use GPL code without following the license?

GPL license violations are a real legal matter. The Software Freedom Conservancy and the FSF have sued companies over this. In typical cases, the company is notified and given the option to fix the situation (publish the code or remove the component). Ignoring it can result in litigation and loss of the right to distribute the product.

Is "source available" the same as open source?

No. Source available means you can see the source code, but the license may restrict what you do with it. BSL (Business Source License) and SSPL are examples: the code is visible, but commercial use may be restricted. The OSI does not approve these licenses as open source.

Are forks always legal?

It depends on the license. With MIT, Apache, or BSD, forking is free — you can take the code and create your own project. With GPL, you can fork, but you need to keep the GPL. With proprietary or restrictive source-available licenses, forking may be contractually prohibited.

The license is the detail nobody reads until they have to

Open source solves a real development problem — you don't have to reinvent the wheel for every project, and the code has been reviewed by many people. But the license is not a secondary detail: it defines what you can build on top of it, whether you can close the code, and what happens if you change your mind later.

For personal projects and experiments, MIT or Apache are safe and widely accepted choices. For software you're going to distribute or sell, ten minutes reading the license before adding a dependency is time well spent — especially if it's GPL or AGPL.

Note: editorial content ends here. The section below is a reference to a related tool.

Related tool

If you're setting up an open source project with an associated web page, one of the first files you'll need is a robots.txt. To generate and validate it with granular bot control, I use the robots.txt Generator — especially useful for projects that want to control what AI crawlers index.