A code implements an algorithm. Following Irmak [8], we take here an algorithm to mean a pattern of instructions, i.e. an abstract entity, a sort of process universal that is then correlated to a class of possible process executions. So, two different codes c1 and c2 can be semantically equivalent (e.g., by being able to generate the same class of possible process executions) if they implement the same algorithm, while being differ- ent codes. For instance, if c2 is produced from c1 by variable renaming, inclusion of comments and modularization, c2 can possess a number of properties (e.g., in terms of understandability, maintainability, aesthetics) that are lacking in c1.

software is usually intended as an artifact whose ulti- mate purpose is constraining the behavior of an environment external to the computer, which the computer monitors and controls by means of transducers bridging between symbolic data and physical properties. In the case of a stand-alone computer such transducers just concern the human-computer interface and the standard I/O devices; for mobile systems they may also include position and acceleration sensors, while in the case of embedded systems they take the form of ad-hoc physical sensors and actua- tors. So, in the general case, the software’s ultimate purpose is achieved by running a code that produces certain effects inside a computer, which drives a physical machine, which in turn produces certain effects on its external environment.

Now, on the basis of these observations, we believe there is another kind of soft- ware artifact emerging, which has a strong social nature: a Licensed Software Product. Such an artifact, which is constituted by a software product, comes into existence when a software product is bought, and it historically depends on a pre-existing service offer- ing concerning a product-service bundle with a certain licensing scheme. So, while, at a given time, there is only one software product named MS Word for PC, there are many licensed products (one for each customer), each one in turn being encoded in several licensed copies. The essential property of a licensed software product is the mutual commitment relationship existing between the vendor and the customer.

In conclusion, while in the previous section we focused on the immediate function of programs as technical artefacts –producing some effects inside a computer– here the Jackson and Zave’s model allows us to understand how programs play their ultimate function, which is producing certain effects in the external environment (i.e., satisfying the high level requirements). Such function is realized in two steps: first, the internal computer behavior result- ing from running the program generates some physical effects in the environment at the interface with the machine (i.e., the programmable platform, including the I/O trans- ducers). For instance, a message appears on the screen. Second, under suitable assump- tions concerning the environment (for instance, there are people able to perceive and understand the message), the ultimate effects of the program are produced (e.g., the person who reads the message performs a certain action). The presence of these two steps in realizing the ultimate function of a program suggests us to introduce two further artifacts, a software system, whose essential prop- erty is being intended to determine a desired external behavior at the machine interface and a software product, whose essential property is being intended to determine some desired effects in the environment by means of the machine behavior at the interface, given certain domain assumptions.

Focusing on the computational aspects, several scholars have addressed the complex relationships with- in i) a software code, understood as a set of computer instructions; ii) a software copy, which is the embodiment of a set of instructions through a hard medium; iii) a medium, the hardware medium itself; iv) a process, which is the result of executing the software copy.

Besides contributing to clarify concepts and terminologies in the software engineering community, our work could also be used as a foundation for software evolution. For instance, on the basis of our analysis, a refined terminology for different kinds of software change may be proposed: Refactoring refers to the creation of new codes, keeping the identity of the program; re-engineering refers to the creation of new programs, keeping the identity of the software system; software evolution refers to the creation of new software systems, keeping the identity of the software product.

In our understanding, the two ovals represent the possible phenomena involving the environment (to the left) and a programmable plat- form connected to the environment, called the machine (to the right). The intersection represents phenomena at the interface between the machine and the environment. The letters mark specific subsets of relevant phenomena: those which are required (R), those which are not required but nevertheless play a relevant causal effect in the envi- ronment (W), those which concern the desired behavior of the machine at its interface with the environment (S), those generated by the program inside the computer that drives the machine (P), and those occurring internally to the machine (M). This view, considered nowadays as a fundamental model for requirements engineering, emphasiz- es the role of the specification of machine’s behavior at its interface with the environment

Osterweil believes that, in addition to com- puter software, there are other kinds of software, such as laws or recipes. In a nutshell, he characterizes software as something non-physical and intangible, which could be executed to manage and control tangible entities [12]. Suber assumes software as an even more general concept, defining software as (physically embodied) patterns which are readable, liftable, and executable by a machine [13]. From this definition, we can derive some extremely unintuitive cases, such as “all circuits deserve the name soft- ware, since they are physical embodiments of patterns, readable and executable by a machine, and liftable. [13]

