» License Finder

Pick a license in under a minute

Answer a short series of questions. You can back out at any step. Results are recommendations, not legal advice.

» Step · q-cc-commercial

Do you allow commercial use?

Creative Commons separates commercial from non-commercial use. Commercial includes anything done primarily for money.

» Step · q-cc-sharealike

Do you require derivative works under the same license?

Share-alike keeps derivatives in the commons. Without it, derivative works can be closed.

» Step · q-copyleft

How much should downstream users be required to share back?

Permissive licenses let people do almost anything with your code, including relicensing. Copyleft licenses require derivative works to stay under the same (or compatible) license.

» Step · q-data-attribution

Do you require attribution when others use the data?

Data licenses look a lot like Creative Commons but address databases and sui generis rights in EU law.

» Step · q-fair-code

What do you most want to prevent?

Fair-code licenses are source-available. They are not OSI-approved.

» Step · q-kind

What are you licensing?

Pick the category that most closely matches the material you want to cover. You can re-run the finder for a different category.

» Step · q-network

Should the copyleft also apply to software offered as a network service (SaaS)?

AGPL closes the 'SaaS loophole' — running a modified copy as a network service counts as distribution.

» Step · q-openness

Should the material qualify as open source?

Open source means an OSI-approved license that permits commercial use, modification, and redistribution. Fair-code licenses are source-available but restrict at least one of these.

» Step · q-patents

Do you want an explicit patent grant from contributors?

A patent grant protects downstream users from patent claims by the contributors. Apache 2.0 includes one; MIT does not.

» Step · q-proprietary

What is the distribution model?

Proprietary agreements are starting points. Have a lawyer review before shipping.

» Result · r-cc-by

Recommended

Attribution required; any use allowed including commercial use and modifications.

Why this fits

You are licensing content or media — not code. You want others to use, remix, and build on your work, including for commercial purposes, as long as they credit you. CC-BY-4.0 is the most permissive Creative Commons license that still requires attribution. It is the standard choice for open educational resources, photography, and open data.

What to do next

  1. Add a visible attribution statement on your work, e.g.: Licensed under CC-BY-4.0 © Author Name Year.
  2. Link to the full license deed at creativecommons.org/licenses/by/4.0/.
  3. If your work is a website, include the license in the footer or an about page.
  4. If you also want derivatives to stay open, consider CC-BY-SA-4.0.

« Start over

» Result · r-cc-by-sa

Recommended

Attribution plus share-alike — derivatives must be released under the same or a compatible license. Wikipedia uses this.

Why this fits

You are licensing content or media and want to ensure that remixes and derivatives stay in the commons. CC-BY-SA-4.0 requires anyone who builds on your work to share under the same terms, while still allowing commercial use and modifications. This is the license Wikipedia and many open-knowledge projects use — it balances openness with a commitment to the commons.

What to do next

  1. Add a visible attribution statement: Licensed under CC-BY-SA-4.0 © Author Name Year.
  2. Link to the full license deed at creativecommons.org/licenses/by-sa/4.0/.
  3. Be aware that CC-BY-SA content cannot be combined with incompatible licenses like CC-BY-ND.
  4. For software, CC licenses are not recommended — use a code license like GPL-3.0 for similar copyleft effect.

« Start over

» Result · r-cc-nc

Recommended

For non-commercial-only use, consider CC-BY-NC-4.0 (not yet in the catalogue). The closest listed license is CC-BY-4.0.

Why this fits

You want to restrict commercial use of your content. The best fit is CC-BY-NC-4.0, which requires attribution but prohibits commercial use. This license is not yet in the catalogue, but CC-BY-4.0 is the closest alternative listed here — it requires attribution while allowing commercial use, which is more permissive than your preference.

What to do next

  1. Review CC-BY-NC-4.0 at creativecommons.org/licenses/by-nc/4.0/ for the full terms.
  2. CC-BY-4.0 is listed here as a fallback, but it allows commercial use — confirm this is acceptable before using it.
  3. Check back when CC-BY-NC-4.0 is added to the catalogue for a complete comparison.

« Start over

» Result · r-cc-nd

Recommended

For no-derivatives, consider CC-BY-ND-4.0 (not yet in the catalogue). The closest listed license is CC-BY-4.0.

Why this fits

You want to allow sharing but not modifications. The best fit is CC-BY-ND-4.0, which permits redistribution but prohibits derivative works. This license is not yet in the catalogue, but CC-BY-4.0 is the closest alternative — it allows both sharing and modifications, which is more permissive than your preference.

What to do next

  1. Review CC-BY-ND-4.0 at creativecommons.org/licenses/by-nd/4.0/ for the full terms.
  2. CC-BY-4.0 is listed here as a fallback, but it allows modifications — confirm this is acceptable before using it.
  3. Check back when CC-BY-ND-4.0 is added to the catalogue for a complete comparison.

« Start over

» Result · r-data-attribution

Recommended

Attribution-only for content and data. For pure databases in EU jurisdictions, also consider ODbL-1.0 (not yet in the catalogue).

Why this fits

