Open Standards,Open Formats,

and Open SourceVersion 5.0

January 2007Final Draft

Davide Cerri and Alfonso FuggettaCEFRIEL - Politecnico di Milano

Open Standards, Open Formats, and Open Source

Davide Cerri and Alfonso Fuggetta

CEFRIEL - Politecnico di Milano

January 2007

AbstractThe 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 ProblemThe 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.

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 1

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:

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 2

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]).

2 http://en.wikipedia.org/wiki/Open_standard

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

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 3

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:

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 4

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 upMost 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 opennessThere 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 royalty-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.

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 5

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

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 6

11 http://www.ietf.org/rfc/rfc3979.txt

12 http://www.w3.org/Consortium/Patent-Policy-20040205

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 standardsOpen 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.

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 7

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’ rightsOpen 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.

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 8

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 proposalsThe 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’ rightsThe 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 standardsIn 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 dataThe 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

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 9

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 resultsPublicly 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 practicesPublic 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. ConclusionsThe 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. References1. 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.

5. L. Lessig. The Future of Ideas: The Fate of the Commons in a Connected World. Vintage, 2002.

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 10

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

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 11

Open Standards, Open Formats, and Open Source

© Davide Cerri and Alfonso Fuggetta, 2007 12

NOTICE: This is the author’s version of a work that was accepted for publication in The Journal of Systems & Software. Changes

resulting from the publishing process, such as peer review, editing, corrections, structural formatting, and other quality control mechanisms may not be reflected in this

document. Changes may have been made to this work since it was submitted for publication. A definitive version was

subsequently published in The Journal of Systems & Software, vol. 80, issue 11, November 2007, doi:10.1016/j.jss.2007.01.048

Alfonso FuggettaCEFRIELVia Fucini, 220133 Milan (Italy) Phone +39 02239541 Fax +39 0223954254 Alfonso.Fuggetta@polimi.it