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 e ects on the IP and therefore on the usability of the artifacts they produce. We then show how this e ects can be shaped to the needs of the licensor and the licensee.
Open source has become more and more important in the last years and has
been adopted widely in the consumer as well as the industrial market. In 2008,
85% of all enterprises were using open source software [
Open Source is not only used in business but also in development. According to [16] 76% of all developers have used open source technology for some of their tasks.
The reasons to develop open source software vary greatly. Some companies provide open source software to rapidly grow their user base [18] and thus creating an industry standard. Other reasons are getting a community invested into the project to create an ecosystem of supporting software (e.g. Plugins) arround the original project or to allow external validation of the software (e.g. every user could potentially security audit open source software). Individuals develop open source software to show o their skill, to show their work to the world, for altruistic reasons, or for potential rewards in the future [17]. Academic institutions provide their software under an open source license to gain a user base, and to foster the use of new approaches in industry. Some companies have a dual license approach where they provide an open source version of the software to gain a user base but o er more exible licenses and customization to business users [29].
The open source licenses re ect this di erent reasons to open source software and to use it and di er from each other considerably [26].
It is therefore important to chose the right license that is consistent with the reasons you license the software as open source. This is especially true for generators as there are more potential pitfalls than with other software as the generator's license can have an in uence on the intellectual property rights of the generated artifacts.
For example a car manufacturer will not use a generator or compiler when the license of the produced code threatens the intellectual property (IP) of his other code or enforces a logo to be placed on the car.
To give an overview about the potential license choices for generators we list the most common licenses and classify them according to categories found in literature. We then show which impact the licenses have on the artifacts if applied to a generator.
Our research questions are: RQ1: Which impact can the open source license choice for the generator have on the license of the artifacts? RQ2: What possible solutions can be used to counteract unwanted e ects on the IP of the artifacts?
The paper is structured as follows: Section 2 reviews the related work. In section 3, we describe the licenses and describe their characteristics as found in literature. Section 4 shows which in uence those characteristics have on the license/ownership of the generated artifacts if the license is applied to a software generator and how this in uence can be shaped to meet the needs of the licensor. Section 5 concludes the paper. 2
Various publications analyse the rationale behind license choices and give guidelines which license is suitable for which project.
[22] examines the scope of licensing in open source and lists the various considerations that determine the license of open source projects. While [24] gives a guide to choosing an open source license in a commercial context.
[21] examines the licenses and their implications in great detail which negative and positive implication they have on projects in general, the reasons to choose a particular license but aso how to draft an own open source license.
[23] gives an overview about trademark, patent, and copyright law in relation to open source and shows how to choose a commercial or open source license. It examines the implications of linking code covered by the gpl and the implications of creating derivative work but only from a developer perspective as well as from a business perspective, but does not cover model driven development.
[30] shows what motivates businesses to provide open source, examines common open source licenses and how they relate to community and corporate interests. It also classi es open source licenses and gives an overview of the implications of licenses for the IP of the code they cover using examples.
[28] presents how the license choice impacts interest into a project and the development activity.
[
However, none of the above papers and books examines the intellectual property situation of artifacts that are generated or created by open source projects as separate case. 3
In this section we describe the most common open source licenses and and show
their characteristics. We chose the licenses by looking at the black duck license
usage statistics [
We looked at the 10 most widely used licenses and decided to exclude the Artistic License as it is mostly used in the context of the Perl Scripting language and the Microsoft Public License because of its similarity to the Eclipse Public License (EPL) which is more important in the context of model driven development (as many widely used open source software for model driven development use this license) and we decided to look only at the most recent version of each license and exclude older versions which gives us 6 potential licenses for our evaluation. We made the choice to include a 7th license the GNU A ero General Public License as it addresses the privacy loophole which isn't addressed by the other licenses. 3.1
Permissions for reuse: We use the classi cation in [30] and di erentiate between three di erent types of licenses called Permissive, Weak Copyleft and Strong Copyleft.
Permissive: These licences permit the redistributor to restrict access to the modi ed source code (make the modi ed source code closed source) and to put the changed software under a di erent license (even a proprietary license).
Weak Copyleft: The license of the software cannot be changed but it only applies to the software that is directly derived from the original software e.g. software that incorporates copies of source code from the original software.
Strong Copyleft: Every software that links or otherwise incorporates code from a software licensed under a strong copyleft license needs to be published under a compatible license [27]. Strong copyleft licenses are often called viral as linking to one strong copyleft library forces the whole project to be put under a compatible license.
Patent license: Some Open Source licenses automatically include a patent granting clause that grants a non-exclusive, worldwide, royalty-free patent license for all patents a contributor holds and that a ect his contribution to the project. In other words if a contributor contributes code to a project that mandates a license grant and the code he contributes would be covered by a patent he holds he needs to give a license to the users of the project without charging them for it.
Enhanced Attribution: All open source licenses specify that that the anyone
who distributes or modi es the software needs to give credit to the original
authors. \Enhanced attribution" means that the license speci es the form of
the credits in a way that goes beyond just giving credit like the attribution
clause in the original BSD license that speci es that a special
acknowledgement needs to be added to all advertising materials mentioning the use of
the licensed software or a feature of the software [
software and just uses it or sells its use e.g. a service provider who sells the use of a webclient, there is normally no obligation to make the changes available to the community. If this loophole is closed on the other hand the changes must be made available. Dual licensing is the practice to distribute software under two di erent licenses [29] while multi licensing is the practice to distribute it under more than two licenses.
Dual Licensing is a common business model in open source. Examples for
famous projects with dual licenses are:
{ Qt [29]
{ MySQL [29]
{ Asterisk [
It is also possible to multi license only parts of a software it sometimes makes sense to license a single le under two di erent open source licenses for example to allow its use in two di erent projects whose licenses are incompatible to each other or to put some parts of the software under a less restrictive license to allow its reuse while the rest of the software remains under a restrictive license. 4
The question under which license the generated artifacts are is a very important one. The relationship is tricky as the generated artifacts are derived from the models (that are owned by the user of the software) but to some extent also include parts from the generator itself and usually work together with a runtime environment and libraries. 4.1
Derivative work according to US copyright law is: \work based upon one or more
preexisting works" [
It is important to notice that the mere output of a program itself is not covered by the license of that program. Only if the output constitutes derivative work of the generating program there is this legal dependency between generator output and generator.
Figure 1 shows an example where the generator copies chunks from its own code into the generated artifact which means that the artifact is derivative work.
An example for such a generator is bison the GNU parser generator which copies parts of itself into the parser source code it generates. Therefore every «handwritten» Generator Output generates «gen»
The restrictive license of the generator causes the output to be derivative work which needs to be distributed under the same or a compatible license as the generator.
Parts that are direct copies from generator sourcecode or from templates that are part of the generator
Legend: Provided under a
copyleft license
Can only be distributed
under a license compatible
with the license of the
generator
Created and owned by
the user of the generator
parser generated with bison would be derivative work of bison but the license
of bison makes an explicit exception to the GPL [
Another example for generators that include parts of themselves into generated code are generators based on the Monticore [20] language workbench. Monticore uses templates to generate source code these templates for example generate class de nitions and their content is directly put into the generated artifacts. If those templates are licensed under a copy left license the generated code is derivative work and needs to be treated accordingly.
Both weak and strong copyleft licenses impose the restriction that derivative work that includes substantial parts of the original work needs to be put under the same or a compatible license only permissive licenses don't have that restriction. 4.2
For strong copyleft licenses it isn't enough that the work is not derivative to cause implications of the license to the work depending on it. Strong copyleft licenses de ne a term \Corresponding Source" which is the code for shared libraries and dynamically linked subprograms that use the work. This \Corresponding Source" needs to be licensed under the same license if the original work is licensed under a strong copyleft license. An example would be a library that is licensed under the GPL and that is used as a shared library by generated artifacts (see Figure 2). These artifacts then need to be licensed under the GPL as well.
For weak copyleft licenses there is no such requirement as merely using a library imposes no e ect on the license of the artifacts.
<<library>> Library provided as part of the generator framework <<linkes>> «handwritten» Generator
Output <<executable>>
Program
The license implication both for incorporating source of the generator in generated artifacts as well as having dependencies to strong copyleft licensed code can create practical problems for users of the generator.
For example a company that uses such a generator to create a product would need to license it as open source under a compatible license. This prevents some business models, e.g. the software could not be distributed as closed source. This is often not intended as the licensor sometimes wants to only protect the generator but not the artifacts.
We identify the following ways to explicitly prevent these dependencies from having practical e ects: Adding an exception in the license. In this approach en exception is added to a restrictive license to allow exactly the usage of dependent or derivative artifacts that is intended by the licensor. This is the approach that the GNU parser generator used it has the advantage that the intentions of the licensor are clear as it is clearly stated what impact the license of the generator should have on the dependent artifacts.
The disadvantage of this approach is that a modi ed version of a license (adding an exception is a modi cation) is a new license. This creates problems for distributors of open source software as they normally use automated approaches to package software which need standardized licenses with clear compatibilities and incompatibilities to other open source licenses.
Users as well as distributors need to check these non standardized exceptions and handle them accordingly this creates additional e ort.
Duallicensing or multilicensing the les the artifacts are derived from or
dependent on. If the generator is under a copyleft license as a whole the licensor can
still release parts of it under a less restrictive license. The licensee can then
choose the license that applies as both are valid. This solution is recommended
by [
RQ1: Which impact can the open source license choice of the generator have on the license of the artifacts? Answer: The license can have an in uence on the artifacts. When the artifacts are derivative work in the case of Weak-Copyleft or Strong-Copyleft licenses or when the artifacts have dependencies on libraries that are part of the generator framework e.g. dependencies on a library in the case of StrongCopyleft licenses.
RQ2: What possible solutions can be used to counteract possibly detrimental e ects? Answer: There are three ways to shape minimize the restrictions: { Adding an exception to the license of the generator. { Dual licensing the code that creates the dependency under a more permissive license. { Using a more permissive license that prevents the problem in the rst place. 5
The license of the generator can have an impact on generated artifacts. Generator providers need to take that into account when choosing the license of their generator. The e ects can be positive and deliberate for example to make the open source version of a generator less attractive when the dual licensing business strategy is employed and thus forcing commercial users to license the commercial version of the generator while still being able to bene t from the open source community. But they can also have detrimental e ects when a generator that is only available under a restrictive license creates artifacts that are derivative work or have dependencies that cause that the artifacts cannot be used in a commercial environment although the licensor wants to allow that and only intended to protect the generator's code not the artifacts it creates. It is therefore important to know the e ects of the license choice on the artifact and to apply the shown solutions if the e ects are not as intended. 16. Hammond, J.S., Brown, V., Murphy, P., Curran, R.: Development Landscape: 2013
Developer Forrsights North America And Europe (2013) 17. Hars, A., Ou, S.: Working for free? Motivations of participating in open source projects. In: System Sciences, 2001. Proceedings of the 34th Annual Hawaii International Conference on. pp. 9{pp. IEEE (2001) 18. Hecker, F.: Setting up shop: The business of open-source software. IEEE software 16(1), 45{51 (1999) 19. Johnston, S.: Simple workload & application portability (SWAP). In: Computer Communications Workshops (INFOCOM WKSHPS), 2014 IEEE Conference on. pp. 37{42. IEEE (2014) 20. Krahn, H., Rumpe, B., Volkel, S.: Monticore: a framework for compositional development of domain speci c languages. International journal on software tools for technology transfer 12(5), 353{372 (2010) 21. Laurent, A.M.S.: Understanding Open Source and Free Software Licensing.
O'Reilly Media, rst edition,annotated edn. (8 2004) 22. Lerner, J., Tirole, J.: The scope of open source licensing. Journal of Law, Economics, and Organization 21(1), 20{56 (2005) 23. Lindberg, V.: Intellectual Property and Open Source: A Practical Guide to Protecting Code. O'Reilly Media, 1 edn. (7 2008) 24. Lindman, J., Paajanen, A., Rossi, M.: Choosing an open source software license in commercial context: A managerial perspective. In: Software Engineering and Advanced Applications (SEAA), 2010 36th EUROMICRO Conference on. pp. 237{ 244 (Sept 2010) 25. MySql: Commercial License for OEMs, ISVs and VARs, http://www.mysql.com/ about/legal/licensing/oem/, accessed: 2014-07-18 Archived by (WebCite at http://www.webcitation.org/6RBMbAzJi) 26. Rosen, L.: Open Source Licensing: Software Freedom and Intellectual Property
Law. Prentice Hall, 1 edn. (8 2004), http://amazon.com/o/ASIN/0131487876/ 27. Sen, R., Subramaniam, C., Nelson, M.L.: Open source software licenses: Strongcopyleft, non-copyleft, or somewhere in between? Decision support systems 52(1), 199{206 (2011) 28. Stewart, K.J., Ammeter, A.P., Maruping, L.M.: Impacts of license choice and organizational sponsorship on user interest and development activity in open source software projects. Information Systems Research 17(2), 126{144 (2006) 29. Valimaki, M.: Dual licensing in open source software industry. Systemes dInformation et Management 8(1), 63{75 (2003) 30. Widenius, M.M., Nyman, L.: The Business of Open Source Software: A Primer.
Technology Innovation Management Review 4(January 2014: Open Source Business) (2014) 31. Zenoss Inc.: 2010 Open Source Systems Management Survey (2010)