You are licensing data or a database and want attribution but not share-alike. CC-BY-4.0 works well for datasets and content — it requires credit but allows commercial use, modification, and redistribution under any license. In EU jurisdictions, databases also have sui generis rights that CC-BY-4.0 may not fully address.

What to do next

  1. Add a visible attribution statement with your dataset.
  2. For databases with sui generis rights (EU), also investigate ODbL-1.0 as a complementary option.
  3. Include clear provenance information so downstream users know how to attribute.
  4. If you want derivatives to stay open, consider CC-BY-SA-4.0 instead.

« Start over

» Result · r-data-sharealike

Recommended

Attribution + share-alike for data and databases. Keeps derived datasets in the commons.

Why this fits

You are licensing data and want attribution plus a requirement that derived datasets stay open under the same terms. CC-BY-SA-4.0 is the standard choice — it ensures that anyone who builds on your data must share their work under a compatible license, while still allowing commercial use. This is the data equivalent of copyleft.

What to do next

  1. Add a visible attribution and share-alike notice with your dataset.
  2. For EU databases with sui generis rights, also investigate ODbL-1.0 for database-specific coverage.
  3. Be aware that share-alike can limit adoption by commercial users who prefer to keep derivatives proprietary.
  4. If you only want attribution without the copyleft requirement, use CC-BY-4.0.

« Start over

» Result · r-fair-busl

Recommended

Business Source License — restricted today, converts to an open-source license after a fixed period (typically 4 years).

Why this fits

You want the benefits of source-available now with a guaranteed path to open source later. BUSL-1.1 restricts commercial and production use until a declared Change Date, after which each version automatically converts to a standard OSS license (commonly Apache-2.0 or GPL). This is popular with venture-backed infrastructure companies that want to ship source code without giving competitors a free ride — but still promise eventual openness.

What to do next

  1. Declare a Change Date (typically 3–5 years after release) and a Change License (commonly Apache-2.0 or GPL-3.0).
  2. Define an Additional Use Grant if you want to allow certain commercial uses before the Change Date.
  3. Place the four-line BUSL header at the top of each source file.
  4. Have a lawyer review the final configuration before publishing.

« Start over

» Result · r-fair-commercial

Recommended

Source-available with commercial-use restrictions — free for non-commercial and development use, paid for production commercial use.

Why this fits

You want to share source code but restrict commercial use without a paid license. Elastic-2.0 allows free use for development, testing, and non-production environments, but requires a commercial license for production use. This model works well for infrastructure software where you want adoption but also a revenue path.

What to do next

  1. Add a LICENSE file with the full Elastic-2.0 text in your project root.
  2. Define clear commercial licensing terms on your website so users know when they need to pay.
  3. Have a lawyer review the commercial terms before publishing.
  4. If you also want to prevent managed-service competition, compare with SSPL-1.0.

« Start over

» Result · r-fair-saas

Recommended

Source-available licenses that prevent competitors from offering your software as a managed service.

Open all 2 in compare →

Why this fits

You want to make your source code available but prevent cloud providers from offering a competing managed service without contributing back. SSPL-1.0 requires anyone offering the software as a service to open-source their entire management stack. Elastic-2.0 takes a simpler approach by restricting the specific use case. Both are source-available, not OSI-approved open source.

What to do next

  1. Choose SSPL-1.0 if you want the broadest copyleft-style obligation on service providers.
  2. Choose Elastic-2.0 if you prefer a simpler, more targeted restriction on managed services.
  3. Both licenses require legal review before use in a commercial product.
  4. If you want automatic conversion to open source after a delay, consider BUSL-1.1 instead.

« Start over

» Result · r-network-copyleft

Recommended

AGPL-3.0 closes the SaaS loophole — running a modified copy as a network service counts as distribution. GPL-3.0 is the next step down if AGPL is too aggressive.

Open all 2 in compare →

Why this fits

You want strong copyleft that also applies when someone offers your software as a web service. AGPL-3.0 is the right default here: unlike GPL-3.0, it requires anyone who modifies and hosts the software to share their changes, even if they never distribute binaries. This is important for SaaS, cloud, and server-side projects. If AGPL is too restrictive for your use case, GPL-3.0 still covers traditional distribution.

What to do next

  1. Add a LICENSE file with the full AGPL-3.0 text in your project root.
  2. Place a short AGPL header at the top of each source file.
  3. Check that your dependencies and target users are AGPL-compatible — some organizations avoid AGPL-licensed code.
  4. If you decide AGPL is too aggressive, fall back to GPL-3.0.

« Start over

» Result · r-permissive-patent

Recommended

A permissive license with an explicit patent grant from contributors to downstream users.

Why this fits

You want open source that stays permissive — others can use, modify, and relicense your code — but you also want patent protection. Apache-2.0 is the only permissive license that includes an express patent grant, which reduces the risk of patent lawsuits against your users. It also requires downstream projects to document significant changes.

