Open Source Software Development License Structures
Language Employed - Python IDE - Canopy
Introduction:
Open source software (OSS) has come to occupy a very important place in the Information Sciences space. Even though it appears as an emerging trend, we can trace the origin of open source projects to the 1960-1970’s, when key developments in the software industry occurred in a collaborative research and academic environment (Lerner, Tirole , 2002). Over time, two dramatic changes in the environment have taken OSS from research labs to corporations and our homes.
- There have been major developments seen in the licensing, copyrights and legal aspects, which provided some formalization for the creation and distribution of open source software (eg. free, BSD, MIT, ASF, GNU GPL (General Public License) etc.).
- The diffusion of Internet meant that anyone could be a collaborator and collaboration was not restricted to the academic or corporate environment. i.e. anyone, anywhere who had the knowledge and interest could now contribute and become a part of the open source community. The unique feature of the open source industry is the fact that a loosely integrated community of developers comes together to build functional software with out any (or very little) direct monetary benefit. As OSS took a greater role in the software development industry, there emerged a need to protect “openness” of OSS software from the potential commercial hijack of the software developed (Stallman, 1999). In this light, new forms of licenses emerged that, unlike traditional licenses, were meant to protect the freedom of the software developed. In specific, there emerged two distinct license regimes, which came out of two different schools of thought. The first was termed as “copyleft” licenses and was meant to completely restrict the sublicensing and commercialization of the code. The way these licenses restricted the commercialization of the code was by introducing a “viral” feature for the license. This viral feature ensured that if the code with a “copyleft (restrictive)” license was used to build new software, then, the new software built should also have the same license. The second school of thought believed that the developer of the open source software should have the right to sublicense or commercialize the software developed. This led to creation of permissive licenses that had most of the features of the restrictive (copyleft) license but also gave the developer the liberty to commercialize and sell the software that she developed. The emergence of two distinct license regimes and its impact on the nature of the artifact (software) produced and structure of collaboration is of concern in this article. In specific, this article tries to expand the work done by Howison and Crowston, 2014 on collaboration through open superposition. In their field-based research, Howison and Crowston argue that collaboration through open superposition is at the core of the success of community-based OSS projects (Howison & Crowston, 2014). This article takes this result forward and tries to understand How the two license regimes differ in terms of superposition of tasks?. We use a network-based approach with individual tasks as nodes to test the propositions formulated. We hope that this article can be the starting point of an empirical research that can help developers and organizations make informed decisions on the type of license to be adopted.