The issue that says “which license?”
It's a Tuesday night and the side project finally has traction: forty-one stars, two outside pull requests, and an issue titled “Licensing?” from someone at a company that wants to vendor your library. Their legal team won't touch unlicensed code — without a LICENSE file, your repository defaults to “all rights reserved,” which is lawyer for “not legally usable by anyone.” A stranger wants to use your work, and the only thing standing in the way is a text file you haven't written yet.
The Open Source License Generator writes that file for you. Pick the license, type your name and the year, and the tool emits the exact published text with your copyright line filled in — MIT, Apache-2.0, GPL-3.0, LGPL-3.0, AGPL-3.0, and the BSD family — along with the plain-English summary of what each one permits, requires, and forbids. The file lands in your repository root, and issue #17 closes with a link instead of an apology.
Two neighboring chores tend to ride along with a first license: the .gitignore Generator for the ignore file a public repo needs before screenshots and .env files start leaking into history, and the Cron Expression Builder for the scheduled job that arrives the moment a project grows contributors. This article covers the license decision itself: how the generator works, what each license family actually says, which ones mix, and the filing conventions that make a repo look like it was built by someone who has done this before.
Filling your first LICENSE file
The workflow is short because the legal part, done properly, is short. Here is the path from unlicensed repository to badge on the front page.
Pick the license family
Start from your goal. “Use it anywhere, credit me” points at MIT or BSD. “Corporate-friendly with patent protection” points at Apache-2.0. “No closed-source derivatives, ever” points at GPL-3.0. The chooser asks three questions and narrows the field.
Enter the copyright holder
Your name, your company's name, or your project's legal entity. This is the one line of the license that belongs to you; everything else is verbatim legal text.
Enter the year
2026 for a first release. For ongoing code, the generator writes a range like 2024-2026 — the year of first publication through the year of the latest change.
Add the GPL options if you chose GPL
GPL-3.0 asks one extra question: -only or -or-later, deciding whether future GPL versions can apply. The generator records the answer in the notice line and the SPDX identifier.
Generate and copy
The full text appears with your line filled in. Copy it into a file named LICENSE at the repository root — plain text, no formatting, exactly as emitted.
Commit and move on
Add the file, push, and watch the hosting platform's license badge appear on the repo home page within minutes. Add the SPDX identifier to your package manifest while you're in there, and the registry's “no license field” warning disappears too.
Sixty seconds, one commit. The decision is the hard part, and the rest of this article exists to make that decision an informed one rather than a coin flip between whatever two names you've heard most.
What the generator writes — and what it never touches
A license is a legal document, and legal documents derive their power from being exact. The generator's first rule follows from that: the published text is reproduced verbatim, character for character. You may fill in the copyright line. You may not improve the wording, modernize the punctuation, or delete the all-caps warranty paragraph because it looks shouty. A modified MIT is no longer the MIT License — it's an unreviewed custom license, and it inherits every problem of one.
What changes between licenses is the number of blanks. MIT has exactly one: the copyright line. The BSD family has the same one, plus a list of conditions that vary by clause count. Apache-2.0 keeps its full nine sections and appendix verbatim and asks you to fill the appendix boilerplate — the short header that goes into each source file and names your copyright. GPL-3.0 ships as a single unchangeable block; your project's identity goes in a separate notice line, traditionally in the README or the program's about text, not inside the license itself.
The generator also emits the SPDX identifier — MIT, Apache-2.0, GPL-3.0-only, GPL-3.0-or-later, BSD-3-Clause — because modern tooling reads those machine-readable tags from package manifests, license scanners, and compliance dashboards. A repo with the right identifier in package.json or pyproject.toml passes automated audit checks that a bare LICENSE file can fail. Small string, disproportionate effect on how your project reads to the robots that triage millions of packages.
The MIT License, read closely
The MIT License is the most copied software license in existence, and it earns that with brevity: about 170 words, one paragraph of grant, one sentence of condition, one paragraph of warranty disclaimer. Read it once and you understand your entire legal exposure.
The grant paragraph gives anyone “permission to deal in the Software without restriction” — use, copy, modify, merge, publish, distribute, sublicense, sell. The list is long on purpose: it forecloses the argument that some unlisted activity was reserved. The single condition is the return trip: every copy or substantial portion must carry the copyright notice and the permission notice. That's the whole bargain. Credit travels with the code; everything else is permitted.
The final paragraph, the one in all caps, disclaims everything else. No warranty. No liability. If the code formats the wrong disk, the authors owe you nothing, and the capitals exist because some courts read conspicuous disclaimers more reliably than quiet ones. The caps are a feature, not a formatting accident, which is also why every serious license closes with the same shouting.
What MIT doesn't say is its own footnote: patents. The text grants rights in “the Software” without mentioning patents, leaving a century of implied-license doctrine to fill the gap. For a date-formatting library, nobody cares. For anything where a method might be patented, the silence is the reason Apache-2.0 exists in the next section.
Apache-2.0 and the patent grant
The Apache License, Version 2.0 is what permissive looks like when lawyers get to draft it: nine numbered sections and an appendix, several pages, and a machinery that MIT's single paragraph handles by omission. The extra machinery earns its length in two places — patents and provenance.
Section 3 is the patent grant MIT lacks. Every contributor grants every user a license to any patent claims the contributor owns that cover their contribution. Section 3(b) adds the teeth: if you sue anyone alleging the software infringes a patent, your patent license terminates. It is a mutual non-aggression pact, and it is the clause corporate legal departments read first — the reason Apache-2.0 has become the default for foundation-backed and corporate-open-source projects.
The other moving parts do quieter work. Section 1 defines “Contribution” carefully enough that everything from commits to intentionally submitted patches counts. Section 4 governs redistribution: keep the notices, include the license text, document your modifications, and pass a NOTICE file along when the project ships one — provenance rules that make audits tractable. Section 6 states the obvious before anyone assumes it: trademarks are not licensed. Your project's name stays yours.
The generator's job for Apache is precise: the full license text, verbatim, plus the appendix boilerplate with your copyright line filled in for the source-file headers. It also produces a starter NOTICE file when your project needs one — a three-line file that spares you a documentation dive at midnight.
GPL-3.0: copyleft with teeth
The GNU General Public License, version 3, answers a different question than the permissive family does. MIT and Apache ask: what may people do with this code? The GPL asks: what may people do with the software this code becomes? Its answer is the copyleft principle — you may use, study, modify, and redistribute, but any derivative work you distribute must carry the same license and its source code.
“Derivative work” is where the GPL gets its reputation, because the term's boundary is the term's power. Linking, static or dynamic, generally makes a combined work in the GPL's reading; mere aggregation — shipping separate programs on the same disk — does not. Whole careers of forum arguments live inside that distinction, and the license's length is largely spent drawing it carefully.
Version 3, published in 2007, modernized the 1991 original in ways that still matter. It carries an explicit patent grant with the same retaliatory structure as Apache's. Its termination clause has a cure path: violators who stop violating get their license back — provisionally, and permanently after 60 days of good behavior or 30 days after curing a first noticed violation. The anti-tivoization clause requires “Installation Information” for user products, so a router running GPL code can't lock out the modified firmware its users are entitled to install. And Section 7 lists additional terms that may be imposed or removed — the legal mechanism that makes BSD-style conditions compatible inside a GPL work.
The family also comes in calibrations: LGPL-3.0 lets the library stay copylefted while proprietary software links to it, and AGPL-3.0 closes the network loophole by counting “use over a network” as distribution. The generator covers the full line, because “I want the GPL” usually means one of three different licenses once the details surface.
Three families, side by side
The license landscape sorts into permissive (MIT, BSD), formally permissive (Apache-2.0), and copyleft (LGPL, GPL, AGPL). One table holds the decision-relevant differences between the three anchors.
| Question | MIT | Apache-2.0 | GPL-3.0 |
|---|---|---|---|
| How long is the text? | About 170 words | Nine sections plus appendix | The longest of the three |
| Explicit patent grant? | No | Yes, with retaliation | Yes, with retaliation |
| Can derivatives go proprietary? | Yes | Yes | No — derivatives stay GPL |
| Extra files in your repo? | LICENSE only | LICENSE, NOTICE when applicable, file headers | LICENSE plus source availability |
| SPDX identifier | MIT | Apache-2.0 | GPL-3.0-only / -or-later |
| Typical home | Libraries, snippets, small tools | Corporate and foundation projects, SDKs | End-user applications, toolchains |
The BSD licenses sit beside MIT on the permissive end: the two-clause version is functionally its sibling, and the three-clause version adds one condition — the names of contributors can't be used to endorse derived products without permission. The four-clause original, with its advertising acknowledgment requirement, is functionally extinct and best left that way; its advertising clause is the reason it's incompatible with the GPL family, and nothing it does is worth that cost in 2026.
The compatibility matrix, decoded
Licenses mix at the code level according to a fixed set of rules: a permissive grant can flow into a stronger license, never the reverse. Copyleft is sticky by design — it is a one-way valve.
| Combination | Allowed? | What to watch |
|---|---|---|
| MIT code inside a GPL-3.0 project | Yes | MIT's notice condition survives; the combined work is GPL |
| Apache-2.0 code inside GPL-3.0 | Yes | One-way: the combined work takes GPLv3 terms |
| Apache-2.0 code inside GPLv2-only | No | Patent and indemnification terms clash — the FSF's published ruling |
| GPL-3.0 code in a proprietary product | No | Distribution triggers the source-sharing obligation |
| MIT and Apache-2.0 together | Yes | Both permissive; Apache's NOTICE duties still apply |
| BSD-3-Clause in a GPL work | Yes | The non-endorsement condition rides along as a Section 7 term |
Two practical consequences fall out of the valve metaphor. First, an MIT project can absorb Apache-2.0 dependencies only by keeping them at arm's length — separate processes or separate distribution — because MIT cannot relicense what it doesn't own. Second, the direction of ambition matters: if your project might someday be vendored into a GPL codebase, license it MIT or Apache-2.0 and the door stays open. License it GPL-3.0 and that door is a wall, which is sometimes exactly the wall you wanted.
Three repos, three choices
Three realistic projects, three different right answers, and the exact text each one lands on. The names are illustrative; the license wording is the real published wording.
Input
Holder: Dana Whitmore. Year: 2026. License: MIT. Goal: maximum reuse with minimum ceremony.
Output
MIT License Copyright (c) 2026 Dana Whitmore Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Input
Project: telemetry-sdk. Holder: Brightline Labs, Inc. Years: 2024-2026. License: Apache-2.0, appendix boilerplate for source-file headers.
Output
Copyright 2024-2026 Brightline Labs, Inc.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.Input
Project: notepad-next. Holder: A. Osei. License: GPL-3.0-or-later. Goal: every distributed fork stays free software. This is the notice block the generator writes for the README and the About dialog.
Output
notepad-next — a tabbed notepad with session restore. Copyright (C) 2026 A. Osei. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
Notice what the generator did in each case: the right blanks filled, the right blanks left alone, and the surrounding conventions — appendix headers for Apache, the notice line for GPL — handled without a trip to the manual. The library got 170 words. The SDK got a patent pact. The app got a wall with a gate in it.
A name and a year, kept to yourself
A license generator is about the least sensitive tool on this site — the data involved is a name, a year, and a menu choice — and it behaves accordingly: everything runs in the browser tab, nothing is transmitted, nothing is stored, and there is no account to create because there is nothing to attach an account to. The generator works with the network cable pulled, which is either a privacy feature or a Tuesday-night dependency, depending on your Wi-Fi.
The no-login design has a second audience: corporate developers on locked-down machines. A tool that asks for nothing can be opened on a restricted network without a procurement conversation, and a generated license text can travel through Slack, email, and code review without anyone's legal-review tooling noticing that a third party was ever involved in producing it. The license looks exactly like something you typed yourself — because, apart from the standard legal wording, it is.
One caution belongs here even though the tool itself collects nothing: don't paste anything else into any web tool, this one included. A LICENSE file is public by definition; the draft roadmap sitting in the same folder is not, and the habit of pasting repository contents into browser tools deserves more suspicion than it usually gets. If your Pwned Password Checker habit ever finds a credential near your open-source work, rotate it before the push, not after.
License questions, answered plainly
Which open source license should I choose?
It depends on what you want strangers to be able to do. MIT if you want maximum adoption with minimum paperwork — anyone can use, modify, and redistribute your code, including inside commercial products, as long as your copyright notice travels along. Apache-2.0 if you want the same freedom plus an explicit patent grant, which matters for projects likely to attract corporate users. GPL-3.0 if the one thing you refuse to allow is closed-source derivatives — the license forces every distributed modification to stay open under the same terms.
Can I write my own license text instead?
Legally you can — a license is just a conditional permission you grant as the copyright holder. Practically you shouldn't. Custom licenses must be reviewed line by line by every potential user's legal department, most corporate policies only approve licenses from the OSI-approved list, and package registries and license scanners flag unknown texts as risks. The standard texts earned their adoption by being pre-reviewed by thousands of organizations; writing a new one forfeits that entire inheritance.
Do I have to use my real name in the copyright line?
The line should identify the actual copyright holder, which can be your legal name, a pen name you're willing to enforce rights under, or a company. What matters is that the holder can be tied to the work. The year is the year of first publication — 2026 for something you're publishing now — and ongoing projects commonly widen it into a range like 2024-2026 as the code keeps changing.
Can I change my project's license later?
Yes, cleanly, while you are the sole copyright holder — you can reissue the project under any license you like. Once outside contributions exist, every contributor owns copyright in their changes, and relicensing the whole needs their consent (or a contributor license agreement you collected in advance). One escape hatch: MIT- or BSD-licensed contributions can be folded into an Apache-2.0 or GPL-3.0 project, because permissive grants are compatible with stronger terms — the reverse direction is not available.
What is the difference between GPL-3.0-only and GPL-3.0-or-later?
The suffix decides which future versions of the GPL your code can be used under. GPL-3.0-only pins recipients to version 3, forever. GPL-3.0-or-later lets them apply version 4 or later if the Free Software Foundation ever publishes one — useful if you trust the FSF's stewardship, risky if you don't. SPDX treats them as distinct identifiers, and the choice is recorded in the notice line you place after the copyright statement.
Does the MIT License grant patent rights?
Not in so many words. The MIT text grants rights in the software without mentioning patents, and legal scholars have argued for decades about whether an implied license covers patent infringement. In practice most projects treat MIT as patent-risky-but-fine, because patents are rarely asserted over small permissive projects. If patents are a live concern — your project's value is a method, or corporate users ask — Apache-2.0 and GPL-3.0 contain explicit, enforceable patent grants and were drafted with that question in mind.
Where does the license file go, and what should I name it?
LICENSE or LICENSE.txt in the repository root, plain text, exactly as published. GitHub and GitLab detect that filename and display a badge on your repo's home page. Apache-2.0 projects add a NOTICE file at the root when one applies and the short header boilerplate in each source file; GPL-3.0 projects ship the full license text and commonly add the one-paragraph notice in a README or the program itself. Package metadata — package.json, pyproject.toml, Cargo.toml — should carry the SPDX identifier so registries stop warning about a missing license field.
Who generates licenses at midnight — and what they generate next
First-time open-source maintainers are the core audience — the developer whose side project outgrew its “free for anyone, I guess?” README line the week someone asked to vendor it. Corporate developers arrive with the deadline inverted: the open-sourcing decision was made upstairs, and the LICENSE file is the last checkbox before the public repo goes live. Students generating a license for a final project that will live on GitHub longer than the grade will. Plugin authors satisfying a registry's metadata linting. And a steady trickle of people who inherited an unlicensed codebase and are regularizing it before accepting their first outside contribution — the one moment relicensing is still easy.
The repo-starter kit tends to get generated in one sitting: the license from this page, the ignore file from the .gitignore Generator, and — once the project starts scheduling anything — the expression from the Cron Expression Builder. Each one is a small legal or operational document that took a standards body years to settle and takes a form two minutes to fill. That asymmetry is the entire genre of developer tooling in miniature: the boring parts, done exactly right, so the interesting parts get the evening.
License texts and where they live
Sources and further reading
- Open Source Initiative — the approved-license list and canonical texts(opensource.org)
- choosealicense.com — GitHub's plain-English license guidance(choosealicense.com)
- Apache License 2.0 — full text, FAQ, and appendix boilerplate(apache.org)
- GNU GPL v3.0 — official text and how-to-apply guide(gnu.org)
We cite primary sources (standards bodies, government agencies, official documentation) wherever they exist so you can verify every number on this page yourself.