Open Source Explained: Licences, Contribution, Risk
Open source software is published with a licence that lets anyone use, study, modify and share it, which turned shared code into the foundation of the modern internet.
In this guide
Almost every product you use runs on open source: operating systems, web servers, programming languages, databases, browsers and build tools. The code is public, but that does not mean it is unowned or free of obligations.
The licence is what makes a project open source. It grants permissions and sets conditions, and those conditions decide what you can do with the code in your own product.
Licences, in plain language
Permissive licences such as MIT, Apache 2.0 and BSD let you use the code in commercial and closed products with few conditions, usually attribution and preservation of notices. Apache 2.0 adds an explicit patent grant.
Copyleft licences such as GPL require that derivative works distributed to others remain under the same licence, which can matter a great deal for a company shipping a proprietary product. Network copyleft licences extend the requirement to software offered as a service.
- MIT and BSD: minimal conditions, maximum flexibility.
- Apache 2.0: permissive with an explicit patent grant.
- LGPL: copyleft on the library itself, with a linking allowance.
- GPL: strong copyleft on distributed derivative works.
- AGPL: copyleft triggered by network use as well as distribution.
How projects are actually sustained
A healthy project has a clear governance model, a release process, responsive maintainers and documented contribution guidelines. Many critical libraries are maintained by a handful of people, sometimes unpaid, which is a real resilience risk for the industry.
Funding models include sponsorship, commercial support, hosted services and foundations. Projects backed by a foundation generally have clearer continuity than those tied to one company's roadmap.
Contributing without wasting anyone's time
Start by reading the contribution guide and searching existing issues. Reproduce the bug on the current version, describe expected and actual behaviour, and include a minimal test case.
Small, focused pull requests get reviewed. Large rewrites from strangers rarely do, because review cost falls on volunteers who owe you nothing. Documentation and tests are welcome contributions that also teach you the codebase.
Managing open source risk
Track your dependencies, because most of your code is written by people you have never met. Lock file versions, scan for known vulnerabilities, and have a plan for applying patches quickly.
Check licence compatibility before adopting a library, and consider the health of the project: recent releases, responsive maintainers and a history of handling security reports. Abandoned dependencies accumulate quietly until they become urgent.
Key facts at a glance
Frequently asked questions
Does open source mean free of charge?
Usually the software is available at no cost, but the licence is about freedom to use and modify, not price. Support, hosted versions and enterprise features are often paid.
Can I use open source in a commercial product?
Generally yes, provided you follow the licence. Permissive licences are straightforward. Copyleft licences may require you to publish the modified source of distributed derivative works.
Is open source less secure?
Not inherently. Public code can be reviewed by anyone, which helps, but review only happens when people actually look. Dependency hygiene and prompt patching matter more than whether source is public.