Walt Scacchi
email: wscacchi@ics.uci.edu

Thomas A Alspaugh
email: thomas.alspaugh@acm.org

Designing Secure Systems Based on Open Architectures with Open Source and Closed Source Components

The development and evolution of secure open architecture systems has received insufficient consideration. Such systems are composed of both open source and closed software software components subject to different security requirements in an architecture in which evolution can occur by evolving existing components, replacing them, or refactoring their interfaces, interconnections and configuration. But this may result in possible security requirements conflicts and organizational liability for failure to fulfill security obligations. We are developing an approach for understanding and modeling software security requirements as security licenses, as well as for analyzing conflicts among groups of such licenses in realistic system contexts and for guiding the acquisition, integration, or development of systems with open source components in such an environment. Consequently, this paper reports on our efforts to extend our existing approach to specifying and analyzing software Intellectual Property (IP) licenses to now address software security licenses that can be associated with secure OA systems.

Introduction

A growing number of enterprises are adopting a strategy in which a softwareintensive system is developed with an open architecture (OA) [START_REF] Oreizy | Open Architecture Software: A Flexible Approach to Decentralized Software Evolution[END_REF][START_REF] Alspaugh | Analyzing software licenses in open architecture software systems[END_REF][START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Scacchi | Emerging issues in the acquisition of open source software within the U.S. Department of Defense[END_REF], whose components may be open source software (OSS) or closed source with open application programming interfaces (APIs). Such systems evolve not only through the evolution of their individual components, but also through replacement of one component by another, possibly from a different producer or under a different copyright license. With this approach, the system development organization becomes an integrator of components largely produced elsewhere that are interconnected through middleware or open APIs as necessary to achieve the desired result.

An OA development process arises in a software ecosystem in which the integrator is influenced from one direction by the goals, interfaces, license choices, and release cycles of the component producers, and in another direction by the needs of its consumers. As a result the software components are reused more widely, and the resulting OA systems can achieve reuse benefits such as reduced costs, increased reliability, and potentially increased agility in evolving to meet changing needs. An emerging challenge is to realize the benefits of this approach when the individual components are subject to different security requirements.

We have been able to address an analogous problem of how to specify and analyze the Intellectual Property (IP) rights and obligations of the licenses of software components [START_REF] Alspaugh | Analyzing software licenses in open architecture software systems[END_REF][START_REF] Alspaugh | Intellectual property rights requirements for heterogeneously-licensed systems[END_REF][START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF]. Our efforts now focus on the challenge of how to specify and analyze software components and composed system security rights and obligations using a new information structure we call a security license. Alternative renderings for a security license are beyond the scope of this paper, but at this point, we believe it is appropriate to develop candidate security policy expressions that can be incorporated into security licenses. Further, we seek to articulate security license terms and conditions in ways that can be easily formalized and readily applied to large-scale OA systems, as well as be automatically analyzed or tested in ways we have already demonstrated [START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF]. This is another goal of our research here. Next, the challenge of specifying secure software systems composed from secure or insecure components is inevitably entwined with the software ecosystems that arise for OA systems. An example software ecosystem producing and integrating software components subject to different security practices is portrayed in Fig. 1. We find that an OA software ecosystem involves not only organizations and individuals producing and consuming components, and supply paths from producer to consumer; but also:

• the OA of the system(s) in question, and how best to secure it,

• the open interfaces provided by the components, and how to specify component security requirements that are enforceable or satisfiable at the interface level, • the evolution of related components, and how to assess that evolution in terms of how overall system security rights and obligations may change, and • the rights and obligations resulting from the security licenses under which various components are released, and that propagate from producers to consumers.

In order to most effectively use an OA approach in developing and evolving a system, it is essential to consider its OA ecosystem. An OA system draws on components from proprietary closed source software vendors and open source software projects. Its architecture is bounded and facilitated by the relevant ecosystem of producers, from which the initial components are chosen. The choice of a specific OA begins with a specialized software ecosystem involving components that meet (or can be encapsulated or "wrapped" 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 secure OA systems, but it is an ever more widespread way. In this paper we build on previous work on heterogeneously-licensed systems [START_REF] German | License integration patterns: Addressing license mismatches in component-based development[END_REF][START_REF] Scacchi | Emerging issues in the acquisition of open source software within the U.S. Department of Defense[END_REF][START_REF] Alspaugh | Analyzing software licenses in open architecture software systems[END_REF] by examining the role of security licenses for components included within OA software ecosystems.

In the remainder of this paper, we survey some related work (Section 2), define and examine characteristics of open architectures with or without secure software elements (Section 3), define and examine characteristics for how secure OA systems evolve (Section 4), introduce a structure for security licenses (Section 5), outline security license architectures (Section 6), and sketch our approach for security license analysis (Section 7). We then close with our conclusions (Section 8).

Related Work

Software systems, whether operating as standalone components, applications, or elements within large system compositions, are continuously being subjected to security attacks. These attacks seek to slip through software vulnerabilities known to the attackers but perhaps not to the software component producers, system integrators or consumers. These attacks often seek to access, manipulate, or remotely affect for nefarious purposes the data values or control signals that a component or composed system processes, or seek to congest or over-saturate networked services. Recent high profile security attacks such as Stuxnet [10] reveal that security attacks may be very well planned and employ a bundle of attack vectors and social engineering tactics in order for the attack to reach strategic systems that are mostly isolated and walled off from public computer networks. The Stuxnet attack entered through software system interfaces at either the component, application subsystem, or base operating system level (e.g., via removable thumb drive storage devices), and their goal was to go outside or beneath their entry context. Furthermore, as the Stuxnet attack involved the use of corrupted certificates of trust from approved authorities as false credentials that allowed corrupt evolutionary system updates to go forward, it seems clear that additional preventions are needed that are external to, and prior to, their installation and run-time deployment. In our case, that means we need to specify and analyze software security requirements and evolutionary update capabilities at architectural design-time and system integration build-time, and then reconcile those with the run-time system composition. It also highlights the need to maintain the design-time, build-time, and run-time system compositions in repositories remote from system installations, and then cross-check and independently verify them prior to run-time deployment in a high security system context.

As already noted, both software intellectual property licenses and security licenses represent a collection of rights and obligations for what can or cannot be done with a licensed software component. Licenses thus denote non-functional requirements that apply to a software systems or system components as intellectual property (IP) or security requirements (i.e., capabilities) during their development and deployment. But rights and obligations are not limited to concerns or constraints applicable only to software as IP. Instead, they can be written in ways that stipulate non-functional requirements of different kinds. Consider, for example, that desired or necessary software system security properties can also be expressed as rights and obligations addressing system confidentiality, integrity, accountability, availability, and assurance [START_REF] Breaux | Analyzing goal semantics for rights, permissions, and obligations[END_REF][START_REF] Breaux | Analyzing regulatory rules for privacy and security requirements[END_REF]. It is often the case that developing robust specifications for non-functional software system security properties in natural language produces specifications that are ambiguous, misleading, inconsistent across system components, and lacking sufficient details [START_REF] Yau | A framework for specifying and managing security requirements in collaborative systems[END_REF]. Using a semantic model to formally specify the rights and obligations required for a software system or component to be secure [START_REF] Breaux | Analyzing goal semantics for rights, permissions, and obligations[END_REF][START_REF] Breaux | Analyzing regulatory rules for privacy and security requirements[END_REF][START_REF] Yau | A framework for specifying and managing security requirements in collaborative systems[END_REF] means that it may be possible to develop both a "security architecture" notation and model specification that associates given security rights and obligations across a software system, or system of systems. Similarly, it suggests the possibility of developing computational tools or interactive architecture development environments that can be used to specify, model, and analyze a software system's security architecture at different times in its development -design-time, build-time, and run-time.

The approach we have been developing for the past few years for modeling and analyzing software system IP license architectures for OA systems [START_REF] Alspaugh | Intellectual property rights requirements for heterogeneously-licensed systems[END_REF][START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF][START_REF] Scacchi | Emerging issues in the acquisition of open source software within the U.S. Department of Defense[END_REF], may therefore be extendable to also being able to address OA systems with heterogeneous "software security license" rights and obligations. Furthermore, the idea of common or reusable software security licenses may be analogous to the reusable security requirements templates proposed by Firesmith [START_REF] Firesmith | Specifying reusable security requirements[END_REF]. But such an extension of the semantic software license modeling, meta-modeling, and computational analysis tools to also support software system security can be recognized as a next stage of our research studies.

Secure Open Architecture Composition

Open architecture (OA) software is a customization technique introduced by Oreizy [START_REF] Oreizy | Open Architecture Software: A Flexible Approach to Decentralized Software Evolution[END_REF] and further expanded [START_REF] Alspaugh | Analyzing software licenses in open architecture software systems[END_REF][START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF][START_REF] Scacchi | Emerging issues in the acquisition of open source software within the U.S. Department of Defense[END_REF] that enables third parties to modify a software system through its explicitly modeled architecture, evolving the system by replacing its components. Increasingly more software-intensive systems are developed using an OA strategy, not only with open source software (OSS) components but also proprietary components with open APIs. These components may or may not have their own security requirements that must be satisfied during their build-time integration or run-time deployment, such as registering the software component for automatic update and installation of new software versions that patch recently discovered security vulnerabilities or prevent invocation of known exploits. Using this approach can lower development costs and increase reliability and function, as well as adaptively evolve software security [START_REF] Scacchi | Emerging issues in the acquisition of open source software within the U.S. Department of Defense[END_REF]. Composing a system with heterogeneously secured components, however, increases the likelihood of conflicts, liabilities, and no-rights stemming from incompatible security requirements. Thus, in our work we define a secure OA system as a software system consisting of components that are either open source or proprietary with open API, whose overall system rights at a minimum allow its use and redistribution, in full or in part, such that they do not introduce new security vulnerabilities at the system architectural level.

It may appear that using a system architecture that incorporate secure OSS and proprietary components, and uses open APIs, will result in a secure OA system. But not all such architectures will produce a secure OA, since the (possibly empty) set of available security license rights for an OA system depends on: (a) how and why secure or insecure components and open APIs are located within the system architecture, (b) how components and open APIs are implemented, embedded, or interconnected, and (c) the degree to which the IP and security licenses of different OSS components encumber all or part of a software system's architecture into which they are integrated [START_REF] Scacchi | Emerging issues in the acquisition of open source software within the U.S. Department of Defense[END_REF][START_REF] Alspaugh | Scenario support for effective requirements[END_REF].

The following kinds of software elements appearing in common software architectures can affect whether the resulting overall composed systems are open or closed, as well as compliant with specified security policies (rights and obligations propagated from components to the overall system) [START_REF] Bass | Software Architecture in Practice[END_REF]. Software source code components -These can be either (a) standalone programs, (b) libraries, frameworks, or middleware, (c) inter-application script code such as shell scripts, (d) intra-application script code, as for creating Rich Internet Applications using domain-specific languages such as XUL for the Firefox Web browser [START_REF] Feldt | Programming Firefox: Building Rich Internet Applications with XUL[END_REF] or "mashups" [START_REF] Nelson | Repurposing: Techniques for reuse and integration of interactive systems[END_REF], or (e) similar script code that can either install and invoke externally developed plug-in software components, or invoke external application (helper) components. In each case the source code is available and if the component is compiled it can be rebuilt. Each may have its own distinct IP/security requirements. Executable components -These components are in binary form, and the source code may not be open for access, review, modification, or possible redistribution [START_REF] Rosen | Open Source Licensing: Software Freedom and Intellectual Property Law[END_REF]. If proprietary, they often cannot be redistributed, and so such components will be present in the design-and run-time architectures but not in the distribution-time architecture. 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" [START_REF] Meyers | Managing Software Acquisition: Open Systems and COTS Products[END_REF]. Software connectors -Software whose intended purpose is to provide a standard or reusable way of communication through common interfaces, e.g. High Level Architecture [START_REF] Kuhl | Creating computer simulation systems: an introduction to the high level architecture[END_REF], CORBA, MS .NET, Enterprise Java Beans, and GNU Lesser General Public License (LGPL) libraries. Connectors can also limit the propagation of IP license obligations, mandate the propagation of license obligations (e.g. via use of a license like the Affero GPL), or provide additional security capabilities. Methods of connection -These include linking as part of a configured subsystem, dynamic linking, and client-server connections. Methods of connection affect license obligation propagation, with different methods affecting different licenses. Configured 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 different licenses, affecting the overall system license and its security requirements. To minimize license interaction, a configured system or sub-architecture may be surrounded by what we term a license firewall, namely a layer of dynamic links, client-server connections, license shims, or other connectors that block the propagation of specific obligations.

Fig. 2 shows a high-level run-time view of a composed OA system whose reference architectural design in Fig. 3 includes all the kinds of software elements listed above. This reference architecture has been instantiated in a build-time configuration in Fig. 4 that in turn could be realized in alternative run-time configurations in Figs. 5, Fig. 3. The design-time architecture of the system in Fig. 2 that specifies a required security containment vessel (domain) scheme.

Firefox User Interface

Gnome Evolution User Interface

AbiWord User Interface

XWindows Apache HTTP Fig. 6. Instantiated build-time OA system of Fig. 4 but with a minimum security architecture via a single overall security containment vessel (domain) for the complete system using a common software hypervisor.

Fig. 7. Instantiated build-time OA system of Fig. 4 but with a mixed security architecture via security containment vessels for some groupings of elements.

(policies) and overall system security schemes. The configured systems consist of software components such as a Mozilla Web browser, Gnome Evolution email client, and AbiWord word processor (similar to MS Word), all running on a RedHat Fedora Linux operating system accessing file, 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. However, note that the software architecture does not pre-determine how security capabilities will be assigned and distributed across different variants of the run-time composition.

OA System Evolution

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 IP and security licenses in a single system. By component evolution -One or more components can evolve, altering the overall system's characteristics (for example, upgrading and replacing the Firefox Web browser from version 3.5 to 3.6 which may update existing software functionality while also patching recent security vulnerabilities). By component replacement -One or more components may be replaced by others with different behaviors but the same interface, or with a different interface and the addition of shim code to make it match (for example, replacing the GPL'd AbiWord word processor with either Open Office or MS Word, perhaps depending on which is considered less vulnerable to security attack).

By architecture evolution -The OA can evolve, using the same components but in a different configuration, altering the system's characteristics. For example, as discussed in Section 3, changing the configuration in which a component is connected can change how its IP or security license affects the rights and obligations for the overall system. This could arise when replacing email and word processing applications with web services like Google Mail and Google Docs, which we might judge to be more secure since the Google services (operating in a cloud environment) may be less easily accessed or penetrated by a security attack.

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. Similarly, the security license for a component may be changed by its producers, or the security license for a composed system changed by its integrators, in order to prevent or deter recently discovered security vulnerabilities or exploits before an evolutionary version update (or patch) can be made available. By a change to the desired rights or acceptable obligations -The OA system's integrator or consumers may desire additional IP or security license rights (for example the right to sublicense in addition to the right to distribute), or no longer desire specific rights; or the set of license obligations they find 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 with known vulnerabilities that have not been patched and eliminated.

The interdependence of integrators and producers results in a co-evolution of software within an OA ecosystem. Closely-coupled components from different 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 creates a tension through the ecosystem relationships with consumers and their releases of OA systems using those components, as integrators accommodate the choices of available, supported components with their own goals and needs. As discussed in our previous work [START_REF] Alspaugh | Intellectual property rights requirements for heterogeneously-licensed systems[END_REF][START_REF] Alspaugh | Presenting software license conflicts through argumentation[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF], license rights and obligations are manifested at each component's interface, then mediated through the system's OA to entail the rights and corresponding obligations for the system as a whole. As a result, integrators must frequently re-evaluate an OA system's IP/security rights and obligations. In contrast to homogeneously-licensed systems, license change across versions is a characteristic of OA ecosystems, and architects of OA systems require tool support for managing the ongoing licensing changes [START_REF] Alspaugh | Intellectual property rights requirements for heterogeneously-licensed systems[END_REF][START_REF] Alspaugh | Presenting software license conflicts through argumentation[END_REF][START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF].

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. • It must take account of the distinctions between the design-time, buildtime, and distribution-time architectures (Sections 3, 5, and 6) and the rights and obligations that come into play for each of them. • It must distinguish the architectural constructs significant for software licenses, and embody their effects on rights and obligations (Section 3). • It must define license architectures (Section 6).

• It must provide an automated environment for creating and managing license architectures. We have developed a prototype that manages an IP license architecture as a view of its system architecture [START_REF] Alspaugh | Analyzing software licenses in open architecture software systems[END_REF][START_REF] Alspaugh | Intellectual property rights requirements for heterogeneously-licensed systems[END_REF][START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF]. • Finally, it must automate calculations on system rights and obligations so that they may be done easily and frequently, whenever any of the factors affecting rights and obligations may have changed (Section 7).

Security Licenses

Licenses typically impose obligations that must be met in order for the licensee to realize the assigned rights. Common IP/copyright license obligations include the obligation to publish at no cost any source code you modify (MPL) or the obligation to publish all source code included at build-time or statically linked (GPL). The obligations may conflict, as when a GPL'd component's 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. Security capabilities can similarly be expressed and bound to the data values and control signals that are visible in component interfaces, or through component connectors. Some typical security rights and obligations might be:

• The right to read data in containment vessel T.

• The right to replace specified component C with some other component.

• The right to add or update specified component D in a specified configuration.

• The right to add, update, or remove security mechanism M.

• The obligation for a specific component to have been vetted for the capability to read and update data in containment vessel T. • The obligation for a user to verify his/her authority to access containment vessel T, by password or other specified authentication process.

The basic relationship between software IP/security license rights and obligations can be summarized as follows: if the specified obligations are met, then the corresponding rights are granted. For example, if you publish your modified source code and sub-licensed derived works under MPL, then you get all the MPL rights for both the original and the modified code. Similarly, software security requirements are specified as security obligations that when met, allow designated users or other software programs to access, modify, and redistribute data and control information to designated repositories or remote services. However, license details are complex, subtle, and difficult to comprehend and track-it is easy to become confused or make mistakes. The challenge is multiplied when dealing with configured system architectures that compose a large number of components with heterogeneous IP/security licenses, so that need for legal counsel or expert security review begins to seem inevitable [START_REF] Rosen | Open Source Licensing: Software Freedom and Intellectual Property Law[END_REF][START_REF] Fontana | A legal issues primer for open source and free software projects[END_REF].

We have developed an approach for expressing software licenses of different types (intellectual property and security requirements) that is more formal and less ambiguous than natural language, and that allows us to calculate and identify conflicts arising from the rights and obligations of two or more component's licenses. Our approach is based on Hohfeld's classic group of eight fundamental jural relations [START_REF] Hohfeld | Some fundamental legal conceptions as applied in judicial reasoning[END_REF], of which we use right, duty, no-right, and privilege. We start with a tuple <actor, operation, action, object> for expressing a right or obligation. The actor is the "licensee" for all the licenses we have examined. The operation is one of the following: "may", "must", "must not", or "need not", with "may" and "need not" expressing rights and "must" and "must not" expressing obligations. The action is a verb or verb phrase describing what may, must, must not, or need not be done, with the object completing the description. A license may be expressed as a set of rights, with each right associated with zero or more obligations that must be fulfilled in order to enjoy that right. Fig. 8 shows the meta-model with which we express licenses. Designers of secure systems have developed a number heuristics to guide architectural design in order to satisfy overall system security requirements, while avoiding conflicts among interacting security mechanisms or defenses. However, even using design heuristics (and there are many), keeping track of security rights and obligations across components that are interconnected in complex OAs quickly becomes too cumbersome. Automated support is needed to manage the complexity of multi-component system compositions where different security requirements must be addressed through different security capabilities.

Security License Architectures

Our security license model forms a basis for effective 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 configuration at design-time, build-time, and run-time deployment. The needed information comprises the license architecture, an abstraction of the system architecture: A second instantiation at run-time (Firefox, Google Docs and Calendar operating within different Firefox run-time sessions, Fedora) of the OA system in Fig. 3 as an evolutionary alternative system version, which in turn implies or requires an alternative security containment scheme.

1. the set of components of the system (for example, see Fig. 2) for the current system configuration, as well as subsequently for system evolution update versions (as seen in Fig. 9); 2. the relation mapping each component to its security requirements (specified and analyzed at design-time, as exemplified in Fig. 3) or capabilities (specified and analyzed at build-time in Fig. 4 and run-time across alternatives shown in Fig. 5, 6, and 7); 3. the connections between components and the security requirements or capabilities of each connector passing data or control signals to/from it; and 4. possibly other information, needed to detect or prevent IP and security requirements conflicts, which is as yet undetermined.

With this information and definitions of the licenses involved, it should possible to automatically calculate rights and obligations for individual components or for the entire system, as well as guide/assess system design and evolution, using an automated environment of the kind that we have previously demonstrated [START_REF] Alspaugh | Analyzing software licenses in open architecture software systems[END_REF][START_REF] Alspaugh | Intellectual property rights requirements for heterogeneously-licensed systems[END_REF][START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF].

Security License Analysis

Given a specification of a software system's architecture, we can associate security license attributes with the system's components, connectors, and sub-system architectures, resulting in a license architecture for the system, and calculate the security rights and obligations for the system's configuration. Due to the complexity of license architecture analysis, and the need to re-analyze every time a component evolves, a component's security license changes, a component is substituted, or the system architecture changes, OA integrators really need an automated license architecture analysis environment. We have developed a prototype of such an environment for analogous calculations for software copyright licenses [START_REF] Alspaugh | Analyzing software licenses in open architecture software systems[END_REF][START_REF] Alspaugh | Intellectual property rights requirements for heterogeneously-licensed systems[END_REF][START_REF] Alspaugh | Presenting software license conflicts through argumentation[END_REF][START_REF] Alspaugh | The challenge of heterogeneously licensed systems in open architecture software ecosystems[END_REF][START_REF] Alspaugh | Software licenses in context: The challenge of heterogeneously-licensed systems[END_REF], and are extending this approach to analyze security licenses. But here we identify two types of analysis that are representative of those our approach supports.

Security obligation conflicts

A security obligation can conflict with another obligation, can negate a related right for the same or nearby components, or require a right that is not available. For instance, consider two components C and D with the following security obligations:

(O1) The obligation for component C to block access to containment vessel T by any other component.

(O2) The obligation for some component connected to component D to grant it access to data in containment vessel T.

Obligations O1 and O2 cannot be simultaneously satisfied under any conditions.

Suppose C is replaced with component C connected to D and having the following obligation:

(O3) The obligation for component C to have been successfully vetted for the capability to grant access to data in containment vessel T.

If C has not been vetted, then O3 is not satisfied; by extension, neither is O2, even though O1 is no longer in force.

Consider the following security right: (R1) The right to grant access to data in containment vessel T.

Even if C was successfully vetted, it requires that R1 be available to it in order to fulfil O2. If R1 is unavailable, then O2 cannot be satisfied.

These kinds of conflicts must be taken into consideration in different ways at different development times:

• at design time, ensuring that R1 can be available and that it will be possible to vet C ; • at build time, ensuring that the specific implementation of C has been vetted successfully; and • possibly at run time as well, confirming that C is certified to have been vetted, or (if C is dynamically connected at run time) vetting C before trusting the current connection to it.

The absence of such conflicts does not mean, of course, that the system is secure. But the presence of conflicts reliably indicates it is not secure.

Rights and obligations calculations

The rights available for the entire system (the right to read and update data in containment vessel T, the right to replace components with other components, the right to update component security licenses, etc.) are calculated as the intersection of the sets of security rights available for each component of the system. If a conflict is found involving the obligations and rights of interacting components, it is possible for the system architect to consider an alternative scheme, e.g. using one or more connectors along the paths between the components that act as a security firewall. 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 conflicting security licenses do not need to be arbitrarily excluded, but instead may expand the range of possible architectural alternatives if the architect seeks such flexibility and choice.

Conclusion

This paper introduces the concept and initial scheme for systematically specifying and analyzing the security requirements for complex open architecture systems. We argue that such requirements should be expressed as operational capabilities that can be collected and sequenced within a new information structure we call a security license. Such a license expresses security in terms of capabilities that provide users or programs obligations and rights for how they may access data or control information, as well as how the may update or evolve system elements. These security license rights and obligations thus play a key role in how and why an OA system evolves in its ecosystem of software component producers, system integrators and consumers.

We note that changes to the license obligations and rights, whether for control of intellectual property or software security, across versions of components is a characteristic of OA systems whose components are subject to different security requirements or other license restrictions. A structure for modeling software licenses and automated support for calculating its rights and obligations in the context of its ecosystem are needed in order to manage an OA system's evolution.

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, as well as robust formal, solutions can be obtained.

Fig. 1 .

 1 Fig. 1. A sample software ecosystem in which secure OA systems may be developed.

Fig. 4 .

 4 Fig.4. A secure build-time architecture describing the version running in Fig.2with a specified security containment vessel scheme.

Fig. 5 .

 5 Fig. 5. Instantiated build-time OA system with maximum security architecture of Fig. 4 via individual security containment vessels (domains) for each system element.

Fig. 8 .

 8 Fig. 8. Security license meta-model

  Fig.9. A second instantiation at run-time (Firefox, Google Docs and Calendar operating within different Firefox run-time sessions, Fedora) of the OA system in Fig.3as an evolutionary alternative system version, which in turn implies or requires an alternative security containment scheme.

  6, and 7 with different security capabilities

	Firefox			Gnome Evolution email, calendar
	AbiWord			Red Hat / Fedora Linux
		Web Browser		Word Processor	Email & Calendar
		User Interface		User Interface	User Interface
		Connector 1		Connector 2	Connector 3
		Web Browser		Word Processor	Email & Calendar
	Intra-Application Scripting
			Inter-Application Scripting
		API 1		API 2	API 3
		Network Protocol		Network Protocol
	Web App Server	Operating System	Email Server
	Key:	Architecture Element	Containment Vessel

Fig. 2. An example composite OA system potentially subject to different IP and security licenses.

Acknowledgments

This research is supported by grants #N00244-10-1-077 and #N00244-12-1-0004 from the Acquisition Research Program at the Naval Postgraduate School, and by grant #0808783 from the U.S. National Science Foundation. No review, approval, or endorsement implied.


Tetsuo Noda
email: nodat@soc.shimane-u.ac.jp

Terutaka Tansho
email: tansho@riko.shimane-u.ac.jp

Shane Coughlan

The Effect of Open Source Licensing on the Evolution of Business Strategy

This paper explores how the approach underlying Open Source development has encouraged a greater sharing of knowledge in related business and legal affairs, and subsequently leads to the emergence of Open Source-driven collaboration by enterprises to address challenges. We use an Economic approach to propose a theoretical framework for Open Source business analysis and provide a defined sample of real-world developments to support its initial findings. We conclude that the need to develop effective Open Source governance solutions has led to widespread collaboration regarding business and legal challenges by stakeholders in the field, and that this collaboration will increase to improve efficiency as the market matures.

Introduction

In spite of the increased adoption of Open Source technology in businesses, most enterprises do not yet have formal processes in place regarding its management. According to research by Gartner (2011), over 50% of organizations are using Open Source as part of their IT strategy, while only 33% have a policy to address it. OpenLogic (2010) reported 65% of organizations who think they do not use Open Source actually include technology licensed under its terms.

It is possible that one of the reasons Open Source has such extensive market penetration is that initial adoption is not associated with a licensing fee. Nevertheless, while users are free to use, study, share and improve the technology, these freedoms are conditional on various terms associated with individual Open Source licenses.

The most common license -and therefore the most illustrative -is the GNU GPL. This latter requirement originated in Open Source and is termed "Copyleft", a play on words that refers to its formal provision of lasting freedom to subsequent users, as opposed to traditional restrictions applied by copyright law. Copyleft as a principle facilitates on-going collaboration on projects like Linux, though as pointed out by [START_REF] Hatta | Software License and the Development Style[END_REF], understanding its scope or definition is not sufficient to explain how and why Open Source itself works. This paper explores this question via the application of historical and logical analysis, asking what conditions are necessary to sustain Open Source dynamics and to encourage the applications of multiple business models -and therefore participants -in the global Open Source community.

Open Source Licensing and the facilitation of Business Models

Copyleft and its Evolution

Richard Stallman, the originator of the formal definition of the Copyleft licensing provision, wanted to ensure that the GNU Operating System would be available to everyone with a lasting set of freedoms. This is not to suggest that the concept of Copyleft itself is uncontroversial. Some would suggest that Open Source licenses without this provision are best because the cooperative model does not require formal statements of subsequent sharing. Some maintain that they want an explicit Copyleft requirement applied to their code.

Of course licenses using provisions like Copyleft have been modified occasionally -with a good example being the GNU GPL, now on its third revisionbut the core grants and the principle of maintaining those grants has been consistently maintained, allowing relatively certainty in the development and use of software under its terms. The same principles and the same expectations also apply to derived licenses such as LGPLv2 and AGPLv3. Where the former takes steps to loosen the conditions applied to linking software packages and the latter increases the Copyleft conditions into the sphere of network-based software (including cloud computing), they are consistent with the core values of Open Source and offer the same pre-conditions that facilitate collaborative development.

Copyleft and the Cooperation of Labor

The Internet has allowed people to communicate and to work together across great distances at a lower cost and at a higher speed than ever before. It has been a powerful driver in reducing barriers to working with partners and customers to accomplish goals, what is sometimes referred to as co-innovation. In the software field it is difficult for a single vendor to meet all the requirements of multiple customers, and it is more effective for several parties to cooperate on developing and enhancing a shared platform. This is what increasingly happens, and it has led to the commercial sustainability of Open Source projects such as the Linux kernel. This is because Open Source, a software paradigm build on the inherent assumption of cooperation and sharing, is a natural beneficiary of trends towards cooperation.

The Effect of Open Source Licensing on the Evolution of Business Strategy 3 The dynamics of the software industry have altered in the last two decades. Twenty years ago the dominant proprietary paradigm resulted in a small number of providers controlling innovation and serving a large number of users in a fairly static relationship. However, the emerging Open Source paradigm encouraged new development models and new software development processes that moved the decision-making emphasis to users. Since the Open Source paradigm gained mainstream traction this has had a profound effect on the market as a whole.

The Cooperation of Labor in Software Development

The proprietary software and Open Source paradigms facilitate the establishment and improvement of various software development models and processes. These development models may be hierarchical, loosely managed or unstructured depending on the given software paradigm and the requirements of the individuals or organizations working on a project. It would be incorrect to attempt to associate Open Source exclusively with one development or business model, though such an approach has in the past been unfortunately common.

There are many business models applicable to Open Source. This is for the same reason that Open Source facilitates multiple development models; as a paradigm Open Source draws a wide set of parameters that participant operate inside. The cooperation of labor in software development indeed evolves a variety of business model in Open Source. And business models corresponding to the market needs, open source businesses as revenue generating model can be formed into practice.

Ultimately the numbers of possible business models applicable to Open Source make it impossible to pick out any one as a clear favorite. As with any field of business, the correct model depends on market segment analysis, an understanding of skills, and a prudent balance between maximization of profit and sustainability. As have been discussed, open source licenses in the meta-level, strongly expressed in the Copyleft concept, have led to the natural consequences of cooperation of labor and collaboration.

Open Source Business Models and Licensing Strategy

Intellectual Property Rights and Business Strategies around Licensing

Business enterprises have always exercised their Intellectual Property Rights (IPR), especially around patent properties, in compliance with their business strategies. [START_REF] Takahashi | General Theory of the Strategy of Licensing Business, Software License and Development Style[END_REF] indicates that the monetary value of patent properties primarily depends not on the scientific value per se but rather on the business assessment regarding its worth and the processes that frame such understanding. This means that aggression is possible with patents of low worth, but also that the opposite holds true.

For example, even if a patent with value in terms of monopolizing a technology implementation is possessed by a business enterprise, the exertion of it is determined based on a strategic understanding of the requirements of the enterprise.

There are occasions when Open Source software packages or projects primarily governed by copyright licenses come into potential conflict with patent issues. Some Open Source licenses address this matter by the inclusion of patent provisions providing non-aggression pledges between collaborators on the licensed software, but the larger issue of whether a business makes a strategic decision to leverage patents aggressively essentially remains open. This is especially true of parties not collaborating on the same Open Source packages, or of third parties who may have minimal investment -and therefore understanding or sympathy -for Open Source approaches as a whole.

Such challenges have led to an evolution in the governance applied to Open Source. Early legal concerns around Open Source focused on copyright issues.

Open Source and Transition of Governance (1) Early cases of open source governance

The governance of Open Source in the late 1990's to early 2000 was naturally focused on the licenses that govern Open Source transactions. The emphasis was on compliance as this was regarded as the critical issue for minimizing potential risk in adoption and deployment.

(

2) Growing up stage in open source governance -supply chain consideration

As Open Source stakeholders became more understanding of how Open Source derived value -namely through collaboration between an ever-changing pool of third parties -they also became more nuanced in their understanding of the governance necessary to provide maximum benefit. This encouraged an alteration in their approach to governance, and there was a shift in perspective towards using governance as a tool to assist in maximizing value throughout the supply chain while honoring obligations in procurement and deployment.

(3) Market solutions There are many services, products and collaborative platforms that contribute to governance in the Open Source marketplace. None is a panacea but many are useful for new entrants and relatively experienced participants alike, providing avenues for discovering and comparing approaches to minimizing risk, improving understand and dealing with suppliers or customers.

Open Source and Remaining Governance Challenges

The trend in Open Source legal affairs is aware from copyright licensing matterswhich are essentially solved though not yet fully refined -and towards broader questions of governance and business management. One key challenge from this perspective remains the aforementioned tension between Open Source concepts and

The Effect of Open Source Licensing on the Evolution of Business Strategy 5 IPR, especially in the context of third parties who do participate in Open Innovation or direct invests in Open Source. Leveraging IPR against Open Source-derived technologies -whether as a business strategy to obtain new revenue streams or to hinder competition -is a significant potential challenge to the future growth and lasting viability of Open Source solutions.

The majority of these actions is rather passive and may introduce further complexity, perhaps by diminishing the perceived value of collaboration around Open Source or by creating complex tangles of Open Source licensing obligations and proprietary licensing conditions. An alternative strategy is to seek other ways to engage with tension between Open Source and IPR, in particular by seeking to find collaborative solutions to this challenge.

Collaboration to Sustain Open Source Business Models

It is observable that in issues related to Open Source license compliance various checks and measures have been created to provide adherence to the rules and to discourage imbalances in the market. Examples include the lawsuits initiated by GPL-violations.org in Europe and later followed by Software Freedom Law Center in the USA, or the knowledge-sharing communities fostered by Linux Foundation and Free Software Foundation Europe.

One similar collaborative approach that has arisen in Open Source to be engaged with IPR tensions is Open Invention Network (OIN), established in 2005 by Red Hat, IBM, NEC, Sony, Novell and Philips. Initially conceptualized as a shared pool of defensive patents and a common agreement not to litigate over a defined set of Linux System technologies, OIN has since grown to lead a community of over 400 companies and projects that formally pledge non-aggression to each other over the Linux System, and to hold hundreds of patents important to all sectors of technology.

While it makes sense for companies investing in the development of new technology to formally register such innovation in the form of patents what these companies subsequently seek to do with these patents is another matter. The aggressive enforcement of rights may provide initial advantage, but it reduces the ability of parties to collaborate in the mid to long-term, thus undermining the central precept behind obtaining lasting returns in Open Source. Taking this into account, the defensive holding of patents -and the strengthening of shared defensive pools and risk mitigation methods -is only logical. It is likely that OIN and perhaps similar entities will remain significant contributors to Open Source legal matters, and that the extent of its shared patent pool may increase as well. The reduction of potential risk from other collaborators on the Linux System in combination with the deterrent against aggression from third parties alone makes this reasonable.

From a broader perspective, it is possible to contextualize the modern governance activity around Open Source as being characterized by stakeholders seeking to efficiently maintain the rules inherent to deriving value between stakeholders, and to mitigate the risk of disruption from third parties wherever possible. This ensures the sustainability of value through collaboration, a state that facilitates a business environment with a wide range of applicable models and investors. As with the intersection between IPR portfolio decisions and Open Source business imperatives, the tension between commercial and collaborative life-cycle knowledge provision may be an interesting vein of potential further study, as may be the multi-layered relations between Open Source and proprietary software companies moving forward.

Conclusion

We analyzed the evolution of business engagement with Open Source as a paradigm for the creation, distribution and shared evolution of software platforms. The inherent value provided by Open Source appears to be that it provides rules for collaboration between multiple parties with multiple motives. While the propositions behind Open Source challenge preconceptions from the perspective of proprietary software development, and while some parties would question the necessity of Open Source-derived measures like Copyleft, there is no doubt Open Source as a concept and licenses like the GNU GPL have in practice delivered tremendous value.

With Open Source now maturing and collaboration moving into avenues of legal and business intelligence, the dynamics of the field are changing. A reoccurring theme is that Open Source and proprietary approaches to software and IPR management increasingly brush against each other, and inevitably will seek some form of coexistence. This will not necessarily be without further tension, though from a rational perspective it is hardly feasible that destructive conflict would be the preferred outcome from either side. It is therefore our conclusion that the need to effectively engage with improvements in Open Source governance will see increased collaboration on all forms of legal issue by the stakeholders in the field, and those stakeholders from both Open Source and proprietary business perspectives will ultimately reach a form of accommodation and equilibrium.


Daniel Izquierdo-Cortázar

Gregorio Robles

Jesús M González-Barahona

Gsyc / Libresoft

Do more experienced developers introduce fewer bugs?

Developer experience is a common matter of study in the software maintenance and evolution research literature. However it is still not well understood if less experienced developers are more prone to introduce errors in the source code than their more experienced colleagues. This paper aims to study the relationships between experience and the bug introduction ratio using the Mozilla community as case of study.

As results, statistical differences among developers with different levels of experience has not been observed, when the expected result would have been the opposite 1 .

Introduction

Software development is a task that demands high intellectual effort. Fixing errors is in among those tasks that are especially difficult. Even more when those errors are located in parts of the source code with which the developer is not familiar. Being familiar with a piece of code can be considered as having some expertise on/with it or previous experience with it (or similar one).

The goal of this paper is to study this assumption from a quantitative point of view, studying differences among developers of different levels of experience using several modules from Mozilla. To this aim, three ways of measuring experience will be used: a) number of commits, b) number of fixing commits, and c) territoriality (measured as the number of files only touched by one developer). Six null hypothesis have been defined: correlation between the three ways of calculating experience and the bug seeding ratio (being the percentage of buggy commits out of the total number of commits), and another three with the relationship among the several experience metrics used.

