Open source software is software whose source code is published under a licence that lets anyone use, study, change and redistribute it. "Open source" does not mean "no rules" or "public domain". It is a legal arrangement, and the licence is what makes it work. The common benchmark is the Open Source Definition kept by the Open Source Initiative (OSI): a licence that meets all ten of its criteria counts as open source. In crypto this matters a lot. Bitcoin Core and the main Ethereum client are both published under OSI-approved licences, so anyone can check the rules a network actually runs on.
Where the term comes from
The label "open source" was chosen at a strategy session in Palo Alto, California, on 3 February 1998, after Christine Peterson suggested it. Eric Raymond and Bruce Perens founded the Open Source Initiative later that month.
The older idea of free software comes from the Free Software Foundation. It describes free software as giving users "the freedom to share, study and modify it", and adds: "We call this free software because the user is free." Here "free" means freedom, not price. Much open source software costs nothing, but price is not what defines it.
The Open Source Definition: ten criteria
The OSI's Open Source Definition (version 1.9) says a licence must meet all of these:
- Free Redistribution: anyone may sell or give the software away.
- Source Code: the source must be included or easy to get.
- Derived Works: changes and derived works must be allowed.
- Integrity of The Author's Source Code: a licence may require changes to be distributed as patches or under a new name.
- No Discrimination Against Persons or Groups
- No Discrimination Against Fields of Endeavor: for example, commercial use cannot be banned.
- Distribution of License: the rights pass to everyone who receives the program.
- License Must Not Be Specific to a Product
- License Must Not Restrict Other Software
- License Must Be Technology-Neutral
Publishing code on a public repository does not make a project open source. Without a licence that meets these terms, the code is only visible to others.
Main licence types
Permissive licences
Permissive licences let others reuse the code, including in closed products, with few conditions. The usual condition is keeping the copyright notice. The MIT License and the Apache License, Version 2.0 are both OSI-approved. Bitcoin Core uses the MIT License: its COPYING file opens with "The MIT License (MIT)" and "Copyright (c) 2009-2026 The Bitcoin Core developers".
Copyleft licences
Copyleft licences require anyone who distributes a modified version to release it under the same terms. The Linux kernel is provided "under the terms of the GNU General Public License version 2 only (GPL-2.0)". It has an explicit exception for the user-space system-call interface. Ethereum's Go client, go-ethereum, splits its licences:
- Library code outside the
cmddirectory uses the GNU Lesser General Public License v3.0. - The binaries built from
cmduse the GNU General Public License v3.0.
GPL-2.0, GPL-3.0 and LGPL-3.0 are all OSI-approved.
Source-available is not open source
Some projects publish their code but limit how it can be used. The Business Source License (BSL) is one example. Its steward, MariaDB, states that "The BSL does not meet the Open Source Definition (OSD)". Under the BSL, the code becomes available under an open source "Change License" on a set Change Date, or on the fourth anniversary of its first BSL release, whichever comes first. Some decentralised exchange protocols have released smart-contract code this way. You can read that code, but until the change date it is not open source.
Open source in everyday technology
Linux shows how far open source reaches. Android, for example, runs on a kernel that Google's documentation says "is based on an upstream Linux Long Term Supported (LTS) kernel", with Android-specific patches added on top.
Is this project really open source?
Answer a few questions about a repository to see whether its code is open source, only source-available, or just visible.
Does the repository contain a LICENSE or COPYING file?
- Yes → next question
- No → Visible, not open source
Does the licence mention the "Business Source License", "non-commercial" use or a change date?
Is the licence on the OSI's list of approved licences (for example MIT, Apache License 2.0, GPL-2.0, GPL-3.0 or LGPL-3.0)?
- Yes → next question
- No or not sure → Not confirmed as open source
What kind of project is it?
- Node software or a wallet → next question
- A deployed smart contract → next question
- Other software → Open source by licence
Does the project document reproducible builds, so independent builders can confirm a published binary matches the public source?
Is the deployed contract's source verified on a block explorer, so anyone can check it matches the bytecode on-chain?
Publishing code on a public repository does not make a project open source. Without a licence that meets the Open Source Definition, the code is only visible to others.
Terms such as the Business Source License, non-commercial limits or a change date mean source-available. MariaDB states that the BSL does not meet the Open Source Definition; you can read the code, but until the change date it is not open source.
A licence counts as open source when it meets all ten criteria of the OSI's Open Source Definition. If it is not on the OSI's list of approved licences, this check cannot confirm it.
An OSI-approved licence lets anyone use, study, change and redistribute the code. Public code is not automatically secure, so look for active review such as independent audits and a maintained repository.
The licence is OSI-approved and the project gives you a way to check what actually runs: reproducible builds for binaries or a verified contract source. Open code still does not guarantee that anyone has reviewed it.
The licence is OSI-approved, but without reproducible builds or a verified contract you cannot easily confirm that what runs matches the public source. Look for independent audits and a maintained repository.
This checks licence terms and the verification steps the article lists only; it does not assess the security of any project, and licence terms can change between releases.
Why open source matters for blockchains
A public blockchain asks users to trust rules rather than a company. Open code is how users can check those rules.
- Anyone can audit the rules. Bitcoin was described in Satoshi Nakamoto's white paper Bitcoin: A Peer-to-Peer Electronic Cash System. The software that enforces those rules today is public and under the MIT License.
- Users can check the binaries they download. Bitcoin Core keeps Guix-based files for "bootstrappable Bitcoin Core builds", so users can audit and reproduce the toolchain "instead of trusting binary downloads". Independent builders can confirm that a published binary matches the public source.
- You can verify deployed smart contracts. On Ethereum-compatible chains, developers can publish a contract's source on a block explorer, where anyone can check that it matches the bytecode on-chain. Etherscan's documentation describes verification as "publishing its source code on the block explorer, where anyone can read it."
- Anyone can fork the code. Because licences allow derived works, a group that disagrees with a project's direction can copy the code and run its own version.
Open source is not automatically secure
Public code lets more people look for bugs. It does not guarantee that anyone does. Two well-documented cases show both sides:
- Heartbleed (CVE-2014-0160). A programming mistake in OpenSSL's TLS heartbeat extension affected OpenSSL 1.0.1 through 1.0.1f. It let attackers read server memory, including private keys, user names, passwords and protected content. The bug was introduced in December 2011, shipped in 1.0.1 on 14 March 2012, and was fixed in 1.0.1g on 7 April 2014.
- The xz backdoor (CVE-2024-3094). On 29 March 2024, Andres Freund reported on the oss-security mailing list that "the upstream xz repository and the xz tarballs have been backdoored". The backdoor was in xz/liblzma 5.6.0 and 5.6.1. On distributions that link OpenSSH to libsystemd, it reached sshd and redirected
RSA_public_decryptduring public-key authentication. It was caught because someone was reading closely, but it had already been added upstream.
For crypto users, the lesson is to look for active review as well as public code: independent audits, reproducible builds, verified contracts and a maintained repository.
Open source and AI
The OSI released version 1.0 of its Open Source AI Definition on 28 October 2024. To count as open source AI, a machine-learning system must make three things available:
- Data information: enough detail about the training data that a skilled person could build a substantially equivalent system.
- Code: the complete source code used to train and run the system.
- Parameters: the model weights or other settings.
Each must be available under OSI-approved terms. Releasing the weights alone does not meet the definition. The definition is disputed: some community members and researchers criticised it when it was released.
How to check whether a project is really open source
- Find the LICENSE or COPYING file in the repository.
- Check that the licence appears on the OSI's list of approved licences.
- Look for terms such as "Business Source License", "non-commercial" or a change date. These mean source-available, not open source.
- For node software or wallets, see whether reproducible builds are documented.
- For smart contracts, check that the deployed contract's source is verified on a block explorer.
Limitations: this article explains definitions and licences; it does not assess the security of any particular project, and licence terms can change between releases.
