Open Formats,
and Open Source
Version 5.0
January 2007
Final Draft
Davide Cerri and Alfonso Fuggetta
CEFRIEL - Politecnico di Milano
Open Standards, Open Formats,
and Open Source
Davide Cerri and Alfonso Fuggetta
CEFRIEL - Politecnico di Milano
January 2007
Abstract
The paper proposes some comments and reflections on the notion of “openness” and on how it relates to three important topics: open standards, open formats, and open source. Often, these terms are considered equivalent and/or mutually implicated: “open source is the only way to enforce and exploit open standards”. This position is misleading, as it increases the confusion about this complex and extremely critical topic.
The paper clarifies the basic terms and concepts. This is instrumental to suggest a number of actions and practices aiming at promoting and defending openness in modern ICT products and services.
Keywords: open source, open standard, open format, software development process, software procurement, interoperability.
1. A Critical Problem
The impressive development of Information & Communication Technology (ICT) is posing new challenges to governments, users, and industries. The pervasiveness of computers, digital devices, and networks is radically changing our society. Nowadays, every business is heavily based on computers, networks, and sophisticated information systems. Every student, professional, or individual in general has become a user of digital technologies: computers, digital cellular phones and PDAs, MP3 players, and the Internet are part of our daily routine. The ICT revolution is changing our life and the way we work, study, enjoy life.
This revolution is going to have permanent and radical effects on the way society is shaped and evolves. Basically, all the modern forms of knowledge and information are managed through digital devices and information. Therefore, there are increasing concerns about the risks and challenges that can derive from an inappropriate handling of emerging issues and problems such as management of intellectual property, control of shared resources (e.g., the spectrum and the telecommunication network infrastructure), software and network standards [5]. In particular, there are three concepts that are considered extremely important in this respect: open standards, open formats, and open source.
Open standards define standard interfaces (in general, requirements) of ICT systems and services. Open standards make it possible to have a variety of interchangeable and interoperable products developed by different companies. They are instrumental to increase competition and, in the end, customer satisfaction. Typical examples of open standards are ANSI C and TCP/IP, two cornerstones of modern ICT technology. Unfortunately, the definition of open standard is not “standard”. There are different interpretations of the term and, more important, there are alternative visions about the strategy that should be followed to define and update these standards.
Open formats are open standards to store and transmit documents, information, and in general knowledge. Examples of open formats are HTML and XML. It may be sufficient to discuss just “standards” in general, as standard formats are just a particular form of standard. However, since formats play a very important role, it is worthwhile to consider them explicitly in the rest of the discussion.
Document formats are often defined by the producers of the software packages that generate them: for instance, a major source of discussion has been the approach used in the past by Microsoft to define and evolve the formats of Office documents. In general, if a document has been produced using a specific package (and is therefore stored using a specific format), users who want to access that document are forced to buy and use the package that has generated it. In general, the notion of open format is subject to discussion and needs some detailed discussion and clarification.
Open source is an approach to manage the development and distribution of software. Open source means that the user of a software program is able (free) to access the source code of the program, study it, change it, and redistribute it. This can be achieved using particular software licenses that grant the user these rights.
Indeed, there are different open source licensing models. The most popular one is the General Public License (GPL), which defines the notion of copyleft as a means to guarantee the free and open diffusion of software. Open source is considered somewhat equivalent to free software. Indeed, even if most practical effects are similar, the motivations of the two movements are different. For the sake of simplicity, in the remainder of the paper the two terms will be considered equivalent.
Open source is considered a winning approach for a variety of reasons: technical, economical, and ethical. This paper will concentrate on some of the issues and claims associated with open source.1 In particular, it
will discuss the relationship among open source, open standards, open formats, and, in general, the protection of customers’ rights. Indeed, many consider open source as the most appropriate (or maybe the only) way to define and enforce open standards and open formats. This view is simplistic and misleading, as the remainder of the paper will try to demonstrate. For these reasons, the ultimate goal of the paper is to provide a coherent, even if preliminary, framework of concepts and proposals to promote the development of the market and to address customers’ needs and requests.
The paper is organized as follows. Section 2 provides some examples of the different meanings that can be associated with the expression “open standard”. Section 3 identifies and illustrates different levels of openness in standards. Section 4 deals with the relationship between open standards and open source software, and Section 5 discusses why and how “openness” is important for the protection of customers’ rights. Finally, Section 6 proposes some concrete actions and practices aiming at promoting openness and defending customers’ rights in the ICT market.
2. What do we mean by “open”?
Terms such as “open standards” and “open formats” are certainly quite popular, but their meaning is far from being unanimously shared. Let’s consider for example some of the definitions and interpretations of the term “open standard” that can be found on the Internet.
Wikipedia proposes the following definition:
Open standards are publicly available specifications for achieving a specific task. By allowing anyone to use the standard, they increase compatibility between various hardware and software components since anyone with the technical know-how and the necessary equipment to implement solutions can build something that works together with those of other vendors.2
A more restrictive definition of open standard is included in the European Interoperability Framework for pan-European eGovernment Services:
The following are the minimal characteristics that a specification and its attendant documents must have in order to be considered an open standard:
1 The reader is invited to consider additional sources for a detailed discussion of other aspects of the problem (see ,for instance, [1] and [2]).
The standard is adopted and will be maintained by a not-for-profit organization, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
The intellectual property - i.e. patents possibly present - of (parts of) the standard is made irrevocably available on a royalty-free basis.
There are no constraints on the re-use of the standard.3
This definition goes well beyond the one proposed by Wikipedia, as it considers also the process according to which the standard is defined and maintained. It also requires that the standard can be implemented without having to pay any royalty fee.
Bruce Perens on his web site proposes an even more articulated definition:
An Open Standard is more than just a specification. The principles behind the standard, and the practice of offering and operating the standard, are what make the standard Open.4
Perens proposes a number of principles and practices. In particular, he stresses the fact that the standard should be “free”, based on a “free” reference implementation, and should be articulated in such a way to make predatory practice impossible, i.e., it must include “license terms that protect against subversion of the standard by embrace-and-extend tactics”.
On the Internet, it is possible to find also additional references to the notion of standard. For instance, this is taken from the Microsoft MSDN website:
In August, 2000, Microsoft, Hewlett-Packard and Intel co-sponsored the submission of specifications for the Common Language Infrastructure (CLI) and C# programming language to the international standardization organization ECMA. As a result, ECMA formed two task groups (TG3 and TG2, respectively) within TC39, its technical committee responsible for programming languages and application development.
During the next year, the co-sponsor companies, in conjunction with other ECMA members and guests (including IBM, Fujitsu Software, Plum Hall, Monash University and ISE), refined these specifications into standards. In December, 2001, the ECMA General Assembly ratified the 1st edition of the C# and CLI standards as ECMA-334 and ECMA-335, respectively. A technical report on the CLI, ECMA TR84, was also ratified.
In late December, 2001, ECMA submitted the standards and TR to ISO/IEC JTC 1 via the latter's Fast-Track process. In April, 2003, ISO ratified the standards as ISO/IEC 23270 (C#), ISO/IEC 23271 (CLI) and ISO/IEC 23272 (CLI TR). Equivalent specifications have also been adopted as 2nd edition standards and TR by ECMA.5
SVG represents another typical approach:
SVG is an open format developed by a coalition of Web-related companies. In brief, it promises a text-based file format that is at once easy to use, space-efficient, and compatible with a range of browser devices – from computers to palmtops to cell phones. Given recent news that the W3C (Worldwide Web Consortium) has accepted SVG as a “recommended candidate” (similar to the
3 http://europa.eu.int/idabc/en/document/3473/5887 4 http://perens.com/OpenStandards/Definition.html 5 http://msdn.microsoft.com/net/ecma/
beta status in software development) to become an open standard, the time for thinking about SVG is now.6
Other forms of “openness” are those defined by Sun for Java and Adobe for PDF.
1. The Java language is defined through the Java Community Process (JCP).7 The process is led by Sun:
other organizations can join the process by signing a specific agreement with Sun (Java Specification Participation Agreement, JSPA). Individual members have to sign an Individual Expert Participation Agreement (IEPA) as well. Sun has a permanent member in the Executive Committee (EC), the board that guides the evolution of Java technologies. Furthermore, Sun controls the Project Management Office (PMO), the “group within Sun Microsystems that is responsible for administering the JCP and chairing the EC” [6].
2. Adobe has published the format of Acrobat (PDF). Therefore, even if the company still controls the format, now other companies can implement readers for PDF documents [1].
Let’s consider now other two important sectors of the ICT world: GSM and Internet.
GSM is considered a major success of the European Industry and the results of an “open standard” approach. GSM was managed by ETSI and, more recently, the 3GPP8: “The purpose of 3GPP is to prepare,
approve and maintain globally applicable Technical Specifications and Technical Reports for a 3rd Generation Mobile System based on the evolved GSM core networks, and the radio access technologies supported by the Partners to be transposed by the Organizational Partners into appropriate deliverables (e.g., standard).” Core members of 3GPP are organizational partners. An organizational partner is “any open Standardization Organization, irrespective of geographical location”.
Important standards for multimedia communications are defined by MPEG, “Moving Picture Experts Group (MPEG), a working group of ISO/IEC in charge of the development of standards for coded representation of digital audio and video.9” Therefore, in this case the working group is part of an official standardization
board (ISO).
Finally, the Internet. “The net” is managed by the Internet Engineering Task Force:
The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual. The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via mailing lists. The IETF holds meetings three times per year.
The IETF working groups are grouped into areas, and managed by Area Directors, or ADs. The ADs are members of the Internet Engineering Steering Group (IESG). Providing architectural oversight is the Internet Architecture Board, (IAB). The IAB also adjudicates appeals when someone complains that the IESG has failed. The IAB and IESG are chartered by the Internet Society (ISOC) for these purposes.10
The process used to create an Internet Standard is presented in RFC 2026 [2]. Standards are created through a complex, open consultation and experimentation process. Eventually, a “specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level.” Internet Standard produced by the IETF are continuously compared and harmonized with “external standards”, which are classified by the IETF in two main categories:
6 http://www.creativepro.com/ 7 http://www.jcp.org/en/home/index 8 http://www.3gpp.org
9 http://www.chiariglione.org/mpeg/ 10 http://www.ietf.org/overview.html
1. Open standards: standards defined by “various national and international standards bodies, such as ANSI, ISO, IEEE, and ITU-T.”
2. Other specifications: “other proprietary specifications that have come to be widely used in the Internet may be treated by the Internet community as if they were a ‘standards’. Such a specification is not generally develop in an open fashion, is typically proprietary, and is controlled by the vendor, vendors, or organization that produced it.”
Thus, Internet Standards are similar in nature to other standards developed by open consortia such as the W3C. They are different from “official” open standards, developed by national and international standards bodies, and may be developed in agreement with “other specifications” that are indeed proprietary.
Summing up
Most of the approaches presented so far are compatible with the definition of open standard proposed in the Wikipedia, but are not coherent with the vision offered by Perens. For instance, someone considers PDF an “open format”, since its definition is public; others would never consider it “open” because a single company controls it. In general, when it comes to discussing the openness of solutions and technologies, there are many different views, despite an apparent endorsement of “open standards”. So what do we really mean by “open”? The issue is very complicate and intricate, and definitely needs some clarification.
3. Standards and levels of openness
There is little debate about the definition of the term “standard”: a standard is a specification, i.e., a set of technical constraints and requirements that globally identifies the external behavior of a product/service. “External behavior” implies that the implementation is irrelevant, as long as it conforms with the standard. For instance, ANSI C defines a “standard” specification for the C language that can be implemented in different products, by different companies, using different strategies and techniques. The real issue is therefore to understand the meaning of “open” and the implications that it induces.
There are different forms of “standards” that can be roughly organized as follows:
Proprietary standards (often covered by patents and/or copyrights). They are “de facto” standards because of their wide availability and adoption. They can be further organized in two subcategories:
Proprietary undisclosed standards: they are standards whose structure is kept undisclosed. They can be used/exploited by other companies through licensing ruled by specific NDAs (Non Disclosure Agreements). Typical examples are protocols or document formats whose details are not made public (e.g., Skype).
Proprietary disclosed standards: they are created by a company and then made public. They can be restricted (nobody can use them) or licensable: in this case, they can be either free or royalty-based. A typical example of a proprietary disclosed standard that has restricted access is Visual Basic: it is well-known, but nobody other than Microsoft can create compilers. Typical examples of licensable proprietary disclosed standards are PDF and Autodesk DWF document formats.
Concerted disclosed standards: these “de facto” standards are defined by closed or controlled groups of organizations that exploit a consultation mechanisms to collect feedback and suggestions about the evolution of the standard. A typical example is Java.
Open standards (concerted): they are defined by open consortia or group of companies, universities, and research institutions. Typical examples are the standard proposed by W3C and IETF.
Open standard (de jure): these standards are defined by official national and international standardization bodies such as ANSI and ISO.
Except for proprietary undisclosed standards, the remaining definitions identify four different levels of “openness”:
1. Disclosed: the standard is owned by a company and is made “available” in some form to other companies and users. The owner controls the evolution of the standard.
2. Concerted: there is a consultation, but the admission to the consultation process and the management of the process itself is controlled by the company or by the association of companies that emits the standard.
3. Open “concerted”: There is an open participation process through which the standard is defined and managed.
4. Open “de jure”: standards are owned and managed by official international and national standardization bodies.
From the above discussion it is clear that often the term “open” is used in very different ways. For instance, on the Autodesk website you can find the following FAQ concerning DWF, the format used by Autocad to publish diagrams on the web:
16. Is DWF an open file format?
DWF is an open file format. Autodesk publishes the DWF specification and makes available C++ libraries for any developer who wants to build applications around DWF, with the DWF Toolkit..
Indeed, DWF (as well as PDF) is a disclosed format, whose usage is supported by making available a free toolkit.
In other situations, such as in the case of Java, the technology is considered “open standard” because it can be ported to different platforms. Actually, Java is a concerted standard. It may appear as a paradox, but Microsoft C# is a true open standard while Java is not.
Another important issue in evaluating the openness of a standard concerns patents and their licensing terms. In fact, a publicly available specification and an open process are not enough to declare a standard as “open”, if the standard cannot be implemented without asking someone for a license and paying the relevant fees.
Each standard organization has its own policy to regulate the inclusion of patented technologies in its standards. The IETF intellectual property rights (IPR) policy is defined in RFC 3979 and, even if it gives preference to unencumbered technologies, it allows the inclusion of patented technologies in Internet Standards, if they are available under “reasonable and non discriminatory” (RAND) licensing terms:
In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses.11
W3C has a more precise patent policy. After a long discussion and public consultation, W3C decided to adopt a royalty-free (RF), rather than RAND, licensing requirement:
In order to promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented on a Royalty-Free (RF) basis. Subject to the conditions of this policy, W3C will not approve a Recommendation if it is aware that Essential Claims exist which are not available on Royalty-Free terms.12
Certainly, it is important to evaluate if the definition of the standard and of the standardization process make it possible to have predatory practices as those indicated by Perens. They can compromise the openness of a standard.
Indeed, the maintenance of an open standard is a critical issue: not allowing extensions may prevent the evolution of the standard and stifle innovation, but on the other side allowing proprietary extensions may lead to the subversion of the standard. A possible solution is to require that all extensions must be published and licensed under royalty-free terms. Moreover, if there is an open source reference
11 http://www.ietf.org/rfc/rfc3979.txt
implementation of the standard, it is reasonable to require the publication of an open source reference implementation of any extension to the standard.
Summing up
In order to evaluate the openness of a standard, it is essential to take into account several elements regarding how the standard is defined, managed, and made available. An open standard must fulfill all of the following requirements:
the standard specification document must be publicly available, either free of charge or at a nominal fee;
the standard must be owned and managed by an official standardization body or by an open group or consortium: it must not be owned or controlled by a single party, and no single party must have special rights on it;
the standard must be defined and managed according to an open process: every interested party must be able to join the standardization process, which must be based on an open decision making procedure (e.g., consensus);
the standard must be free to implement for all interested parties, without any royalty fee: possible patented technologies included in the standard must be licensed with royalty free non discriminatory terms;
it must be possible to extend and reuse the standard in other open standards.
4. Open source and open standards
Open source is a complex phenomenon that spans many different issues and topics. In this context, it is interesting to consider it as a potential means to guarantee the real openness of standards and formats. Indeed, open source advocates claim that open source software is the only way to guarantee interoperability and interchangeability, as they are considered synonyms of open standard. This is not true, as there can be closed implementations of open standards, as well as open source programs using their own protocols and formats.
Recently, Sun has announced that Java will be released using an open source license (GPL). It must be made clear that this decision does not make Java an open standard. The definition of the Java language is still carried out using the Java Community Process. Sun’s decision only pertains to the license applied to the
implementations of the JVM and of other components. Therefore, this is a clear demonstration of the differences between open source and open standard.
Nevertheless, the issue of the relationships between open source software and open standards is important and deserves careful consideration. It is necessary to guarantee that an open standard remains really open and is not jeopardized by anybody. This can be achieved in a variety of ways:
Open standards are released by bodies that do have the power to control the definition of a standard, especially in the case of “de jure” open standards.
Procurement practices of large customers (e.g., public administrations) may have a strong influence on technology providers that do not adhere to standards.
Certainly, one may observe that big monopolists may extend an open standard in proprietary ways despite the positions of official standardization bodies. Also, individual users, single companies and administrations may be unable to impose their requirements to large software vendors. Thus the issue of providing an open source/free reference implementation of an open standard arises. An open source/free implementation can facilitate the dissemination of the standard and, at the same time, may disincentive companies from proposing solutions not compliant with an open standard. However, even this approach does not constitute a perfect solution, as its effectiveness depends on the degree of penetration of the market leading company. For instance, Internet Explorer has such a strong position in the market that it can “de facto” impose non-W3C compliant extensions to HTML.
Therefore, the issue of protecting open standards is not simply solved by asserting the need for open source reference implementations. It is necessary to pursue a combination of actions and initiatives able to ensure and maintain the openness of a standard. Antitrust authorities may play a role when anticompetitive practices induce a distortion of market and competition. In general, the final goal of these combined efforts is to have a number of competing implementations of the same standard.
5. Openness and the protection of customers’ rights
Open source and open formats are often considered the only practical way to protect customers’ rights. In particular, the main claims associated to the adoption of open software and open standards and formats can be summarized as follows:
Users can inspect the source code and check that it does not accomplish unsafe or undesired operations.
Users can take full control of software. They can change the company in charge of maintaining it. They can develop, fix, change, improve, and redistribute the code without restrictions and limitations. The adoption of open standards (e.g. standard communication protocols) allows systems developed by different technology providers to interoperate. Therefore, a user or organization is not forced to use products from a single provider, and different users or organizations can communicate even if they use products from different providers. In particular, the adoption of open formats makes the users free to change a program without loosing data and information. Moreover, anybody can access the information without necessarily purchasing or acquiring non-free programs. Open standards and formats are needed in order to avoid the “lock in” problem.
These claims are particularly relevant when applied to public administrations. They store critical personal and government data. Moreover, they offer “public” services to the entire population and must therefore guarantee equal access to everybody, and neutrality with respect to technology and service providers. Indeed, the needs and requests underlying the above-mentioned claims are legitimate and more than reasonable. Nevertheless, requiring software and formats to be “only” open is in some cases unnecessary, and in others impossible to obtain and, therefore, unrealistic or discriminatory. Let’s consider some examples.
Too often the discussion on open source is carried out without distinguishing between packages and custom software. A package is a piece of software released to users via a license (proprietary or free/open source). The license indicates the rights granted to the user and also the limitations he/she must obey to. Even free licenses such as the GPL do impose limitations and constraints (for instance, any code linked to a GPL program must be GPL as well). Custom software is developed through a service contract for a specific user. Since it is paid in full, it is reasonable (and obvious) to request that the source code be delivered to the customer who must have the (possibly non-exclusive) ownership of the software. Therefore, the problems identified by open source advocates hold for packages, but basically disappear in the case of custom software.
As for packages, it must be noted that the ability to inspect the code does not necessarily require that the software be open source (or free). Open source means that the code can be also modified and redistributed. This goes well beyond the issue of protecting customers’ rights. Often, open source advocates claim that the redistribution of code is needed to facilitate and promote the dissemination of knowledge. This is another misleading statement. Source code can be used to disseminate knowledge about programming idioms and techniques. However, it is substantially ineffective when used to disseminate the knowledge associated with software architecture and, more important, the application domains the software refers to [3]. Certainly, open source can be a vehicle to facilitate the dissemination of technology, and therefore can be an effective means in the exploitation phase of publicly funded projects.
In general, customers may require free/open source implementations also for packages, if they want (and can exploit) the possibility to modify and redistribute the code independently from the original supplier. Anyway, a general requirement that all software should be open source is extreme and in many cases unrealistic. Nevertheless, the discussion about openness of the source code must not overshadow other sides of the problem.
Indeed, the problem is different for standards like communication protocols. Users must be free to choose between different products and implementations (proprietary or free/open source) that can interoperate, and technology providers must be free to build interoperable implementations. This is made possible by open standards: without open standards, market leading companies can exploit their prominent position to cut others out.
Openness is even more important for document formats, since it involves the ownership of the information being represented through the format. Certainly, the contents of a document or of a data base are not owned by the developer of the package used to create and store them. A novelist is the exclusive owner of the story he/she wrote, independently of the word processor that was used to write it. Similarly, the information about citizens stored by a public administration in a data base are a “public” resource, whose control cannot be limited or influenced in any form by the developer of the data base management systems. Similarly, citizens cannot be forced to purchase a specific product to access information and data published or released by a public administration. It is therefore essential to identify means to protect the rights of the owner of any specific information stored or manipulated by a software system. They will be discussed in the next section, which illustrates a number of concrete proposals to address the issues presented so far.
6. Some concrete proposals
The previous sections have mainly been devoted to critically analyze positions and proposals that are currently pushed forward, especially in the open source/free software community. This section aims at proposing concrete actions and practices that can be instrumental in addressing the issues discussed so far.
6.1.
The protection of customers’ rights
The source code of custom software should be owned by the procurer, at least in non-exclusive form. In this way, the procurer is not bound to the original supplier, and can use, modify, and redistribute the software in the most appropriate way (e.g., through open source licenses). This is particularly important for public administration bodies: they should make sure that their procurement practices take this issue into account carefully.
With respect to software packages, even when they are not free/open source, it is reasonable to request that the source code is made available to the customer for inspection and recompilation. Again, this is important in particular for public administrations, e.g., for security reasons (think about an electronic voting system). Moreover, the package license should allow the customer to turn to other suppliers if the original one is no more available, or able or willing to maintain the package. This can be obtained by requiring the code to become open source in such situations.13
6.2.
Interoperability and open standards
In order to guarantee interoperability and the possibility to choose among different products, it is essential to promote and enforce the adoption of open standards, unless there are very specific and motivated reasons not to pursue this choice. Again, public bodies may play a major role, by enforcing this policy in their procurement policies and IT systems (e.g., exploitation of web services for public portals and web sites). It is indeed important to clarify that a publicly available specification is not a sufficient condition to declare a standard as “open”. Only open “de jure” or “concerted” standards can be considered really “open”, as they are managed with an open process, not controlled by a single party, and available on a royalty free basis.
6.3.
Open formats and open access to data
The technology supplier cannot claim any right on the customers’ data and information or impose limitations and constraints on their manipulation. The customer must have the true possibility to switch to another supplier and to access its own information without being anyhow limited. If a program stores user data
13 In most situation, a software solution is a combination of custom software and packages. Of course, each individual component can be managed according to the policies that have been proposed in this paper.
in a proprietary format (e.g. for performance reasons), it must anyway be possible to export that complete
data in an open format.
Public bodies must publish data using open formats, because citizens cannot be forced to buy a particular product in order to access public data. Public bodies can also publish data in proprietary formats (e.g., if these formats are very common), but any document must always be available in at least an open format without any loss of information. Moreover, the open format version of the document must be the authoritative one.
6.4.
Dissemination of results
Publicly funded research projects should require a certain level of “openness” in the dissemination of results, e.g., open source implementations. This should be defined by considering the percentage of cost coverage provided by the funding authority, the nature of the organization using the funds, and the overall goal and mission of the funding program. For instance, it is reasonable to define different policies for 100% funded academic research initiatives wrt to 50% funded industrial exploitation programs (in this case, there is a private investment of the industrial component).
6.5.
Public procurement practices
Public bodies procurements practices can have a great influence on the behavior of technology providers.
The adoption of procurement guidelines like the ones mentioned above can greatly foster the spread of open standards and formats. Another interesting policy might concern custom software acquired by public bodies: it may be released as open source software, in order to promote reuse of solutions and synergic development efforts.
7. Conclusions
The discussion on open standards, open formats, and open source is extremely important as it involves some of the key technologies that determine the development of our society. The discussion on these topics suffers from two different kinds of problems. First, software is a relatively “new and unique” technology, as it is basically an immaterial “goods”. Software is knowledge, and therefore it is not easy to adapt to software the same kind of approaches and concepts used in other industrial sectors. Second, the discussion is too often biased and influenced by social, political, and also ethical factors. Even if these issues are of course extremely important, they are introduced in a very confusing and misleading way. This tends to generate radical and unreasonable positions. In particular, the promotion of open standards and open formats is confused with the open source movement. Certainly, these issues are interrelated, but it is wrong to overlap them.
This paper has tried to provide a coherent framework to assess and understand the span and complexity of these problems. In particular, it has identified a number of definitions for the term “open standard”, based on the different practices in the market. Moreover, the paper contains some proposals to deal with the different issues and challenges related to the notions of openness, customers’ right, and market development. Hopefully, the paper will be a contribution to promote an “open” and constructive approach to foster the creation of a healthy software market.
8. References
1. Adobe. PDF Reference: Fifth Edition. Adobe Systems Incorporated, 2004. Available at http:// partners.adobe.com/public/developer/pdf/index_reference.html
2. S. Bradner. The Internet Standards Process – Revision 3. Network Working Group Request for Comments: 2026. Available at http://www.ietf.org/rfc/rfc2026.txt
3. A. Fuggetta. “Open source software: an evaluation”. Journal of Systems and Software, April 2003. 4. A. Fuggetta. “Open Source and Free Software: A New Model for The Software Development
Process?“ Upgrade (The European Journal for the Informatics Professional), October 2004. Available at http://www.upgrade-cepis.org/index.html.
6. Sun Microsystems, Inc. JCP 2: Process Document. The formal procedures for using the Java Specification development process. http://www.jcp.org/en/procedures/jcp2