Empirical Approach

Some Mozilla Foundation projects have been the selected case of study for this paper. The analysis is based on the Mercurial repository2 which offers a list of repositories that can be easily cloned. As a summary, 19 projects were analyzed, with more than 100,000 commits, more than 2,500 authors and around 4 years of history up to June 2011. In this scenario, we define following concepts:

• Bug fixing commit: commit that fixes an issue.

• Bug seeding commit (or buggy change): commit whose action has caused a later fixing action.

• Bug seeding ratio: the value represents the percentage of buggy changes done by a developer.

• Territoriality: number of files touched only by one committer.

• Bug fixing activity: this activity is detected analyzing the log message left by developers when performing a commit. In our case study, the developers of the Mozilla usually specify the fix of an error by means of the key word Bug followed by an integer. This integer matches with an id of an issue in the bug tracking system (BTS). We have validated our process and tested the heuristic we used, and have obtained 91,7% of precision and 89,65% of recall.

• Bug seeding activity: in general, the method is based on three steps: a) detection of fixing activity as previously detailed; b) identification of the lines involved; and, c) identification of previous commits where those lines were involved. The identification of commits inducing fixing actions is based on the SZZ algorithm [START_REF] Śliwerski | When do changes induce fixes?[END_REF], a method that has been also used in other research works [START_REF] Kim | Classifying software changes: Clean or buggy?[END_REF]. The main assumption of this algorithm is that modified or removed lines in a fixing commit are the ones suspicious of having caused the fixing action (or being part of the error). Tracing back in the source code management system (SCM) to the time when they were added or modified results in the commit where the error was introduced.

