On this page
When we decided to release CrizaVoise, our billing app, as open source, we expected to pick a licence and be done. It took longer than that. The licence on our own code turned out to be the easy part. The work was in the code we had not written: the original project we started from, and the 158 packages the app depended on.
This is what we checked and what we changed. It describes our release, not legal advice, so have a lawyer look at your own.
Start with what you inherited
CrizaVoise began as a fork of Invoiso, a billing app by Anoop P released under the MIT licence. MIT is permissive: it lets you use, change, sublicense and sell the code, as long as the copyright and permission notice stays with it.
That gave us two obligations and one freedom. We had to keep Invoiso's notice, which we did in the repository's third-party notices and on the app's open-source licences screen. We had to be honest about the origin, which we are, in the README and on our product page. And we were free to release our own work, and the combined app, under a different licence.
Why Apache 2.0 rather than MIT?
MIT would have been simpler. We chose the Apache License 2.0 for three things it adds.
- A patent grant. Section 3 gives everyone who uses the code a licence to any patents the contributors hold on it. Business users care about this, even if they never read it.
- A NOTICE file that must travel. Under section 4(d), anyone who redistributes the work must keep the NOTICE file. We used ours for the credit we ask for: "Based on CrizaVoise by Criza Labs (https://criza.dev)". MIT only requires the licence text, which nobody sees.
- Your name stays yours. Section 6 says the licence does not grant permission to use the licensor's trade names or trademarks. Anyone can fork the code, but not call their fork CrizaVoise.
A copyleft licence such as the GPL would have forced anyone who ships a changed version to publish their source. For an app we want shops and developers to adopt freely, including inside commercial products, that was the wrong trade.
Then check every dependency
A Flutter app pulls in a lot of packages, and each has its own licence. We wrote a small script that read the app's lock file, looked up every package's licence and wrote a report. Of 158 packages, three needed a decision.
| Package | Licence | What it did | What we did |
|---|---|---|---|
| fuzzywuzzy | GPL-2.0 | Fuzzy matching in help search | Wrote our own similarity scoring, with tests |
| Syncfusion PDF viewer | Commercial | Previewing PDFs | Switched to the preview in the printing package (Apache 2.0) |
| flutter_esc_pos_utils | LGPL | Formatting thermal receipts | Wrote our own ESC/POS encoder |
The GPL package was the clear problem. Distributing an app that contains GPL code brings the whole program under the GPL, and the Apache License 2.0 is not compatible with GPL version 2.
The commercial package needed a paid licence above a revenue threshold. That might be fine for one shop, but not for a project anyone is meant to be able to fork and ship.
The LGPL package is the subtle one. The LGPL lets you use a library in other software if users can swap in their own version of it. A Flutter release build compiles all the Dart code into one binary, which makes that hard to honour. Replacing it was simpler than arguing about it, and our encoder also stopped sending two stray bytes that printed dots on some printers.
After the changes, the report listed 145 packages: 88 BSD, 40 MIT, 10 Apache 2.0, 5 from the Flutter and Dart SDK, and 2 MPL 2.0. The MPL is a file-level copyleft, and those two Linux-only packages are used unchanged, which the notices file records.
Write down how people may use the name
Open source covers code, not brands. We added a short TRADEMARKS.md that says what people may do (say their project is based on CrizaVoise, write reviews, pass on official builds) and what they may not do without asking (ship a changed version under our name or logo, or suggest we endorse it). A fork gets its own name and icon, keeps the licence and notice files, and shows the credit line.
That one file avoids the most common trouble with popular open-source apps: copies in app stores that look like the original.
Make it easy to credit you correctly
Credit only happens if it is easy. We put the exact credit line in the NOTICE file, the README and the app's About screen, and added a CITATION.cff file so GitHub shows a "Cite this repository" button. On the CrizaVoise website, a page explains in plain words how to fork it.
A checklist before you open-source anything
- Find the licence of everything you started from, and keep its notice.
- Choose your licence for what you want others to do: permissive to spread it, copyleft to keep changes open.
- Scan every dependency and decide on each GPL, LGPL, AGPL or commercial one before release.
- Remove secrets, private keys and internal URLs from the code and its history.
- Add LICENSE, NOTICE (for Apache 2.0) and a trademark note.
- Say clearly where the project came from.
If you are planning software of your own and want to know which parts you can build on and which you should own outright, we can help you work it out before a line is written. See our custom software development service.
Sources
All pages were accessed on 10 November 2026.
- Apache License, Version 2.0, Apache Software Foundation
- Apache License v2.0 and GPL compatibility, Apache Software Foundation
- The MIT License, Open Source Initiative
- CrizaVoise dependency licence report, GitHub
- CrizaVoise trademark policy, GitHub
Frequently asked questions
Can I relicense MIT code under the Apache License 2.0?
You can release your own changes and the combined work under Apache 2.0, because the MIT licence allows sublicensing. You must keep the original MIT copyright and permission notice with the code it covers.
Why is a GPL dependency a problem for an Apache-licensed app?
If you distribute an app that includes GPL code, the GPL's terms apply to the whole program, and the Apache License 2.0 is not compatible with GPL version 2. Replacing the package keeps the app under the licence you chose.
Does the Apache License let someone use my product's name?
No. Section 6 of the Apache License 2.0 says it does not grant permission to use the licensor's trade names or trademarks, except to describe where the work came from.
Is this legal advice?
No. It describes what we checked for our own release. For a commercial product, have a lawyer review your licence choices and your dependencies.
