--- title: "Open Source Licensing: What I Learned the Hard Way" description: "Hard-won open-source licensing lessons: why MIT was the wrong default, the move to CC BY-NC-SA, dual licensing, AGPL for SaaS, and why a CLA matters." date: 2025-02-02 category: Engineering readingTime: "3 min read" --- I have open-sourced several projects. Each time, the hardest decision was not what to build. It was how to license it. This post is about the licensing mistakes I made, the decisions that worked, and how I think about open source licensing now. ## The Default Trap: MIT for Everything When I first started publishing code, I put MIT on everything. It is the default choice. It is permissive. GitHub suggests it. What could go wrong? What went wrong: someone took code from one of my projects, built a commercial product on top of it, and sold it. Legally, they were within their rights. The MIT licence explicitly allows this. But it felt wrong. I had spent months on that code, and someone was profiting from it without contributing anything back. This is not a criticism of MIT. It is the right licence for many situations. But it is not the right licence if you care about how your code is used commercially. ## Choosing CC BY-NC-SA For several of my projects, I switched to Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA). This licence allows: - Sharing and adapting: anyone can use, modify, and redistribute - Attribution: they must credit the original author - NonCommercial: they cannot use it for commercial purposes without permission - ShareAlike: derivatives must use the same licence The NonCommercial clause was the key. It lets individuals, students, and hobbyists use the code freely while requiring commercial users to get a separate licence. ## The Dual Licensing Model The natural extension of CC BY-NC-SA is dual licensing: 1. An open source licence (CC BY-NC-SA) for non-commercial use 2. A commercial licence for businesses that want to use the code in commercial products This model is well-established in the industry. MySQL and Qt have used variations of it for years. The open source version drives adoption and community. The commercial licence generates revenue. The mechanism that makes it work is copyright ownership: because you hold the rights to the whole codebase, you can offer the same code under two different licences at once. A user picks whichever terms suit them. That is also exactly why the CLA further down this post is not optional once you accept outside contributions. At HMD Developments, the team uses this model for several internal tools we have published. The open source version is full-featured. The commercial licence adds support, priority bug fixes, and the legal right to use it in commercial products. ## Lessons I Learned ### Choose Your Licence Before Writing Code The licence affects your contributor agreements, your partnership options, and your exit strategy. Deciding after the fact, especially if you have contributors, creates legal complexity. ### CC Licences Are Not Ideal for Software This is a nuance I learned too late. Creative Commons explicitly states that their licences are not designed for software. They are designed for creative works. For software, they recommend using licences like GPL, LGPL, or AGPL instead. CC BY-NC-SA works for my use case because my projects include significant creative content alongside code. But for pure software, a purpose-built software licence is better. ### AGPL for SaaS Protection If your open source project could be deployed as a service (SaaS), consider AGPL. The ordinary GPL is triggered by *distribution*: if you never ship the binary, you never have to share the source. Running software over a network does not count as distribution, so a company can take GPL code, host it as a service, and owe nothing. AGPL closes that gap by treating network interaction as a trigger: anyone who runs a modified version as a service must offer its source to the users of that service. That is what shuts the cloud loophole where companies take open source code, run it as a service, and contribute nothing back. ### CLA Matters for Future Flexibility A Contributor Licence Agreement (CLA) ensures that you retain the ability to change the licence in the future. Without a CLA, every contributor retains copyright over their contributions, and changing the licence requires unanimous consent from all contributors. ## The Human Side Open source licensing is not just legal. It is philosophical. Every licence represents a set of values: - MIT and BSD: maximum freedom. Build whatever you want. - GPL and AGPL: freedom with responsibility. If you benefit, share back. - CC BY-NC-SA: freedom for the community. Commerce requires partnership. There is no universally right answer. But there is a personally right answer, and it depends on what you are trying to achieve with your code. I open-source code because I believe in knowledge sharing. But I also run a business. Dual licensing lets me do both.