That commit is the one that is considered as the bug seeding commit.

Related Research

Expertise in developing teams is a recurrent piece of study. As claimed by some authors: "Finding relevant expertise is a critical need in collaborative software engineering, particularly in geographically distributed developments" [START_REF] Mockus | Expertise browser: a quantitative approach to identifying expertise[END_REF].

From a quantitative point of view, experience has been found to be measured in several ways: a) Number of commits [8, 7, 2]; b) Fixing activity [START_REF] Ahsan | Mining effort data from the oss repository of developer's bug fix activity[END_REF]; and, c) Ownership of the source code [START_REF] Fritz | Does a programmer's activity indicate knowledge of code[END_REF][START_REF] Daniel | Using software trails to reconstruct the evolution of software: Research articles[END_REF].

Regarding our methodology, the approach used follows the assumption made by the SZZ algorithm where the lines that are part of a fixing activity are suspicious of being causing the fixing action (or being at least part of the problem) [START_REF] Śliwerski | When do changes induce fixes?[END_REF].

Results

Testing hypothesis H 0,a , H 0,b and H 0,c : these hypotheses say that there is not correlation between bug seeding ratio and a) number of commits, b) number of fixing commits, and c) territoriality.

Table 1 shows the results we have obtained, offering the values of R 2 and the p-value for the projects under study. This table provides information about the comparison between bug seeding ratio and two types of experience: number of commits and number of fixing commits. Regarding to the territoriality study (H 0,b ), all of the projects dataset is aggregated given that there are few values of study per project. In this case the R 2 is 0.037 and the p-value is 0.06. In all of the cases the inspection of the values provides low correlation. When visually analyzing the graphs for the projects, we have observed a behavior that is worth mentioning. We expected that developers with a high number of commits would have lower bug seeding ratios, graphically appearing on the left upper corner of the charts. However, some of the projects present a surprising pattern: the area the dots covers is similar to a triangle. This can be observed especially well in the case of Mozilla Central (see Figure 1), where those developers contributing with more than 800 commits have values of bug seeding ratio between 0.5 and 0.75, while we can find developers with less than 200 commits mostly in the range that goes from 0.25 to 0.85. Although the pattern is not that clear as with the Mozilla Central, due probably to having a lower number of developers, the rest of the projects show a similar behaviour.

