Frequently Asked Questions

A software license is a legal document that defines how others can use, modify, and distribute your code. Without a license, your code is automatically protected by copyright, meaning others cannot legally use it. A license grants specific permissions while potentially adding conditions.

It depends on your goals:

• Private code: No license file is often best (all rights reserved by default)
• Open source: Yes, you absolutely need a license
• Public but not open source: Use an explicit "All Rights Reserved" license

Without a license, your code is "all rights reserved" by default under copyright law. This means:

• Nobody can legally use, copy, distribute, or modify your code
• GitHub will show "No license" on your repository
• For private projects, this is actually the strongest protection
• For public projects you want shared, this defeats the purpose

Yes! You can change your license at any time. However:

• The new license only applies to future versions
• People who already have the code under the old license can continue using it under those terms
• Going from permissive → copyleft is easier than copyleft → permissive
• If you have contributors, you may need their permission (depending on the license)

Yes, there are several scenarios:

• Dual licensing: Offer the same code under two licenses (e.g., GPL + commercial)
• Different files: Use different licenses for different parts (must be compatible)
• Dependencies: Your project can depend on libraries with different licenses

Be careful with copyleft licenses - they may require your entire project to use the same license.

Usually not. For truly private repositories, having no LICENSE file provides the strongest protection (all rights reserved by default). However, you might want an explicit LICENSE if:

• The repo is shared with contractors or clients
• It's a team repository with external collaborators
• You want to be crystal clear about rights

It's recommended but not legally required in most jurisdictions. Including the year helps establish when the work was created. You can use:

• Single year: Copyright (c) 2024
• Range: Copyright (c) 2020-2024
• Some projects update the year annually, others use the original year

