Mixing Open Source Licenses? Check This First
The first question to ask before pulling in an open source library is how you plan to distribute what you're building. Permissive licenses like MIT, Apache-2.0, and BSD only require keeping the copyright notice, so they can be freely included even in closed-source commercial software — the safest choice by far. GPL-family licenses are the opposite: they carry strong copyleft terms, so the moment you distribute a program that includes GPL code, the entire combined work has to be released under the same license.
MPL-2.0 and LGPL-3.0 sit in between as weak copyleft licenses. MPL applies at the file level, so as long as you haven't modified the library's own files, you can still include it in closed-source software. LGPL lets you keep your application closed as long as you link to the library dynamically — only changes to the library itself need to stay LGPL. AGPL-3.0 looks like GPL but goes further: it extends the copyleft obligation to network-delivered services, so running unmodified AGPL code behind a SaaS product can still trigger a source-disclosure requirement.
This checklist simplifies the combinations developers run into most often. For situations that carry real legal weight, consult a lawyer with open source expertise or your organization's compliance team, and for larger projects with many dependencies, pair this with a license scanner to audit your full dependency tree.
Frequently Asked Questions
Yes. Permissive licenses only require keeping the copyright notice, so they can be freely included even in closed-source commercial products.
GPL is a strong copyleft license. The moment you distribute it as part of your program, the combined work must also be released under the GPL.
LGPL only requires releasing changes to the library itself when dynamically linked, while GPL extends that obligation to the entire combined program.