The role of software ecosystems in the development and evolution of open architecture systems has received insu cient 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. The software licenses of the components both facilitate and constrain the system's ecosystem, and the rights and duties of the licenses are crucial in producing an acceptable system. We discuss software ecosystems of open architecture systems from the perspective of an architect or an acquisition organization, and outline how our automated tool and environment help address their challenges, support reuse, and assist in managing coevolution and component interdependence.
A substantial number of development organizations are adopting a strategy in
which a software-intensive system (one in which software plays a crucial role) is
developed with an open architecture (OA) [
This challenge is inevitably entwined with the software ecosystems that arise for OA systems. We nd that an OA software ecosystem involves organizations and individuals producing and consuming components, and supply paths from producer to consumer; but also { the OA of the system(s) in question, { the open interfaces met by the components, { the degree of coupling in the evolution of related components, and { the rights and obligations resulting from the software licenses under which various components are released, that propagate from producers to consumers.
Producers
Mozilla Foundation
Gnome Foundation
AbiSource Community
Corel Components
Thunderbird license
Firefox license
Gnome license
AbiWord
WordPerfect license license Integrators OA Systems
System Consumers
Independent
Software Vendors
Government
Contractors sys. rights, obligations sys. rights, obligations sys. rights, obligations In order to most e ectively use an OA approach in developing and evolving a system, it is essential to consider this OA ecosystem. An OA system draws on components from proprietary vendors and open source projects. Its architecture is made possible by the existing general ecosystem of producers, from which the initial components are chosen. The choice of a speci c OA begins a specialized software ecosystem involving components that meet (or can be shimmed to meet) the open interfaces used in the architecture. We do not claim this is the best or the only way to reuse components or produce systems, but it is an ever more widespread way. In this paper we build on previous work on heterogeneously-licensed systems [2{4] by examining how OA development affects and is a ected by software ecosystems, and the role of component licenses in OA software ecosystems.
A motivating example of this approach is the Unity game development tool,
produced by Unity Technologies [
An OA system can evolve by a number of distinct mechanisms, some of which are common to all systems but others of which are a result of heterogeneous component licenses in a single system.
By component evolution | One or more components can evolve, altering the overall system's characteristics.
By component replacement | One or more components may be replaced by others with di erent behaviours but the same interface, or with a di erent interface and the addition of shim code to make it match.
By architecture evolution | The OA can evolve, using the same components but in a di erent con guration, altering the system's characteristics. For example, as discussed in Section 4, changing the con guration in which a component is connected can change how its license a ects the rights and obligations for the overall system.
By component license evolution | The license under which a component is available may change, as for example when the license for the Mozilla core components was changed from the Mozilla Public License (MPL) to the current Mozilla Disjunctive Tri-License; or the component may be made available under a new version of the same license, as for example when the GNU General Public License (GPL) version 3 was released.
By a change to the desired rights or acceptable obligations | The OA system's integrator or consumers may desire additional license rights (for example the right to sublicense in addition to the right to distribute), or no longer desire speci c rights; or the set of license obligations they nd acceptable may change. In either case the OA system evolves, whether by changing components, evolving the architecture, or other means, to provide the desired rights within the scope of the acceptable obligations. For example, they may no longer be willing or able to provide the source code for components within the reciprocality scope of a GPL-licensed module.
The interdependence of integrators and producers results in a co-evolution
of software within an OA ecosystem. Closely-coupled components from di erent
producers must evolve in parallel in order for each to provide its services, as
evolution in one will typically require a matching evolution in the other.
Producers may manage their evolution with a loose coordination among releases,
for example as between the Gnome and Mozilla organizations. Each release of a
producer component create a tension through the ecosystem relationships with
consumers and their releases of OA systems using those components, as
integrators accomodate the choices of available, supported components with their own
goals and needs. As discussed in our previous work [
We propose that such support must have several characteristics.
{ It must rest on a license structure of rights and obligations (Section 5),
focusing on obligations that are enactable and testable. For example, many
OSS licenses include an obligation to make a component's modi ed code
public, and whether a speci c version of the code is public at a speci ed
Web address is both enactable (it can be put into practice) and testable. In
contrast, the GPL v.3 provision \No covered work shall be deemed part of an
e ective technological measure under any applicable law ful lling obligations
under article 11 of the WIPO copyright treaty" is not enactable in any
obvious way, nor is it testable | how can one verify what others deem?
{ It must take account of the distinctions between the design-time,
buildtime, and distribution-time architectures (Sections 4, 5, 6) and the rights
and obligations that come into play for each of them.
{ It must distinguish the architectural constructs signi cant for software
licenses, and embody their e ects on rights and obligations (Section 4).
{ It must de ne license architectures (Section 6).
{ It must provide an automated environment for creating and managing
license architectures. We are developing a prototype that manages a license
architecture as a view of its system architecture [
In the remainder of this paper, we survey some related work (Section 2), provide an overview of OSS licenses and projects (Section 3), de ne and discuss characteristics of open architectures (Section 4), introduce a structure for licenses (Section 5), outline license architectures (Section 6), sketch our approach for license analysis (Section 7), and conclude (Section 8). 2
Jansen et al. discuss the perspective of software vendors on software ecosystems
[
Brown and Booch discuss issues that arise in the reuse of OSS components,
such as that interdependence causes changes to propagate, and versions of the
components evolve asynchronously giving rise to co-evolution of interrelated code
in the OA [
Ven and Mannaert discuss the challenges independent software vendors face
in combining OSS and proprietary components, with emphasis on how OSS
components evolve and are maintained in this context [
Scacchi and Alspaugh examine the features of software architecture and OSS
licenses that a ect the success of an OA strategy [
There are a number of discussions of OSS licenses, such as Rosen [
Traditional proprietary licenses allow a company to retain control of software it produces, and restrict the access and rights that outsiders can have. OSS licenses, on the other hand, are designed to encourage sharing and reuse of software, and grant access and as many rights as possible. OSS licenses are classi ed as academic or reciprocal. Academic OSS licenses such as the Berkeley Software Distribution (BSD) license, the Massachusetts Institute of Technology license, the Apache Software License, and the Artistic License, grant nearly all rights to components and their source code, and impose few obligations. Anyone can use the software, create derivative works from it, or include it in proprietary projects. Typical academic obligations are simply to not remove the copyright and license notices.
Reciprocal OSS licenses take a more active stance towards sharing and reusing software by imposing the obligation that reciprocally-licensed software not be combined (for various de nitions of \combined") with any software that is not in turn also released under the reciprocal license. The goals are to increase the domain of OSS by encouraging developers to bring more components under its aegis, and to prevent improvements to OSS components from vanishing behind proprietary licenses. Example reciprocal licenses are GPL, the Mozilla Public License (MPL), and the Common Public License.
Both proprietary and OSS licenses typically disclaim liability, assert no warranty is implied, and obligate licensees to not use the licensor's name or trademarks. Newer licenses often cover patent issues as well, either giving a restricted patent license or explicitly excluding patent rights.
The Mozilla Disjunctive Tri-License licenses the core Mozilla components under any one of three licenses (MPL, GPL, or the GNU Lesser General Public License LGPL); OSS developers can choose the one that best suits their needs for a particular project and component.
The Open Source Initiative (OSI) maintains a widely-respected de nition of
\open source" and gives its approval to licenses that meet it [
Common practice has been for an OSS project to choose a single license under which all its products are released, and to require developers to contribute their work only under conditions compatible with that license. For example, the Apache Contributor License Agreement grants enough of each author's rights to the Apache Software Foundation for the foundation to license the resulting systems under the Apache Software License. This sort of rights regime, in which the rights to a system's components are homogenously granted and the system has a single well-de ned OSS license, was the norm in the early days of OSS and continues to be practiced. 4
Open architecture (OA) software is a customization technique introduced by
Oreizy [
It may appear that using a system architecture that incorporate OSS
components and uses open APIs will result in an OA system. But not all such
architectures will produce an OA, since the (possibly empty) set of available
license rights for an OA system depends on: (a) how and why OSS and open
APIs are located within the system architecture, (b) how OSS and open APIs
are implemented, embedded, or interconnected, and (c) the degree to which the
licenses of di erent OSS components encumber all or part of a software system's
architecture into which they are integrated [
The following kinds of software elements appearing in common software
architectures can a ect whether the resulting systems are open or closed [
Software source code components|These can be either (a) standalone
programs, (b) libraries, frameworks, or middleware, (c) inter-application script
code such as C shell scripts, or (d) intra-application script code, as for creating
Rich Internet Applications using domain-speci c languages such as XUL for the
Firefox Web browser [
Executable components|These components are in binary form, and the
source code may not be open for access, review, modi cation, or possible
redistribution [
Software services|An appropriate software service can replace a source code or executable component.
Application programming interfaces/APIs|Availability of externally
visible and accessible APIs is the minimum requirement for an \open system"
[
Software connectors|Software whose intended purpose is to provide a
standard or reusable way of communication through common interfaces, e.g.
High Level Architecture [
Methods of connection|These include linking as part of a con gured subsystem, dynamic linking, and client-server connections. Methods of connection a ect license obligation propagation, with di erent methods a ecting di erent licenses.
Con gured system or subsystem architectures|These are software systems that are used as atomic components of a larger system, and whose internal architecture may comprise components with di erent licenses, a ecting the overall system license. To minimize license interaction, a con gured system or sub-architecture may be surrounded by what we term a license rewall, namely a layer of dynamic links, client-server connections, license shims, or other connectors that block the propagation of reciprocal obligations.
Figure 2 shows a high-level view of a reference architecture that includes all the kinds of software elements listed above. This reference architecture has
Web Browser User Interface been instantiated in a number of con gured systems that combine OSS and closed source components. One such system handles time sheets and payroll at our university; another implements the web portal for a university research lab (http://proxy.arts.uci.edu/gamelab/). The con gured systems consist of software components such as a Mozilla Web browser, Gnome Evolution email client, and WordPerfect word processor, all running on a Linux operating system accessing le, print, and other remote networked servers such as an Apache Web server. Components are interconnected through a set of software connectors that bridge the interfaces of components and combine the provided functionality into the system's services. 5
Copyright law is the common basis for software licenses, and gives the original author of a work certain exclusive rights: the rights to use, copy, modify, merge, publish, distribute, sub-license, and sell copies. The author may license these rights, individually or in groups, to others; the license may give a right either exclusively or non-exclusively. After a period of years, copyright rights enter the public domain. Until then copyright may only be obtained through licensing.
Licenses typically impose obligations that must be met in order for the licensee to realize the assigned rights. Common obligations include the obligation to publish at no cost any source code you modify (MPL) or the reciprocal obligation to publish all source code included at build-time or statically linked (GPL). The obligations may con ict, as when a GPL'd component's reciprocal obligation to publish source code of other components is combined with a proprietary component's license prohibition of publishing its source code. In this case, no rights may be available for the system as a whole, not even the right of use, because the two obligations cannot simultaneously be met and thus neither component can be used as part of the system.
The basic relationship between software license rights and obligations can be
summarized as follows: if the speci ed obligations are met, then the
corresponding rights are granted. For example, if you publish your modi ed source code
and sub-licensed derived works under MPL, then you get all the MPL rights for
both the original and the modi ed code. However, license details are complex,
subtle, and di cult to comprehend and track|it is easy to become confused or
make mistakes. The challenge is multiplied when dealing with con gured system
architectures that compose a large number of components with heterogeneous
licenses, so that the need for legal counsel begins to seem inevitable [
We have developed an approach for expressing software licenses that is more formal and less ambiguous than natural language, and that allows us to calculate and identify con icts arising from the rights and obligations of two or more component's licenses. Our approach is based on Hohfeld's classic group of
Web Browser
User Interface
eight fundamental jural relations [
Heterogeneously-licensed system designers have developed a number heuristics to guide architectural design while avoiding some license con icts. First, it is possible to use a reciprocally-licenced component through a license rewall that limits the scope of reciprocal obligations. Rather than connecting con icting components directly through static or other build-time links, the connection is made through a dynamic link, client-server protocol, license shim (such as a Limited General Public License connector), or run-time plug-ins. A second approach <Licensee, may, use, the binary form of COMPONENT> <Licensee, may, redistribute, derived or collective works in binary form of COMPONENT> <Licensee, must, retain, copyright notices in the binary form of COMPONENT> <Licensee, must, retain, the BSD conditions in the binary form of COMPONENT> used by a number of large organizations is simply to avoid using any reciprocallylicensed components. A third approach is to meet the license obligations (if that is possible) by for example retaining copyright and license notices in the source and publishing the source code. However, even using design heuristics such as these (and there are many), keeping track of license rights and obligations across components that are interconnected in complex OAs quickly becomes too cumbersome. Thus, automated support is needed to manage the multi-component, multi-license complexity. 6
Our license model forms a basis for e ective reasoning about licenses in the context of actual systems, and calculating the resulting rights and obligations. In order to do so, we need a certain amount of information about the system's conguration at design-, build-, distribution-, and run-time. The needed information comprises the license architecture, an abstraction of the system architecture: 1. the set of components of the system; 2. the relation mapping each component to its license; 3. the relation mapping each component to its set of sources; and 4. the relation from each component to the set of components in the same license scope, for each license for which \scope" is de ned (e.g. GPL), and from each source to the set of sources of components in the scope of its component.
With this information and de nitions of the licenses involved, we can calculate rights and obligations for individual components or for the entire system, and guide heterogeneously-licensed system design. 7
Given a speci cation of a software system's architecture, we can associate software license attributes with the system's components, connectors, and subsystem architectures, resulting in a license architecture for the system, and calculate the copyright rights and obligations for the system's con guration. Due
Components
Sources
Licenses
Scopes (sets of components and sources, each with
a defining license)
to the complexity of license architecture analysis, and the need to re-analyze
every time a component evolves, a component's license changes, a component
is substituted, or the system architecture changes, OA integrators really need
an automated license architecture analysis environment. We are developing a
prototype of such an environment [
We use an architectural description language speci ed in xADL [
We analyze rights and obligations as described below [
Propagation of reciprocal obligations We follow the widely-accepted interpretation that build-time static linkage propagate the reciprocal obligations, but appropriate license rewalls do not. Analysis begins, therefore, by propagating these obligations along all connectors that are not license rewalls. An obligation can con ict with another obligation, or with the set of available rights, by requiring a copyright right that has not been granted. For instance, a proprietary license may require that a licensee must not redistribute source code, but GPL states that a licensee must redistribute source code. Thus, the con ict appears in the modality of the two otherwise identical obligations, \must not" in the proprietary license and \must" in GPL. The rights available for the entire system (use, copy, modify, etc.) are calculated as the intersection of the sets of rights available for each component of the system. If a con ict is found involving the obligations and rights of linked components, it is possible for the system architect to consider an alternative linking scheme, e.g. using one or more connectors along the paths between the components that act as a license rewall. This means that the architecture and the automated environment together can determine what OA design best meets the problem at hand with available software components. Components with con icting licenses do not need to be arbitrarily excluded, but instead may expand the range of possible architectural alternatives if the architect seeks such exibility and choice. 8
This paper discusses the role of ecosystems in the development and evolution of OA systems. License rights and obligations play a key role in how and why an OA system evolves in its ecosystem. We note that license changes across versions of components is a characteristic of OA systems and ecosystems. A structure for modeling software licenses and the license architecture of a system and automated support for calculating its rights and obligations are needed in order to manage a system's evolution in the context of its ecosystem. We have outlined an approach for achieving these and sketched how they further the goal of reusing components in developing software-intensive systems. Much more work remains to be done, but we believe this approach turns a vexing problem into one for which workable solutions can be obtained.
This research is supported by grants #0534771 and #0808783 from the U.S. National Science Foundation, and the Acquisition Research Program at the Naval Postgraduate School. No endorsement implied.