The Journal of Systems and Software 80 (2007) 1930–1937

www.elsevier.com/locate/jss

Controversy Corner
q
Open standards, open formats, and open source
Davide Cerri, Alfonso Fuggetta *

CEFRIEL – Politecnico di Milano, Via Fucini 2, 20133 Milano, Italy

Received 13 July 2006; received in revised form 25 January 2007; accepted 26 January 2007
Available online 20 February 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 extre-
mely critical topic.
The paper clarifies the basic terms and concepts. This is instrumental to suggest a number of actions and practices aiming at promot-
ing and defending openness in modern ICT products and services.
 2007 Elsevier Inc. All rights reserved.

Keywords: Open source; Open standard; Open format; Software development process; Software procurement; Interoperability

1. A critical problem eral has become a user of digital technologies: computers,

The impressive development of Information and Com-
munication Technology (ICT) is posing new challenges to
governments, users, and industries. The pervasiveness of
computers, digital devices, and networks is radically chang-
ing our society. Nowadays, every business is heavily based
on computers, networks, and sophisticated information
systems. Every student, professional, or individual in gen-
q
Controversy corner. It is the intention of the Journal of Systems and
Software to publish, from time to time, articles cut from a different cloth.
This is one such article.
The goal of CONTROVERSY CORNER is both to present informa-
tion and to stimulate thought and discussion. Topics chosen for this
coverage are not just traditional formal discussions of research work; they
also contain ideas at the fringes of the field’s ‘‘conventional wisdom’’.
These articles will succeed only to the extent that they stimulate not just
thought, but action. If you have a strong reaction to the article that
follows, either positive or negative, send it along to your editor, at
card@software.org.
We will publish the best of the responses as CONTROVERSY
REVISITED.
*
Corresponding author.
E-mail addresses: cerri@cefriel.it (D. Cerri), alfonso.fuggetta@poli-
mi.it (A. Fuggetta).
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. There-
fore, there are increasing concerns about the risks and chal-
lenges that can derive from an inappropriate handling of
emerging issues and problems such as management of intel-
lectual property, control of shared resources (e.g., the spec-
trum and the telecommunication network infrastructure),
software and network standards (Lessig, 2002). In particu-
lar, 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

0164-1212/$ - see front matter  2007 Elsevier Inc. All rights reserved.
doi:10.1016/j.jss.2007.01.048
 D. Cerri, A. Fuggetta / The Journal of Systems and Software 80 (2007) 1930–1937