For maximum legal protection, use your legal name (or your company's legal name). However:

• A consistent username/pseudonym can work for individual developers
• For business projects, always use the company's legal name
• Consider privacy vs legal strength trade-off
• Whichever you choose, be consistent across all files

Not required, but it's good practice for larger projects:

• A single LICENSE file at the root is usually sufficient
• Per-file notices provide extra protection if files are distributed individually
• Some licenses (like Apache 2.0) recommend it
• Enterprise/commercial projects often require it

Open source software has source code that anyone can inspect, modify, and enhance. To be officially "open source," a license must be approved by the Open Source Initiative (OSI) and meet their Open Source Definition, which includes:

• Free redistribution
• Source code must be available
• Derived works must be allowed
• No discrimination against persons, groups, or fields of endeavor

OSI-approved (true open source): Meets the Open Source Definition. Examples: Apache 2.0, MIT, GPL.

Source-available: Source code is visible, but the license restricts certain uses (typically commercial SaaS). Examples: SSPL, BSL, Elastic License. These are NOT open source.

The key difference: OSI-approved licenses don't discriminate against fields of endeavor, while source-available licenses explicitly restrict certain commercial uses.

Copyleft is a licensing strategy where derivative works must be released under the same license. It "flips" copyright to keep software free. There are different strengths:

• Weak (file-level): MPL 2.0 - only modified files must stay open
• Library: LGPL v3 - library itself must stay open, but can link from proprietary code
• Strong (project-level): GPL v3 - entire derivative project must be open
• Network: AGPL v3 - even network use triggers sharing requirements

A patent grant is an explicit license to use any patents that cover the software. Without it:

• Someone could contribute code, then sue users for patent infringement
• You have copyright permission but might still violate patents

Licenses with patent grants (Apache 2.0, GPL v3, MPL 2.0) protect both contributors and users. MIT and BSD lack this protection.

A trademark clause explicitly states that the license does NOT grant permission to use the project's name, logo, or trademarks. This prevents:

• Forks claiming to be the official project
• Commercial products misusing your brand
• Confusion about endorsement

Apache 2.0 and MPL 2.0 have explicit trademark clauses. MIT and BSD don't.

Choose Apache 2.0 if:

• You want patent protection (recommended for most projects)
• You care about trademark rights
• Your project might be used by enterprises

Choose MIT if:

• You want the absolute simplest license
• You prefer fewer legal terms
• Patents aren't a concern for your project

Our recommendation: Apache 2.0 for serious projects, MIT for quick/simple projects.

The Blue Oak Model License 1.0.0 is an OSI-approved permissive license written in plain English. It packs a patent grant (Apache 2.0's biggest advantage over MIT) into roughly 250 readable words, lets you satisfy the notice requirement with just a link, and uniquely gives you a 30-day window to fix an accidental compliance slip instead of instantly terminating.

It has notable adopters — the npm creator's core packages (glob, lru-cache, minimatch, rimraf) use it, so it's transitively installed nearly everywhere Node runs — but it's still far less recognized than MIT or Apache 2.0, and unfamiliar corporate legal reviews can add friction. Apache 2.0 also keeps two protections Blue Oak omits: defensive patent termination and an explicit trademark clause. We keep recommending Apache 2.0 as the default, with Blue Oak as a strong pick for small, widely-installed libraries or when plain language matters to you.

The key difference is the "network use" trigger:

• GPL v3: You must share source code only if you distribute the software
• AGPL v3: You must share source code even if you just run it as a network service (SaaS)

AGPL closes the "SaaS loophole" where companies could use GPL code in cloud services without sharing. However, AGPL can scare away potential users due to its strictness.

Use LGPL v3 when:

• You're writing a library
• You want the library to stay open source
• But you also want wide adoption (including from proprietary software)

LGPL lets proprietary applications link to/use your library without becoming GPL themselves. Only modifications to the library itself must be shared.

MPL 2.0 offers file-level copyleft - a middle ground between permissive and strong copyleft:

• Files you modify must stay open source
• You can add new files under any license
• You can combine with proprietary code in the same project
• Good for libraries that want some protection but wide adoption

Used by Firefox, Thunderbird, and LibreOffice.

AGPL v3 has trade-offs:

Pros:

• Strongest protection of software freedom
• Prevents cloud providers from exploiting your work
• Still OSI-approved open source

Cons:

• Many companies have policies against using AGPL software
• Can significantly reduce adoption
• May not actually prevent cloud vendors (they might just fork)

Use AGPL if software freedom is more important than wide adoption.

Yes! "Free" in open source means freedom, not price. You can:

• Sell the software itself
• Sell support, training, or consulting
• Sell hosted/managed versions
• Sell additional features or plugins
• Offer paid licenses (dual licensing)

However, buyers can also give it away for free (that's the point of open source).

Dual licensing means offering your software under two different licenses:

• Copyleft license: Free for open source use (e.g., AGPL v3)
• Commercial license: Paid license for proprietary use

This lets you serve both communities while generating revenue. Examples: MySQL, Qt, MongoDB. Requires owning all copyright (or contributor agreements).

You have a few options:

• AGPL v3: Forces cloud services to open source their modifications (OSI-approved)
• Source-available licenses: SSPL, BSL, Elastic (NOT open source, controversial)
• Dual licensing: AGPL + commercial license for cloud use

Caution: These strategies may reduce adoption and community goodwill. Many successful projects (Redis, Elasticsearch) have faced backlash when switching licenses.

AWS offered MongoDB as a managed service (DocumentDB) without contributing back to MongoDB Inc. MongoDB's solution:

• Switched from AGPL v3 to SSPL (source-available, not open source)
• SSPL requires cloud providers to open source their entire stack
• This effectively prevents SaaS offerings without a commercial license

This sparked debate about open source sustainability vs. corporate exploitation.

No. Despite having "available" source code, they're not open source because:

• They discriminate against fields of endeavor (violates OSI definition #6)
• OSI explicitly rejected SSPL
• Won't be included in Debian, Fedora, etc.
• Can't use the OSI-approved trademark

They're better described as "shared source" or "source-available proprietary."

No. This site provides educational information only. It is not legal advice. For legal guidance specific to your situation, consult a qualified attorney licensed in your jurisdiction.

Consider consulting a lawyer if:

• You're choosing a source-available license
• You're planning dual licensing
• Your project has significant commercial value
• You're accepting contributions and need CLAs
• You have patent concerns
• Someone violated your license
• You're unsure about license compatibility

Steps to take:

1. Document the violation (screenshots, links, dates)
2. Contact them politely - many violations are unintentional
3. Request compliance (e.g., add copyright notice, share code)
4. If they refuse, consult a lawyer about cease & desist
5. Legal action is expensive - consider if it's worth it

Most violations are resolved with a friendly email. Lawsuits are rare and expensive.

A CLA is an agreement where contributors grant you (the project owner) rights to their contributions. Used for:

• Dual licensing (you need to relicense contributions)
• Protection against patent claims from contributors
• Ability to change the license later

CLAs are controversial - some see them as corporate overreach. Only needed for specific business models.

SPDX (Software Package Data Exchange) is a standard way to document license information. SPDX license identifiers are short codes like:

• Apache-2.0
• MIT
• GPL-3.0-or-later

You can add them to files like: SPDX-License-Identifier: Apache-2.0

Two methods:

Method 1: Manual

1. Create a file named LICENSE (no extension) in your repo root
2. Paste the full license text
3. Commit: git commit -m "Add Apache 2.0 license"
4. GitHub will auto-detect it

Method 2: GitHub UI

1. Go to your repository
2. Click "Add file" → "Create new file"
3. Name it "LICENSE"
4. Click "Choose a license template" button
5. Select your license and commit

LICENSE (no extension) is standard and recommended:

• Standard convention
• GitHub auto-detects it best
• Plain text format

LICENSE.md or LICENSE.txt also work:

• GitHub recognizes these too
• Some prefer .md for Markdown rendering
• Slightly less common

Our recommendation: Use LICENSE with no extension.

Some licenses (notably Apache 2.0) allow an optional NOTICE file for:

• Attribution notices
• Copyright notices
• Trademark information
• Warranty disclaimers

If present, distributors must include it. Not required - only create one if you need it.