The ideas exposed in this chapter have been elaborated and evaluated in a contract with the Italian Defense Acquisition Process, partially described in [MFRCR16]. For this project we did not use the proposed contractual schema, although some principles were implemented (e.g., the bonus-malus mechanism).
The reference project has been the LC2Evo technology demonstrator. The project lasted about 87 weeks of work, that is, about two years. Sprints lasted 4 or 5 weeks each. Overall, the cost of the project was about 2.6 Million Euro. In this case instead of Function Points, Scrum Sprints have been used to define the contract. After each Sprint, the Definition of Done and acceptance criteria were assessed by external Army engineers. Their assessment were also useful for the subsequent Sprint planning.
A generic +50% increment factor was applied to take into account the better effec- tiveness and the reduced risk associated to the LC2Evo improved Agile development environment, with respect to the previous Waterfall development cycle.At the end of the project this +50% increment factor has proven to be pessimistic, since the ef- fectiveness of the improved Agile development cycle was much better than expected. Moreover, due to an important cost reduction, leftover funds where used for extra hardware improvements.
Using a time and material estimation for a predetermined number of iterations (six to eight as we refer to LC2Evo) may be seen as a sort of “body rental” contract, where man-hours and materials are allocated in Sprints. The requirements refine- ment (through User Stories evolution and continuous iterations) was included in the contract. Both parties were trained and fully aware of the Scrum method, to avoid misunderstanding and prevent miscalculation of the effort. Figure6.4summaries the results that have been obtained using this approach. Unfortunately, specific details are classified for national security reasons. However, the resulting proportion provides a fairly accurate visualization of what happened. After an initial phase, the produc- tivity increase of the new Agile approach was quite evident. Still, the merit of such productivity improvement can not be merely attributed to the different contracting structure, since the project followed a more traditional Arms & Materials contract. However, organizing the contract in an Agile fashion was a clear prerequisite for the project’s success.
Finally, this case study gave us the relevant experience to design the new Agile contractual scheme, suitable for the Italian public administrations.
6.7 Conclusions
This chapter is an attempt to carry out a foundational work about Agile contracts. Starting from the Law & Economics of contracts, we explained how relevant principles
should be wider understand by the Software Engineering community. We pointed out how, through the alignment of interests, reduction of asymmetry and flexibility, Agile could be wider use in today’s Software Engineering environment, especially within the Public Sector. Indeed, the awareness of software engineers about the economic motivations behind a contractual relationship is of pivotal importance to enhance software quality. Information symmetry is of greatest importance for Agile software development, due to structural reasons related to the day-by-day relationship with the customer and the short development–deployment iterations.
Companies which strive for competitive advantages can easily customize Agile contracts according to the contractual freedom principle (i.e., art. 1322 cc). This is not the case for public administrations which need to follow strict constitutional duties regarding public procurements. However, also these organizations (especially in the defence & security domain) need their software systems to evolve rapidly, to address new-world scenarios. Therefore, this chapter provides the first discussion about Agile contracting for the Public Sector.
Doing so, we highlighted the keystone for Agile contracting within the Italian public administration. These recommendations have a direct impact on all civil law countries, since they face similar procurement law principles. To contextualize bet- ter our proposal, we used a case study where Agile contracting principles has been implemented. The outcomes of the presented project are positive and significant.
Future work will proceed in two main directions. Firstly, both foundational as empirical studies about the implications and implementation of Agile contracts will be carried out. Accordingly, a detailed framework for an Agile contract for the Italian public administration will be presented in the near future. Secondly, the empirical validation of such contracts needs to be further studied. In particular elements related to the assessment of non-invasive measurements, effort estimation based on Sprints or SiFP, as well as social aspects of the negotiation should be considered for further studies.
Chapter 7
Legal Implications of Software
Reuse
7.1 Introduction
A software clone is a fragment of source or executable code, that is copied in the same program or in a different one, whereas the act of copy is called software cloning [382]. Software cloning is a form of software reuse; in fact clones are identical or simi- lar pieces of code, designs, or other artifacts exploited during the development of a software system. The copy-paste of someone else’s code fragments into a different au- thor’s software program is a widely used programming practice, ranging from 5%-15% of the code base [397] up to 50% [386]. On average, the reuse of other people’s code in large software programs is estimated around 20%-30% of code [29].
There are several ways of reusing code that are more formal (such as software components [183], web services [376], etc.) in which licensing problems are addressed explicitly (e.g., in open source software [363]). However, developers sometimes prefer different and more informal approaches [384]. There are many reasons why pro- grammers copy software fragments and these reasons are largely studied in technical literature [245]. Several authors have already explored a model that studies the in- teraction and tracking of software licenses. For example, [172] developed a model which describes the interconnection of components from a legal point of view, using document integration patterns that are commonly used to solve the license mismatch problem in practice. For Open Source licenses, [359] proposes an approach to auto- matically track changes occurring in the licensing terms of a system. However, those reasons are not the focus of this study; what we want to address here are not the technical advantages or disadvantages of cloning software but the behavior of courts. In fact, this work is a study on the main rulings of software cloning from a Software Engineering perspective, following an approach started in [49], where the focus was on how software patents can influence software designers.
The issue of reuse by cloning is widely studied in Software Engineering, for in- stance, [382] lists hundreds of papers; however, in some situations cloning is consid- ered unlawful. In fact, since in several countries, and especially in Europe, software is protected by the copyright law, software cloning is a form of plagiarism. We found this topic particularly relevant from a society’s perspective, since this aspect of Software Engineering has wide cross effects, well beyond the technical dimension.
However, the definition of plagiarism for software is controversial. For instance, software clones are known to be closely related to various issues in the design of soft- ware for games, especially with respect to originality and creativity, qualities that have to be evaluated when an investigation of plagiarism takes place. For instance, in some competitions for software designers, notably in the World Computer Chess
Championship, there is an “originality" rule, which requires that all competing pro- grams must either be original or quote other programmers whose work was used. Such a rule has been invoked a number of times, accusing some author of cheating by pla- giarizing code to create a program [103]. These discussions about plagiarism are even more intriguing in the case of open source software [205, 388]. “If to plagiarize is to borrow too much code, then one needs to decide exactly how much is too much” [103]. Deciding about plagiarism is difficult. Trying to demonstrate that a program has been copied is not simple, for instance there are clones that reproduce only the functionality of a program, while the source code is different.
We did not find in literature a similar research dealing with court’s perspective. We are only aware of a similar paper published in 1996 which outlines some legal implication regarding software reuse in general within the European Union [442]. The main contribution of this work is to survey the case law of these issues, as the court’s point of view.
With this chapter we want to offer an insight for researchers and practitioners to understand the ‘way of thinking’ of US and EU courts when dealing with software cloning and, more generally, to IPR issues.
The main considerations are summarized after each section. The structure of this chapter is as follows. In Section 7.2 a brief explanation of the different clone types is given. To understand the main reference points of courts, in Section 7.3 a brief overview of the main laws are depicted. In Section7.4we carried out all relevant US and European Court of Justice case laws. A manual analysis of both case law was performed. Moreover, an analysis of the European Court of Justice was carried out, to compare both jurisprudential leanings of the courts. We found out that one ruling has a particularly disruptive nature, thus, in Section7.5we discuss it since we believe it will have a huge impact on software copyright in general. In Section7.6we discuss some of the major implication of this chapter. Eventually, we conclude and outline some future research in Section7.7.