Let us start with computer code. We take computer code as a well-formed3 se- quence of instructions in a Turing-complete language. Since such instructions are mere sequences of symbols, the identity of code is defined accordingly: two codes are identi- cal if and only if they have exactly the same syntactic structure. So, any syntactic change in a code c1 results in a different code c2. These changes may include variable renaming, order changes in declarative definitions, inclusion and deletion of comments, etc.

Consider now a program, constituted by a certain code. Let us observe first that this is not a physical object, as it lacks a location in space. So, in pace with Irmak, we take a program to be a particular kind of abstract artifact. On one hand, it behaves like a type (or universal) since it defines patterns that are repeatable in a number of copies. On the other hand, unlike a type, a program is not outside space and time. A program does not exist eternally like other abstract entities such as numbers and set; in particular, a program does not pre-date its creator. As previously mentioned, it is in fact historical- ly dependent on an intentional “act of baptism” and, hence, on its creator. In addition to such historical dependence, we shall assume that a program constantly depends on some substratum in order to exist, in the sense that at least a physical encoding (a copy) of its code needs to exist.

constitutedBy: We mean here the relation described extensively by Baker [20]. We just assume it being a kind of generic dependence relation that is both asymmetric and non-reflexive, and does not imply parthood.

Since code and program differ in their essential properties (programs are necessari- ly artifacts and possess essential proper functions; codes are not necessarily artifacts), we have to conclude that a program is not identical to a code. However, if program and code are different entities, what is the relation between the two? In general, the relation between an artifact and its material substrata is taken to be one of constitution. As not- ed in [20], the basic idea of constitution is that whenever a certain aggregate of things of a given kind is in certain circumstances, a new entity of a different kind comes into being.

analysis is founded on a revisit of Jackson and Zave’s seminal work on the foundations of requirements engineering [9], [10], [11]

In conclusion, we explore in this paper the ontological distinctions underlying the different reasons for software change, by making a sharp distinction between different kinds of software artifacts, and describing the ways they are connected in the context of a software engineering process. While doing so, on one hand we shall take inspiration from the requirements engineering literature to better understand the ontological nature of software, and on the other hand we shall leverage on such ontological analysis to better understand the software engineering process, especially in the light of software change management.

Consider now one such software product, say MS Word for Mac. Starting with version V1, which denotes the specific software system constituting the software prod- uct at the time of its first release, this product will suffer a number of possible changes in its constituents in order to fix bugs, to include new functionalities, to improve per- formance, security, precision, etc. Each of these changes leads to distinct code, but some of them (those that are not just bug fixings) will also lead to a new program, while others (those that concern changes in the external interface) will also lead to a distinct software system, namely to a different version (V2) of the same product.

In the light of these observations, a code is not necessarily an artifact. If we acci- dentally delete a line of code, the result might still be a computer code. It will not, however, be “intentionally made to serve a given purpose”. Moreover, we can clearly conceive the possibility of codes generated randomly or by chance (for instance, sup- pose that, by mistake, two code files are accidentally merged into one). In contrast, a program is necessarily an artifact. A computer program is created with the purpose of playing a particular proper function.

While the essential function of a software system is to control the external behavior of a certain machine (i.e., according to the Jackson et al.’s approach, that part of the behavior that is “visible” to both the environment and machine), the essential function of a software product is to control the environment’s behavior which is not visible to the machine, but can be influenced by it, under given environment (domain) assumptions, as a result of the interaction with the environment.

By identifying the rationale for these changes in the different abstraction layers, our work contributes to establish a rigorous foundation for software versioning. Tradi- tional version codes are usually decided on the basis of the significance of changes between releases, but the decisions of the significances are entirely arbitrary and up to the author. On the basis of our approach, versioning numbers can be established in a rigorous standard way (e.g. v 1.2.3: 1 - software system specification number; 2 - pro- gram specification number, 3 - code number).

