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:
- An open source licence (CC BY-NC-SA) for non-commercial use
- A commercial licence for businesses that want to use the code in commercial products
This model is well-established in the industry. MySQL, Qt, and many others use variations of it. The open source version drives adoption and community. The commercial licence generates revenue.
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. It requires that anyone who runs a modified version of your software as a service must also open-source their modifications. This prevents 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.