EPL-2.0 · File-level copyleft
Weak copyleft at the module level, common in the Java ecosystem. Modifications to EPL-covered code must be made available; larger works that merely combine with it need not be.
The same license produces different obligations depending on whether the software is distributed, hosted, or kept internal. This is the distinction most dependency scanners collapse.
| How you ship it | Result | Why |
|---|---|---|
| Hosted SaaS | No obligation | EPL-2.0 applies copyleft per file, not to your project as a whole. Files it covers must stay under it and their modifications must be published, while your own files may carry any terms you choose. It treats static and dynamic linking alike, so how you link makes no difference. |
| Distributed binary / app | No obligation | EPL-2.0 applies copyleft per file, not to your project as a whole. Files it covers must stay under it and their modifications must be published, while your own files may carry any terms you choose. It treats static and dynamic linking alike, so how you link makes no difference. |
| Delivered to customer | No obligation | EPL-2.0 applies copyleft per file, not to your project as a whole. Files it covers must stay under it and their modifications must be published, while your own files may carry any terms you choose. It treats static and dynamic linking alike, so how you link makes no difference. |
| Internal use only | No obligation | EPL-2.0 applies copyleft per file, not to your project as a whole. Files it covers must stay under it and their modifications must be published, while your own files may carry any terms you choose. It treats static and dynamic linking alike, so how you link makes no difference. |
| Published library | No obligation | EPL-2.0 applies copyleft per file, not to your project as a whole. Files it covers must stay under it and their modifications must be published, while your own files may carry any terms you choose. It treats static and dynamic linking alike, so how you link makes no difference. |
Source disclosureAttribution
As a build-time dependency it is a different question.
EPL-2.0 appears as a dev dependency, so it is not part of the artifact you ship. Distribution-triggered obligations do not arise. Tools that emit code into your output, such as code generators, are a separate case worth checking individually.
Want to know whether anything in your project is under EPL-2.0?
Check your whole manifest →LicenseGuard reports information derived from published license texts and dependency manifests. It is not legal advice and using it does not create an attorney-client relationship. Results reflect license metadata as declared; they do not identify every obligation or violation. Consult qualified counsel for decisions that matter.