A different approach to account for the artifactual nature of software is taken by Irmak [8], also acknowledged by Ray Turner in his recent, comprehensive entry on the philosophy of Computer Science published in the Stanford Encyclopedia of Philosophy [19]. According to Irmak, people have tried to understand software (which he considers as synonymous with program) in terms of algorithm, code, copy and process, but none of these notions can be identified with software, since - due to its artifactual nature - software has different identity criteria. Therefore, a program, which for him is synony- mous with software, is different from code. We share very much Irmak’s intuitions, as well as the methodology he adopts to motivate his conclusions, based on analysis of the conditions under which a software maintains its identity despite change.

notion of (technical) artifact. We are aware that many such notions have been discussed in the literature, but the one by Baker [20] works well for us: “Artifacts are objects intentionally made to serve a given purpose”; “Artifacts have proper functions that they are (intentionally) designed and produced to perform (whether they perform their proper functions or not)”; “What distinguishes artifactual [kinds] from other [kinds] is that an artifactual [kind] entails a proper function, where a proper function is a pur- pose or use intended by a producer. Thus, an artifact has its proper function essentia l- ly”.

As we have seen, the different kinds of software artifacts we have discussed are based on a requirements engineering perspective. We can’t ignore however another perspective that deeply affects the current practice of software engineering, namely the market- ing perspective.

several papers by Jackson and Zave [9], [21], [10], which draw a clear distinction between the environment, which is where the ultimate effects of software are expected, and the machine, the computer-driven system where software operates. Their goal is to show that the intentional relationship between the two can be defined by establishing a logical connection between the intended external behavior of the machine (described by a specification S), the relevant assumptions about environmental properties (described by a body of world knowledge W), and the desired environmental behavior (described by a set of requirements R)

we agree with Irmak that we cannot identify a program either with a code, a process, or an algorithm. The reason is that this view conflicts with common sense, since the same program usually consists of different codes at different times, as a result of updates4. What these differ- ent codes have in common is that they are selected as constituents of a program that is intended to implement the same algorithm. To account for this intuition, we need a

Indeed, the very same software product can be sold at different prices by different companies, under different licensing policies. The result is that software products come to market in the form of service offerings, which concern product-service bundles. According to [22], a service offering is in turn based on the notion of service, which is a bundle of social commitments that under certain circumstances can trigger the execution of certain ac- tions by a service provider. Service offerings are therefore meta-commitments, i.e., they are commitments to engage in specific commitments (namely, the delivery of certain services) once a contract is signed.

In software engineering, the desired effects the software is intended to have on the environment are called requirements. The role of the sub-discipline of software engi- neering called requirements engineering is to elicit, make explicit and analyze these requirements in order to produce a specification that describes the behavior of a (com- puter-based) machine.

a program is constituted by some code intended to determine a specific behav- ior inside the computer. Such behavior is specified by a program specifica- ttiioonn..  a software system is constituted by a program intended to determine a specific external behavior of the machine (at its interface with the environment). Such eexxtteerrnnaall bbeehhaavviioorr iiss ssppeecciiffiieedd bbyy aa ssooffttwwaarree ssyysstteemm ssppeecciiffiiccaattiioonn..  a software product is constituted by a software system designed to determine specific effects in the environment as a result of the machine behavior, under given domain assumptions. Such effects are specified by the high level re- quirements.

As Eden and Turner observe [7], a peculiar aspect of software, with respect to other information artifacts such as laws or recipes, is its bridging role between the abstract and the con- crete: despite the fact that it has an abstract nature, it is designed to produce specific results in the real world. Therefore, it seems natural to us to adopt a requirements engi- neering perspective while analyzing the essence of software, looking at the whole soft- ware engineering process, including requirements analysis, instead of focusing on computational aspects only.

In their ontology of computer programs [7], Eden and Turner focus on the differ- ence between code and process, which they understand as two main sub-categories of program, namely program-script and program-process. For them, the term ‘program’ is therefore polysomic: a program-script is a well-formed expression based on a Tu- ring-complete programming language, while a program-process is just the execution of a program-script. A concretization relationship links a program-script to the corre- sponding program-process. Another case of concretization relationship exists for them between a program specification (a kind of meta-program) and a program-script. Final- ly, they tend to consider software as synonymous with (and therefore as ambiguous as) program, and as posing “unique philosophical questions the observation that programs bridge between the abstract (e.g., Turing automata) and the concrete (desktop comput- ers, microwave ovens)”.