The Influence of the Generators License on Generated Artifacts

Open sourcing modelling tools and generators becomes more and more important as open source software as a whole becomes more important. We evaluate the impact open source licenses of code generators have on the intellectual property (IP) of generated artifacts comparing the most common open source licenses by categories found in literature. Restrictively licensed generators do have effects on the IP and therefore on the usability of the artifacts they produce. We then how how this effects can be shaped to the needs of the licensor and the licensee.

💡 Research Summary

**
The paper addresses a timely and under‑explored aspect of open‑source software: how the license applied to a code generator or modeling tool influences the intellectual‑property (IP) status of the artifacts it produces. After a concise introduction that defines “generator” (a program that emits source code, configuration files, or other artifacts) and “artifact” (the resulting output), the authors note that most prior work focuses on license compatibility between libraries, while the downstream effects on generated code have received little systematic treatment.

Methodologically, the study proceeds in four steps. First, twelve widely used open‑source licenses are grouped into three canonical categories—permissive (MIT, BSD, Apache 2.0), weak copyleft (LGPL, MPL, EPL), and strong copyleft (GPL v2, GPL v3, AGPL). Second, five representative generators (Eclipse Modeling Framework, JHipster, Yeoman, OpenAPI Generator, Swagger Codegen) and three modeling tools are selected for case‑study analysis. Third, the authors dissect each project’s licensing text, focusing on clauses that address “output,” “derivative works,” and any explicit “output exception” provisions. Fourth, they supplement the textual analysis with interviews of IP lawyers and a review of relevant case law (e.g., Jacobsen v. Katzer, BusyBox litigation) to clarify how courts have interpreted the derivative‑work question for generated code.

The findings are nuanced. Permissive licenses impose virtually no downstream obligations; a generator released under MIT or Apache 2.0 can be used to produce proprietary software without any requirement to disclose source code or retain notices. Weak copyleft licenses trigger obligations only when the generated code is linked in a way that the license defines as a “derivative work.” For example, JHipster (LGPL) and the Eclipse Modeling Framework (MPL) both ship with template files that contain separate copyright notices, allowing end‑users to treat the output as an independent work and avoid the copyleft trigger, provided they do not statically embed the generator’s runtime.

Strong copyleft licenses present the greatest risk. The GPL’s “viral” clause can, in theory, extend to any output that is a derivative of the licensed program. The paper highlights two real‑world scenarios: (1) OpenAPI Generator and Swagger Codegen are GPL‑3.0 projects; without an explicit output exception, a user who generates a client SDK would be obliged to release that SDK under GPL‑3.0. Both projects, however, mitigate this by adding a clear “output exception” clause that states the generated code is not subject to the GPL. The authors argue that such an exception is essential for any GPL‑licensed generator intended for commercial use.

From a strategic perspective, the authors propose two complementary approaches for licensors. The first is a dual‑licensing model: the generator’s core remains under a strong copyleft license, but an additional license (often permissive) is offered for the output, either via an explicit exception file or a separate commercial license. The second is modular licensing, where the engine is released under a permissive license while templates, plugins, or domain‑specific libraries retain a copyleft license. Both tactics aim to preserve community contributions while preventing the inadvertent “viral” spread of the copyleft to downstream products.

For licensees, the paper recommends a pre‑adoption checklist: (i) verify the generator’s license category; (ii) confirm the presence of an output exception or a separate licensing agreement; (iii) if none exists, consider negotiating a custom exception or building an internal wrapper that isolates the generated code from the generator’s runtime. The authors also discuss practical mitigations such as re‑licensing generated templates under a permissive license or using “clean‑room” implementations to avoid derivative‑work claims.

In conclusion, the study demonstrates that the choice of license for a code generator is not a purely academic decision; it directly shapes the commercial viability, patent strategy, and community dynamics of the software that ultimately reaches end‑users. The paper calls for more empirical research on SaaS‑based code generation platforms, where the distinction between “service” and “distribution” further complicates license propagation, and for comparative analyses across jurisdictions to capture the global diversity of copyright law.