If you want one answer to how to choose an open source license: pick a permissive license such as MIT or Apache 2.0 when you want the widest adoption, and pick a copyleft license such as GPL or AGPL when you need every derivative to stay open. That single choice drives most of the rest. This guide walks through the whole decision for civic and public-sector apps, and none of it is legal advice — your counsel reads the fine print, not me.
Civic software has an unusual constraint that trips up teams coming from commercial product work. Your user is often a neighbouring municipality, a contractor bidding on your open data contract, or a volunteer hackathon team who needs to fork your code on a weekend. Wide adoption matters more here than anywhere else in software, which pushes most teams toward permissive terms by default.
Still, a parking-data collector that someone else forks and turns into a paid compliance product is a real scenario in this field, and a permissive license does nothing to stop it. Knowing how to choose an open source license well means holding both of those facts at once.
Table of Contents
- What You Need
- A written statement of what the app does
- A list of the people who have touched the code
- A dependency inventory
- A distribution plan
- Step-by-Step
- 1. Define How the App Will Be Used
- 2. Separate Required Permissions From Desired Ones
- 3. Check Dependencies and Compatibility
- 4. Compare Common Open Source Licenses
- 5. Test the Choice Against Real Scenarios
- 6. Add the License and Document the Decision
- 7. Review Changes as the Project Evolves
- Common Mistakes
- Choosing by popularity
- Confusing open source with public domain
- Publishing with no licence at all
- Inventing your own terms
- Licensing code you do not own
- Ignoring what you copied in
- Frequently Asked Questions
- Should I use MIT or GPL?
- What is the difference between MIT and Apache 2.0?
- Do I need a license if my repository is public?
- Can I change my open source license later?
- Do I own the copyright to code I wrote at work?
- Which license should I use for a hosted civic SaaS?
- Conclusion
What You Need
Before you read a single license text, gather four things. Licensing decisions go wrong when people start from the license list instead of the project itself.
A written statement of what the app does
One paragraph covering the deployment target, the user base and the operating model. Is this a mobile app on the app stores, a self-hosted piece of municipal software, or a hosted service your city runs for other cities? Hosting changes the licensing calculus more than anything else, because AGPL’s network clause only matters for the hosted case.
A list of the people who have touched the code
Full-time staff, agency subcontractors, contract developers, volunteer contributors from events, and any AI-assisted code your team pasted in. Copyright ownership is the quiet killer in civic projects, where code often starts inside one agency’s IT department and ends up published by a different one. Confirm in writing who holds the rights before you attach any license to it.
A dependency inventory
Every imported library, framework, template, bundled data file, icon set and font. A package manifest and lockfile get you most of the way there. Compatibility problems with copyleft show up in this list, not later.
A distribution plan
Where the code will live, who will download or clone it, whether you will publish it to a package registry, and whether a vendor will redistribute it inside a commercial product. Each channel carries a different set of obligations, and a license that is fine for one can be wrong for another.
Step-by-Step
1. Define How the App Will Be Used
Write down who uses the app, how they get it, whether they will modify it, and whether you expect anyone to run a private fork. Then answer one harder question: is this staying open forever, or is it source-available with a commercial layer planned later?
That answer matters because permissive and copyleft licences behave completely differently on hosted services. A city that releases a web portal under MIT can be undercut by a company who hosts a competing version without publishing a single line back. AGPL was written specifically to close that gap for network use.
Government procurement adds a wrinkle. Many tender documents require a specific licence or a perpetual, irrevocable grant to a list of downstream agencies. Check the procurement rules before you pick, because a licence you cannot change later is a requirement, not a preference.
2. Separate Required Permissions From Desired Ones
Split your wish list into two columns. The first column holds the permissions you actually need: commercial use, modification, redistribution, sublicensing to customers who embed your code, and the right to run it as a hosted service. Almost every OSI-approved licence grants all five.
The second column holds the conditions you want attached. Attribution and copyright notice retention are cheap and standard. Explicit patent grants and patent termination are less common and matter more than most beginners expect, particularly if your employer or agency may patent something it built with public money. Trademark rights are granted by almost no open source licence, which is why nobody is legally obliged to keep your project name on a fork.
Once the two columns are separated, the choice usually narrows to two or three candidates instead of nine.
3. Check Dependencies and Compatibility
Run a licence scan over the repository before you commit, and read the actual output rather than the summary. A dependency under GPL or AGPL does not automatically poison your project, because combining code is different from distributing a combined work, and the boundary is genuinely contested. What it does mean is that the moment you ship a combined binary or bundle, reciprocal obligations can attach to the whole.
Two practical rules cover most cases. Never combine an AGPL dependency into a proprietary hosted product without advice. And never copy a file out of another repository without keeping its header notice — the BSD-3-Clause header that came with the file does not stop being BSD-3-Clause because you pasted it somewhere else. This shows up constantly in forums, and it is not an edge case.
4. Compare Common Open Source Licenses
Here is the short version of the seven licences that cover almost every civic project. Each row is the practical difference, not the legal text.
| License | Commercial use | Closed-source derivative | Attribution | Patent grant | Copyleft strength | Best fit |
|---|---|---|---|---|---|---|
| MIT | Yes | Yes | Required | No | None | Libraries, hackathon projects, anything aiming for maximum adoption |
| Apache 2.0 | Yes | Yes | Required, plus NOTICE | Yes, with termination | None | Corporate and agency projects where patent exposure matters |
| BSD 3-Clause | Yes | Yes | Required | No | None | Systems software and projects already shipping in that ecosystem |
| MPL 2.0 | Yes | Yes, for unmodified files | Required | Yes | Weak, file level | Larger codebases where you want changes to your files shared back |
| LGPL | Yes | Yes, with relinking rights | Required | Yes | Weak, library level | Shared libraries that must stay replaceable |
| GPLv3 | Yes | No, must stay GPL | Required | Yes | Strong, whole program | Tools and utilities you want forks to keep open |
| AGPLv3 | Yes | No, including over a network | Required | Yes | Strong, plus network use | Hosted civic services where cloud forks are the real risk |
MIT and Apache 2.0 are the two defaults, and the gap between them is narrower than most searches suggest. MIT is shorter, requires nothing but the copyright notice, and carries no patent language at all. Apache 2.0 adds an explicit patent licence from contributors, a patent termination clause if that contributor is sued over the patent, and a NOTICE file convention. If your agency might be building something patentable, that clause is worth the extra length. If you just want the shortest file that works, MIT is fine.
The BSD licences sit alongside those two. BSD 3-Clause adds a no-endorsement clause that stops anyone using your contributor’s name to promote a derived product, which matters for public bodies whose names carry weight.
MPL 2.0 and the LGPL are the middle ground: copyleft that applies to specific files or to the library rather than the whole program. If you modify an MPL file, you publish that file. Files you added around it stay yours. For a shared library like a routing engine or a schema validator, that is usually the balance that keeps contributions coming without handing your whole product to the community.
GPLv3 and AGPLv3 are the strong copyleft options. GPLv3 requires that distributed derivatives carry the same licence. AGPLv3 adds the condition that users interacting with the software over a network are entitled to the corresponding source, which is why it turns up in hosted products and rarely in libraries.
If you are unsure about the practical split, the well-known lineage helps: Babel, Rails and .NET are MIT; Ansible and uBlock Origin are GPLv3. Ecosystem convention is a real tiebreaker in the final round, because matching what the surrounding community already uses removes friction for contributors and for lawyers reading your file later.
5. Test the Choice Against Real Scenarios
Run four scenarios against your shortlist and count the conflicts each one creates.
A municipal pilot where two departments co-develop the tool and one may fork it for local rules. Permissive wins easily, and you avoid any argument about whether the fork is a derivative work.
A private contractor who wants to fork your code into a commercial product they resell. Permissive permits it with attribution. Copyleft forbids shipping it closed, which protects your city’s investment but may end the conversation.
A commercial API built on your open core. Here the AGPL question becomes real. If the hosting provider can run your code for paying customers without publishing changes, AGPL is the only OSI-approved licence that reaches that case.
A mobile app on the store. The app binary is distributed, so GPL obligations attach to the distributed app. Most civic app teams discover this late and settle on permissive for that reason alone.
A collaboration project with volunteers from a hackathon. Permissive lowers the barrier to contributing because nobody needs to sign a contributor agreement or accept reciprocal terms on their own side project.
6. Add the License and Document the Decision
Put the exact, unmodified licence text in a file named LICENSE at the root of the repository. Match the filename to the convention: LICENSE, LICENSE.md or LICENSE.txt all work, but mixed casing confuses automated detection. If you use the GitHub license picker on a new repository, it creates the file and inserts the year and copyright holder for you, which avoids the two typos that show up most often — a missing year and a wrong name.
Then record the licence as structured data. Add the SPDX identifier — MIT, Apache-2.0, BSD-3-Clause, MPL-2.0, LGPL-3.0-only, GPL-3.0-only or AGPL-3.0-only — to your package manifest so scanners and registries can read it. Add a short notice line to the README naming the licence and pointing at the LICENSE file.
Write a short decision record next to it: the date, who decided, the two or three candidates that were considered and why the chosen one won. Six months later, when a vendor asks why you did not use Apache 2.0, that file answers the question without a meeting. This is also where you note who owns the copyright and whether contributions come in with assignment or a contributor agreement.
7. Review Changes as the Project Evolves
Relicensing is harder than people expect, and the fear of it is the single biggest emotional block in forum threads about licence choice. You can change the licence for code you still hold rights to, but you cannot revoke the old grant. Every copy already distributed stays under the old terms, permanently. Contributors who sent you a patch usually gave you rights only under the licence in force at the time, so moving to a stricter copyleft licence needs their explicit permission, and moving to a stricter one often requires them to sign something.
The safer pattern is dual licensing: publish under an open licence and separately offer commercial terms to anyone who needs an exception. That is how several large civic-adjacent projects fund maintenance without abandoning openness. It does add real work, since someone has to operate two licence tracks and answer both enquiries.
Set a review trigger rather than a review date. Re-evaluate when a large company contributes, when you add paid hosting, when a dependency’s licence changes, when your legal structure changes, or when someone files a patent claim touching your code. Each of those is a moment where the old choice was made under different conditions.
Common Mistakes
Choosing by popularity
MIT is common because it is easy, not because it is right for your project. Popularity is a decent tiebreaker at the end of the process, and a poor substitute at the start.
Confusing open source with public domain
Open source still means the copyright holder keeps ownership and grants permissions on conditions. Public domain means nobody owns it, which in practice only CC0 and the Unlicense get close, and some jurisdictions reject the concept entirely. If you want maximum freedom including patent claims, say so explicitly; do not assume a permissive licence gives it to you.
Publishing with no licence at all
This one surprises people. Without a licence, default copyright applies: nobody may legally copy, modify or redistribute your code. A public repository is not a licence, and a comment saying “feel free to use this” is not one either. If you have already published without a licence, adding one later does not reach anyone who copied the code before.
Inventing your own terms
Writing a bespoke licence creates legal busy work and will fail your organisation’s procurement review. Pick an OSI-approved licence and set the project-specific rules in contribution docs and a code of conduct instead.
Licensing code you do not own
Work made in the course of employment usually belongs to the employer, and client work usually belongs to the client under a contract. Publishing it without written authorisation is a real exposure, not a technicality. Agencies that commission code frequently ask for it to be released under a named open source licence — that clause should be in the contract, not negotiated after delivery.
Ignoring what you copied in
Stack Overflow snippets, generated boilerplate, tutorial code and AI-assisted output all carry their own terms or none. A repository scan does not catch a pasted function in a single file. Keep a note of provenance as you go.
Frequently Asked Questions
Should I use MIT or GPL?
Use MIT if you want the widest adoption and do not mind closed-source derivatives, which is the default for libraries, mobile apps and hackathon projects. Use GPL when the thing you actually care about is that anyone who modifies and distributes your code releases their changes. The honest shortlist for most civic apps is MIT or Apache 2.0, and the choice between them usually comes down to whether you want the Apache patent grant. Pick one deliberately rather than by habit.
What is the difference between MIT and Apache 2.0?
Both allow commercial use, modification and closed-source derivatives, and both require attribution. Apache 2.0 is longer because it adds an explicit patent licence granted by contributors, a clause that terminates that patent grant if the contributor is sued over the patent, a NOTICE file convention and a no-endorsement clause. MIT says nothing about patents at all. Choose Apache 2.0 where patent exposure is plausible, MIT where you want the shortest file.
Do I need a license if my repository is public?
Yes. A public repository has no licence attached by default, which means default copyright applies and nobody may legally copy, modify or redistribute your code. GitHub’s Terms of Service do not grant reuse rights. Adding a licence later does not retroactively cover copies made before it existed, so add the file before you share the link rather than after the first fork.
Can I change my open source license later?
Partly. You can apply a new licence to code you still control, but you cannot withdraw the old grant: every copy already distributed stays under the old terms permanently. Contributors who sent patches typically only granted rights under the licence in force at the time, so a move to a stricter licence requires their permission. Dual licensing from the start avoids some of this friction.
Do I own the copyright to code I wrote at work?
Usually not, and this is the most common mistake in public-sector projects. Work created in the course of employment normally belongs to the employer, and contracted work usually belongs to the client under the contract terms. Publishing such code without written authorisation creates real exposure. If your agency wants to publish, put an explicit open source release clause in the contract and get it signed before anyone writes code.
Which license should I use for a hosted civic SaaS?
MIT or Apache 2.0 if you want other providers to build on it freely, which is usually the right call when the goal is wider municipal adoption. AGPL 3.0 if the thing you fear is a hosted competitor running your code without contributing changes back, because its network clause extends the source obligation to software used over a network. AGPL also makes some corporate adopters and contributors nervous, which is a real cost to weigh.
Conclusion
Start by writing down your distribution model, because open source versus hosted decides more than the licence name does. Then scan dependencies and confirm in writing who holds the copyright. From there, shortlist MIT or Apache 2.0 and treat copyleft as a deliberate choice you make only when reciprocal release is the outcome you actually want.
None of this is legal advice. If your project involves corporate contributions, paid hosting or patent exposure, take the written decision record to a lawyer before you publish.
