The weekend project trap
You spend a Saturday building a parser for a weird config format. It handles edge cases, runs fast, and actually works. You push it to crates.io so your friends can use it in their projects. A week later, a maintainer of a popular framework messages you. They want to integrate your parser. They ask, "What's the license?"
You check your repository. There's no license file. You realize your code is effectively locked in a vault. By default, copyright law grants you all rights, which means everyone else has none. No one can copy, modify, or distribute your crate. Not even your friends. Adding a license is the key that unlocks the vault. Without it, your crate is technically unusable by anyone except you.
Licenses are permissions, not restrictions
A license is a legal permission slip. It tells users what they can do with your code and what they must do in return. Many developers think licenses are about restricting others. In open source, licenses are about enabling others. They define the rules of engagement so users can rely on your code without fear of being sued later.
In the Rust ecosystem, we use SPDX identifiers. SPDX stands for Software Package Data Exchange. It's a standardized list of license names that tools can read. Instead of writing a paragraph of legalese in your Cargo.toml, you write a short string like MIT or Apache-2.0. Cargo, crates.io, and dependency managers understand these strings. This standardization allows tools to automatically check license compatibility across your entire dependency tree.
The SPDX standard
SPDX identifiers remove ambiguity. If you write "MIT License" in a text field, a tool might not recognize it. If you write MIT, the tool knows exactly what that means. The SPDX list covers thousands of licenses, from the permissive MIT to the copyleft GPL to the public domain Unlicense.
Using SPDX identifiers enables automation. When a company audits its software supply chain, tools can scan Cargo.toml files and report which licenses are present. If a dependency uses a license that conflicts with the company's policy, the tool flags it. This works only if everyone uses the standard identifiers.
Convention aside: The Rust community expects SPDX identifiers in the license field. If you use a non-standard string, cargo publish will warn you, and some tools may fail to parse your metadata. Stick to the SPDX list. You can find the full list at spdx.org/licenses.
Minimal setup
The standard choice for Rust crates is MIT OR Apache-2.0. This is the license used by the Rust compiler, the standard library, and most crates in the ecosystem. It offers users a choice between two permissive licenses.
[package]
name = "my_parser"
version = "0.1.0"
edition = "2024"
// SPDX identifier. The 'OR' lets the user pick either license.
license = "MIT OR Apache-2.0"
This single line does a lot of work. It tells Cargo that your crate is dual-licensed. It tells crates.io to display the license information on your crate's page. It tells users that they can use your code under the terms of either the MIT license or the Apache 2.0 license.
How dual licensing works
When you set license = "MIT OR Apache-2.0", you are offering a choice. The user can accept the terms of the MIT license, or they can accept the terms of the Apache 2.0 license. If they satisfy one, they are good. This is called dual-licensing.
The MIT license is short and simple. It allows users to do anything with your code as long as they include the copyright notice and license text in their project. The Apache 2.0 license is longer but includes an explicit patent grant. This protects users from patent trolls who might sue them for using your code. By offering both, you cover more ground. Some organizations have legal teams that prefer Apache 2.0 because of the patent clause. Others prefer MIT for its brevity.
Convention aside: When you use MIT OR Apache-2.0, Cargo expects two files: LICENSE-MIT and LICENSE-APACHE. If you only have a single LICENSE file, cargo publish might complain. Follow the naming convention to keep the tooling happy. The content of each file must match the corresponding license text.
The patent clause matters
The difference between MIT and Apache 2.0 often comes down to patents. The MIT license does not mention patents. If you write code that implements a patented algorithm, and you distribute it under MIT, you might still sue users for patent infringement. The MIT license grants permission to use the code, but it doesn't explicitly grant a license to the patents.
Apache 2.0 includes an explicit patent grant. It says that contributors grant users a license to any patents they hold that are necessary to use the code. This protects users from patent lawsuits from the contributors themselves. It also includes a patent retaliation clause. If a user sues someone for patent infringement related to the code, their patent license terminates. This discourages patent trolling.
For most Rust crates, the patent risk is low. Rust code rarely implements patented algorithms. However, the Apache 2.0 license provides peace of mind for users in industries where patent litigation is common. That's why the Rust project chose to include it as an option.
Realistic scenarios
Not every crate needs MIT OR Apache-2.0. Your choice depends on your goals and your audience.
If you want to ensure that derivatives of your code remain open source, you might choose a copyleft license like GPL-3.0-or-later. This license requires anyone who distributes your code to also distribute the source code under the same license. This is useful if you want to prevent companies from taking your code, modifying it, and selling it as a proprietary product without contributing back.
If you want to give your code away with zero strings attached, you might choose Unlicense. This dedicates your work to the public domain. There are no conditions. Users can do anything. Note that some jurisdictions don't recognize public domain dedications, so Unlicense includes a fallback permissive license for those cases.
If you have a specific legal requirement that standard licenses don't cover, you might need a custom license. This is rare and usually requires a lawyer. Custom licenses break tooling and create friction for users. Avoid them unless you have a compelling reason.
Pitfalls and cargo errors
The most common mistake is setting the license field in Cargo.toml but forgetting the actual license text file. cargo publish will reject your crate. The error looks like this: failed to verify package tarball: license file not found. Cargo expects a file named LICENSE or LICENSE-MIT and LICENSE-APACHE in the root of your project. The content of the file must match the SPDX identifier. If you say MIT, the file must contain the MIT license text.
Another pitfall is using AND instead of OR. license = "MIT AND Apache-2.0" means the user must satisfy both licenses simultaneously. This is almost never what you want. It creates a legal mess. Stick to OR for dual licensing.
Convention aside: Permissive licenses still require attribution. You can't just take code licensed under MIT and claim it's yours. You must keep the copyright notice and license text. "Permissive" doesn't mean "no rules." It means "few rules."
Choosing your license
Use MIT when you want maximum simplicity and don't care about patent protection. It's short, clear, and permissive.
Use Apache-2.0 when you want a permissive license that includes an explicit patent grant. This protects users from patent trolls who might sue them for using your code.
Use MIT OR Apache-2.0 when you are publishing a standard Rust crate. This is the community convention. It matches the Rust compiler's license and gives users the best of both worlds.
Use GPL-3.0-or-later when you want to ensure derivatives remain open source. This is copyleft. If someone uses your code in their product, they must open-source their product too.
Use Unlicense when you want to dedicate your work to the public domain. There are no conditions. Users can do anything.
Reach for a custom license only when you have a specific legal requirement that standard licenses don't cover. This is rare and usually requires a lawyer.
Don't leave your code naked. Add a license before you publish. Trust the convention. MIT OR Apache-2.0 works for 99% of crates. Check your files. cargo publish will stop you if the license text is missing.