Testing hypothesis H 0,a-b , H 0,a-c and H 0,b-c : these hypotheses say that there is not correlation among the three ways of measuring experience. Table 2 shows the results for the comparison between the number of commits and number of fixing commits. In addition, the comparison between number of commits and territoriality has provided a R 2 of 0.085 and a p-value of 0.004. Besides the study of the correlation between the number of bug fixing commits and the territoriality has raised a R 2 of 0.006 and a p-value of 0.444. cant values were found when correlating territoriality with number of commits and number of fixing commits.

Discussion

Results are detailed in Table 3. It is surprising to find that there is no correlation between any of the ways we measure experience and the bug seeding ratio. Our intuition and related research (see Eyolfson et al. [START_REF] Eyolfson | Do time of day and developer experience affect commit bugginess[END_REF]) had made us expect that developers would increase the quality of their code the more they contribute to a project. However, both results could be compatible. Eyolfson et al. study developers on an individual basis and consider their evolution, finding that the quality of the contributions improve over time. Our study is done in a specific snapshot and does not consider changes over time. 3. Null Hypotheses and results. BSR: bug seeding ratio. FR: fail to reject.

Our results raise some very interesting research questions. One first question is to look for the reason for which experienced and less-experienced developers introduce bugs to the same extent. This may lie in the peer review policy that some of the Mozilla Foundation projects follow 3 .

