License decisions in frontend architecture have long-term consequences – especially when components are used across multiple products or delivered to external clients. Most developers know the MIT License but treat all others as a black box. In practice, a single problematic license in the dependency tree can jeopardize an entire project.
Two License Families
Open-source licenses fall into two categories: Permissive licenses (MIT, Apache 2.0, BSD) allow use in proprietary software without disclosure obligations. Copyleft licenses (GPL, LGPL, EUPL) require that derivative works be published under the same or a compatible license.
For internal design systems, this distinction is critical: a permissively licensed system can be used in any product. A copyleft-licensed system can extend the disclosure obligation to the entire product – depending on the license and type of integration.
Permissive licenses typically only require retaining the copyright notice. The code may be modified, commercially used, and redistributed without disclosing your own changes. This makes them the preferred choice for component libraries and design system infrastructure.
Copyleft licenses go further: they require derivative works to be published under the same (or compatible) license. The strength of copyleft varies considerably: GPL v3 (strong copyleft) can extend to the entire program. LGPL (weak copyleft) limits the obligation to the library itself. EUPL offers weak copyleft with an explicit compatibility list.
The Four Most Important Licenses in Detail
MIT is the de-facto standard license with over 70% market share in the npm ecosystem. Its strength is simplicity: 171 words, no restrictions beyond attribution. Its weakness: no patent clause, no trademark rights, no data protection provisions.
Apache 2.0 is the mature alternative for regulated industries. It contains an explicit patent grant – anyone publishing code under Apache 2.0 automatically grants a license on relevant patents. It also requires documentation of changes (NOTICE file).
GPL v3 is the most well-known copyleft license. Any program that incorporates GPL-licensed code must itself be published under GPL – including source code. For frontend projects, this is rarely practical.
EUPL v1.2 is the only open-source license under EU law. It offers weak copyleft with an explicit compatibility list: derivative works may also be distributed under GPL v2/v3, LGPL, MPL, CECILL, or Apache 2.0. The jurisdiction is the competent court of the EU Member State of the licensor.
Compatibility Issues
The most common problem in practice is not the license of a single library, but the combination of different licenses in one project. GPL v2 and Apache 2.0 are incompatible – code under these licenses may not be combined in one work. In monorepos with hundreds of packages, such conflicts can easily be overlooked.
Automated Auditing
Tools like FOSSA, license-checker (npm), or Licensee (GitHub) scan dependency trees and identify license conflicts. For organizations distributing design systems to third parties, regular automated license auditing is not an optional best practice but a compliance requirement.
npx license-checker --summary
npx license-checker --failOn "GPL-3.0;AGPL-3.0;SSPL-1.0"Key Takeaways
- Permissive licenses allow proprietary use; copyleft licenses require disclosure of derivative works.
- MIT is the npm ecosystem standard but offers no patent protection – Apache 2.0 is the better choice for regulated industries.
- GPL-licensed code in transitive dependencies can extend the disclosure obligation to the entire project.
- The EUPL is the only open-source license under EU law with weak copyleft and broad compatibility.
- License combinations in monorepos can lead to hidden conflicts – automated auditing is essential.
- Licenses can change: regular auditing protects against the “MIT-to-BSL” risk.
