License Integration Patterns: Dealing with Licenses Mismatches in Component-Based Development Daniel M. German Department of Computer Science University of Victoria, Canada [email protected] Ahmed E. Hassan School of Computing Queen’s University, Canada [email protected] To appear at the 31st International Conference on Software Engineering (ICSE) 2009 Abstract for the creation of many successful projects. Over the last decade, various research efforts have In this paper we address the problem of combining focused on the technical aspects of supporting and im- software components with different and possibly incom- proving component-driven software development pro- patible legal licenses to create a software application cesses. For example, Garlan et al. discuss the chal- that does not violate any of these licenses while poten- lenges of component development due to architecture tially having its own. We call this problem the license and interface mismatches [8]. However, little atten- mismatch problem. The rapid growth and availability tion has been directed toward the legal complexities of Open Source Software (OSS) components with vary- surrounding component based software development. ing licenses, and the existence of more than 70 OSS li- Builders of component based applications must com- censes increases the complexity of this problem. Based bine components with different licenses to create a new on a study of 124 OSS software packages, we developed software application, i.e., derivative work, with its own a model which describes the interconnection of compo- licensing terms. nents in these packages from a legal point of view. We used our model to document integration patterns that With the widespread of open source components, are commonly used to solve the license mismatch prob- practitioners are likely to pick open source components lem in practice when creating both proprietary and OSS when building their next large component based appli- applications. Software engineers with little legal exper- cation. In contrast to commercial components, open tise could use these documented patterns to understand source components have a large number of licenses. At and address the legal issues involved in reusing compo- last count there are 70 approved open source licenses. nents with different and possibly conflicting licenses. Each license has its own set of permissions and restric- tions. Combining components of differing and possibly conflicting licenses is the next big challenge for compo- nent based development. We call this challenge - the 1. Introduction license-mismatch problem. The Bugzilla software application [31] is a great ex- Most large software applications are not built from ample to highlight the sheer complexity of this prob- scratch, instead they are built by combining several lem in modern component-driven development. In its components such as reused code snippets, self con- most common instance, Bugzilla makes use of 82 pack- tained binary libraries, or other applications. Compo- ages. These packages use 10 different licenses including nent based development (e.g., [19]) has been a catalyst original 4-clauses BSD, new 3-clauses BSD, Artistic v1, 1 GNU General Public License (GPL) v1, GNU GPL v2, problem. Through a detailed study of the licenses and GNU Lesser General Public License v2.1, MIT, Apache architecture of 124 OSS packages, we identified and v2, and IBM Public License v1.0. Many of these li- documented patterns that are commonly used to in- censes conflict with each other, for example, the GPL tegrate components with different licenses. By docu- licenses insist that all code linked to them must be menting these patterns, we aim to 1) Demonstrate the GPL-licensed as well; one would expect that the fi- effect of legal issues on the architecture of modern soft- nal product, i.e., Bugzilla, would be licensed under the ware applications, 2) Define common vocabulary for GPL. However, Bugzilla is licensed under the Mozilla discussing and analyzing the effects of licenses on soft- Public License 1.1. To combine all these conflicting ware, 3) Provide a set of cookbook advice, i.e., patterns licenses, the developers of Bugzilla had to adapt and for practitioners to learn best practices, for academic modify their technical solutions and architecture to en- to improve research and education matters associated sure that Bugzilla complies with the other ten licenses. with software licensing issues. Several models have been proposed in the past to model the selection of components (such as [3]) but 1.1. Overview Of Paper do not address how its license affects the requirements and potential uses of a component-based system, and This paper is organized as follows. Section 2 gives a its architecture. Others have warned about the diffi- brief overview of the legal protections available for soft- culties of including open source software in commer- ware. Section 3 presents our model to describe licenses cial software [1, 16, 25, 29]. IBM’s Ariadne Ariadne and the legal consequences of combining components of appears to be the only tool that fully incorporates the different licenses. Section 4 presents our system of pat- management of intellectual property in software devel- terns. In Section 5 we conclude the paper and outline opment [4]. Some organizations, however, have poli- possible venues for future work. cies and procedures on how open source components should be selected for inclusion in proprietary prod- ucts [16, 10]. 2. Legal protections for Software License compliance is rapidly becoming an im- portant and critical challenge for many software or- From a legal point of view, software, or more specif- ganizations worldwide. Companies like Hewlett- ically, a “‘computer program’ is a set of statements or Packard (http://www.hp.com), Black Duck Soft- instructions to be used directly or indirectly in a com- ware (http://blackducksoftware.com) and Palimida puter in order to bring about a certain result.”[37]. (http://palamida.com) have created infrastructures Computer programs are usually protected using one or and toolsets to help software organizations tackle the more legal alternatives: a) trademarks–which protect license mismatch problem. For example, Koders.com the software name, logos, and any specific mark as- by Black Duck Software is a source code search engine sociated with the software; b) trade secret–the source which permits developers to limit their code search to code of the program is kept secret, only binary or specific licenses; and the FOSSology Project by HP obfuscated versions of the program are distributed, provides the infrastructure to automatically detect li- c) patents–software related inventions are patentable, censes in software packages to aid in identifying possi- giving the owner of the patent a monopoly on its ble license mismatches [10]. exploitation though not all countries permit software In contrast to technical challenges, the license mis- patents, d) copyright–gives its owner certain exclu- match problem is a more complex challenge for which sive rights such as making copies of the software. See software engineers have limited training and knowl- [2, 11, 14, 24] for comprehensive discussions on how edge. Undergraduates exposure to legal issues is con- these protections are applied to software. This paper fined to a few lectures in a single course as per the focuses on the use of copyright to protect software. ACM Software Engineering Curriculum guidelines. The main contributions of this paper are twofold. 2.1. Exclusive rights and licenses First, the development of a model to describe licenses, and the implications of licenses on components reuse The copyright owner of a software system has var- efforts. This model is the first step for creating frame- ious exclusive rights over it, namely [37]: 1) to make works which could automatically verify legal compli- copies of it, 2) to prepare derivative works based on it, ance. Second, we highlight and document the efforts of 3) to distribute copies for sale, rent, lease or lending, the open source community in addressing the mismatch 4) to perform the work in public, and 5) to display the 2 work in public. A copyright owner can exploit these 2.3. Open source licenses exclusive rights for a fixed period of time, as long as 95 years if the owner is an organization, from the first Open source licenses create a legal framework which publication of a piece of software. An owner can ex- permits the collaboration of different individuals and plicitly forfeit the copyright of a work. A work with no organizations in the creation of software: “Open source copyright owner is said to be in the public domain. licensing has become a widely used method of creative A license is a legal mechanism used by the copyright collaboration that serves to advance the arts and sci- or patent owner (the licensor) to grant permission to ences in a manner and at a pace that few could have others (the licensees) to use and exploit her intellectual imagined just a few decades ago.” [13]. property in ways that would otherwise be forbidden by The Open Source Initiative (OSI) (http://www. copyright or patent law [15, 17, 28]. For example, an opensource.org/) defines and promotes the “Open integrator who wants to modify and include a compo- Source Definition” (OSD). The OSD defines open nent as part of a larger software application and sell the source as software that is distributed under a license application will require the rights to create a derivative that satisfies 11 specific criteria for an open source work of the component, make copies of it, to distribute license[32]. These criteria include: the source code it and to sell it. The integrator would have these rights should be available; the license should allow modifi- if a) she owns the intellectual property of the compo- cations and derived works, the distribution of such de- nent, b) the intellectual property of the component is rived works are licensed under the same terms as the in the public domain, or c) she has a license for the original license; and the license must not discriminate component which grants her these rights.