Building in Public | Choosing a Software License
- erinvh620
- Aug 27
- 12 min read
Updated: Sep 17
TL;DR I thought choosing a software license would be a quick admin task — instead, it made me rethink what open source really means, and in the end I embraced the MIT License.
I’m ashamed to admit I know almost nothing about software licenses. I’ve seen the MIT license at the top of countless files. I’ve heard of the GNU license. The Apache license rings a bell. But beyond the names, I couldn’t tell you much.
Throughout my career, I've worked on proprietary software, and so licenses didn't come up in my day-to-day. I probably should have learned about them earlier, but with so much else to learn and so much work to do, software licensing was an easy topic to push aside.
Now, I finally have the time to dig in.
This post is part of my Building in Public series, where I’m documenting my journey creating an iOS app. If you’d like some background, you can start with the first post: I’m Finally Creating My Own App.
Do I need to license my code?
The first question I want to answer is simple: Do I need to license my code?
While taking a screenshot of GitHub for this post, I noticed a link: About Licenses. I clicked and quickly learned that if you don’t license your code, default copyright laws apply. That means you keep all rights to your code, and no one else may legally reproduce, distribute, or create derivative works from it.
GitHub’s docs led me to another link (opensource.guide/legal), where I learned that even cloning a repository counts as “reproducing” it. In other words, without a license, other developers can’t legally clone my repository — which would make it difficult for them to contribute.
I don’t expect many contributors — maybe none at all — but I want to make contributions possible. To do that, I’ll need to license my codebase. Question answered.
What do I need in a software license?
When creating a new repository on GitHub, the license drop-down menu makes it clear there are plenty of options. My app isn’t cutting-edge, and my reasons for building it — learning and creating a portfolio piece — aren't groundbreaking. So, I’m confident there’s a license already out there that fits my needs.
So the question now is: what do I need from a license?
I want other developers to be able to contribute to my codebase.
I’d love for people to point out where my code, tooling, or workflows could be better. I want to learn from others, and the last thing I want is a legal barrier stopping someone from sharing their feedback.
I don't want someone else to profit from the code I write.
That would feel unfair and demotivating. I’m not putting in the work so someone else can cash in on it — if there’s money to be made, I feel it should come back to me.
That said, if someone used my code in a free, open-source application and gave me credit, I’d probably be fine with it. I suppose it would reflect well on me if my code made another product better.
(My stance on this point will change before the end of this post.)
I don't plan to monetise.
Right now, I don't have any definitive plans to monetise. I plan to release the app for free to keep the barrier to entry low — more users means more feedback, which means faster learning and improvement.
If, after 6–12 months, the app gains traction, I might consider monetisation. However, if others contribute code, it wouldn’t feel right to profit without sharing, so I’d have to find a way to compensate them, and that could be complicated.
Realistically, though, both contributors and traction feel unlikely right now. So I’m taking the advice of Jason Cohen (a founder I follow on LinkedIn and whose posts I enjoy): don’t spend time solving problems you might never have.
Keeping all that in mind, I’m ready to explore some common software licenses to get a sense of what’s out there.
The 5 Most Popular Open-Source Licenses
According to ChatGPT, the five most popular open-source software licenses are:
the MIT License
the Apache License 2.0
GPL v3
the BSD 3-Clause License
Creative Commons
All of these are listed in the license drop-down menu when creating a new repository on GitHub. Let's talk through these five licenses.
If you just want the big picture and don’t care about license details right now, feel free to skip to the next section, "Learnings".
The MIT License
Extremely permissive — anyone can use, copy, modify, distribute, or sell your code, as long as they include your copyright and the MIT license. There’s no warranty or liability protection.
This is one of the simplest and most permissive open-source licenses. It basically says: “Do whatever you want with this code — just give credit, and if it breaks, that’s on you.”
I'm still a bit foggy on what each of the other permissions means, so let's talk through some concrete examples for each. If these are terms you are already familiar with, feel free to skip down to the "Apache 2.0" section.
📝 Copy
Copying is the most fundamental act — almost everything else (use, modify, distribute, sell) involves copying at some level.
Examples:
Forking or cloning my repo (copies it to their account or machine)
Downloading a ZIP of my project
Copying snippets of my code into another codebase
Compiling my code and shipping the resulting app (a binary copy of my source)
⚙️ Use
Using means taking your code and running it as-is or making it part of something else.
Examples:
Embedding my project as a module or package in another app
Running my code internally at a company (e.g. on a knitting shop’s internal system)
Learning from it or copying small pieces of logic into their own project
Automating tasks behind the scenes with my code
✍️ Modify
Modifying means changing your code in any way, big or small.
Examples:
Tweaking how my calculator rounds numbers
Updating the UI or rearranging the layout
Adding new features (like a crochet mode)
Refactoring for maintainability
Porting from Swift to Kotlin or JavaScript
📦 Distribute
Distribution means sharing your code (or anything built from it) with others.
Examples:
Uploading my code to a different GitHub repo
Publishing my code as a Swift Package or CocoaPod
Including my code inside a larger project and sharing that
Shipping an app built from my code on the App Store
Even giving someone my code on a USB stick
They just have to include your copyright + license notice.
💰 Sell
Selling doesn’t mean selling your repo directly — it means using your code inside something they sell.
Examples:
Building my code into an app and charging £2.99
Forking my code, adding features, and selling it as their own app
Bundling my code inside a larger paid toolkit
Offering paid support, training, or customisations
Under MIT, commercial use is fully allowed — as long as they credit you and include the license.
⚠️ No Warranty or Liability
The MIT License also includes a broad disclaimer: “Here’s my code. Use it at your own risk.” This means:
If someone uses my code and it breaks something, they can’t sue my.
If my code has bugs or security holes, I'm not on the hook to fix them.
I'm not promising it’s fit for any particular purpose.
This clause is what lets hobbyists and indie devs share code without risking legal trouble.
✅ Bottom line: The MIT License is short, permissive, and business-friendly — but it does allow others to profit from my work.
Apache License 2.0
Very similar to MIT — permissive, allows commercial use — but also includes explicit patent protection.
Like the MIT License, Apache 2.0 allows others to use, copy, modify, distribute, and sell your code, provided they include the copyright and license. The key difference is patents. Apache 2.0 explicitly says that contributors grant you a license to any patents they hold — including ones they might obtain later — if those patents cover the code they contributed.
Example:
Someone contributes a new algorithm to my knitting calculator.
They either already hold a patent on that algorithm or they get one in the future.
By contributing under Apache 2.0, they automatically give me (and anyone who uses my code) permission to use that patented algorithm, and they can’t later sue for patent infringement.
MIT doesn’t mention patents at all, which means it offers no built-in protection if patented code accidentally makes its way into my project.
🤔 Why use MIT instead of Apache 2.0?
On paper, Apache 2.0 looks strictly better: it gives all the freedoms of MIT plus explicit patent protection.So why does anyone still choose MIT?
A few reasons:
It’s shorter and simpler.
The MIT license is only about 170 words (roughly 1/10 the word count of Apache 2.0). Developers can read and understand it instantly, which makes it less intimidating for small projects.
It has less legal “noise.”
Apache 2.0 is much longer and more formal. Some developers worry that the heavier legal language might scare off casual contributors or hobbyists.
It doesn’t require managing a NOTICE file.
Apache 2.0 requires preserving and updating a NOTICE file if one exists. MIT doesn’t, which makes it slightly easier to maintain.
It’s the default choice on GitHub and in many communities.
Because it’s so common, using MIT signals “this is simple and safe to use” and avoids raising legal questions.
✅ Bottom line: MIT is popular because it’s fast, familiar, and frictionless, while Apache 2.0 is chosen when you specifically want patent protection or corporate-friendliness.
I’ll admit I’m still not entirely convinced — using MIT when I could use Apache feels like leaving myself exposed to a host of potential legal issues… but given that huge projects like React, Rails, and jQuery all use MIT, it’s clearly trusted and battle-tested.
GPL (GNU General Public License) v3
A “copyleft” license — anyone who distributes your code (or derivatives of it) must also make their source code available under GPL v3.
GPL v3 is very different from MIT or Apache. Instead of being permissive, it’s copyleft: if someone uses your code in their project and distributes it, they must also open source their entire project under the same license.
This ensures your code (and anything built on top of it) stays open source forever — which makes GPL popular for projects focused on protecting user freedoms.
But it’s much less business-friendly, because companies can’t use your code inside proprietary or closed-source software.
⚖️ How copyleft works
If someone uses your code internally (never distributing it), they can keep their code closed.
If they share, sell, or publish software that includes your code, they must:
release their entire project’s source code
license it under GPL v3 as well
In short: distribute → must open source.
🛡️ Extra protections
GPL v3 also adds strong legal protections:
Anti-tivoization: stops companies from locking your software to specific hardware
Patent protection: contributors grant patent rights for their code (similar to Apache 2.0)
These features make GPL v3 more complex but also more protective of user freedoms.
✅ Bottom line: GPL v3 guarantees your project stays open source, but it makes your code incompatible with proprietary software, so companies are less likely to use or contribute to it.
BSD 3-Clause License
Very similar to MIT — permissive, allows commercial use — but adds a “no endorsement” clause.
The BSD 3-Clause License is another permissive license, like MIT. It lets others use, copy, modify, distribute, and sell your code as long as they include your copyright and license.
The key difference is a small but important restriction: they can’t use your name or project name to promote their version without permission.
🚫 No Endorsement
Example:
Someone forks my knitting calculator and adds new features.
They release it as a paid app.
Under BSD 3-Clause, they can’t advertise it as “Approved by Erin’s Knitting Calculator™” unless I explicitly say so.
MIT doesn’t say anything about endorsements, so in theory someone could imply your approval even if you don’t support their version. I guess this is kind of the opposite outlook of "all publicity is good publicity."
✅ Bottom line: BSD 3-Clause is essentially MIT with an added “don’t use my name to market your fork” protection. It’s a good option if you want a permissive license but care about avoiding unwanted brand association.
Creative Commons (CC0 / CC-BY)
Not designed for code — best suited for things like documentation, artwork, or data.
Creative Commons licenses are widely used, but they’re generally not appropriate for software. GitHub includes them in its license dropdown because people sometimes publish non-code content (like documentation, datasets, or designs) on GitHub.
Summary
After exploring these five licenses, I feel like I'm starting to understand the landscape a bit:
MIT and BSD 3-Clause are simple and permissive.
Apache 2.0 is just as permissive, but with added patent protection.
GPL v3 enforces openness through copyleft.
Creative Commons is better suited for non-code content.
With that foundation in place, I’m ready to decide which license makes the most sense for my knitting calculator project.
Learnings
Now that I’ve learned about software licenses, I realise how careless I’ve been about pulling dependencies into past projects. I’ve never checked a dependency’s license in my life!
I thought I was getting by just fine without this knowledge — but it turns out I was just ignoring a risk I didn’t know was there.
Do I need a CLA?
While reading this guide on legal topics in open source, I came across the concept of a CLA — a Contributor License Agreement.
The licenses I explored above are about how others can use my code (often called outbound licensing). A CLA is about how I can use code contributed by others (inbound licensing).
From what I’ve read, a CLA would be overkill for a small project like mine. Still, I’m glad I know about it now — it’s the kind of concept that might be useful down the road.
If you’re working on a project where a CLA might be relevant, this guide is a great place to start your research.
Rethinking What “Open Source” Means
When I started looking at licenses, none of them seemed to fit.
I didn’t want others profiting from my work, so I ruled out the permissive licenses — MIT, Apache 2.0, BSD 3-Clause. I assumed I needed something stricter, like GPL v3.
But GPL wouldn’t really fit either. I don’t want to force people to open-source their projects just because they used my code. I’d want credit, and I’d want their app to be free, but that’s about it. And GPL doesn't prevent commercial use anyway.
And as it turns out, there’s no license like that — because it wouldn’t be considered “open source” at all.
According to the Open Source Initiative (OSI), all open-source licenses must allow commercial use. If you block monetisation, your project becomes source-available instead — the code is visible, but not truly open.
This was a bit of a shock. I hadn’t realised that "no discrimination against fields of endeavor" meant not preventing open source from being used commercially. I also hadn't even seen my own desire to stop others from using my code commercially as gatekeeping or deciding whose motives are “pure enough.”
So I started reading more about the open-source philosophy, and I realised that allowing commercial use might not be the threat I imagined. When it comes to commercial use, there are two scenarios I was worried about:
Someone taking my code, modifying it, and profiting financially.
For example, they might copy my code, but modify the UI, and maybe their UI would be better and their app would be far more popular.
Interestingly, when I dig into this scenario, it doesn't seem to be the financial part that bothers me: it's the idea of someone else being more successful with my idea than I am. I'm afraid that would make me look silly.
Someone taking my code, not modifying it at all, and charging for it.
I would feel so much despair at the money I left on the table that they were now enjoying.
However, the more I think about it, the more I think I need to change my perspective on these two scenarios. If someone else creates something better, I can simply learn from that! I don't need to feel silly. And I suppose that if someone charges for an exact replica of my app, I'm supposed to believe that market forces will prevail and people will discover my free version and download that instead. I must admit . . . I don't know how fully I trust "market forces". What if that other person has tons of money for advertising? Or already has a huge and loyal following?
I’ve also come to appreciate a few other open-source principles along the way:
Collaboration multiplies value. Someone might fork my calculator and add something brilliant — I could gain ideas, exposure, or inspiration.
Reputation matters more than ownership. The more widely my code is used, the better I look. That’s new territory for me, but it’s growing on me.
Code is cheap, execution is hard. Anyone can copy code; few will polish it, support it, and keep it alive. That, I already believe.
Together, these ideas have shifted my perspective: what I saw as “risk” might actually be "learning opportunities".
My Final Decision: the MIT License
I’ve decided to go fully open source. I’m choosing the MIT License — the simplest and most permissive license of all.
At first, the idea of someone polishing up my code and profiting from it felt threatening. But I'm beginning to see it differently: if that happens, it would mean my work had real value — and it could spark something bigger than me.
In the open-source world, your strength isn’t ownership. It’s reputation, creativity, and persistence. I’m still getting used to this way of looking at things.
What a journey this has been. I thought this would be five minutes of skimming a few licenses and picking one. Instead, I ended up questioning my assumptions, rethinking my values, and learning more philosophy than I expected.