modern ICT technology. Unfortunately, the definition of
open standard is not ‘‘standard’’. There are different inter-
pretations of the term and, more important, there are alter-
native 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. Exam-
ples of open formats are HTML and XML. It may be suf-
ficient 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 pro-
duced 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 discus-
sion 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 redis-
tribute 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 guaran-
tee 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 simplic-
ity, in the remainder of the paper the two terms will be con-
sidered 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, frame-
work 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 asso-
1
The reader is invited to consider additional sources for a detailed
discussion of other aspects of the problem (see, for instance, Fuggetta,
2003, 2004).
1931
ciated with the expression ‘‘open standard’’. Section 3 iden-
tifies 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 us 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 vari-
ous hardware and software components since anyone
with the technical know-how and the necessary equip-
ment 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:
• The standard is adopted and will be maintained by a
not-for-profit organization, and its ongoing develop-
ment 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 spec-
ification document is available either freely or at a nom-
inal 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.
2
http://en.wikipedia.org/wiki/Open_standard.
3
http://europa.eu.int/idabc/en/document/3473/5887.
1932 D. Cerri, A. Fuggetta / The Journal of Systems and Software 80 (2007) 1930–1937
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 offer-
ing and operating the standard, are what make the stan-
dard 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 ref-
erences 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# pro-
gramming 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 con-
junction with other ECMA members and guests (includ-
ing IBM, Fujitsu Software, Plum Hall, Monash
University and ISE), refined these specifications into stan-
dards. 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 pro-
cess. 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 com-
puters to palmtops to cell phones. Given recent news that
the W3C (Worldwide Web Consortium) has accepted
SVG as a ‘‘recommended candidate’’ (similar to the beta
status in software development) to become an open stan-
dard, the time for thinking about SVG is now.6
Other forms of ‘‘openness’’ are those defined by Sun for
Java and Adobe for PDF.
4 7
http://perens.com/OpenStandards/Definition.html.
5 8
http://msdn.microsoft.com/net/ecma/.
6 9
http://www.creativepro.com/.
(1) The Java language is defined through the Java Com-
munity Process (JCP).7 The process is led by Sun:
other organizations can join the process by signing
a specific agreement with Sun (Java Specification Par-
ticipation 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. Fur-
thermore, Sun controls the Project Management
Office (PMO), the ‘‘group within Sun Microsystems
that is responsible for administering the JCP and
chairing the EC’’ (Sun Microsystems, 2004).
(2) Adobe has published the format of Acrobat (PDF).
Therefore, even if the company still controls the for-
mat, now other companies can implement readers for
PDF documents (Adobe, 2004).
Let us consider now other two important sectors of the
ICT world: GSM and the 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 third Generation Mobile Sys-
tem 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 geo-
graphical 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 dig-
ital 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 sev-
eral areas (e.g., routing, transport, security, etc.). Much
of the work is handled via mailing lists. The IETF holds
meetings three times per year.
http://www.jcp.org/en/home/index.
http://www.3gpp.org/.
http://www.chiariglione.org/mpeg/.
 D. Cerri, A. Fuggetta / The Journal of Systems and Software 80 (2007) 1930–1937
The IETF working groups are grouped into areas, and
managed by Area Directors, or ADs. The ADs are mem-
bers of the Internet Engineering Steering Group (IESG).
Providing architectural oversight is the Internet Archi-
tecture 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 pre-
sented in RFC 2026 (Bradner, 1996). 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 continu-
ously compared and harmonized with ‘‘external standards’’,
which are classified by the IETF in two main categories:
(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 organiza-
tion 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, devel-
oped by national and international standards bodies, and
may be developed in agreement with ‘‘other specifications’’
that are indeed proprietary.
2.1. Summing up
Most of the approaches presented so far are compatible
with the definition of open standard proposed in the Wiki-
pedia, but are not coherent with the vision offered by
Perens. For instance, someone considers PDF an ‘‘open for-
mat’’, since its definition is public; others would never con-
sider it ‘‘open’’ because a single company controls it. In
general, when it comes to discussing the openness of solu-
tions 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 com-
plicate 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 tech-
10
http://www.ietf.org/overview.html.
1933
nical 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 lan-
guage that can be implemented in different products, by
different companies, using different strategies and tech-
niques. The real issue is therefore to understand the mean-
ing 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.
Typical examples of licensable proprietary disclosed
standards are PDF and Autodesk DWF document
formats.
Concerted disclosed standards: these ‘‘de facto’’ stan-
dards are defined by closed or controlled groups of orga-
nizations 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 pro-
cess through which the standard is defined and
managed.
1934 D. Cerri, A. Fuggetta / The Journal of Systems and Software 80 (2007) 1930–1937
(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 concern-
ing 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 tech-
nology 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 stan-
dard cannot be implemented without asking someone for a
license and paying the relevant fees.
Each standard organization has its own policy to regu-
late 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 pat-
ented technologies in Internet Standards, if they are avail-
able 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-discrim-
inatory terms, or even with no licensing commitment, if
they feel that this technology is superior enough to alter-
natives with fewer IPR claims or free licensing to out-
weigh the potential cost of the licenses.11
W3C has a more precise patent policy. After a long dis-
cussion 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 stan-
dards, W3C seeks to issue Recommendations that can
be implemented on a Royalty-Free (RF) basis. Subject
11
http://www.ietf.org/rfc/rfc3979.txt.
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
implementation of the standard, it is reasonable to require
the publication of an open source reference implementation
of any extension to the standard.
3.1. 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 consor-
tium: 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 tech-
nologies 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
12
http://www.w3.org/Consortium/Patent-Policy-20040205.
 D. Cerri, A. Fuggetta / The Journal of Systems and Software 80 (2007) 1930–1937
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 pertains only 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: the
former relates to the implementation of a software system,
while the latter identifies a property (‘‘being open’’) of a
standard, i.e. a specification.
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 jeop-
ardized 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 tech-
nology 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, individ-
ual users, single companies and administrations may be
unable to impose their requirements to large software ven-
dors. Thus the issue of providing an open source/free refer-
ence 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 com-
pany. 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 refer-
ence implementations. It is necessary to pursue a combina-
tion 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 imple-
mentations 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 particu-
1935
lar, the main claims associated to the adoption of open
software and open standards and formats can be summa-
rized 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 commu-
nication protocols) allows systems developed by differ-
ent 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 differ-
ent providers. In particular, the adoption of open for-
mats makes the users free to change a program
without loosing data and information. Moreover, any-
body can access the information without necessarily
purchasing or acquiring non-free programs. Open stan-
dards 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
us consider some examples.
Too often the discussion on open source is carried out
without distinguishing between packages and custom soft-
ware. A package is a piece of software released to users via
a license (proprietary or free/open source). The license indi-
cates 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 spe-
cific user. Since it is paid in full, it is reasonable (and obvi-
ous) to request that the source code be delivered to the
customer who must have the (possibly non-exclusive) own-
ership 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 soft-
ware 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
1936 D. Cerri, A. Fuggetta / The Journal of Systems and Software 80 (2007) 1930–1937
is needed to facilitate and promote the dissemination of
knowledge. This is another misleading statement. Source
code can be used to disseminate knowledge about pro-
gramming idioms and techniques. However, it is substan-
tially ineffective when used to disseminate the knowledge
associated with software architecture and, more important,
the application domains the software refers to (Fuggetta,
2003). 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 gen-
eral requirement that all software should be open source
is extreme and in many cases unrealistic. Interoperability
can be ensured by requiring software applications to be
compliant to open standards, even when their implementa-
tion is proprietary.
Openness is important for document formats, since it
involves the ownership of the information being repre-
sented through the format. Certainly, the contents of a doc-
ument 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 administra-
tion in a data base are a ‘‘public’’ resource, whose control
cannot be limited or influenced in any form by the devel-
oper of the data base management systems. Similarly, citi-
zens 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 pre-
sented so far.
6. Some concrete proposals
The previous sections have mainly been devoted to crit-
ically 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 address-
ing 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 pro-
mote 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 and not controlled by a single party.
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 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 prod-
uct 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 avail-
able in at least an open format without any loss of informa-
tion. 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 consid-
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.
 D. Cerri, A. Fuggetta / The Journal of Systems and Software 80 (2007) 1930–1937
ering the percentage of cost coverage provided by the fund-
ing authority, the nature of the organization using the
funds, and the overall goal and mission of the funding pro-
gram. For instance, it is reasonable to define different pol-
icies for 100% funded academic research initiatives w.r.t.
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 men-
tioned above can greatly foster the spread of open stan-
dards and formats. Another interesting policy might
concern custom software acquired by public bodies: it
may be released as open source software, in order to pro-
mote 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 rela-
tively ‘‘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 intro-
1937
duced in a very confusing and misleading way. This tends
to generate radical and unreasonable positions. In particu-
lar, 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 defi-
nitions for the term ‘‘open standard’’, based on the differ-
ent practices in the market. Moreover, the paper contains
some proposals to deal with the different issues and chal-
lenges related to the notions of openness, customers’ rights,
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.
References
Adobe, 2004. PDF Reference: Fifth Edition. Adobe Systems Incorpo-
rated. Available from: <http://partners.adobe.com/public/developer/
pdf/index_reference.html>.
Bradner, S., 1996. The Internet Standards Process – Revision 3. IETF,
Request for Comments 2026. Available from: <http://www.ietf.org/
rfc/rfc2026.txt>.
Fuggetta, A., 2003. Open source software: an evaluation. Journal of
Systems and Software 66 (1), 77–90.
Fuggetta, A., 2004. Open source and free software: a new model for the
software development process? Upgrade, The European Journal for
the Informatics Professional, October 2004. Available from: <http://
www.upgrade-cepis.org/index.html>.
Lessig, L., 2002. The Future of Ideas: The Fate of the Commons in a
Connected World. Vintage.
Sun Microsystems, Inc., 2004. JCP 2: process document. The formal
procedures for using the Java Specification development process.
Available from: <http://www.jcp.org/en/procedures/jcp2>.