The challenge of heterogeneously-licensed systems in open architecture software ecosystems

Abstract

=^Åèìáëáíáçå=oÉëÉ~êÅÜ=mêçÖê~ã= do^ar^qb=p`elli=lc=_rpfkbpp=C=mr_if`=mlif`v= 1= k^s^i=mlpqdo^ar^qb=p`elli= Approved for public release, distribution unlimited. Thomas Alspaugh-Thomas Alspaugh is adjunct professor of computer science at GeorgetownUniversity and visiting researcher at the Institute for Software Research at UC Irvine. His research interests are in software engineering and software requirements. Before completing his PhD, he worked as a software developer, team lead, and manager in industry and as a computer scientist at the Naval Research Laboratory on the Software Cost Reduction project, also known as the A-7E project.Hazel Asuncion-Hazel Asuncion is a postdoctoral scholar at the Institute for Software Research.Starting Fall 2010, she will be an assistant professor in the Department of Computer Science at the University of Washington, Bothell. Her research interests focus on traceability, process workflows, software system architectures, and their interrelationships. AbstractThe role of software ecosystems in the development and evolution of open architecture systems has received insufficient consideration. Such systems are composed of heterogeneously licensed components, open source or proprietary or both, in an architecture in which evolution can occur by evolving existing components or by replacing them. But this may result in possible license conflicts and organizational liability for failure to fulfill license obligations. We have developed 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 open-source components in such an environment. This work is based on empirical analysis of representative software licenses and heterogeneously licensed systems, and collaboration with researchers in the legal world. Our approach provides guidance for achieving a "best-of-breed" component strategy while obtaining desired license rights in exchange for acceptable obligations.

Processes in securing open architecture software systems

“…The ability to model and automatically analyze such obligations and rights is needed at build-time and release deployment-time. Automated analysis mechanisms then allow us to determine whether the specified component interconnections entail matches or conflicts in component-component license alignments [1,2]. However, we have also observed that design-time actions must accommodate build-time and deployment-time element bindings, as well as accommodate the evolution of licenses, policies, and system element versions [29].…”

“…An OA system can evolve by a number of distinct mechanisms or process enactment pathways, some of which are common to all systems, but others of which arise only in OA systems or where components in a single system are heterogeneously licensed [2]. Figure 5 provides a summary of some of the various paths, further explained below.…”

“…We decided to design something in-between these two extremes, by taking into account where different components might be hosted within a networked, multi-server platform environment. What our OA system design process produced is an abstract architectural configuration of component types (each attributed with IP license constraints-not shown but described elsewhere [1,2,30]), a minimal component interconnection scheme, and what we call a hybrid virtual machine confinement scheme, as shown in Figure 2. Given that we have so far only examined the architectural design process, we note that we are already beginning to see that we need to anticipate non-functional requirements for the other downstream software processes that follow, particularly in the form of process enactment directives or constraints.…”

“…We annotate our OA system designs within oAS4 using formal constraint expressions on components interfaces, such as intellectual property (IP) license obligations and rights [1,2]. Security policy constraints for components, configured sub-systems, or an overall system are expressed and analyzed in a similar manner [30].…”

“…We have used an OA tailored version of the UCI ArchStudio4 architecture design system (oAS4) as a locally developed plug-in to the Eclipse IDE to realize a partially automated system for architectural design activities [1,2]. oAS4 allows us to visually model the architectural configuration of software components, component interfaces, and component connectors as OA system elements.…”