What to do next

  1. Add a LICENSE file with the full Apache-2.0 text in your project root.
  2. Add a NOTICE file if your project uses Apache-licensed dependencies that require attribution.
  3. Place a short SPDX header at the top of each source file: SPDX-License-Identifier: Apache-2.0
  4. If you later need copyleft protections, consider upgrading to MPL-2.0 or LGPL-3.0.

« Start over

» Result · r-permissive-short

Recommended

Short permissive licenses with minimal requirements. MIT is the default in most ecosystems.

Open all 3 in compare →

Why this fits

You want open source with as few restrictions as possible — others can do almost anything with your code. These licenses only require keeping the copyright notice. MIT is the most widely recognized; ISC is functionally equivalent but shorter; BSD-3-Clause adds a no-endorsement clause. For most projects, MIT is the safe default.

What to do next

  1. Add a LICENSE file with your chosen license text in your project root.
  2. Update the copyright line to name the right author and year.
  3. For maximum compatibility, prefer MIT — it is recognized everywhere.
  4. If patent risk is a concern, consider Apache-2.0 instead for its explicit patent grant.

« Start over

» Result · r-prop-eula

Recommended

Starting point for a closed-source end-user license agreement. Must be reviewed by a lawyer before use.

Why this fits

You are shipping closed-source software to end users and need a license agreement that restricts copying, modification, and redistribution. A standard EULA provides clauses for grant of license, restrictions, termination, and disclaimer of warranty. It is a starting point only — EULAs must be tailored to your product, jurisdiction, and business model.

What to do next

  1. Have a lawyer review and customize the EULA for your specific product and jurisdiction.
  2. Define payment terms, support obligations, and acceptable use policies separately if needed.
  3. Ensure the EULA is presented to users before or during installation (click-wrap) for enforceability.
  4. Review your EULA annually — laws and your product change.

« Start over

» Result · r-prop-reserved

Recommended

All rights reserved notice. Pair with an NDA or internal policy; do not distribute externally without a license.

Why this fits

You are keeping the material confidential or internal, and do not intend to grant any license to the public. An 'all rights reserved' notice asserts full copyright protection and puts recipients on notice that no use is authorized without explicit permission. This is appropriate for internal tools, trade secrets, and materials shared only under NDA.

What to do next

  1. Add a clear copyright notice: 'Copyright © [Year] [Owner]. All rights reserved.'
  2. Pair this with a Non-Disclosure Agreement (NDA) or internal access policy for anyone who receives the material.
  3. Do not publish the material publicly — an all-rights-reserved notice on a public repo creates confusion.
  4. If you later decide to license the material, you can apply a specific license at any time.

« Start over

» Result · r-public-domain

Recommended

CC0 waives all copyright and related rights to the fullest extent possible. For software, the Unlicense is a common alternative.

Why this fits

You want to place your work in the public domain — no attribution, no restrictions, no copyleft. CC0-1.0 is the most comprehensive public-domain dedication, waiving all rights and not requiring attribution (though it does request it). It works for content, data, and code — though for software specifically, the Unlicense or 0BSD may be more conventional.

What to do next

  1. Add a CC0-1.0 dedication notice with your work: 'To the extent possible under law, [Author] has waived all copyright and related rights.'
  2. For software projects, also consider the Unlicense or 0BSD — they use language more familiar to developers.
  3. Be aware that public-domain dedication is not recognized in all jurisdictions (e.g., some EU countries). CC0 includes a fallback license for this case.

« Start over

» Result · r-strong-copyleft

Recommended

Strong copyleft — anyone who distributes derived works must release the whole project under GPL-3.0.

Why this fits

You want open source with teeth. GPL-3.0 ensures that anyone who distributes your code — modified or combined with other code — must make the complete source available under the same license. It also includes an explicit patent grant and anti-tivoization provisions. This is the right choice when keeping the entire ecosystem open matters more than maximizing adoption.

What to do next

  1. Add a LICENSE or COPYING file with the full GPL-3.0 text in your project root.
  2. Place a short GPL header at the top of each source file identifying the project and license.
  3. Be aware that GPL-3.0 is incompatible with some corporate environments — check your dependencies are GPL-compatible.
  4. If you are building a network service, consider AGPL-3.0 to close the SaaS loophole.

« Start over

» Result · r-weak-copyleft

Recommended

Weak copyleft — modifications to the licensed files stay under the license, but new files and linking code can use any license.

Open all 2 in compare →

Why this fits

You want improvements to your code to stay open, but you do not want to force the entire project that uses your code to be open-source. Weak copyleft applies at the file level: changes to the licensed files must be shared, but code that links or imports them remains free. Choose MPL-2.0 for applications and libraries; choose LGPL-3.0 when your library competes with a proprietary alternative.

What to do next

  1. Add a LICENSE file with the full license text in your project root.
  2. Clearly separate your library code from application code so downstream users understand what the copyleft covers.
  3. Place a short SPDX header at the top of each copyleft-covered source file.
  4. If you are unsure between MPL-2.0 and LGPL-3.0, compare them side-by-side.

« Start over

Feature

Not sure which license fits?

Answer a few questions and get a shortlist you can compare.

Open the finder →