De-Bugging Open Source Software Licensing

Home computer users and businesses often rely on software developed by unconventional programmers known as hackers. Hackers claim that the code they develop is superior in quality to the code developed by commercial software firms because hackers freely share the code they develop. This code sharing enables a multitude of programmers from around the world to rapidly find and fix bugs. The legal mechanism that enables hackers to deploy this worldwide team of de-buggers is a license agreement or, to be more precise,an assortment of license agreements known as open source licenses. Although open source software developers may regularly fix buggy software, they do not regularly fix their licenses. There are a multitude of licenses that purport to meet the goals of open source development. These licenses reflect different, and sometimes contradictory, approaches to core licensing issues. Many of these licenses are buggy-out of date, misapplied, misunderstood and hopelessly confusing. This state of affairs benefits no one. Hackers suffer because they do not know which license form to use. End users suffer because they do not fully understand the terms of use. Commercial software developers suffer because they have difficulty discerning how open source licensed software may affect their intellectual property. The key to successfully de-bugging open source licensing is setting up a better process for creating and updating open source licenses. This article outlines one such process. This article begins by describing the array of open source licenses. It then explains the significant shortcomings in these licenses.The article concludes by proposing that a standards organization assume responsibility for improving important open source license forms and licensing practices

Interdisciplinary insights on Open Source

The term “open source” is widely applied to describe some software development methodologies. This paper does not provide a judgment on the open source approach, but exposes the fact that simply stating that a project is open source does not provide a precise description of the approach used to support the project. By taking a multidisciplinary point of view, we propose a collection of characteristics that are common, as well as some that vary among open source projects. The set of open source characteristics we found can be used as a tick-list both for analysing and for setting up open source projects. Our tick-list also provides a starting point for understanding the many meanings of the term open source

Interdisciplinary Insights on Open Source

The term “open source” is widely applied to describe some software development methodologies. This paper does not provide a judgment on the open source approach, but exposes the fact that simply stating that a project is open source does not provide a precise description of the approach used to support the project. By taking a multi- disciplinary point of view, we propose a collection of characteristics that are common, as well as some that vary among open source projects. The set of open source characteristics we found can be used as a tick-list both for analysing and for setting up open source projects. Our tick-list also provides a starting point for understanding the many meanings of the term open source

Assisting Software Developers With License Compliance

Open source licensing determines how open source systems are reused, distributed, and modified from a legal perspective. While it facilitates rapid development, it can present difficulty for developers in understanding due to the legal language of these licenses. Because of misunderstandings, systems can incorporate licensed code in a way that violates the terms of the license. Such incompatibilities between licensing can result in the inability to reuse a particular library without either relicensing the system or redesigning the architecture of the system. Prior efforts have predominantly focused on license identification or understanding the underlying phenomena without reasoning about compatibility in a broad scale. The work in this dissertation first investigates the rationale of developers and identifies the areas that developers struggle with respect to free/open source software licensing. First, we investigate the diffusion of licenses and the prevalence of license changes in a large scale empirical study of 16,221 Java systems. We observed a clear lack of traceability and a lack of standardized licensing that led to difficulties and confusion for developers trying to reuse source code. We further investigated the difficulty by surveying the developers of the systems with license changes to understand why they first adopted a license and then changed licenses. Additionally, we performed an analysis on issue trackers and legal mailing lists to extract licensing bugs. From these works, we identified key areas in which developers struggled and needed support. While developers need support to identify license incompatibilities and understand both the cause and implications of the incompatibilities, we observed that state-of-the-art license identification tools did not identify license exceptions. Since these exceptions directly modify the license terms (either the permissions granted by the license or the restrictions imposed by the license), we proposed an approach to complement current license identification techniques in order to classify license exceptions. The approach relies on supervised machine learners to classify the licensing text to identify the particular license exceptions or the lack of a license exception. Subsequently, we built an infrastructure to assist developers with evaluating license compliance warnings for their system. The infrastructure evaluates compliance across the dependency tree of a system to ensure it is compliant with all of the licenses of the dependencies. When an incompatibility is present, it notes the specific library/libraries and the conflicting license(s) so that the developers can investigate these compliance warnings, which would prevent distribution of their software, in their system. We conduct a study on 121,094 open source projects spanning 6 programming languages, and we demonstrate that the infrastructure is able to identify license incompatibilities between these projects and their dependencies

Dependability Issues in Open Source Software - DIRC Project Activity 5 Final Report

This report presents the findings of this investigation by reporting on the main activities that have been undertaken and presenting our informed final recommendation on a follow-on project activity. It is structured in the following way. Section 2 explains the obstacles encountered while trying to understand the term "open source", contacts pursued and projects observed with respect to open source. Section 3 presents insights into the sociology of open source software development, whereas section 4 describes observations drawn and main issues identified for open source software development and dependable systems engineering. Finally, section 5 explains our recommendation together with the reasons behind our decision. Further insights on the activities described in this report, as well as various papers that have been written in relation to this activity can be found in the appendices A - E

Resistance as Motivation for Innovation: Open Source Software

