open source study for the european space...

Open Source Study for the European Space Agency

ESA STUDY CONTRACT REPORT

ESA Contract No: 21138/07/NL/FM

SUBJECT:Open Source Software Study

CONTRACTOR:MERIT

* ESA CR( ) No: No of volumes: 1This is Volume no: 1

CONTRACTOR'S REFERENCE:

ABSTRACT:This deliverable provides an overview of the key finding of the ESA OSS Study. It presents and discusses what Open Source Software (OSS) is and what role it plays in the European space software domain and its main sub-domains (flight software, ground software, and engineering tools. Incidence and development as well as usage patterns are illustrated and legal issues are discussed in order to conclude conclusions and possible cornerstones for an OSS strategy to be developed by ESA

The work described in this report was done under ESA Contract. Responsibility for the contents resides in the author or organisation that prepared it.

Name of authors: Rishab Ghosh, Ruediger Glott, Kirsten Haaland (MERIT)

** NAME OF ESA STUDY MANAGER:

DIV: RES-PTEDIRECTORATE:

** ESA BUDGET HEADING:

* Sections to be completed by ESA** Information to be provided by ESA Study manager

MERIT. Prepared on May 12, 2008 1


Deliverable D5

Executive Summary of the Study

Relating and contributing to WP4: Elaborate conclusions and recommendations

Date: 12 May 2008

Authors: Romain Berrendonner (AdaCore)Rishab A. Ghosh (MERIT)Rüdiger Glott (MERIT)Kirsten Haaland (MERIT)



Preface

This deliverable is the last one in a row of five deliverables. It provides an overview of the key findings and recommendations across the four other deliverables. Deliverable 1 examines the application of OSS in the space software domain. Deliverable 2 supplements this report by examining overall software trends outside the space sector. Deliverable 3 provides an overview and discussion of business models in the software sector and the space software domain. Deliverable 4 provides an overview of legal aspects related to OSS in a commercial environment and relates those to business models; it also provides recommendations for ESA that are intended to serve as cornerstones for an OSS policy.



Table of Contents Preface.............................................................................................................................................3 1. Purpose of the study and structure of this report........................................................................5 2. Definition of OSS ......................................................................................................................6 3. OSS in the space software domain..............................................................................................8 4. OSS outside the space software domain...................................................................................12 5. OSS business models in the space software domain................................................................15 5. Legal issues, conclusions and recommendations......................................................................17



1. Purpose of the study and structure of this report

The present study was ordered by the European Space Agency (ESA) in order to obtain guidelines as to how to establish a consistent policy for supporting European Space Freely-Licensed Open Source Software (OSS) projects. The present document describes the current situation in this area; examines patterns of OSS development and usage, investigates economic, legal and technical issues and draw conclusions from that for guidelines and recommendations that shall serve ESA as cornerstones for a possible OSS strategy to be developed in future. Apart from literature, two sources of information were used for this report. The first one was a quantitative survey on software development and usage in ESA units and software companies in the main space software sub-domains (ground software, flight software, engineering tools). The second information source was five in-depth interviews with ESA representatives and two interviews with industry representatives. The interviews covered topics such as specifics of the various space software sub-domains, organisation of software development in these sub-domains, past and future trends, business opportunities, and license issues.

Since the concept of OSS might be ambiguous to readers who are not familiar with the field and its terminology, this deliverable starts with a definition of OSS.

In the second section we provide an overview of OSS development and use in the space software domain, including the examination of specific patterns in the space software sub-domains, including motivations to fund space software in general and OSS space software in particular, an analysis of the peculiarities of the space software market with regard to commercial, legal, organisational and technical aspects.

In the third section this report addresses the issue of worldwide trends of the use of OSS in industrial applications outside the space software domain. For this purpose, a literature review has been carried out in order to identify the current trends worldwide. Starting from an overview of general issues of OSS usage in industrial applications we further describe the situation in economic sectors that provide insights in software trends that could be relevant for the space domain. Embedded systems have been considered to be important in this regard as the increasing use of these software systems is a major trend not only in sectors such as medical equipment, aeronautics and defence, and telecommunications but also in space software. This is followed by a discussion of trends and the possible impact on the space sector.

The fourth section provides an overview and discussion of business models in the software sector and the space software domain. The analysis covered ESA organizations and private companies that were further distinguished by flight, ground and engineering tools software. The data that has been used for this report was gathered in a quantitative survey of ESA units and businesses in the space software domain and in-depth interviews with 5 representatives of ESA units in the three main space software sub-domains (flight software, ground software, and engineering tools) and two representatives of software companies in the space software domain. This section includes overview of OSS business models.

Finally, the fifth section provides some guidelines and recommendations of practical value for decision-makers and strategists in the field of European space software and industrial policy.



2. Definition of OSS

As the term Open Source Software is ambiguous, it is first important to define precisely what it means. Technically speaking, Open Source conveys the idea that the sources of the software should be accessible. However, there is a number of different ways to achieve this. Free and Open Source software match this definition, even if they come from different backgrounds and cover different scopes. It is important for ESA to understand those distinctions for several reasons. First, the communities behind Free and Open Source software are not always the same, even if they overlap to some extent, and it is important for the Agency to understand the foundations of those communities in order to interact evenly and productively with them. Second, the philosophical differences are enshrined into legal differences that matter for the field of this study.

The term Free Software was the first to appear in the early 80’s, when Richard Stallman started the GNU project to ensure that computer scientists would always be able to study and use high-quality computer programs. The Free Software Definition is maintained by the Free Software Foundation and requires that the licensor grants to the licensee “the freedom to run the program, for any purpose; the freedom to study how the program works, and adapt it to your needs; the freedom to redistribute copies so you can help your neighbour; he freedom to improve the program, and release your improvements to the public, so that the whole community benefits”. Free software is therefore oriented towards maintaining the freedom of the user of the software rather than enforcing the right of the creator of the software.

In order to achieve this result, Free Software exploits some features of copyright law. The license agreement, which determines what the recipient of the software is legally bound to do with it, allow more freedom that usual software licenses do, like the right to use with no limitation the software, the right to study, modify and redistribute it. In order to make sure that those freedoms are not removed from users, the license must be irrevocable, i.e. last as long as the work is protected by copyright law. In addition to those basic properties, some Free Software licenses, known as copyleft licenses, also prevents the addition of restrictions to the rights they grant when the software is redistributed. A perfect example of a copyleft license can be found with the GPL. In practical terms, the exercise of those rights requires access to the source code; this is usually organized by the license agreement as well.

Open Source, as fostered by the Open Source Initiative (OSI), a non-for profit organization that approves open source licenses, is much more recent. "Open Source" was created as a "marketing term" for "Free Software" which, due to the ambiguity of the English language, could be interpreted as implying free-of-charge rather than free-as-in-freedom. The Open Source Definition was first published in 1998; it was designed to be equivalent to the Free Software definition but with more specific details, and requires that software complies with 10 different requirements in order to be qualified as Open Source, including:

1. Free redistribution of the code;2. Access to source code;3. Allowance of derived works;4. Acknowledgement of author’s source code;5. No discrimination against persons or groups;6. No discrimination against fields of endeavour;



7. The license must apply as is to all to whom the program is made available without additional obligations;

8. The license must not be product-specific;9. The license must not restrict other software that is distributed along with the work;10. The license must be technology-neutral;

This is achieved, in legal terms, by a license statement that enforces those rules, and in technical terms, by making the source code available to users.

Those definitions have therefore different slightly focus. The Free Software Definition put the emphasis on end-user rights and freedoms, while the Open Source Definition put the emphasis on the technical properties of the license agreement. It should be noted that FSF-approved and OSI-approved licenses are not exactly the same. Some licenses are FSF-approved and not OSI-approved; this is the case for instance of the LaTeX Project Public License or the OpenSSL license. Some others are OSI-approved and not FSF-approved, like the Artistic License 1.0. Most FSF-approved licenses are OSI-approved, too. However, these differences are usually due to the different processes used for approval between the different organisations, and neutral interpretations of the FSF and OSI definitions do not distinguish between them.

Other groups maintain for their own purpose definitions of Free Software for their own needs. Another example can be found with the Debian project, whose social contract defines what requirement software must comply to in order to be consider for inclusion into their distribution. We will not consider these definitions within the scope of our study, although we note that they are all more-or-less equivalent.

It should also be noted that the term Open Source is often incorrectly used for a very different class of software projects, which have a license agreement that does not grant more rights than classical restricted software, except for the right to read the source code. This can be as far as preventing from compiling the source code. A perfect example could be found in the past when Sun provided the source code of its Solaris operating system under such a license agreement; or where Microsoft provides some clients (such as governments) limited access to studying (but not usually modifying) source code to some software through its "Shared Source" programme. Such restricted software will not be considered in this study.

In the rest of the present study, we will define Open Source software as Software which license matches either the FSF Free Software definition or the OSI Open Source definition.



3. OSS in the space software domain

ESA has an important role as funding and standardization body within the European space software domain. In this role, it is tempting for ESA to act as a catalyser in the space software arena, and subsidize software production in order to achieve what the market does not achieve in terms of sharing costs of software development and maintenance, reducing the risks of development, pooling project management resources, and increasing the user base. Taking for granted that it is a small market compared to the whole software industry, ESA’s role of sharing and pooling costs, risks, project management efforts involved with software development is a natural one. In fact, as a multi-national organization, with significant public funding and strong technical expertise in terms of project management, ESA is the right entity for structuring the Space software market.

There are various choices for software funding between restrictively licensed software and OSS software. Regarding motivations to fund OSS development, the study identified as main motivators a need for open standards, cost efficiency, and control over the software. ESA contact points selected for this study, as well as OSS developers, mostly invoke low cost and flexibility to their needs as the prominent reasons for choosing OSS over restricted software. This notion of costs includes only accession cost to the software, and not the global whole lifecycle cost of software, leading to a biased perception as to what is the cost of OSS. Paradoxically, the study also found out that ease of maintenance and quality are not the most prominent aspects for using OSS within the space community, while they are generally considered as important ones in non-space software communities.

Although there is no clear policy on OSS so far, ESA has become a significant player not only for the initialisation, coordination and funding of OSS but also as a developer of OSS within the space software domain. There are however significant differences between the space-software sub-domains in this regard:

In flight software, the general principle is to leave all direct development to industry. In the engineering tools sub-domain, ESA develops some OSS. In ground software, there is already a strong incidence of OSS development, especially in the

scientific data analysis branch, and a tendency to become a more active OSS developer in the ground segment software branch.

Both, developers as well as users in the space software domain assess the quality of OSS as very high. Significant criticism was only uttered with regard to documentation. The survey revealed that the actors within the space software domain have associated quite a number of very different positive expectations with their engagement in OSS and that usually most of these expectations have been met by the OSS that was used and / or developed. Most important advantages that were seen by developers as well as by users were cost-efficiency, flexibility, community support, and openness. Both groups are also aware of problems aligned with OSS. Developers emphasised in this context problems of project coordination, IPR issues, and funding. Users, in contrast, stressed out problems related to stable quality and support, including maintenance issues. Another issue that was mentioned by many respondents was the intransparency of the OSS market. A “Space OSS repository”, operated by ESA alone or in concert with the European Commission, has been considered as useful in principle by all our experts.



The study revealed that, overall, ESA has a neutral opinion on proprietary software and OSS in the sense that is does not prefer one over the other. Generally, ESA supports the development of proprietary software as well as of OSS. Although some experts pointed out that they have made good experiences with OSS communities they all also declared that they do not treat OSS communities differently from proprietary software communities. The overall impression was that the differences between OSS and proprietary software are not as pronounced as many expect – in the sense that project organisation and coordination in OSS communities is as formal as in proprietary environments. At any rate, no ESA expert showed any affection to collaborate with others in informal organisational and procedural structures.

Nevertheless, there is a strong need for more OSS in all space software sub-domains. However, all experts commonly reported that the interest of ESA in truly open OSS communities is quite limited. It is evident from the interviews that concerns regarding IPR, the deployment of European tax-payers’ money for firms outside the ESA member states, and legal restrictions (such as export controls) dominate over the expectation of benefits from OSS for the European space software industry and ESA. The approach to “operational software” (i.e. software that is developed by firms under an ESA contract and on which ESA holds the IPR) obviously helped ESA to get more control over the usage and dissemination opportunities of the software that it commissioned. The development of OSS is mainly driven by a demand for open standards and increased interoperability. Apart from that, safety issues and the need to re-use more code and to deploy more agile ways of software development played a role.

On the technical side, our findings show that the way OSS is developed in the space sector is close to the traditional development paradigms found in the software industry. Two examples of this can be illustrated by the release methods and the development processes of OSS space projects. The release processes used by OSS developers is close to the two traditional release models; the frequency of releases is more related to the level of maturity of the software than the fact it is OSS or restricted software. The development teams are often cathedral-style, centralized development, far from the much advertised bazaar-style commonly associated with OSS. Maintenance and support are, in the same manner, done by the same teams that do the development. It would seem that little difference is made between the former and the latter, meaning that the space sector has not taken all the possible advantages of the change of paradigm brought by OSS. A general conclusion to this study is therefore that apparently software development in the space software domain usually does not yet apply agile methods. In most of the various aspects we studied, it seems that the space sector uses the same method as it did for restricted software. In some cases, this has no consequences; in some others a shift of policy is required that ESA could be instrumental in promoting.

The OSS production model within the space software domain is dominated by internal development within the companies / ESA Units and developer communities. The overall management of development projects is typically under control of the companies / ESA units. In most cases, there seem to be a clear release schedule, which appears rather relaxed than strict. Comments of the respondents made however also clear that there is a wide range of release schedules. Quality issues and quality assurance are taken very seriously by developers. The funding of OSS development in the space software seems to be nurtured by national and internal R&D budgets and especially ESA funds. The commercial dimension of OSS in the space software domain appears very limited, as most of the space-specific software is special purpose (or niche) applications with only small user bases. The dominant business model is therefore rather community-oriented than business-oriented.



Driving force of the community orientation seems to be the need for a minimum of community support, which appears to be important with regard to maintenance. Both, developers and users, commonly reported that this task is mainly provided by (open or restricted) developer communities, though internal users play also a significant role for maintenance.

However, the in-depth interviews have revealed that there are a number of problems aligned with the prevailing community-oriented approach. In the light of the information we have received from the space software experts this approach appears more as a retreat area or the least common denominator of actors that are bound together in collaboration projects although they usually compete for the same resources. It seems that the lack of clear guidelines for OSS development together with the ambiguous roles of business partners and the unstable design of mission and project networks build a consolidated blockade towards the development of stable but flexible structures in which ESA members can trust each other and act together in order to improve both, space software and business opportunities. OSS could be an element of an industrial policy that can overcome this blockade. Instead, at current almost each single industrial partner seems to consider OSS as a potential threat of its business opportunities.

License issues play a role in the space software domain when OSS is considered, but the variety of licenses that are used is quite limited, with a dominating role of the GNU Public License (GPL). The reasons why companies and ESA units have chosen a specific license shows no clear-cut or dominant strategy, rather than that we have observed a multitude of very different reasons that motivate these decisions, ranging from the wish to initiate community support over a demand for cost savings to the desire to ease setting a standard.

ESA units either see industry as a partner, or they have learnt that fundamental software strategies can only be realised when they act in a concert with the industrial partners. The industrial political function of ESA is taken very seriously in all sub-domains, although there are some complaints that especially the prime contractors, but sometimes even a single small company, has the power to block developments that ESA or one of its units considers to be useful. What is obviously missing is a guideline that helps to decide when and under which conditions an ESA unit is allowed to develop or commission the development of OSS. Although this has not been mentioned explicitly, there seems to be some discontent with the fact that without such a guideline or policy the development teams and ESA units have to go through time consuming approval procedures, which outcome is hard to foresee. The reason for this discontent is obviously not distrust in the ESA management but a need for optimised development schedules, which sometimes seems to contradict heavily to the decision-making schedules.

Given the demand of ESA units for more clarity, flexibility, and independence regarding software development on the one hand and the serious notion of themselves as industrial political instruments, it seems to be worth a second thought if such a policy should address both, OSS development and better opportunities for businesses to develop efficient business models and to adapt and sell the products and services they develop in the space software domain to other sectors and markets. From the industrial policy point of view, it seems to be useful anyway to improve the conditions for companies to conquer new markets, as all experts pointed out that the markets in their specific domain are too small for industry to make significant profits. The main point in the context of the study is however that such a double objective could be used to generate more industry support for OSS in the space software domain. Another issue that seems worth to consider in this context is that the current design of ESA‘s contracting forces players together that otherwise



are used to compete for the same funds. This fact, together with the circumstance that the consortia change their composition from mission to mission and project to project, creates a lot of instability in the potential actor networks within the space software domain. As long as companies have to operate under these unstable conditions, we assume, as long there will be distrust to any initiative that appears to touch the competitiveness of single companies – such as initiatives towards OSS. A fundamental conclusion of the study is therefore that the Agency, together with its national sister organisations, political decision-makers, and business partners, should develop an OSS strategy that integrates a move towards a broader and deeper implementation of OSS in European space software with efforts to make the European space industry more competitive. This would possibly require a careful evaluation of today’s principles of European industrial policy, which seem sometimes to take more care of the interests of individual firms than of the sector as a whole.



4. OSS outside the space software domain

OSS plays an increasingly important role in all industrial sectors. Although much of the recent OSS debate has focused primarily on desktop applications (Open Office, Mozilla Firefox, etc.), it is obvious that its origins and strongest points have been in the tools and infrastructure underlying the Internet and Web services. Software like GNU/Linux, Apache, Bind, and the networking protocols for data transfer, email, the world wide web, file transfer and so on. This suggests that OSS may have a particularly important role to play in the secondary software sector (i.e. domains where software is used as a component in other products, such as embedded software in the automotive sector, consumer electronics, mobile systems, telecommunications, and utilities (electricity, gas, oil, etc.)). Moreover, these observations illustrate the most relevant advantages of OSS with regard to feature that are relevant to all forms of software – i.e. interoperability and collaboration as well as appropriate software strategies.

Enterprises use OSS in different ways, e.g. internally, for its Software and/or system development and administration, externally as part of own products or solutions, or by using OSS and contributing their own software to OSS communities. Industry representatives have become increasingly aware of the benefits OSS provides. For instance, OSS is expected to

increase software quality, reduce development and maintenance costs for the individual users decrease vendor lock-in, facilitate rapid evolution of the software encourage reuse of software

The usage of OSS in industry depends on factors such as ease of installation, ease of use, maturity and quality, and harmlessness or reliability with regard to productive or mission critical systems. Non-usage of OSS inside a company appears mainly caused by a lack of experienced users and administrators, perceived lack of applications and support, as well as product immaturity. Based on available literature, the study distinguished five ways how industry uses OSS:

Internally: for infrastructural purposes, e.g. Linux, Apache, MySQL Internally: standalone-applications and tools, e.g. CVS, BugZilla In products: small components, e.g. libraries In products: large components, e.g. embedded Linux, MySQL For customers: in consulting services

To decide if and to what extent a company should engage in OSS is obviously not an easy task, as each company has to develop its own strategy towards OSS, depending on its markets, customers, and products (systems, solutions). Measures for firms to evaluate whether or not they should engage in OSS have been developed, such as MySQL’s scorecard. Other authors recommend assessing OSS projects / communities by three major criteria:

Maturity of the OSS project. Market presence of the OSS product Commercial orientation of the project.



Embedded systems play an increasingly important role in many economic sectors, such as medical equipment, aeronautics and defence, telecommunications, but also in the space software domain. These sectors show the following characteristics of software usage that appear relevant in the space domain, too:

a strong reliance on real-time operations a high degree of mission-critical software a large number of sensors, actuators, and the like

The interviews with business experts turned out that Embedded Systems become more and more important and widely used in the space software domain. A representative of GMV, a large software company that is active in all space software sub-domains, pointed out, the share of embedded systems increases very much because of an increasing demand for safety critical software, both on ground and onboard. The ESA expert for flight software reported that there is a growing overlap between space flight software, aeronautics, and the automotive sector. A good example of this is the case of Toulouse, a very important aircraft centre as well a centre for car manufacturers and the space industry, where joint workshops for all these communities together take place. All three sectors would like to have the same framework for open source as they share the same concerns for safety and security; they have same needs for reference software architecture with building blocks. A risk of this growing overlap for the space software domain is however that bigger communities from other sectors emerge in this field, maybe focusing on different application fields than ESA and its stakeholders would prefer.

Deeper insights in three selected reference sectors for the space software industry (medical equipment, aeronautics & defence, telecommunications equipment) revealed that industry can manage to find solutions for challenges that ESA and the European space software industry are also confronted with, such as building communities and bringing competitors into a network where they can freely and trustfully collaborate. A precondition for such a success seems to be that the initiator releases the open code at a point that is early enough for others to jump on the project and to apply such a strategy to products where enough players are in the field who can benefit from freely accessible code. Infrastructure software seems to provide a good example of the type of software that is promising for such efforts.

Regarding general trends, it appears sure to expect that the dynamics of OSS that could be observed in recent years will go on in the coming years. The results of the analysis allow also drawing some conclusions on OSS trends in industrial environments. One trend that could be observed in the telecommunications sector and medical equipment sector, the increasing spread and importance of embedded systems, will probably go on within the next five years. Another prediction that could be made based on the analysis of OSS in industrial environments is that OSS will remain attractive for industry, especially for large companies. Preconditions for a significant intensification of the dynamics in this regard are however that

firms and OSS communities learn better to interact with each other, maintenance problems will be solved, and legal constraints will be overcome

It is likely that OSS code contribution of firms will increase in the future, as OSS still conquers more and more market segments (e.g. through the rise of embedded systems). In the secondary software sector, sharing maintenance cost will probably become more common, as software platforms do not provide a factor of competitiveness for these firms.



Future scenarios assume a change in company strategies for the interaction with the OSS community, mainly in the sense that companies will give back more code to the community than it is the case today, and possibly paying more OSS developers. Also, the complexity and opaqueness (regarding licenses and functionalities) of OSS retrievable from OSS repositories must improve in order to meet industry’s demand. As mentioned in the previous section, this is also an issue in the space software domain. To achieve improvements, cultural changes are also demanded, such as the acknowledgement of the emergence of new values, such as

Respect Open communication Transparency Give and take ( you have to pay either cash or code)

Some of the observed trends and future scenarios appear to have an impact on companies and organizations in the space software domain. For instance, on the technical side it is likely that the existing reliance on real-time operations and a high degree of mission-critical software will further dominate this domain. The fact that especially embedded systems in this domain are safety-driven might impose strong requirements regarding skills and responsibility on OSS developers. This might lower the capacity of OSS projects in the space software domain to attract sufficient volunteers in order to fully tap the potential provided by OSS communities.

If this happens it would coincide with the fact that most software in the space software domain is niche software with only small user bases. Opportunities for a commercialization of OSS on its own in the space software domain may therefore appear limited. However, a continuation of business models consistent with many current practices, including the development of custom software, is very much in line with the OSS model of business development.

Furthermore, OSS has proved to be successful in several niche areas, such as parts of the medical systems market, where a small number of specialised players can use OSS licensing models and distribution models (such as open repositories) to avoid complex IPR-sharing contracts. While a larger OSS community (let alone OSS volunteer developers) are not necessarily attracted to such niche software, the niche participants themselves form the (more tightly knit) community. In some cases, such as within Philips Medical Systems, an "internal open source" model (called InnerSource by Philips) is applied, where open source principles are used to eliminate barriers between contributors within the firm – similar to the “operational software” approach at ESA. More commonly, though, true open source is used partly in order to meet licensing requirements of open source software tools that are being incorporated within or used with the niche software. As the demands of the scenarios described above illustrate, there are opportunities for new forms of interaction between actors in the space software domain and OSS communities. If these opportunities can be realized, new business opportunities for space software developers may emerge.



5. OSS business models in the space software domain

The main difference between OSS and proprietary software lies in the intention with which software is produced. Conversely to proprietary software that is exclusively produced in firms, FLOSS is produced by a diverse group of developers and firms, presenting the OSS community. According to Krishnamurthy (2003), it is the passion for the product rather than seeking profits that drives OSS community members to develop the software. Particularly, in developing the software, OSS community members do not distinguish between individual and corporate users, but make the product and source code available to all kind of interested users.

In this regard, the OSS community is found to be predominantly interested in the widespread adoption of its products, hence acting indifferent to the profits that corporations may derive from its products (Krishnamurthy 2003). It is the usage of licensing agreements that allows the OSS community to maintain control over the distribution of its products.

In recent years, the market for Open Source Software has considerably accelerated. Factors such as the availability of high-quality software, low cost and low barriers to entry, vendor independence and flexibility as well as the availability of customization and local support services have been found to significantly contribute to this trend (Ghosh 2006) .

With the expanding demand for and supply of open source software on the market, the traditional OSS model that used to be purely driven by the developer community and university support has transformed to include the industry as a major driving force. The industry involved in the demand and supply of FLOSS is found to encompass businesses devoted to the development, support, maintenance and integration of specific products as well as large industrial players such as IBM, Oracle, Philips, Nokia and SAP. Interesting to note for this project is the fact that OSS has considerably reshaped the business model strategies of these companies (Ghosh 2006). The common denominator of these novel business models is the fact that making profit purely out of software does not lie at the core of these business models anymore. As the remaining of this report illustrates, a wide range of business models have been developed to draw revenues from solutions based on OSS.

Following examples of OSS business models have been identified Sell support services Build (or run) hardware Proprietary components Dual Licensing Advertising Badgeware Platform providers Selection/consulting companies Franchising model Subscription model The ecosystem enabler business model Combined business models



Despite – or maybe because of – this multitude of business models we observed that a significant part of the projects included in the study have difficulties finding out an appropriate business model or, given a business model, have difficulties with defining and implementing their strategies. This can be corroborated by the results in the legal side of the problem. Most projects select their licenses on grounds that are not related to business considerations, but rather driven by habit, technical or contractual constraints. We found out that many projects are aware of these difficulties and mention, as a drawback of using OSS, the difficulty to address these issues.

As a general trend, (OSS) business models can less easily be allocated to one typical strategy to achieve revenue streams. Even the rough distinction between distributors / retailers & service providers becomes difficult when some modern business approaches are considered. The reason for this is that both, big companies as well as SMEs, have obviously developed business models that go beyond the boundaries that were observable five or six years ago. A common feature of these approaches is that they combine (elements of) different business models, thereby covering both ends of the spectrum, distributing/retailing as well as service provision.

Another basic conclusion from this report is that the space software domain is a small niche in which either niche and speciality OSS distributors can make profit or companies that are large and powerful enough to cover more than only one space software sub-domain. Probably due to these small markets there is a strong community-orientation within the space OSS business models. As explained in D1, this orientation is probably driven by the need for standards and community support.

Following conclusions have been drawn from the two case studies: OSS in the space software domain seems to provide opportunities for both, large companies

and SMEs The success of an OSS approach however seems to depend on its purpose: Obviously,

aiming at network effects provided by the OSS community does not work out at current because the community is too small, whereas software and service business models based on OSS seem to work out quite well

This implies that efforts should be undertaken in order to enlarge the space OSS community; steps in this direction could be the opening of the whole domain towards other sectors, such as aeronautics, or to regulate the domain through a strong actor, such as ESA. The latter opportunity was however considered with some scepticism and reservation with regard to the implications for software companies in these small markets.

The architecture of project networks within the space sector seems to bear some issues because the current mode of tendering results in various projects of which each bundles more or less the same players in different combinations and with different functionalities. All these players compete however for the same scarce resources, therefore trust to the other business players and stable relationships are obviously not strongly pronounced within the space software domain.



5. Legal issues, conclusions and recommendations

A number of legal issues were considered in the study, and detailed analyses have been provided in deliverable D4. We do not reproduce these here, but summarise the guide to selecting an open source licence. There are a number of available open source licences: more than 100 today And it's always possible to create a new one. Licences approved as open source by the open source initiative (such approval is required in order to host software under these licences on many open source repositories) are published on the web site of the Open Source Initiative (opensource.org).

Fortunately, very few licences are really significant in terms of usefulness or usage. The main question to clarify is the distinction between two families of licences: reciprocal and permissive as previously explained.

The matrix below helps identify the most suitable licence if the agency releasing the software has rights to all the software, or if the third party components are made available under a (proprietary or open source) licence allowing the agency to determine the licence of the derived work, i.e. the full software including those components1.

Q1 Do you allow other programmers to use and modify your code to redistribute it (as modified version or as derived work including all or part of your code) ?

Q2 Do you allow others to combine your source code with their (possibly proprietary) products and to redistribute these products (possibly as proprietary software)?

Q3 Do you allow other programmers to combine your source code with other “GPL licensed” source code, and to redistribute the whole under the terms of the GPL?

Q4 Are other programmers modifying and redistributing your source code obliged to publish / share the source of their modified or redistributed version ?

Q5 If the recipient further distributes your code, must he ensure that no further restrictions beyond the original licence are imposed, such as additional patent licences?

Licence Q6 is your code based or including one or more pieces of code that was

1 This grid is adapted from the “Study on the effect on the development of the information society of European pub-lic bodies making their own software available as open source” by Schmitz, P-E., Ghosh, R. A., Glott, R. and Ger-loff, K. See www.publicsectoross.info for the full report.



obtained under GPL?

BSD Y Y Y N N N

LGPL Y Y Y Y Y N

GPL (1) N Y Y Y Y

Mozilla Public License Y Y (2) Y N N

Notes: (1) Some businesses in the software industry refuse to accept GPLed source code into their projects, although other businesses strongly prefer GPL over other licences. Contrast with code under BSD et al, LGPL, or Mozilla PL 1.1, which nobody refuses to accept, since they allow components to be distributed under different licences. (2) MPL 1.1 can be specifically amended to allow combining with GPL, according to the FSF's licence list.

The study also considered the ESA-OSS draft licence, which it recommended should not be used, and the EUPL, which it recommended could be used when the ESA would like a licence drafted with European legal principles in mind.

On the issue of "closed community software", a number of solutions were explored but the study recommended that the use of non-open source closed community software was generally not required; in most cases existing legislation (e.g. on security) would be sufficient, and in other cases a policy of dual licensing (with a reciprocal open source licence such as the GPL or EUPL and another licence on a case-by-case basis for proprietary commercial use) would be suitable.

Finally a number of concrete recommendations were made, which are described below.

Open Source has been shown to be a model of software development that supports successful business models, indeed is compatible with the business models related to the vast majority of employment and spending in the software sector. This is also true for niche software sectors, and applies also to the European space sector. There is a strong potential for open source to save costs and increase efficient innovation through streamlining and utilisation of all available resources, including internal resources at ESA, with the minimum of barriers. In this respect, open source in the space sector is no different from elsewhere; thus, we recommend that the use and development of open source should be encouraged by ESA.

We have shown that open source increases the competitivity of European ICT industry in general, as the FLOSSIMPACT report published by the European Commission found, and we believe that the same applies for the European space sector. Supporting open source is therefore not in contravention to ESA's mission to benefit European industry, but is likely to further this mission. In general, therefore, ESA should adopt a principle that software fully funded through public funds should be available to the public to build upon. I.e., ESA should by default require software that is fully developed with its funds to be made available under an appropriate open source licence. Of course, exceptions may be made, including through the use of dual licensing.

ESA should develop an OSS policy that is flexible and adaptable to different requirements of different applications. While one possible differentiation is based on the sub-domains, in fact it would be better to use as categories the extent of interaction with broader


http://www.fsf.org/licenses/license-list.html




communities, i.e. the level of "nicheness". Where there is a small number of potential vendors, there is also likely to be a significant

degree of involvement from ESA's own experts, and a majority (or even complete) funding by ESA. The encouragement of open source in such a situation would reduce the likelihood of vendor lock-in (overdependence of ESA on one of the few vendors) and thereby also be in line with the support of open standards. It would also increase the sustainability of the software, as it could be maintained by firms other than the original developer. This increased sustainability of open source justifies lowering the entry barriers to ESA procurement processes for tenders requiring open source software. Entry barriers such as revenue and capital requirements, years of operation etc are typically intended in order to ensure that the company is sustainable, and therefore the software developed by the company will be sustainable. With open source, the software can be sustainable even without the company that originally developed it, so barriers can be lowered.

Where there is a large number of potential vendors, or, going further, a larger community of related software users and developers (e.g. with GEANT4), funding for the software may not be only or even largely from ESA. There may be a wider customer base. However, in such a case ESA's public funding is even less justified given the presence of a larger customer base, without getting some public benefit in return. Thus, the use of open source for ESA-funded software in such cases is also recommended, but along with the encouragement of models to integrate ESA and its contractors into the wider community of support and development. When a market exists beyond the ESA niche, it is also likely that support - including open source developments - may exist and be contributed from elsewhere, perhaps even with non-European public funding. This is the case with GEANT4, Eclipse, GNAT, etc. Thus, for these "wider niche" cases, ESA should encourage not only the use of open source, but also awareness of open source community processes.

ESA should provide guidelines for departments and teams, national agencies, and companies on how best to make space software OSS and an overview of its implications

ESA should organise policy support from member states and stakeholders and demonstrate that OSS is not against economic or industrial policy subjects such as competitiveness. This should be done not only because ESA needs stakeholder support in order to initiate an OSS policy, but also because OSS is most successful when community collaboration is embraced as an intentional principle, rather than an accidental side-effect.

ESA's software strategy should standardise on the models, underlying algorithms, and open standards rather than on specific software applications in order not to impose a specific software applications on industry and promote vendor lock-in. A preference for open standards (implementable freely and equally by all potential producers) tends to be in line with a preference for open source, as shown in many previous studies.

Rather than defining only a high-level policy, in which case special-case resistance to open source may translate into the entire policy being blocked, policy can be based on classifying software according to different requirements. For example, strategic software (infrastructure etc.) should become ESA property in order to be distributed as OSS but also perhaps under a dual licensing strategy as described in the legal analysis.

In order to encourage OSS collaborations, ESA could establish a European OSS space repository, or develop a section of the European Commission's repository and collaborative development environment for the EU public sector, OSOR. Note that NASA has some space



software repositories2 though not necessarily collaborative development environments. This repository could become a portal for information on open source in space, legal issues, policy etc, as well as building a community of developers - this is indeed the intention of the EC's OSOR for the broader public sector.

Use OSS as a means to overcome the duplication of software efforts in Europe – when most of the software is OSS it can be shown in and downloaded from a repository and after that it can be tailored to mission-specific needs – this would reduce development time and costs and bring Europe’s industry in a more competitive situation

Reconsider the restriction of software usage to ESA member states – US space software applications have conquered the world markets (e.g. in the medical sector) because they were not facing such restrictions; exposing European companies more to worldwide competition should not be considered solely as a risk but also as an opportunity to develop creative and competitive business models

EU, ESA member states, ESA and its units / national partner agencies should not think only about the maintenance and long-term availability of software but also establish means in order to adapt space software tools to requirements in other sectors (i.e. industrial political mission of ESA should be broadened). Note that releasing software as open source makes this less difficult for ESA to do, as interested parties in other industrial sectors will be able to find and adapt technology of interest to them. Experience has shown that such broadening is likely to increase contributions to the software that could also be useful to ESA itself (e.g. the situation with GEANT4 and Eclipse).

Use OSS as a means to better integrate SMEs in ESA missions (SMEs would become more independent from large software vendors that require huge ex ante investments from anyone who wants to develop applications based on their proprietary software)

Use OSS as a means to increase competitiveness in the European space software market. Contracts with a small number of prime contractors might be more attractive for prime contractors than for the industry as a whole; what is good for the industry is not necessarily good for every participant (or may be good but require changes), so there may resistance to an OSS policy from interested parties.

Strengthen more open collaborative forms of software development in order to become faster and more flexible. Open source automatically supports this by reducing procedural barriers between users and developers (and between developers in different organisations, locations or departments) - as seen in the scientific data analysis sub-sector.

Support more service-oriented business models in space software domain – this will reduce firms’ dependency on the software product, offers market opportunities to more companies, and may work towards OSS (because importance to keep code secret would probably decrease)

When it comes to the process for adopting open source for a specific project, a number of issues are involved and it would be useful to prepare and widely circulate guidelines for how to use open source, including:

● how to issue a tender that is legal while requiring open source● how to release software as open source - legal issues● how to build and interact with an open source community

2e.g. http://opensource.gsfc.nasa.gov/



While some of these issues have been addressed in this report, specific guidelines for each topic should be created once a firm ESA open source policy is in place. Note that a number of guidelines, including for the three topics described above, have been prepared for the public sector in general by the EC's OSOR project3. Some specific recommendations in terms of project management for an open source project would include:

● Determine expected lifetime of the project at start; ● Determine the way to sustain financially the project over its expected lifetime from the

beginning. For this, either find a suitable business model or appropriate ESA funding, or combine the two models.

● Once the business model is determined, select the license so that it makes the business model or strategy possible;

● If the project involves creating a community, determine the governance structure and policy so that it is possible to separate the common interest from private interests.

● If the project involves creating a sustainable product, make sure support is considered from the inception, supported by appropriate funding/business model

● If the project interacts with large communities (e.g. Eclipse, FSF ...) make sure that communities are fully engaged with, i.e. participation from ESA (or contractor) users and developers within the communities, contribution (ideally of code) the community so that it is clear that two-way collaboration is taking place. Such communities are merit-based and having ackowledged experts is the best way to extract knowledge and expertise from the community.

In conclusion, we believe that open source provides significant opportunities and very limited or controllable risks for ESA and the European space sector. Open source is already widely used in the space sector, internationally as well as in Europe. Thus, these opportunities are being exploited and open source is growing as the software model for the European space sector.

As the main funder of European space software, ESA is in a position to take advantage of these opportunities and drive them further and faster than is already happening. ESA as a public body also has the obligation to spend public funds efficiently, produce results that benefit the public and are publicly accessible, and support European industry. We have shown that increasing the use and development of open source by ESA furthers these goals.

However, with any change, there is resistance. With open source, we have found in other sectors and also in space, that resistance declines with increasing awareness of and familiarity. Thus we believe that an ESA policy that generates support by increasing awareness of open source among stakeholders has a good chance of making the most of open source to the benefit of the European space sector.

3Authored or co-authored by UNU-MERIT.


open source study for the european space...

Documents