This document summarizes a group discussion comparing major open‑source licenses (GPL‑2.1, MIT, Apache 2.0, MS‑PL, and LGPL) and clarifies obligations when using GPL‑2.1 or LGPL libraries in commercial, internal, or customer‑specific software scenarios. The focus is on practical compliance requirements for developers and organizations.
- Type: Strong copyleft
- Key Traits:
- Derivative works must be GPL‑licensed
- No explicit patent license
- Incompatible with Apache 2.0 and MS‑PL
- Heavy redistribution obligations (must provide source, build scripts, license text)
- Type: Permissive
- Key Traits:
- Minimal obligations (preserve copyright + license)
- No explicit patent license
- Compatible with most licenses
- Allows proprietary use
- Type: Permissive
- Key Traits:
- Explicit patent license with retaliation clause
- Requires NOTICE file and modification statements
- Compatible with GPL‑3.0 (not GPL‑2.1)
- Corporate‑friendly
- Type: Weak copyleft (file‑level)
- Key Traits:
- Explicit patent license
- Only modified MS‑PL files must remain MS‑PL
- Can combine with proprietary code if isolated
- Not GPL‑compatible
- Allowed to sell GPL‑based products.
- Must release full source code of combined work under GPL‑2.1.
- Must provide build scripts and license text.
- Cannot keep proprietary code closed if linked to GPL‑2.1 library.
- No additional restrictions allowed on customers.
- No obligations if software is not distributed outside the organization.
- GPL obligations trigger only upon distribution.
- Internal proprietary use is unrestricted.
- Obligations apply because distribution occurs.
- Must provide full source code, build scripts, and GPL license.
- Customer gains rights to modify, redistribute, and share.
- Cannot impose confidentiality on GPL‑covered parts.
- Proprietary retention is not possible if linked to GPL‑2.1 library.
- Obligations extend only to direct recipients of distribution.
- No requirement to provide source code to unrelated third parties.
- If customer redistributes, they must fulfill GPL obligations.
- Proprietary applications can link to LGPL libraries.
- Obligations apply only to the library, not the entire application.
- Must provide library source and modifications (if any).
- Must allow replacement of the library (dynamic linking or object files).
- Must permit reverse engineering of the LGPL component.
- No obligation to open‑source proprietary code.
- Allowed with proprietary applications.
- Compliance requires shipping library source or link, license text, and ensuring replaceability.
- No obligations if software is not distributed externally.
- Must provide LGPL library source and modifications.
- Must allow customer to replace the library.
- Proprietary application code remains closed.
- Compliant if LGPL DLL is separate and replaceable.
- Must include license text and provide source or link.
- Reverse engineering of LGPL DLL must be allowed.
- Embeds DLLs, breaking replaceability requirement.
- Compliance achieved by also distributing a normal build with replaceable DLLs.
- Optional optimized builds are acceptable if a compliant build is available.
- Documentation should clarify which build satisfies LGPL obligations.
- GPL‑2.1: Suitable only if you want all derivatives open‑sourced. Not business‑friendly for proprietary distribution.
- MIT/Apache 2.0: Best for maximum freedom and corporate use. Apache adds patent protection.
- MS‑PL: Middle ground with file‑level copyleft.
- LGPL: Ideal compromise for proprietary applications using open‑source libraries.
- Ensure distribution packages include license texts and source links.
- Avoid single‑file publish for LGPL libraries unless a compliant build is also provided.
- Clarify obligations in customer contracts (GPL rights cannot be restricted).
- Document compliance steps in product release notes.
- Compare GPL‑2.1 with GPL‑3.0 for modern projects (patent clauses, compatibility).
- Explore MPL as another weak‑copyleft alternative.
- Draft standard compliance notices for customer deliveries.