A second question is related with the tendency observed in several graphs where more experienced developers tend to a constant bug seeding ratio. This could mean that there exists an inherent difficulty for any software project that will make developers introduce a given number of bugs, and that this cannot be circumvented with more experienced developers.

Our results show that among the various ways of defining experience, territoriality may be the better choice. But further research should study if other aspects, such as an optimized peer review process, would not provide better output.

According to the reproducibility classification criteria proposed in [START_REF] Jesús | On the reproducibility of empirical software engineering studies based on data retrieved from development repositories[END_REF], detailed information can be obtained at http://gsyc.urjc.es/ ~grex/oss2012.

Conclusions

In this paper we have analyzed the relation between various ways of measuring developer experience and the ratio at which bugs are introduced into the code. We have found no linear correlation between experience and bug seeding ratio; more experience does not imply that less buggy code is included in the project.

We have seen that for the various ways of measuring experience (number of commits, territoriality, bug fixing activity), territoriality seems to be the best choice to have low number of bugs introduced, although this fact is not strongly supported by our results. Number of commits and bug fixing activity are highly correlated, so for studies that handle developer experience one of them can be left out.

Our study opens the door to new research, among which we propose to study the importance of peer reviewing, the existence of a project-specific characteristics that make more experienced developers tend towards a value of bug seeding ratio, a better understanding of developer territoriality and implications of our findings in recommender systems.

