I recently faced a dilemma that kept me up at night.
I needed to redact sensitive data from PDFs for a client project.
PyMuPDF seemed like the perfect solution. It’s powerful, reliable, and well-documented.
There was just one problem: it’s licensed under AGPL.
My first question? “Do we have to open source everything now?” I didn’t have a good answer.
Like many developers, I’d been copying and pasting MIT licenses for years. Without truly understanding what they meant or what alternatives existed.
This experience forced me to dive deep into the world of software licensing, and what I learned surprised me.
If you’ve ever hesitated before importing an open source library because of licensing concerns, this open source license guide is for you.
The License Landscape: Not All “Free” Software Is Created Equal
Open source licenses fall into two main categories: permissive and copyleft.
Understanding this distinction is crucial for making informed decisions.
Permissive licenses (MIT, BSD, Apache) give you maximum freedom. You can use the code in proprietary software, modify it however you want, and never share your changes.
The only requirement? Give credit to the original author.
Copyleft licenses (GPL, AGPL) have strings attached.
They require that if you distribute the software (or in AGPL’s case, make it accessible over a network), you must share your source code under the same license. The philosophy: software freedom should propagate.
AGPL: The Misunderstood License
The GNU Affero General Public License (AGPL) is often treated as radioactive by companies.
I’ve seen developers immediately reject any AGPL-licensed library without understanding why (me for example).
Here’s what AGPL actually requires: If you modify AGPL-licensed software and make it accessible to users over a network, you must provide them with the source code.
Notice what it doesn’t say:
- “Publish your code on GitHub for the world to see”
- “Open source your entire codebase”
- “Share with your competitors”
The key insight: “users” means the people actually using your software, not the general public!
This was the major “aha” moment for me, and made me write this open source license guide.
The Internal Use Case
This distinction matters tremendously for internal tools.
If you build a web application for your company using AGPL-licensed components, your obligations are minimal.
Your company’s employees are the “users,” and they can request the source code.
But since your company owns the code anyway, this requirement is easily satisfied.
According to Snyk’s AGPL compliance guide, purely internal use without external distribution typically doesn’t trigger AGPL’s source code disclosure requirements to the outside world.
Where AGPL Becomes Restrictive
AGPL creates real constraints when you want to:
- Commercialize your software – Selling it as a SaaS product means customers can request your source code
- Keep it proprietary – You can’t hide modifications from network users
- Embed in products – If you include it in software you distribute, copyleft provisions apply
Permissive Licenses: Maximum Freedom
Let’s compare the three most popular permissive licenses for our open source license guide:
MIT License
The MIT License is the minimalist’s choice. Its requirements fit on a single page:
- Include the copyright notice
- Include the license text
- That’s literally it
You can use MIT-licensed code in proprietary software, modify it however you want, and never share your changes.
Projects like React, Node.js, and Rails use MIT, making it the most popular open source license on GitHub.
BSD-3-Clause License
The BSD-3-Clause License is nearly identical to MIT with one addition: you cannot use the original author’s name to endorse your product without permission.
For example, if you use a BSD-3 licensed library called “FastPDF,” you can’t advertise your product as “Officially endorsed by FastPDF” or “FastPDF Pro Edition.”In practice, this rarely matters unless you’re doing something ethically questionable with branding.
Apache 2.0 License
The Apache License 2.0 is the heavyweight of permissive licenses.
It includes everything MIT and BSD-3 provide, plus explicit patent protection.
Here’s why this matters:
Imagine an author patents an algorithm, writes code implementing it, and licenses the code under MIT. You use that code, and later the author (or someone who bought the patent) sues you for patent infringement.
The MIT license doesn’t protect you. It only covers copyright.
Apache 2.0 explicitly grants you patent rights, making it safer for use in commercial products.
This is why major projects like Kubernetes, Android, and most Apache Software Foundation projects use it.
The Enforcement Reality: Can You Actually Get Sued?
This is the question that kept me researching late into the night.
The answer: Yes, but probably not.
Software licenses are legally binding contracts. Violating them constitutes copyright infringement, which can result in lawsuits, injunctions, and financial penalties.
According to the Software Freedom Conservancy, GPL and AGPL violations are real legal issues.
However, enforcement has important limitations: Only the copyright holder can sue you.
Not “open source police” (which doesn’t exist), not advocacy groups (unless they own the copyright), and not random developers who notice your violation.
For AGPL specifically, enforcement is rare for internal tools because:
- Detection is nearly impossible (it’s running on your servers)
- Copyright holders focus on large commercial violations
- Most violations are resolved with cease-and-desist letters, not lawsuits
- Legal battles are expensive and time-consuming
That said, the risk isn’t zero. If you’re building a commercial SaaS product with AGPL components and not providing source code to customers, you’re in dangerous territory.
Making the Decision: A Practical Framework
When I finally had to choose between PyMuPDF (AGPL) and alternatives for my PDF redaction tool, I asked these questions:
Question 1: Is this for internal use only?
- Internal only → AGPL is probably fine
- Will be commercialized → Consider permissive licenses
Question 2: Can users request source code?
- Yes, and we can provide it → AGPL works
- No, must be fully proprietary → Use permissive licenses
Question 3: Does the functionality justify the constraints?
- Yes → AGPL worth it
- No, alternatives exist → Choose permissive option
Question 4: What’s the client’s risk tolerance?
- Risk-averse (banks, government) → They may reject AGPL outright
- Flexible → Explain the implications and let them decide
In my case, we chose PyMuPDF (AGPL) because:
- It was strictly for internal use
- The client owned the source code already
- True PDF redaction was critical for security
- The client had no plans to commercialize
Quick Reference: License Comparison
| Feature | MIT | BSD-3 | Apache 2.0 | AGPL |
|---|---|---|---|---|
| Commercial use | ✅ | ✅ | ✅ | ✅ (with conditions) |
| Modify code | ✅ | ✅ | ✅ | ✅ |
| Keep proprietary | ✅ | ✅ | ✅ | ❌ (for network users) |
| Patent grant | ❌ | ❌ | ✅ | ✅ |
| Must share modifications | ❌ | ❌ | ❌ | ✅ (to users) |
| Use author’s name for endorsement | ✅ | ❌ | ❌ | ❌ |
Lessons Learned
After research and consultations, here’s what I wish I’d known from the start:
- Read the license before you code – Not after you’ve already integrated it into your project
- AGPL isn’t “open source everything” – It only applies to the actual users of your software
- Internal use is low risk – Enforcement focuses on commercial violations
- Document your reasoning – If you ever get questioned, you want proof you made an informed decision
Hopefully our open source license guide can save you time and money!
Resources for Further Reading
- Choose a License – GitHub’s excellent license selection tool
- TLDRLegal – Plain English explanations of software licenses
- Open Source Initiative – Official license texts and explanations
- FOSSA’s License Guide – Deep dive into AGPL compliance
Conclusion
Software licensing doesn’t have to be mysterious. Not with our open source license guide.
The key is understanding what each license actually requires. Not what developers fear it might require.
AGPL isn’t as scary as its reputation suggests, especially for internal tools.
Permissive licenses offer maximum freedom at the cost of no patent protection (except Apache 2.0).
And most importantly, only copyright holders can enforce licenses, making the practical risk much lower than the theoretical risk.
The next time you’re evaluating a library, don’t just look at its features and performance.
Take five minutes to understand its license. Your future self (and your legal team) will thank you.
Disclaimer: This open source license guide is for informational purposes only and does not constitute legal advice. For specific legal concerns regarding software licensing, consult a qualified attorney experienced in intellectual property law.