UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Investigating software developers' understanding of open source software licensing Almeida, Daniel A. 2017

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2017_september_araujoalmeida_daniel.pdf [ 243.6kB ]
Metadata
JSON: 24-1.0354559.json
JSON-LD: 24-1.0354559-ld.json
RDF/XML (Pretty): 24-1.0354559-rdf.xml
RDF/JSON: 24-1.0354559-rdf.json
Turtle: 24-1.0354559-turtle.txt
N-Triples: 24-1.0354559-rdf-ntriples.txt
Original Record: 24-1.0354559-source.json
Full Text
24-1.0354559-fulltext.txt
Citation
24-1.0354559.ris

Full Text

Investigating Software Developers’ Understanding ofOpen Source Software LicensingbyDaniel A. AlmeidaBachelor of Computer Science, Universidade Salvador, 2014A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMaster of ScienceinTHE FACULTY OF GRADUATE AND POSTDOCTORALSTUDIES(Computer Science)The University of British Columbia(Vancouver)August 2017© Daniel A. Almeida, 2017AbstractSoftware provided under open source licenses is widely used, from forming high-profile stand-alone applications (e.g., Mozilla Firefox) to being embedded in com-mercial offerings (e.g., network routers). Despite the high frequency of use ofopen source licenses, there has been little work about whether software developersunderstand the open source licenses they use. To help understand whether or notdevelopers understand the open source licenses they use, I conducted a survey thatposed development scenarios involving three popular open source licenses (GNUGPL 3.0, GNU LGPL 3.0 and MPL 2.0) both alone and in combination. The 375respondents to the survey, who were largely developers, gave answers consistentwith those of a legal expert’s opinion in 62% of 42 cases. Although developersclearly understood cases involving one license, they struggled when multiple li-censes were involved. To understand the context in which licensing issues arise inpractice, I analyzed real-world questions posed by developers on online question-and-answer communities. The analysis of these questions indicate that licensingissues can constrain software evolution and technical decisions can have an impacton future licensing issues. Finally, I interviewed software developers in indus-try to understand how developers reason about and handle license incompatibilityin practice. The developers I interviewed are cautious of restrictive licenses. Toidentify potential licensing issues, these developers rely on licensing guidelinesprovided by their organization and sometimes use specialized tools to automati-cally detect licensing issues in their projects. When faced with a situation in whicha component that suits their needs is not compatible, developers tend to look foralternative components made available by open source communities. They some-times leverage the technical architecture of their projects to enable the use of com-iiponents under restrictive licenses and might rewrite the required functionality ifnecessary. An analysis of the results indicate a need for tool support to help guidedevelopers in understanding the structure of the code and the technical details of aproject while taking into account the exact requirements imposed by the licensesinvolved.iiiLay SummarySoftware developers rely on software components created by other developers tobuild new software applications. These components are made available under spe-cific licenses that specify under which terms and conditions others can use them.Because modern software applications frequently use many components, it is im-portant for developers to understand how they are allowed to use components. Thisrequires a correct understanding of their licenses. In this thesis, I report on the re-sults of a survey that investigates whether software developers understand a numberof hypothetical scenarios involving the use of software components under differentlicenses. The results indicate that developers struggle to interpret what actions areallowed in those scenarios. To understand the contexts in which these issues arisein practice and how developers handle them, I report on the results of the anal-ysis of real-world cases involving software licensing issues and interviews withsoftware developers in industry.ivPrefaceAll of the work presented in this thesis was conducted in the Software PracticesLab at the University of British Columbia, Point Grey campus. All projects and as-sociated methods were approved by the University of British Columbia’s ResearchEthics Board [certificate #H16-01527].A version of Chapter 4 has been published [2]. I was involved in conceptformation and responsible for all data collection and analysis, as well as manuscriptcomposition. Greg Wilson and Mike Hoye were involved in the early stages ofconcept formation. Gail C. Murphy was the supervisory author on this projectand was involved throughout the project in concept formation, data analysis, andmanuscript composition.vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixDedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Overview of Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.1 Participant Recruitment . . . . . . . . . . . . . . . . . . . . . 104.1.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Survey Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2.2 Quantitative Results . . . . . . . . . . . . . . . . . . . . . . . 13vi4.2.3 Qualitative Analysis . . . . . . . . . . . . . . . . . . . . . . . 154.2.4 Detailed Examples . . . . . . . . . . . . . . . . . . . . . . . 204.3 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4 Summary of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 The Context of License Incompatibilities . . . . . . . . . . . . . . . . . 265.1 Mining Real-World Cases . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4 Summary of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Conclusion and Future Work . . . . . . . . . . . . . . . . . . . . . . . . 35Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A StackExchange Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B Interview Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48viiList of TablesTable 4.1 Survey scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Table 4.2 Participant demographics . . . . . . . . . . . . . . . . . . . . . . . 14Table 4.3 Participant responses by case. Dots indicate answer of legalexpert. Green bar for each case is a “Yes” answer; red bar is a“No” answer and blue bar is a “Unsure” answer. . . . . . . . . . 16Table 4.4 Codes for assumptions . . . . . . . . . . . . . . . . . . . . . . . . 17Table 4.5 Codes for comments for cases . . . . . . . . . . . . . . . . . . . . 20Table 4.6 Codes describing assumptions . . . . . . . . . . . . . . . . . . . . 20Table 4.7 Codes describing cases . . . . . . . . . . . . . . . . . . . . . . . . 25Table 5.1 Number of questions per community for each query . . . . . . . 28Table 5.2 Codes used to describe real-world cases . . . . . . . . . . . . . . 28Table 5.3 Codes assigned to each question . . . . . . . . . . . . . . . . . . . 29Table 5.4 Job title and company size for each participant . . . . . . . . . . 31viiiAcknowledgmentsI would like to thank my parents for their unconditional support and love. They areexamples of integrity, without which no work should ever be done. I also thank mysister for her kindness and support at all times.I must thank my supervisor, Gail Murphy, for her invaluable guidance andsupport. She is an example for those who strive for excellence and deeply careabout their work. It was my privilege to learn from her.I thank my friends, both in Brazil and in Canada, for being there for me when-ever I needed them. I also thank the colleagues and friends at the Software PracticesLab and at the Department of Computer Science at UBC.Finally, I must thank my better half, Larissa, for joining me in this adventure.She not only listened to me as I rambled on or ranted about a variety of topicsthat were not particularly interesting, but supported me through difficult times andcelebrated my victories.DANIEL A. ALMEIDAThe University of British ColumbiaAugust 2017ixDedicationFor of Him and through Him and to Him are all things, to whom beglory forever. Amen. (Rom. 11:36)xChapter 1IntroductionSoftware developers increasingly use open source software to build applications.As one example, Sonatype, the organization behind the Central Repository thathelps Java developers access open source components as part of the build of an ap-plication, reports that the average number of open source components relied uponin 2014 was 106 per application [15].Most often when an open source software component is selected and used ina new application, it is accessed via an application programming interface (API).Over the last twenty years, there has been substantial investigation of challengesdevelopers face in understanding and using APIs (e.g., [13], [4], [12]). This pre-vious work has focused primarily on technical aspects of components, such as thecode and related documentation. However, when developers who are working ona software project, whether open or closed source, choose to use an open sourcecomponent, they must also understand and determine if the software to be used islicensed in a way that is compatible with their intended use of the component.If there were only one or two open source licenses in existence, understand-ing the licenses and how they can be used would be reasonably straightforward.Unfortunately for developers, there are many open source licenses. As just oneexample of the diversity of licenses for software in one programming language,Vendome and colleagues found over 25 licenses used in a sample of Java GitHubprojects [17]. When a developer makes use of open source software, the use maytake many forms, such as through copying a code snippet, using a self-contained1library, extending code that is structured as a framework, to name just a few. Notall of the ways in which a developer may wish to make use of open source codemay be allowed by the license applied to that code and the way in which the codeis used may affect the resultant license of the application being built. The intri-cacies of licenses and how they apply in different situations can result in licenseincompatibility issues. Germa´n and colleagues report finding license incompatibil-ity issues as a result of dependencies between software with different licenses [8].Hermel and colleagues describe how the gpl-violations.org project has detected li-cense compliance problems on over 150 products, such as a Linksys router [10].It is possible that the developers working in these situations knowingly used thelicensed software inappropriately. However, it is also possible that the developersdid not understand the implications of using the open source software as they did.Despite an indication that license problems occur when using open source soft-ware components, there is little research investigating whether developers under-stand the licenses and how to use them. I could find evidence of only one investi-gation of license interactions from a developer’s point of view. Vendome and col-leagues surveyed developers from projects in which licenses for software changed,asking how licenses were picked and reasons for license evolution [20]. The fo-cus of their study was thus on developers involved in license change decisions asopposed to developers involved in using components.In this thesis, I first explore whether developers involved in open source soft-ware development understand licenses and their interactions through a survey. Thesurvey asked developers about 42 different cases of the use of code under differ-ent open source licenses. To make the survey tractable for developers to answer,I focused on three popular open source licenses (GNU GPL 3.0, GNU LGPL 3.0and MPL 2.0). I advertised the survey on mailing lists and Twitter and collectedresponses from 375 participants, who were largely developers and who came frommany parts of the world.Analyzing the survey responses required determining, for each case, appropri-ate answers. The answers were determined by recruiting an intellectual propertylawyer with deep knowledge of the open source community as our oracle. Thisexpert, who has over a decade’s specialization in patent reform, open source li-censing, and related issues, kindly gave us his opinion on each of the scenarios in2the survey, and helped identify ambiguities and missing information that could bechecked to see if developer respondents spotted the same issues and analyzed themthe same way.An analysis of the survey responses indicate that developers had a good graspon development cases involving a single license. However, developers struggledwhen more than one license was involved. Developers recognized that some licenseinteraction cases were more dependent on technical details and others on licensedetails, but they lacked a deep grasp of the intricacies of license interactions.The survey results indicate that software developers struggle with license in-compatibility issues. However, these results do not shed light on the situations inwhich these issues happen and how software developers reason and handle licenseincompatibility issues in practice.To better undertand the context in which licensing incompatibility issues arise,I analyzed real-world questions involving licensing issues. These questions wereobtained from a popular network of question-and-answer communities. To gaininsight into how software developers reason about and handle license incompati-bility situations in practice, I interviewed software developers who have built orare currently building on open source software in their projects.The analysis of real-world cases shows many situations in which licensingincompatibility can constrain software evolution. In other situations, developersseem to struggle due to previous technical decisions that can have an impact onlicensing issues.The interviews with software developers indicate that they tend to be cautiousof restrictive licenses. They rely on licensing guidelines provided by their organi-zation or use specialized tools to identify potential licensing issues in their projects.In a situation in which a component that suits their needs is under an incompati-ble license, developers tend to look for alternative components provided by opensource communities. In some of these cases, they are able to leverage the technicalarchitecture of the project to enable the use of a component or rewrite the requiredfunctionality themselves.This thesis makes three contributions:• It provides empirical evidence that software developers understand how to3use individual open source licenses in both simple and complex developmentscenarios, but struggle to understand cases involving combinations of opensource licenses.• It provides an analysis of the factors that developers consider as they workwith combinations of open source licenses.• It identifies contextual situations in which license incompatibility issues arisein practice and investigates how software developers reason about and handlethese issues.The results of the survey and analysis of real-world cases and interviews withsoftware developers indicate a need to help developers better understand the ram-ifications of the licenses associated with open source software components uponwhich they rely. This help needs to include tool support that can help a devel-oper comprehend, and reason about interactions between licenses in the contextof how components are being incorporated and modified into the software beingbuilt. There is also potentially a role for recommenders that can recommend howcode should be structured to enable the use of components with particular licensecharacteristics.I begin with an overview of previous related research on open source licenses(Chapter 2) and a brief overview of the licenses used in this work (Chapter 3). Ithen describe the survey, including our method and results, and the analysis of real-world cases and interviews with software developers (Chapter 5). Finally, I presentmy conclusions and discuss ways forward to improve the situation (Chapter 6).4Chapter 2Related WorkThe role of open source licenses on open source projects has been the focus ofresearch from a number of different perspectives.Some researchers have focused on the overall trends of open source licenseuse. For example, Aslett has shown the ratio of permissive (e.g., MIT style licensesthat have limited restrictions on reuse) vs. restrictive (e.g., GPL style licenses thatrequire changes to be open source) licensed projects shifted in favour of permissivelicenses between 2008 and 2011 [1]. This result is echoed in the work of Hofmannand colleagues [11]. Di Penta and colleagues have looked at the issue of opensource license use at a more detailed level, considering how licenses can change forand within a project over time [6]. By considering overall trends, these researchershave helped provide a characterization of open source license use, showing thatmany licenses are used in practice and that the choice of a license is not static for aproject as a whole or for parts of a project.Other researchers have taken a different perspective, considering how the choiceof a particular open source license (or licenses) can impact a project. Throughanalysis of open source project artifacts, Stewart and colleagues found business-friendly open source licenses had a positive association with project success [16],where success is defined as user interest in and development activity on a project.Using a similar analysis approach, Sen and colleagues determine factors that affectthe choice of a license for a project (e.g., [14]).Another area of research focus has been on the impact of license interactions5on software development. Germa´n and Hassan were the first to describe the licensemismatch problem, which occurs when two or more pieces of software with dif-ferent licenses with different restrictions are combined in a new project. Germa´nand Hassan developed a model to describe mismatch problems and to documentintegration patterns for solving such problems [7]. Researchers have since lookedat the license mismatch problem in several different ways. For example, Alspaughand colleagues developed a meta-model to analyze the interaction of licenses fromthe viewpoint of software architecture [3]. Germa´n and colleagues developed theNinka tool [9] to identify licenses in source code, making possible larger scalestudies of license use and evolution (e.g., [19] and [21]). The research in this areahas focused largely on technical aspects and implications of licenses, such as thedetection of license interactions and the role of software structure both in causinginappropriate interactions and ways to resolve interactions.In this thesis, I focus on the developer perspective on open source licenses, con-sidering how well developers understand open source licenses, particularly whenthose licenses interact, and how developers reason about and deal with licensingissues. In considering the developers’ perspectives, our work is closest to Vendomeand colleagues [20]. Their work includes a survey of 138 developers chosen fromprojects in which the evolution of a license use occurred. Their survey focused onhow developers picked licenses and motivations for license changes. This surveyrelies on the fact that developers responding to the survey understood the licenseswith which they work and the situations in which the licenses are used. In thisthesis, I focus on a more general population of developers, not just those who havedealt with license changes, and delve into the question of whether the more generalpopulation understands open source license use both when one license is used andwhen a combination of licenses is in use. Furthermore, I analyze real-world casesin which licensing issues arise to understand their situational context and conductinterviews with software developers in industry to understand how developers rea-son about and deal with license incompatibility issues in practice.6Chapter 3Overview of LicensesBefore we introduce the method we used to investigate questions regarding devel-oper knowledge of the use of open source licenses, we present a brief overview ofthe licenses referred to in the survey. We focused on these licenses because theyrepresent common licenses in use (e.g., [20]), because they represent a range fromrestrictive (e.g., GNU GPL) to permissive (e.g., Mozilla Public License (MPL))and because they represent different technological choices in license applicationand resultant restrictions (e.g., GNU GPL vs. GNU LGPL).GNU General Public License (GPL), Version 3.0 (GPL-3.0) The GNU GeneralPublic License (GPL)1 ensures end users of the software being licensed will beable to run, view, share and modify the software. The GPL is a copyleft licensethat requires the rights to be retained when software is shared or modified. Theupdates to the GPL in Version 3.0 were instituted to protect the copyleft featuresgiven recent legal and technological changes.GNU Lesser General Public License, Version 3.0 (LGPL-3.0) The GNU LesserGeneral Public License (LGPL)2 is a weak copyleft license. The LGPL can beapplied to software that is deployed as a shared library; code in the shared librarymust be available to be viewed, modified and shared, but proprietary code using1https://opensource.org/licenses/GPL-3.02https://opensource.org/licenses/LGPL-3.07the library need not be made freely available.Mozilla Public License, Version 2.0 (MPL-2.0) The Mozilla Public License (MPL-2.0)3 provides a different balance between proprietary and free software. TheMPL-2.0 is copyleft, similar to the GPL-3.0, but at the file level, easing the combi-nation of code under different licenses. For example, software that is a mixture ofboth proprietary and MPL code requires only modifications to files licensed underthe MPL to be made available.3https://opensource.org/licenses/MPL-2.08Chapter 4SurveyWe chose a survey instrument to investigate whether developers understand opensource licenses because we were interested in trends about which aspects of li-censes developers understand and which aspects developers struggle with. Trendsidentified in a survey can later be investigated in more depth using other instru-ments, such as interviews.4.1 MethodTo develop the survey, two authors of this paper posited a number of different casesof how software might be licensed, how a software system might be built out ofexisting components and how software might evolve. The other two authors ofthe paper, each of whom has extensive development experience, commented andhelped refine the cases. All authors of the paper then collaboratively developed aset of scenarios based on the identified cases. We originally planned to include fourlicenses in our survey. After piloting, we decided to reduce the number of licenses(to 3) and scenarios (to 7) to keep survey completion time under 40 minutes.The on-line survey we distributed consisted of:• six demographic questions,• seven hypothetical software development scenarios, some of which includedmultiple license combinations, and9• four open-ended questions.A copy of the full survey is available for reference.1Table 4.1 summarizes the seven development scenarios in the survey. The firstscenario description in Table 4.1 is laid out similar to how the questions appearedin the survey. The second scenario description shows how questions were posedabout different combinations of licenses. The remaining scenario descriptions arein compact form. These scenarios included a total of 45 cases. In this paper, werefer to the cases by their scenario number (as in S1) and the license (or licensesinvolved, as in S2-GPL-GPL). For each case, a participant could answer yes, noor unsure. If a participant answered unsure, an extra textbox appeared afterthe question asking for further clarification as an open-ended text comment. Foreach scenario, there was also an open-ended text box for the participant to state anyassumptions she or he made about the scenario posed.In developing the survey, we had to make a choice between full and long-specifications of all the details of a given scenario, such as detailed descriptionsof the architecture of the software being combined in some scenarios, versus morebrief descriptions. We chose the latter approach to make the survey tractable forparticipants and as we were interested in the assumptions participants may (or maynot) make.4.1.1 Participant RecruitmentWe recruited participants in two ways. First, three authors of the paper, with over6,000 followers combined, tweeted about the survey with a link to the survey. Sec-ond, the authors used mailing lists to advertise the survey.4.1.2 AnalysisWe analyzed the results of the survey both quantitatively and qualitatively.Quantitative analysis required correct answers for each of the 45 cases. Asdescribed in Chapter 1, we asked a lawyer with relevant expertise to rule on eachcase and to point out ambiguities and omissions that could affect the answer. This1https://goo.gl/v2JGol10Table 4.1: Survey scenariosScenario #1 - Layout similar to surveyJohn has been working on ToDoApp, his own personal task management application. ToDoApp is going to be a desktop-based application that willbe used exclusively by John on his own computer. To make sure he does not lose any of his very special tasks, John is planning to use a lightweightlibrary called LightDB to persist ToDoApp’s data.If LightDB is distributed under the following licenses, would John be allowed to use it as part of ToDoApp?GNU GPL3.0 (S1-GPL) ○ Yes ○ No ○ UnsureGNU LGPL3.0 (S1-LGPL) ○ Yes ○ No ○ UnsureMPL 2.0 (S1-MPL) ○ Yes ○ No ○ UnsureScenario #2 - Layout abbreviated but similar to surveyHaving used ToDoApp for three months, John realized how much his productivity has improved. To help other people manage their tasks as efficientlyas well, John has decided to make ToDoApp available as open source.If LightDB, the lightweight library used to persist ToDoApp’s data is distributed under GNU GPL 3.0 would John be allowed to make ToDoAppavailable under the following licenses?GNU GPL3.0 (S2-GPL-GPL) ○ Yes ○ No ○ UnsureGNU LGPL3.0 (S2-GPL-LGPL) ○ Yes ○ No ○ UnsureMPL 2.0 (S2-GPL-MPL) ○ Yes ○ No ○ UnsureSurvey repeats the question for LightDB under GNU LGPL 3.0 and MPL 2.0 for each license combination for ToDoApp.Scenario #3 - Compact FormAfter the success of the open source version of ToDoApp, John has decided to create a brand new commercial task management application: TaskPro.TaskPro is going to be built from scratch and use LightDB as a lightweight library to persist data.If LightDB, is distributed under {GNU GPL 3.0, GNU LGPL 3.0, MPL 2.0}, would John be allowed to make TaskPro commercially availableunder each of the {GNU GPL 3.0, GNU LGPL 3.0, MPL 2.0} licenses?Scenario #4 - Compact FormAs the lead developer of a new product at GreatSoftware Inc., Laura decided to use an existing authentication library she found on the Web calledSafeAuth. She realizes that SafeAuth could be improved using a stronger cryptographic algorithm when storing users’ information. The productis going to be released under a commercial software license, but Laura would like to release the improved version of SafeAuth as open source.If SafeAuth, is distributed under {GNU GPL 3.0, GNU LGPL 3.0, MPL 2.0}, would Laura and her team be allowed to release the improvedversion of SafeAuth under each of the {GNU GPL 3.0, GNU LGPL 3.0, MPL 2.0} licenses?Scenario #5 - Compact FormLaura who works for GreatSoftware Inc. has changed the open version of SafeAuth found on the Web and added a new, stronger cryptographicalgorithm to it. Despite Laura’s intentions to release the modified version of SafeAuth as open source, her manager sees a very strong competitiveadvantage for their products and decides not to release the modified version as open source.Considering that the new product is going to be distributed under a commercial license, if SafeAuth is distributed under the {GNU GPL 3.0, GNULGPL 3.0 and MPL 2.0}, can Laura and her team use the modified version as part of their new product?Scenario #6 - Compact FormShaoqing believes there are unhappy users out there willing to pay for a premium email client. To get to market faster, she decided to use an opensource implementation of the Simple Mail Transfer Protocol (SMTP).If the SMTP implementation is released under {GNU GPL 3.0, GNU LGPL 3.0, MPL 2.0}, would Shaoqing be allowed to fork the SMTP projectand change the fork’s license to the {GNU GPL 3.0, GNU LGPL 3.0, MPL 2.0} license in order to use it in her commercial e-mail client?Scenario #7 - Compact FormShaoqing has been trying to optimize the way her email client handles old e-mails. Browsing on the Web, she found a fairly sophisticated implemen-tation of a compression algorithm on a software developer’s blog that could be used on archived emails. The algorithm implementation has hundredsof lines of code and does not include an explicit license, but there is a copyright notice on the blog that states “All Rights Reserved”.If Shaoqing used the source code she found on the blog in her e-mail client, would be allowed to distribute the e-mail client commercially under the{GNU GPL 3.0, GNU LGPL 3.0, MPL 2.0} license?11allowed us to score responses from developers and also to check how many wereable to correctly identify the same issues.Qualitative analysis was performed on the open-ended comments provided byparticipants about answers for cases for which they were unsure and assumptionsmade for the scenarios in which the case appeared. Two of the authors open-codedthe collected comments [5]. We focused on comments and assumptions for ques-tions for which over 30% of the answers did not match the legal expert’s answer(14 cases) or for which over 10% of the answers were “unsure” (14 cases). Wechose 30% as the threshold for which answers did not match the legal expert’s an-swer to allow room for ambiguity; we believe a simple majority threshold wouldhave suggested the answers are always clearcut. We choose to analyze cases forwhich over 10% of the answers were “unsure” to capture where ambiguity seemedto be likely occurring. Applying these thresholds, nine out of the 28 cases identi-fied overlapped, resulting in the coding of comments for 19 cases and assumptionsfor four scenarios. We took the approach of assigning only one code to each com-ment, choosing the code that best described the comment. For comments for fiveof the cases (a total of 132 comments), each coder independently coded the caseand then the coders met to discuss the codes and form agreement. After five caseswere coded, the coders independently coded the remaining 14 cases and then metto form an agreement. The Cohen’s kappa score for the 14 cases that involved393 comments was .836. Similarly, the coders independently coded assumptionsfor one scenario (a total of 53 comments), met to form agreement and then inde-pendently coded the assumptions for the remaining three scenarios. The Cohen’skappa score for coding assumptions for the 282 assumptions across the three sce-narios was .853.4.2 Survey ResultsThe survey was started 825 times. Ultimately, 375 individuals completed the sur-vey for a completion rate of 45%. We report on the demographics of the partici-pants before providing a quantitative and qualitative analysis of the respondents’results. A data package containing aggregate results and participants’ comments12may be consulted for further information.24.2.1 ParticipantsParticipants came from all over the world (i.e., USA (267), UK (133), Germany(63), Canada (62), etc.). Table 4.2 summarizes the roles and experience of theparticipants. As the majority of the participants identified their role as developeror team lead, we will refer to our findings from the survey in terms of findingsabout developers. The participants had significant software development experi-ence, with 93% reporting at three years or more. The participants came from arange of size of company with 20% working in companies with over 5000 employ-ees down to 7% working solely. Most participants have previously chosen softwarelicenses and most contribute to open source. The table shows the top five languagesused, with participants reporting use of over 10 different programming languages.4.2.2 Quantitative ResultsTable 4.3 presents the participants’ survey answers. For each case, a bar chart isshown that compares the participants’ responses for the case to the legal expert’sopinion: a dot is used to indicate the response of the legal expert in each case. Foreach chart, the green bar represents “Yes” answers, the red bar represents “No”answers and the blue bar represents “Unsure” answers.As we delved into the details of participants’ responses, we noted an issue withScenario 5. By comparing the assumptions of the legal expert with the participants’assumptions, we determined that the scenario was not stated clearly enough interms of which source code would eventually be released. As a result, we haveomitted the results for Scenario 5 in Table 4.3 and we do not include Scenario 5 inany further reporting or analysis. Its removal leaves 42 cases for analysis.We consider that the participants’ answers for a case are correct when 70% orover of the participants’ answers match the legal expert’s. We chose this thresholdto account for the potential ambiguity in our short scenario descriptions, whichmay lead participants to be unsure of the meaning of the scenarios. Applying2https://www.cs.ubc.ca/labs/spl/projects/softwarelicensing/resources/UBC SPL softwarelicensing survey data.zip13Table 4.2: Participant demographicsDemographicsJob titleProgrammer/Soft. Dev./Soft. Eng. 67.2%Technical Lead/Team Leader 13.3%Other 13%Sys. Administrator/Network Engineer 3.2%Project Manager 2.9%Level of ExperienceMore than 7 years 61.3%At least 3 years 32.3%Less than 3 years 6.4%Ever chose a software project’s license?Yes 85.3%No 14.7%Often contribute to open source projects?Yes 74.7%No 25.3%Programming languages used the mostPython 51.6%JavaScript 25.7%C++ 25.4%Java 22.5%C 19.8%this threshold, participants’ responses matched the legal expert’s in 26 of the 42cases (62%). This rate of matching the legal expert’s opinion is encouraging asit suggests that participants understood many aspects of the open source licensesused in the scenarios. Participants also matched the opinion of the legal expertwhenever only one open source license is in use in the scenario (e.g., S2-GPL-GPL or S7-MPL-MPL, etc.). However, when more than one license is involved,the participants’ answers differed from the expert’s. We were not able to find anytrend in particular license combinations that were troublesome: four cases involvedGPL and LGPL, three cases involved GPL and MPL and five cases involved LGPLand MPL. From these results, we make the following two observations.14Observation 1. Developers cope well with single licenses even in complexscenarios.Observation 2. Developers have difficulty interpreting which actions areallowed in scenarios where more than one open source license is in use.To learn what aspects the participants struggled with, we focus our remaininganalysis on the 12 cases in which the participants answered differently than thelegal expert and the 13 cases for which over 10% of the participants were not surewhich answer to choose. These cases overlap, resulting in 17 cases on which wefocus our remaining analysis.4.2.3 Qualitative AnalysisThe qualitative analysis we conducted considered assumptions at the scenario leveland comments made by participants about individual cases.AssumptionsFor each scenario, participants had the opportunity to express assumptions that theymade when answering the cases. We coded the assumptions for the three scenarios(S2, S3 and S4) on which we focus our qualitative analysis.We ended up defining 11 codes to describe the assumptions; Table 4.4 de-scribes these codes. The codes demonstrate the wide range of concerns partici-pants considered when thinking about the use of the open source licenses. Forinstance, participants thought deeply about how the nature of the change—whichfiles (CD), who is making changes (AG), where the author was located (AG), ef-fects on the product architecture (TA)—could affect the situation. Participants alsothought deeply about how licenses might interact, such as how code under one li-cense might be re-licensed or dual licensed (LI), and whether the licenses in useincluded particular exhibits, such as Exhibit B for the MPL that enables an authorto mark certain files as incompatible with secondary licenses (LA). Other codescapture comments that we could not interpret (I), such as “All’s good”, descrip-15Table 4.3: Participant responses by case. Dots indicate answer of legal expert.Green bar for each case is a “Yes” answer; red bar is a “No” answer andblue bar is a “Unsure” answer.Case S1 Case S2-GPL Case S2-LGPLMPLLGPLGPL2.1%0.8%4.8%3.5%0.8%0.5%94.4%98.4%94.7%MPLLGPLGPL0.5%6.7%14.7%1.3%66.5%63.1%98.1%26.8%22.2%MPLLGPLGPL3.5%0.8%12.3%5.3%0.8%26%91.2%98.4%61.7%Case S2-MPL Case S3-GPL Case S3-LGPLMPLLGPLGPL14.8%13.9%6.2%10.8%8.3%0.5%74.5%77.7%93.3%MPLLGPLGPL1.9%5.6%13.9%12%60.5%58.4%86.1%33.9%27.7%MPLLGPLGPL2.9%1.3%11.6%11.2%4%24.5%85.8%94.7%64%Case S3-MPL Case S4-GPL Case S4-LGPLMPLLGPLGPL13.1%12.6%9.1%14.7%9.9%2.7%72.2%77.5%88.2%MPLLGPLGPL1.3%5.3%9.1%2.7%83.7%82.1%96%10.9%8.8%MPLLGPLGPL5.6%2.1%11.1%24.9%1.9%70.5%69.5%96%18.4%Case S4-MPL Case S5 - Removed Case S6-GPLMPLLGPLGPL15.5%16.4%7.5%31%29.2%2.1%53.5%54.4%90.3%MPLLGPLGPL1.6%3.5%7%24.2%90%86.8%74.2%6.5%6.2%Case S6-LGPL Case S6-MPL Case S7MPLLGPLGPL6.2%2.4%8.4%36.4%16.9%77.5%57.4%80.6%14.1%MPLLGPLGPL13.9%14.1%8.9%42.9%41.5%11.1%43.2%44.4%80.1%MPLLGPLGPL5.3%5.3%7.5%92.5%92%88.5%2.1%2.7%4%16Table 4.4: Codes for assumptionsAG Authorship/Geo Who is author and where arethey locatedCD Change Dependent What system files are to bemodifiedI Invalid Text could not be interpretedIQ Invalid Question Participant felt question wasinvalidLA License Assumption Characteristics of licensesLI License Interactions Ramifications of more thanone licenseTA Tech. Assumption System structure, deploy-ment, etc.PA Patent Assumption Patent or IPSC Specific Case Dual licensingTeA Term Assumption Meaning of term unclear inlicense or scenarioU Unsure Unsure about scenario or li-censetions of why the participant felt the question was invalid (IQ), where participantsquestioned the meaning of terms in the question (i.e., TeA) and where participantswere unsure, such as not knowing a license being asked about (i.e., U).Table 4.6 states the frequency of each assumption code and indicates the totalnumber of assumptions received for each scenario (ranging from 14% of the par-ticipants stating assumptions for S4 to 30% of the participants stating assumptionsfor S3). For scenario 2, assumptions about the technical aspects of the scenariowere most frequent, with over 42% of the assumptions having the TA code. Thisscenario involved an open source application that might be licensed differentlythan an open source library that the application relies on. Participants consideredsuch questions as how the library might be used; for instance, would the library bestatically or dynamically linked to the application?Participants also questioned how the code would be structured and releasedfor scenario 3 (52% of codes were tagged with the TA code), in which partic-ipants were asked to consider a commercial distribution of a product including17open source. For this scenario, participants differed in response from the expert inthree of nine cases, with two of those cases involving MPL which describes licenseconstraints at the file level. The difference in participant responses from the expertmay also be related to the larger number of questions by participants about termsused in the scenario, such as the precise meaning of the term “commercial”; theterm assumption code (TeA) accounted for 22% of the codes for this scenario.For scenario 4, which described a developer making modifications to an opensource library and releasing the modified version of the library as open source, themost frequently occurring code is about the nature of the change, specifically whichand how many files might be changed (over 18% of the codes are CD). Participantresponses for three of the nine cases in this scenario did not match the legal expert’sopinion; all cases that differed involved the GPL and LGPL licenses, includinghow they interact with each other and how they interact with MPL. Although manyparticipants understood that MPL places file-based restrictions on subsequent usewhen modified, the majority of participants thought there were ways to structurethe modifications to enable MPL licensed code to be redistributed as GPL or LGPLcode (S4-MPL-GPL and S4-MPL-LGPL).For scenarios 2 and 4, the second most frequently occurring group of codesrelates to licenses. For scenario 2, 28% of the assumptions questioned aspects ofthe licenses, such as what relicensing is possible for source under a given opensource license and the possibilities for dual licensing code (i.e., the LI and LAcodes). Over 20% of the assumptions for scenario 4 relate to licenses (i.e., 20.8%of codes are LA and 7.3% of codes are LI). Some assumptions with these codesindicate significant knowledge of one or more of the open source licenses used inthe scenarios, such as referencing the “tri-license” header.This analysis leads us to two additional observations.Observation 3. Developers understand technical decisions will impactopen source license use.Observation 4. Developers recognize that there are interactions between18open source licenses, but those interactions were not always correctly inter-preted.Case CommentsWe also analyzed 462 comments provided by participants for the 17 cases of inter-est. Table 4.5 describes the seven codes that resulted from the process describedin Chapter 4.1.2; these codes include comments about license interactions (LI),specific cases of relicensing or dual licensing (SC), technical details regarding thescenario (TD), and uncertainty about the scenario (U, A, Am and U).Table 4.7 reports on the frequency of occurrences of each code in the commentsfor each case. From this table, it becomes evident that different combinations ofcodes appear for the same license combinations: the S2-GPL-LGPL case, as anexample, has 20% of comments as license interactions, but license interactionswere not a concern for the S3-GPL-LGPL and S6-LGPL-GPL cases. These threecases differ in how the software is used, changed and combined (i.e., the technicalcontext), leading to the following observation.Observation 5. Questions that arise about the use of multiple open sourcelicenses are situationally dependent.The most frequently occurring code across the cases is the Unsure code. Thisuncertainty often had to do with details related to the licenses, such as “don’t knowif GPL allows it” and “don’t know to which point GPL is viral”. The prevalence ofthis code leads to the following observation.Observation 6. A number of developers lack knowledge of the details ofopen source licenses.The second more frequently occurring code across the cases studied was forlicense interactions (LI). Comments made by participants echoed concerns raised19Table 4.5: Codes for comments for casesA Assumption An assumption about thecase.Am Ambiguity Description of ambiguouspoint in case.I Invalid Meaning of comment un-clear.LI License Interaction Concern about actions pos-sible with more than one li-cense.SC Specific Case Concern about relicensing ordual license.TD Technical Detail Concern about technical as-pects of case.U Unsure Case is unclear.Table 4.6: Codes describing assumptionsScenario # Code (%) TotalAG CD I IQ LA LI PA SC TA TeA U #Scenario 2 2.1 5.2 6.3 3.1 20.8 7.3 2.1 4.2 42.7 1.0 5.2 96Scenario 3 0.9 1.8 4.4 0.9 8.9 2.7 0.9 - 52.2 22.1 5.3 113Scenario 4 3.8 18.9 15.1 7.6 13.2 9.4 5.7 3.8 11.3 5.7 5.7 53in the assumption coding, such as which licenses could subsume other licenses,when code could be dual licensed and when code could be re-licensed. This datahelps reinforce Observation 4.4.2.4 Detailed ExamplesWe look at two cases in more detail to provide more context for the findings thatparticipants struggled with license interactions and technical assumptions. The twocases we consider are from scenario 2, which involves the use of an existing opensource library (LightDB) to build an application that will also be released underan open source license (ToDoApp). A full description of scenario 2 is available inTable 4.1.20License InteractionFor the S2-GPL-MPL case, only 63.1% of participants responded with an answerthat matched the legal expert’s opinion and 14.7% of the participants were unsure.After the unsure code, the second most frequently occurring code for this casewas the license interaction (LI) code. In these comments, participants expressedtheir doubts about appropriate interactions. For instance, one participant wrote:“I don’t understand how the secondary license restriction and GPL interact”. An-other wrote: “MPL/(L)GPL dual licensing is popular, so I assume there is a reasonfor that”. Even in a comment labelled unsure, a participant recognized license in-teractions might be relevant: “Have not studied the details; generically expecttrouble when mixing non-GPL licenses with GPL so would have guessed ’No’ ifforced”. These comments highlight that although participants recognize licenseinteraction, they do not understand the intricate details of when interactions occuror the results.Technical DetailsFor the S2-GPL-LGPL case, only 66.5% of participants responded with an answerthat matched the legal expert’s opinion and 12.3% were unsure.After the unsure code, the most frequently occurring code was the technicaldetails (TD) code. Participants expressed a need to understand more technical de-tails about the scenario in order to interpret how the licenses would interact. Forexample, one participant wrote: “It depends on how ToDoApp is distributed. IfToDoApp was only distributed as source then this would be fine. For binary dis-tributions, if ToDoApp is statically linked against LightDB it must be distributedunder GPL. The case is less clear for dynamically linked code - I understand theFSF and other organizations disagree!”. This comment indicates knowledge ofthe licenses and views of the communities around the licenses. Other participantsknew the technical details might matter, but not why: “I think it might depend onhow the two libraries are linked together”.214.3 Threats to ValidityThe survey provided links to the licenses referred to in the survey but did not re-quire participants to answer questions to validate their understanding of individuallicenses, which may have affected the construct validity of the survey. We madethis choice for two reasons. First, we wanted to allow participants to interact withthe licenses as they normally would; for instance, some participants might relyon their knowledge of the licenses, some might reference the licenses to answersurvey questions and others might use other sources, such as choosealicense.comor knowledgeable colleagues. The survey asked if participants used additional re-sources: 36% reported using resources such as Wikipedia, TLDRlegal.com andchoosealicense.com.Second, the overall survey is lengthy and adding more questions to validateunderstanding of each of three licenses would be even more time consuming forparticipants. The choice not to validate individual license understanding may haveresulted in participants answering questions for which they have no background.For some survey questions, we received a large number of comments, such as over100; the insight in many of these comments suggests many participants had suffi-cient background to answer the questions posed. A large number of individuals,825, started the survey with 45% completing the survey; some of the individualsthat started the survey but did not finish might represent individuals without suffi-cient license knowledge.The construct validity may also have been affected by the particular three li-censes we chose to use in the survey. We deliberately picked a mixture of restrictive(i.e., GPL) and permissive (i.e., MPL) licenses to trigger license interactions. Ourfindings might differ if only a set of more permissive licenses were used. Futurework should investigate developers’ understanding of fine-grained license interac-tions.The survey has limitations with regards to content validity, which considersthe degree to which the survey investigates developers knowledge of open sourcelicense use. The survey questions required participants to understand individuallicenses, such as GPL, and how the use of the license affects scenarios involvinginteractions with other licenses. Furthermore, because the questions were pre-22sented as multiple choice problems, they are likely not as complex as many of thescenarios faced in practice. As noted above, the survey is limited in what can beconcluded about the knowledge of individual open source licenses.Another issue we faced in the design of the survey was the specificity to pro-vide in the scenarios posed in the survey questions. As some of the participantsnoted, the wording of the scenarios had some ambiguity. In particular, participantsstruggled with the wording in scenario 3 in which the term “commercial” was used;the confusion involved whether the term implied any changes made to open sourcesoftware were to be kept as closed source or whether the term meant money maybe charged for use of the resultant software. We did not foresee this ambiguityand note that the term commercial has also been used in previous surveys on opensource software [20]. The ambiguity also did not arise in pilots we conducted of thesurvey questions. The lack of specificity may have also caused differences betweenthe legal expert’s reading of the cases and the participants’. We have tried to miti-gate the effects of question ambiguity through careful analysis of the legal expert’sinput and careful analysis and reporting of the qualitative comments provided byparticipants.As described in Section 4.2, the participants in the survey came from a largenumber of countries, used a wide variety of programming languages and largelydescribed their job as a software developer. As noted above, the techniques weused to recruit participants for the survey may have biased the population fromwhich the participants are drawn. In particular, we observed that the large majorityof the participants (85.3%) had chosen a software project’s license before, whichmight be an instance of self-selection bias. The diversity of participants suggeststhe results may be applicable to a reasonable segment of open source developers.4.4 Summary of ResultsThe software developers who took our survey were able to correctly interpret avariety of simple and complex development scenarios involving one license (Ob-servation 1). These software developers understand that how the software is builtaffects license interactions, but they have neither a consistent and deep grasp ofwhat technical details matter (Observation 2 and Observation 3) nor a solid un-23derstanding of the intricacies of how licenses interact (Observation 4). Developersare aware that different characteristics matter in different situations of multiple li-cense use (Observation 5), but overall lack the knowledge to tease apart licenseinteractions across multiple situations (Observation 6).24Table 4.7: Codes describing casesCase Code (%)A Am I LI SC TD U #Scenario 2S2-GPL-LGPL - - - 20.0 - 32.0 48.0 25S2-GPL-MPL - - 2.2 17.4 6.5 8.7 65.2 46S2-LGPL-MPL - - 5.9 14.7 2.9 11.8 64.7 34S2-MPL-GPL - 2.5 7.5 25.0 7.5 - 57.5 40S2-MPL-LGPL - 5.6 - 19.4 5.6 - 69.4 36Scenario 3S3-GPL-LGPL - - 46.7 - - 26.7 26.7 15S3-GPL-MPL 2.9 - 11.4 8.6 5.7 8.6 62.9 35S3-LGPL-MPL - - 8.0 12.0 4.0 4.0 72.0 25S3-MPL-GPL 3.5 - 6.9 17.2 3.5 3.5 65.5 29S3-MPL-LGPL - 3.6 3.6 17.9 3.6 3.6 67.9 28Scenario 4S4-LGPL-GPL - - 15.4 15.4 46.2 - 23.1 13S4-LGPL-MPL - - 5.6 33.3 5.6 5.6 50.0 18S4-MPL-GPL - 3.3 10.0 23.3 13.3 - 50.0 30S4-MPL-LGPL - 6.1 15.2 21.2 12.1 - 45.5 33Scenario 6S6-LGPL-GPL - 7.1 7.1 - - - 85.7 14S6-MPL-GPL - - - 9.5 33.3 - 57.1 21S6-MPL-LGPL - - - 10.0 10.0 - 80.0 2025Chapter 5The Context of LicenseIncompatibilitiesThe survey results indicate that software developers struggle with license incom-patibilities and that technical details and license interaction seem to be particularlyimportant. The survey considered hypothetical cases, with limited informationabout real cases gathered through open-ended comments by participants.To gain insight into the context in which license incompatibilities arise, I posedtwo research questions:RQ#1 In what real-life situations do license incompatibilities arise?RQ#2 How do software developers reason about and handle license incompatibil-ities?To investigate the first question, I mined and analyzed questions posed by de-velopers, and the answers they received, on popular online question-and-answercommunities. To investigate both questions, I also interviewed software develop-ers in industry to better understand how software developers approach and handlelicense incompatibility issues in practice.265.1 Mining Real-World CasesTo obtain real-world cases involving software licensing issues, I mined informationfrom StackExchange, a popular network of question-and-answer (Q&A) commu-nities. One community within StackExchange is Open Source Stack Exchange,which is a community for ”people organizing, marketing or licensing open sourcedevelopment projects”1. In addition to this source, I considered two other StackEx-change communities —Software Engineering and Stack Overflow—because theseare popular communities that also deal with licensing issues and may be morelikely to see a mix of open and closed source licensing questions.To find real-world cases on these sites, I performed queries about software li-censes. To focus the exploration, I narrowed my queries to those involving twoof the three licenses considered in the survey: GPL, LGPL and MPL. I made thischoice to increase the likelihood of finding discussions of license incompatibilities,because more than one license is mentioned, and to follow-up on situations hintedat in the survey. I performed three queries on each of the three StackExchangecommunities to search for questions containing the following combinations in theirbody: ”GPL” and ”LGPL”, ”GPL” and ”MPL”, or ”LGPL” and ”MPL”. The re-sults of these queries are exchanges from the community that consist of a questionwith different answers and threaded replies to each answer.Performing the queries on the StackExchange communities produced 60 re-sults. Table 5.1 shows the number of questions retrieved from the different com-munities for each search query. As analysis of each result is qualitative, I chose tosample from the results to analyze whether a license incompatibility had occurred.I randomly sampled a third of the results to analyze. For each selected result, Isummarized the question and tagged the question with codes from the qualitativeanalysis of the survey’s case comments (Table 4.5). I also considered whether anynew codes needed to be added to capture the intent of the question; no new codesemerged. Table 5.2 reports on the number of times each code was assigned to oneof the questions. A full list of the questions analyzed, their summary and assignedcodes can be found in Appendix A.As Table 5.2 shows, seven of the 20 questions analyzed were assigned the1https://opensource.stackexchange.com/27Table 5.1: Number of questions per community for each queryCommunity GPL and LGPL GPL and MPL LGPL and MPLStack Overflow 30 4 3Software Engineering 15 0 4Open Source 4 0 0Table 5.2: Codes used to describe real-world casesCode # Questions DescriptionInvalid (I) 7 Unrelated to licensing.License Interaction (LI) 9 Actions possible with more than one license.Specific Case (SC) 2 Relicensing or dual license.Technical Detail (TD) 10 Technical aspects of case.invalid code (I), meaning that the question was not related to licensing issues.These questions are not considered in any further analysis and can be seen as falsepositives due to the fact that our search queries considered any questions containingtwo of the three open source licenses in their body.For each of the analyzed questions assigned a valid code, Table 5.3 showsthe exact codes assigned to the question. From the analysis of the remaining 13questions, three kinds of contextual situations emerged. I describe each in turn.Situation #1: Constrained Software EvolutionMany of the cases analyzed involved developers looking for components releasedunder permissive licenses because they were unable to use open source componentsunder more restrictive licenses such as GPL and LGPL. The authors had a specifictask they were trying to complete and were looking for existing open source com-ponents that implemented the required functionality. This theme occurred in eightcases (Questions 1, 3, 5, 6, 8, 10, 11, and 13).For example, the author of question #6 was asking for a recommendation ofan asymmetric cryptographic algorithm. The author was willing to implement thealgorithm from scratch or use an existing library that implements the algorithm,but the library could not be licensed under GPL or LGPL because the project usesstatic linking, and the author did not want to have GPL or LGPL apply to their28Table 5.3: Codes assigned to each question# Community Code(s)0 Software Engineering SC, TD1 Stack Overflow SC3 Stack Overflow TD4 Software Engineering TD, LI5 Stack Overflow TD6 Stack Overflow TD7 Stack Overflow LI8 Stack Overflow TD, LI10 Stack Overflow TD, LI11 Software Engineering LI, TD13 Open Source LI, TD15 Software Engineering TD, LI19 Stack Overflow LI, TDentire project. Similarly, the author of question #5 was trying to improve the waya legacy application encodes/decodes video, but seemed to be constrained becausethe current solution was built around an existing open source library (ffmpeg).The author recognizes that ffmpeg is a popular solution to the problem at hand,but is looking for an alternative because a co-worker made him believe that changesor improvements to the existing code would result in a violation of ffmpeg’slicensing requirements.Situation #2: Technical Decisions Impact Future LicensingAnother theme in the analyzed question was that of a developer who is strugglingwith licensing issues because of previous technical decisions. Some of these weredue to characteristics of the project itself. This theme occurred in six question(Questions 3, 5, 11, 13, 15, and 19).For instance, the author of question #3 is in need of a library for an Androidapplication, but states that libraries under GPL or LGPL cannot be used. One of therespondents (OleGG) seems to think that the author holds a misconception aboutLGPL and suggests that it is possible to use LGPL components without making theauthor’s code open source. Another respondent (bovine) replies and explains that29OleGG’s suggestion only applies when there is a ”suitable shared library mecha-nism”, which is not the case for Android projects by definiton because the resultingapplication would be released as a single Dalvik Executable (DEX) file.In a different question (#11), a developer is facing difficulties while trying toeliminate dependencies acquired during the development of a prototype. The teamhad decided to use a number of open source components and made design deci-sions based on the existence of these components. Later on, they realized that oneof the components imposed licensing requirements that were incompatible withtheir intended use, requiring a significant amount of effort to work around previousdesign decisions and eliminate that dependency.Situation #3: Developers Struggle to Find Appropriate LicensesIn most of the cases analyzed, authors described facing difficulties related to li-censing while working with existing open source components. In a few cases, incontrast, authors describe trying to choose a license for their own projects. Theyseem aware of the implications of licensing decisions and are trying to better un-derstand their options. Questions #0 and #4 are examples of this theme. The authorof the first question seems to be aware of the implications of a number of popu-lar licenses, but is unable to identify which licensing option meets a number ofrequirements. Similarly, the author of the second question needs help to confirmhis understanding of how MPL and LGPL relate to the specific details of a project.The author wants to make sure he chooses a license that effectively imposes certainrestrictions on those making use of his open source component in the future.5.2 InterviewsTo better understand the context in which license incompatibility issues take placeand how developers approach and handle these issues in practice, I conducted semi-structured interviews with developers in industry. Appendix B contains the scriptfor these interviews.To find participants who are more likely to have experienced license incom-patibility issues in practice, I recruited software developers that have built or arecurrently building on open source software in their projects. Six developers vol-30Table 5.4: Job title and company size for each participantP# Job Title Company SizeP1 Software Developer (DevOps) 51 to 200P2 Senior Software Engineer 501 to 1000P3 Solutions Architect 51 to 200P4 Principal Engineer 201 to 500P5 Principal Engineer 201 to 500P6 Software Engineer (DevOps) 201 to 500unteered to participate and were interviewed via a web conferencing system. Ta-ble 5.4 shows, for each participant, their job title and company’s size. All partici-pants are male. The interviews were recorded and simultaneously analyzed by anexperienced researcher in the field and the author. We then compared and discussedour findings to identify themes that might shed light on how developers handle li-cense incompatibility situations in practice. I describe each one of the themes inturn.Theme #1: Developers and software development companies are cautiousof restrictive licenses. Five interviewees mentioned avoiding software compo-nents under restrictive licenses, such as GPL. They also mentioned that, in suchsituations, they tend to consider alternative components available under permissivelicenses.Two interviewees mentioned situations in which GPL components were rewrit-ten as the functionality was required, but GPL components could not be used. Aninterviewee also mentioned that, in his organization, there can be requests to usecomponents under the LGPL license; such a request would be made if the compo-nent could be used in the right technical structure or if the component was the bestin its class.Theme #2: Developers use the technical architecture of the product to en-able the use of components under restrictive licenses. Three interviewees talkedabout using the architecture of the system to enable the use of components underrestrictive licenses. One of them mentioned a situation in which a GPL licensedcomponent was used in development, but not in the version of the product shippedto customers.31Similarly, other participants talked about how specific architectural decisionscan enable the use of components under restrictive licenses, e.g., by offering soft-ware as a service or having the end-user download a specific component.Theme #3: Developers assume communities use a certain kind of license.Three interviewees mentioned that they believe certain open source communitieswould generally use permissive licenses. One of the interviewees seemed to believethat JavaScript packages found on npm are usually available under permissive li-censes. While talking about a Java project on which he had been working, anotherparticipant admitted to making what is a dangerous assumption in his opinion:namely that components available through Maven are under permissive licenses.Finally, a third participant, as a member of an open source community, suggestedthat most members of that community use a specific license.Theme #4: License incompatibility situations arise but not frequently. Fiveinterviewees mentioned remembering a situation in which license incompatibilitywas a concern, but such situations do not seem to happen often for these individu-als. One interviewee mentioned the frequency of about once per year dealing witha license incompatibility between components.Theme #5: Developers use specialized tools to detect licenses. Three inter-viewees mentioned having used specialized tools to identify what licenses are usedby a project and its dependencies and help them detect possible licensing issues.5.3 Threats to ValidityThe extent to which results of the real-world cases describe the frequency of situa-tions in which license compatibilities arise is unclear for two reasons.First, the cases I analyzed were obtained from a single source (StackExchange)and might not be representative of all kinds of licensing incompatibility issuesfaced by software developers in practice. I focused on StackExchange insteadof other online communities dedicated to specific licenses because: 1) StackEx-change communities are widely used by software developers,StackOverflow alonehas more than 14 million questions and is visited by 51,000 developers per monthon average.2 and 2) StackExchange draws a wide variety of developers given its2https://stackoverflow.com/company32diverse forums.Second, I obtained the real-world cases using search queries that included thenames of the three licenses used in the survey. I made this decision because thepurpose of this analysis is to better understand the context in which licensing is-sues first identified in the survey happen. Just as the results of the survey are notnecessarily representative of all kinds of licensing issues developers struggle with,the contextual situations identified in the real-world cases I analyzed cannot begeneralized to all other licenses. A better understanding of the types of existingopen source licenses and of their different characteristics would help us understandto what extent the contextual situations I identified can be generalized.The interviews with software developers also may not represent all themes thatarise in license incompatibility scenarios. The population of developers was com-prised of developers motivated to discuss issues involving open source licenses.They came from organizations that had between 51 and 1000 employees. Licensingincompatibility issues might be more or less frequent in organizations of differentsizes and the themes that emerged could be different given a different population.5.4 Summary of ResultsThe analysis of real-world cases suggests that the contextual situations in whichlicense incompatibility takes place involve a mix of technical details and licenseinteractions. In many of these cases, technical decisions had an impact on futurelicensing issues, while in other cases licensing issues imposed constraints on soft-ware evolution. In a few of the cases developers were struggling to understandwhat licensing approach to use in order to impose the restrictions they intended fortheir own open source projects.The developers I interviewed are cautious of restrictive licenses, such as GPLand LGPL. They use specialized tools to detect the licenses being used in theirprojects and possible licensing issues. When faced with a situation in which acomponent that suits their needs is under a restrictive license, developers tend torely on open source communities to find alternative components that can be used.They sometimes leverage the product’s technical architecture to enable the use ofcomponents under restrictive licenses and might rewrite the required functionality33if necessary.34Chapter 6Conclusion and Future WorkOpen source software is not a self-contained world with a specific set of develop-ers involved and a small set of open source licenses with well-defined interactions.Many closed-source, commercially-oriented software projects rely on open sourcesoftware. Many open source licenses exist with different ramifications depend-ing on how the software with different licenses interact (i.e., via dynamic linking,copying of source code, etc.). Many software developers work on a variety of opensource projects with different licenses and move back and forth between open andclosed source software projects.The results of our survey indicate that many of the 375 respondents to our sur-vey, who were largely software developers, have a good grasp of at least three opensource licenses (MPL, GPL, LGPL) when only one of those licenses is being used.When a combination of open source licenses is being used, developers struggleto ask the right questions for the situation, such as whether to focus on technicaldetails of the situation or generic issues of how two licenses interact (i.e., is onelicense more permissive than another). Overall, our survey indicates that the devel-opers who responded lack the knowledge and understanding to tease apart licenseinteractions across multiple situations.The analysis of real-world cases and the interviews with experienced softwaredevelopers in industry shed light on the context in which license incompatibilityissues take place in practice.We found that although some developers make use of specialized tools to iden-35tify licenses being used in a project and potential problems arising from the in-teraction of those licenses, others rely on licensing guidelines provided by theirorganization to decide if a component under a license can be used.Across the cases we analyzed and interviews we conducted, there is a clear ten-dency towards avoiding restrictive licenses in favour of more permissive licenses.This tendency can be seen in many real-world cases in which developers ask forhelp to find a component under a permissive license and that satisfies their needsas well as from the experiences of the developers I interviewed and the guidelinesadopted at their organizations.In situations where a specific component seems to fit the developers’ needs butis incompatible with their project’s licensing guidelines, the software developersinterviewed and the cases analyzed suggest at least three approaches to resolve thisissue.The first approach is to find an alternative component available under a per-missive license. The increasing number of open source components available todevelopers allows them to look for alternative components released under a licensecompatible with their projects. In this case, developers rely on the open sourcecommunity and seemed fairly confident that many of the components availablethrough existing package management tools, such as npm and Maven, are underpermissive licenses.The second approach is to rewrite a component from scratch. Dependingon the effort necessary to implement the required functionality, developers mayprefer to rewrite the component themselves and avoid any risks involved in usingcomponents under restrictive licenses.The third approach is to restructure the system code to enable the use of acomponent. In some cases, developers can enable the use of certain componentsor work around them by restructuring the way that component is being used intheir project. This was observed in multiple interviews and the examples given in-volved changes to the packaging and distribution of the software (e.g., by adoptinga software as a service (SaaS) distribution model) and changes to the architectureof the product (e.g., removing a component from a software product and allowingthe end-user to download such component).To improve the support for developers in dealing with license incompatibili-36ties, enhanced tool support is needed. This enhanced support can build on existingefforts of researchers. For example, Germa´n and Hassan [7] provide a model foridentifying possible mismatches when different open source licenses interact, butthis model is not able to recognize code structures that cause these mismatches.Vendome’s research goes further, suggesting a need for tools that are able to findincompatibilities, explain why there is an incompatibility, and recommend a wayto fix incompatibilities, possibly through a license change or through code restruc-turing [18]. The comments we analyzed from participants completing our surveyand the analysis of the context in which license incompatibility happens suggestthat such a recommendation engine may need to be more extensive and robust thansuggested by Vendome. Our results indicate a need for tools capable of analyzingthe structure of the code and the technical details of the project while taking intoaccount the exact requirements imposed by the licenses involved in that project.Such tools should be able to suggest ways to restructure the code and/or changethe open source code to enable the use of a component without causing license in-compatibilities. This type of recommender may require a means of formally mod-elling licenses, the effects of a license in terms of how it is used in code, and thevariability allowed by the license in terms of code interactions. This formal modelwould then need to be potentially integrated with code refactoring tools, to per-haps automatically search for refactorings that would allow a license compatibilitycheck to pass. Models, such as that introduced by Alspaugh and colleagues [3],may provide a starting point for building such tools.37Bibliography[1] On the continuing decline of the gpl. http://blogs.the451group.com/opensource/2011/12/15/on-the-continuing-decline-of-the-gpl/, 2011. →pages 5[2] D. A. Almeida, G. C. Murphy, G. Wilson, and M. Hoye. Do softwaredevelopers understand open source licenses? In Proceedings of the 25thInternational Conference on Program Comprehension, ICPC ’17, pages1–11. IEEE Press, 2017. → pages v[3] T. A. Alspaugh, W. Scacchi, and H. U. Asuncion. Software licenses incontext: The challenge of heterogeneously-licensed systems. Journal of theAssociation for Information Systems, 11(11):730, 2010. → pages 6, 37[4] S. Clarke. Measuring API usability. Dr. Dobb’s Journal, SpecialWindows/NET Supplement, 2004. → pages 1[5] J. Corbin and A. Strauss. Grounded theory research: Procedures, canons andevaluation criteria. Qualitative Sociology, 13:3–21, 1990. → pages 12[6] M. Di Penta, D. M. German, Y.-G. Gue´he´neuc, and G. Antoniol. Anexploratory study of the evolution of software licensing. In Proceedings ofthe 32Nd ACM/IEEE International Conference on Software Engineering -Volume 1, ICSE ’10, pages 145–154. ACM, 2010. → pages 5[7] D. M. German and A. E. Hassan. License integration patterns: Addressinglicense mismatches in component-based development. In Proceedings of the31st International Conference on Software Engineering, ICSE ’09, pages188–198. IEEE Computer Society, 2009. → pages 6, 37[8] D. M. German, M. Di Penta, and J. Davies. Understanding and auditing thelicensing of open source software distributions. In Proceedings of the 2010IEEE 18th International Conference on Program Comprehension, ICPC ’10,pages 84–93. IEEE Computer Society, 2010. → pages 238[9] D. M. German, Y. Manabe, and K. Inoue. A sentence-matching method forautomatic license identification of source code files. In Proceedings of theIEEE/ACM International Conference on Automated Software Engineering,ASE ’10, pages 437–446. ACM, 2010. → pages 6[10] A. Hemel, K. T. Kalleberg, R. Vermaas, and E. Dolstra. Finding softwarelicense violations through binary code clone detection. In Proceedings of the8th Working Conference on Mining Software Repositories, MSR ’11, pages63–72. ACM, 2011. → pages 2[11] G. Hofmann, D. Riehle, C. Kolassa, and W. Mauerer. A dual model of opensource license growth. In IFIP International Conference on Open SourceSystems, pages 245–256. Springer, 2013. → pages 5[12] M. P. Robillard and R. Deline. A field study of api learning obstacles.Empirical Software Engineering, 16(6):703–732, Dec. 2011. → pages 1[13] M. B. Rosson and J. M. Carroll. The reuse of uses in smalltalkprogramming. ACM Trans. Comput.-Hum. Interact., 3(3):219–253, Sept.1996. → pages 1[14] R. Sen, C. Subramaniam, and M. Nelson. Determinants of the choice ofopen source software license. J. Manage. Inf. Syst., 25(3):207–240, Dec.2008. → pages 5[15] Sonatype. 2015 state of the software supply chain report: Hidden speedbumps on the road to ”continuous”, 2015. → pages 1[16] K. J. Stewart, A. P. Ammeter, and L. M. Maruping. Impacts of licensechoice and organizational sponsorship on user interest and developmentactivity in open source software projects. Info. Sys. Research, 17(2):126–144, June 2006. → pages 5[17] C. Vendome. A large scale study of license usage on github. In Proceedingsof the 37th International Conference on Software Engineering - Volume 2,ICSE ’15, pages 772–774. IEEE Press, 2015. → pages 1[18] C. Vendome and D. Poshyvanyk. Assisting developers with licensecompliance. In Proceedings of the 38th International Conference onSoftware Engineering Companion, ICSE ’16, pages 811–814. ACM, 2016.→ pages 3739[19] C. Vendome, M. Linares-Va´squez, G. Bavota, M. Di Penta, D. German, andD. Poshyvanyk. License usage and changes: A large-scale study of javaprojects on github. In Proceedings of the 2015 IEEE 23rd InternationalConference on Program Comprehension, ICPC ’15, pages 218–228. IEEEPress, 2015. → pages 6[20] C. Vendome, M. Linares-Vasquez, G. Bavota, M. Di Penta, D. M. German,and D. Poshyvanyk. When and why developers adopt and change softwarelicenses. In Proceedings of the 2015 IEEE International Conference onSoftware Maintenance and Evolution (ICSME), ICSME ’15, pages 31–40.IEEE Computer Society, 2015. → pages 2, 6, 7, 23[21] C. Vendome, M. Linares-Va´squez, G. Bavota, M. Di Penta, D. German, andD. Poshyvanyk. Machine learning-based detection of open source licenseexceptions. In Proceedings of the 39th International Conference on SoftwareEngineering, ICSE ’17, pages 118–129. IEEE Press, 2017. → pages 640Appendix AStackExchange CasesQuestion #0: Help me choose an Open-Source licenseLink: https://softwareengineering.stackexchange.com/questions/50764/help-me-choose-an-open-source-licenseCodes: Specific Case, Technical DetailsSummary: Question asks for help to select a license that fulfills a numberof requirements. The author is implementing a library and wants to allow itsuse in other open source projects regardless of their licenses, but not in closed-source/commercial projects unless s/he grants written authorization. The proposedsolution is dual licensing and answers suggest it isn’t possible to fulfill all of therequirements.Question #1: digital signature with specific itext version 4.2.0Link: https://stackoverflow.com/questions/25879897/digital-signature-with-specific-itext-version-4-2-0Codes: Specific CaseSummary: The author wants to know if the iText library offers a certain featurein version 4.2 (instead of 5.0) because the latest version has been released underAGPL (according to its GitHub repository, they ”moved to the AGPL to improvetheir ability to sell commercial licenses”). Version 4.2 was released under duallicensing (MPL/LGPL).Question #2: Use default authentication and separate cloaking/impersonation in41DCOM callLink: https://stackoverflow.com/questions/1993651/use-default-authentication-and-separate-cloaking-impersonation-in-dcom-callCodes: InvalidSummary: Author has a programming question and mentions that his project willbe released under GPL/MPL as an incentive (”So your help will go GPL/MPL.”).Question #3: Use default authentication and separate cloaking/impersonation inDCOM callLink: https://stackoverflow.com/questions/9213152/override-mapview-tile-sourceCodes: Technical DetailsSummary: Author is looking for an Android component/library that overrides theMapView behaviour. The component cannot be based on GPL/LGPL. One of theanswers suggests a couple of libraries that are under LGPL, but the author reiteratesthat he was trying to avoid anything under LGPL. The respondent clarifies to theauthor that it’s possible to use LGPL libraries without making his code available.A second respondent goes further and explains that it’s possible to use LGPL ifthere’s a ”suitable shared library mechanism”, which is not the case for Androidbecause the resulting application will be a single DEX (Dalvik Executable format)file.Question #4: Mozilla Public License (MPL 2.0) vs Lesser GNU General PublicLicense (LGPL 3.0)Link: https://softwareengineering.stackexchange.com/questions/221365/mozilla-public-license-mpl-2-0-vs-lesser-gnu-general-public-license-lgpl-3-0Codes: Technical Details, License InteractionSummary: The author wants to release a library as open source while making itpossible for others to use it in proprietary/closed projects. He is considering eitherLGPL or MPL and identifies the type of linking as the main difference (static forMPL and dynamic for LGPL). He believes that LGPL imposes extra obstacles forpackaging and that neither of them (LGPL or MPL) requires extensions of thesoftware library to be released as open-source. His solution is: ”With the help of42the discussion in the accepted answer, I choose to stick to the MPL because of thepopularity, freedom in linking and because it is an official, unmodified license.”Question #5: How to encode/decode video using C#?Link: https://stackoverflow.com/questions/1834667/how-to-encode-decode-video-using-cCodes: Technical DetailsSummary: Author is trying to find a better way of encoding/decoding video toimprove a legacy application built around ffmpeg, an open-source library releasedunder GPL or LGPL. The author seems to be confused about what he can or cannotdo with the current code (co-workers made him believe that improvements/changesto the current code might result in violations of ffmpeg’s license and possibly itsdependencies’ licenses as well.Question #6: Fast asymmetric cypher for C++ applicationLink: https://stackoverflow.com/questions/2247697/fast-asymmetric-cypher-for-c-applicationCodes: Technical DetailsSummary: Author is looking for an algorithm for asymmetric cryptography sothat he can implement it himself OR a library that implements the algorithm. Heneeds to use static linking in his proprietary application, which means that thelibrary cannot be under GPL or LGPL. He says that MIT/BSD or public domaincode would be fine.Question #7: GPL, LGPL licensed product in a comercial software [closed]Link: https://stackoverflow.com/questions/12030426/gpl-lgpl-licensed-product-in-a-comercial-softwareCodes: License InteractionSummary: Author is confused about what GPL, LGPL allows him to do. Hewants to use a piece of software’s documentation in his commercial product. Itturns out that the product (processing.org) is released under GPL or LGPL, but itsdocumentation is under Creative Commons.Question #8: How to handle DWG files in C++43Link: https://stackoverflow.com/questions/22597111/how-to-handle-dwg-files-in-cCodes: Technical Details, License InteractionSummary: Author asks for a library to handle a certain file type but specifies thatit has to be under a permissive license (e.g, MIT or BSD) or a weak copyleft licensethat allows him to statically link (he mentions LGPL but isn’t sure if it allows staticlinking).Question #9: Restful Webservice Java, server sideLink: https://stackoverflow.com/questions/14971059/restful-webservice-java-server-sideCodes: InvalidSummary: Author is looking for a simple embedded servlet container and says itcannot be under GPL/LGPL.Question #10: iText 2.1.7 in commercial ProjectLink: https://stackoverflow.com/questions/8705697/itext-2-1-7-in-commercial-projectCodes: Technical Details, License InteractionSummary: Author wants to use a library (iText, a Java PDF library) in his com-mercial project but isn’t sure about how to proceed and what is allowed. The libraryused to be under MPL/LGPL until version Version 2.1.7, but is now under AGPL.He has questions regarding a number of different aspects, such as: a) if the lib canbe used in a commercial project;b) if he can choose which license to use (MPL or LGPL);c) if he has to ship only the license text or the library source code as well;d) if he can put everything in an executable or if the iText should be in a separatejar file.Question #11: Legal problem on lifting from open source librariesLink: https://softwareengineering.stackexchange.com/questions/321722/legal-problem-on-lifting-from-open-source-librariesCodes: License Interaction, Technical Details44Summary: Author used a number of libraries during prototyping development andnow wants to reduce external dependencies. It turns out that he is heavily using aclass (LazyInitializer) from the apache common-lang3 library (under Apache 2.0)to implement the Singleton Pattern and isn’t sure about the licensing implications.He says that removing that dependency would implicate in the creation of morethan 40 static inner private classes to implement the Singleton Pattern. Finally, hesimply asks what are the implications of other major open source licenses (men-tions MIT, GPL, LGPL, and BSD).Question #12: Is there any free opensource (GNU GPL, LGPL etc) Comet VideoChat? (PHP)Link: https://stackoverflow.com/questions/2766018/is-there-any-free-opensource-gnu-gpl-lgpl-etc-comet-video-chat-phpCodes: InvalidSummary: Author is looking for an open-source/free Comet Video Chat imple-mentation to use in his own CMS (Content Management System).Question #13: Which licenses can I use?Link: https://opensource.stackexchange.com/questions/4484/which-licenses-can-i-useCodes: License Interaction, Technical DetailsSummary: Author understands that some licenses are not compatible with eachother and is concerned with compatibility issues between GPL or LGPL and alicense already in use in his project (MongoDB driver in Java released under AGPL3). He wants to know which licenses are compatible if the project or libs in theproject are under GPL, LGPL, and AGPL. Respondent explains AGPL license andpossible license combinations. Another respondent suggests that LGPL and AGPLcode are compatible provided that they’re linked (doesn’t specify if dynamic orstatic linking though).Question #14: Qt License now after Digia bought itLink: https://stackoverflow.com/questions/11893121/qt-license-now-after-digia-bought-itCodes: Invalid45Summary: Author doesn’t know if a set of libraries (Qt platform) is still underthe same license (LGPL) and is afraid of any changes that might prevent its usein commercial projects. Respondent quotes the company’s website suggesting thatboth versions (one under LGPL and the other under a commercial license) willcontinue to be maintained.Question #15: Can I use GPL, LGPL, MPL licensed packages with my applicationand make it closed source?Link: https://softwareengineering.stackexchange.com/questions/125606/can-i-use-gpl-lgpl-mpl-licensed-packages-with-my-application-and-make-it-closeCodes: Technical Details, License InteractionSummary: The author is not sure about the extent to which a program releasedunder GPL affects the licensing of other software in the same ”aggregate” [2] (abundle of individual programs under different licenses). In this case, he mentionsa company building closed-source applications mixed with/using BusyBox [1], anapplication released under GPL.The most accepted answer suggests that GPL allows the use of open andclosed-source software in an aggregate as long as the GPL license is respected,i.e., the source code of the software under GPL is released. According to the re-spondent, GPL doesn’t extend to other programs running on the same computer.It’s possible to have closed-source software interacting/communicating with open-source code under GPL. ”As a rule of thumb, the GPL reaches as far as the addressspace of the licensed code.”Question #16: Efficient Multiply/Divide of two 128-bit Integers on x86 (no 64-bit)Link: https://stackoverflow.com/questions/8776073/efficient-multiply-divide-of-two-128-bit-integers-on-x86-no-64-bitCodes: InvalidSummary: Author wants to know how to efficiently do something and cannot useGPL/LGPL code.Question #17: How to read utf-16 file into utf-8 std::string line by lineLink: https://stackoverflow.com/questions/29012472/how-to-read-utf-16-file-into-utf-8-stdstring-line-by-line46Codes: InvalidSummary: Author wants to know how to do something and cannot use GPL/LGPLcode.Question #18: Which Licenses to ship within an NW.js - application?Link: https://stackoverflow.com/questions/29234304/which-licenses-to-ship-within-an-nw-js-applicationCodes: InvalidSummary: Author is using a library built on top of Chromium, which has a num-ber of dependencies under different licenses. The author doesn’t know what licens-ing information he has to provide to respect those dependencies’ licenses.Question #19: Requirements for using ffmpeg to create mpeg4 files in SaaS solu-tionLink: https://stackoverflow.com/questions/39082573/requirements-for-using-ffmpeg-to-create-mpeg4-files-in-saas-solutionCodes: License Interaction, Technical DetailsSummary: Author is building a SaaS solution and is trying to avoid a commonlyused library (ffmpeg) because it introduces ”licensing hell” not only with GPL/L-GPL, but because it is not available under a commercial license. He doesn’t nothow licensing applies to SaaS solutions since the code will not be distributed.A respondent clarifies that a few of the license’s requirements don’t seem toapply to his case (SaaS solution) based on his own interaction with the companythat owns the library’s rights.47Appendix BInterview Script1. What is your current role in your organization?2. What are your main responsibilities?3. How are you involved with the software products produced at your organi-zation?(a) Do you write code? Select open source components? Test?4. How are licensing decisions made at your organization?(a) How are developers involved? Could you give a few examples of deci-sions you have been involved in?5. Have you ever encountered license incompatibility issues?6. Could you describe a particular scenario in which license incompatibilitiesoccurred?(a) What were the licenses? What was the structure of the code carryingthe licenses?(b) How did the code with different licenses interact?(c) What was your role in identifying or resolving the challenge?7. How often has a situation like this occurred?48

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0354559/manifest

Comment

Related Items