Fig. 1 .

 1 Fig.1. Correlation study between number of commits and the bug seeding ratio. Each dot represents a developer of the Mozilla Central repository (Firefox project).

  No correlation between BSR and # commits FR except in Tam. Tracing H 0,b No correlation between BSR and territoriality Rejected, although no linear correlation is found H0,c No correlation, BSR -fixing activity FR except in Mozilla and Tamarin Central H 0,a-b No correlation, # commits -territoriality Rejected, although no linear correlation is found H0,a-c No correlation, # commits -fixing activity Rejected and strong linear correlation is found H 0,b-c No correlation, territoriality -fixing activity FR Table

Table 1 .

 1 Testing hypothesis H0,a: Number commits vs. bug seeding ratio and H0,c: Correlation of bug fixing activity and bug seeding ratio

	textbfProject	R 2 p-value	R 2 p-value
	ActionMonkey	0.006	0.432 0.019	0.166
	ActionMonkey Tamarin 0.193	0.276 0.409	0.088
	Camino	0.004	0.825 0.083	0.319
	Chatzilla	0.001	0.953 0.005	0.876
	Comm Central	0.007	0.557 0.037	0.157
	Dom Inspector	0.000	0.941 0.238	0.077
	Graphs	0.038	0.712 0.480	0.127
	Mobile Browser	0.000	0.978 0.004	0.794
	Mozilla Central	0.010	0.068 0.041	0.000
	Tamarin Central	0.329	0.065 0.402	0.036
	Tamarin Redux	0.009	0.651 0.001	0.897
	Tamarin Tracing	0.419	0.043 0.005	0.849

http://hg.mozilla.org/

http://www.mozilla.org/hacking/committer/

 [START_REF] Ahsan | Mining effort data from the oss repository of developer's bug fix activity[END_REF]This work been funded in part by the European Commission under project ALERT (FP7-IST-25809) and by the Spanish Gov. under project SobreSale (TIN2011-28110).

Table 2 has shown that a high linear correlation between these two variables exist, with high values of R 2 . As the p-values are below the specified threshold, the results are statistically significant. On the contrary, no signifi-