Resistance is frequently viewed as a negative aspect of human interaction. Although resistance manifests itself in numerous ways, resistance to change is frequent when individuals are introduced to new ideas or innovations. This form of resistance can limit forward progress of either an individual or an organization. However, a few papers investigated possible positive roles of resistance in human life. This paper proposes that resistance can be a positive motivator to achieve change. Open source software (OSS) is a technological innovation that is laden with aspects of resistance. One of the initial motivations for the development of open source software was psychological reactance on the part of a few software developers. Reactance is a limited part of the overall construct of resistance; specifically, resistance caused by external threats to an individual\u27s freedom of choice, which generally manifests itself affectively. This paper looks at the role of resistance as a motivator for technological innovation from the perspective of open source softwre development. It also presents techniques for overcoming resistance to the adoption of open source software. Specific techniques presented are the Alpha and Omega strategies for overcoming resistance. Alpha strategies work by attempting to increase the approach forces towards some goal. Conversely, Omega strategies attempt to decrease the avoidance forces, thereby removing resistance to change. Both techniques are used in the context of open source software development to motivate participants

An investigation of licensing of datasets for machine learning based on the GQM model

Dataset licensing is currently an issue in the development of machine learning systems. And in the development of machine learning systems, the most widely used are publicly available datasets. However, since the images in the publicly available dataset are mainly obtained from the Internet, some images are not commercially available. Furthermore, developers of machine learning systems do not often care about the license of the dataset when training machine learning models with it. In summary, the licensing of datasets for machine learning systems is in a state of incompleteness in all aspects at this stage. Our investigation of two collection datasets revealed that most of the current datasets lacked licenses, and the lack of licenses made it impossible to determine the commercial availability of the datasets. Therefore, we decided to take a more scientific and systematic approach to investigate the licensing of datasets and the licensing of machine learning systems that use the dataset to make it easier and more compliant for future developers of machine learning systems

The importance of socio-technical resources for software ecosystems management

AbstractSoftware Ecosystem (SECO) is often understood as a set of actors interacting among themselves and manipulating artifacts with the support of a common technology platform. Usually, SECO approaches can be designed as an environment whose component repository is gathering stakeholders as well as software products and components. By manipulating software artifacts, a technical network emerges from interactions made over the component repository in order to reuse artifacts, improving code quality, downloading, selling, buying etc. Although technical repositories are essential to store SECO’s artifacts, the interaction among actors in an emerging social network is a key factor to strengthen the SECO’s through increasing actor’s participation, e.g., developing new software, reporting bugs, and communicating with suppliers. In the SECO context, both the internal and external actors keep the platform’s components updated and documented, and even support requirements and suggestions for new releases and bug fixes. However, those repositories often lack resources to support actors’ relationships and consequently to improve the reuse processes by stimulating actors’ interactions, information exchange and better understanding on how artifacts are manipulated by actors. In this paper, we focused on investigating SECO as component repositories that include socio-technical resources. As such, we present a survey that allowed us to identify the relevance of each resource for a SECO based on component repositories, initially focused on the Brazilian scenario. This paper also describes the analysis of the data collected in that survey. Information of other SECO elements extracted from the data is also presented, e.g., the participants’ profile and how they behave within a SECO. As an evolution of our research, a study for evaluating the availability and the use of such resources on top of two platforms was also conducted with experts in collaborative development in order to analyze the usage of the most relevant resources in real SECO’s platforms. We concluded that socio-technical resources have aided collaboration in software development for SECO, coordination of teams based on more knowledge of actor’s tasks and interactions, and monitoring of quality of SECOs’ platforms through the orchestration of the contributions developed by external actors

The Business of Open Source Software: A Primer

This article is meant as a primer for those interested in gaining a basic understanding of the business of open source software. Thus, we cover four main areas: i) what motivates businesses to get involved in open source; ii) common open source licenses and how they relate to community and corporate interests; iii) issues regarding the monetization of an open source program; and iv) open source business models currently employed. This article is particularly suitable for people who want a general understanding of the business of open source software; people who want to understand the significant issues regarding an open source program's potential to generate income; and entrepreneurs who want to create a company around open source code.peerReviewe

Software Licenses in Context: The Challenge of Heterogeneously-Licensed Systems

The prevailing approach to free/open source software and licenses has been that each system is developed, distributed, and used under the terms of a single license. But it is increasingly common for information systems and other software to be composed with components from a variety of sources, and with a diversity of licenses. This may result in possible license conflicts and organizational liability for failure to fulfill license obligations. Research and practice to date have not kept up with this sea-change in software licensing arising from free/open source software development. System consumers and users consequently rely on ad hoc heuristics (or costly legal advice) to determine which license rights and obligations are in effect, often with less than optimal results; consulting services are offered to identify unknowing unauthorized use of licensed software in information systems; and researchers have shown how the choice of a (single) specific license for a product affects project success and system adoption. Legal scholars have examined how pairs of software licenses conflict but only in simple contexts. We present an approach for understanding and modeling software licenses, as well as for analyzing conflicts among groups of licenses in realistic system contexts, and for guiding the acquisition, integration, or development of systems with free/open source components in such an environment. This work is based on an empirical analysis of representative software licenses and of heterogeneously-licensed systems. Our approach provides guidance for achieving a “best-of-breed” component strategy while obtaining desired license rights in exchange for acceptable obligations