Open Standards and Open Source Software:

Similarities and Differences

Jack Verhoosel
TNO Telecom
Enschede, The Netherlands
j.p.c.verhoosel@telecom.tno.nl

1. Introduction
Standardization is already a fairly old means to reduce complexity and to simplify
working procedures, communication protocols and so on. In the area of
communication between ICT-systems, standardization has evolved very rapidly
over the last ten years. This has led to standardization of networks on for instance
the TCP/IP standard and web technologies. These standardization processes
have been fairly open mainly thanks to the approach of organizations like IETF
and W3C. The next challenge we face is standardization at the information level
and the interfaces of software applications that exchange this information. Open
standards in this area are generally accepted by the end-user organizations as a
means to improve interoperability between their systems.

In the area of software applications for exchanging information, a related relatively

new trend is the use of open source software. While many talk about open source
software, the exact meaning of open source software is fairly unknown as are the
advantages of using it. Open source software is for instance being built using a
modular approach, because this simplifies control of the software developments in
a large community of independent software developers. Another advantage of this
approach is that extensions can be easily added without loss of stability and
quality. In a nutshell, the most important pros for using open source software are:
independence of software-vendors, usually lower implementation costs and easier
coupling with other systems.

Important to notice is that the advantages of using open source software are
almost equal to those for the use of open standards. Therefore, although open
standards and open source software are entirely different concepts, they are often
confusingly mixed. This paper briefly defines both concepts and discusses some
similarities and differences between open standards and open source software.

2. Source code
The commonalities between open standards and open source software are mainly
based on the similar objectives of both concepts, like the prevention or tackling of
monopolies of software vendors, the decrease of cost of software and more
freedom of choice for the end-user. In principle, however, open standards and
open source software are entirely different concepts. Open standards are
concerned with the content and meaning of information, while the subject matter
with open source software is the source code, i.e. only the software and not the
information that it operates upon. Of course, open standards can be used in open
source software. In fact, open source development communities generally use
rather a good open standard instead of a badly constructed proprietary one. Open
source developers have no interest in keeping their standards private or closed,
because this is against the principle of openness that they propagate for their
software. Another reason for using open standards in open source software is the
costs for using proprietary standards. On the other hand, there is also open source
software that uses closed standards, mainly because there are no good open
alternatives. In this context, it is hard to keep the specifications of the closed
standard confidential and they will usually be publicly available. However, that
doesn’t make them completely open, because for instance they can still be
maintained in a closed decision process.

Technically speaking, there is no difference between open source software and

software of vendors of which the source code is not publicly available, also called
closed source software. The technical components of both types of software do
not differ. Therefore, open source or closed source software do not basically differ
in quality, stability, security and functionality. This is mainly determined by the level
of programming skills of software developers and the software development
process they use.

The discussion about open source software is primarily a juridical one. The basis
of a license under which an open source software product is being distributed is
different from the usual software licensees. An open source software license
guarantees a number of liberties. Sometimes a requirement is being used that
guarantees that, if the software is changed and redistributed, the same liberties
hold. The Open Source Initiative (OSI), a non-profit organization, has defined ten
characteristics of open source software and its licensees. OSI certifies open
source licensees and publishes a list of certified open source software. The most
well-known examples of open source licensees are the GPL (GNU Public
License), MPL (Mozilla Public License) and the BSD (Berkeley Software
Distribution).

Summarizing can be concluded that a piece of software is called open source,

whenever access to the source code and the application (target code) itself is free
of charge and that the program can be adapted, used and under certain criteria be
redistributed.

3. Free of charge?
There is a widespread mistake that open source software is completely free of
charge because of the liberties laid down in open source licensees. Indeed, no
fees have to be paid for the use of the software, whether the program is being
installed on 1 or 10.000 computers. However, the use of open source software is
never totally free. The software has to be installed, configured and managed,
which of course also involves certain costs.

A well-known analogy that is often being used in this sense is “the car with the
sealed hood”. Whenever the motor of a usual car breaks down, the driver can
open up the hood and try to repair the motor himself. Thus, the driver has a
choice: with sufficient knowledge of mechanics, he can fix the motor himself or he
can call the road-service for assistance. For the latter he will of course be charged.
Whenever the motor of a car with a sealed hood breaks down, the driver has no
choice and has to call for assistance and be charged.

With closed source software, there is usually only an executable program (byte-
code or binary code) without access to the source code. The software can
therefore not be easily changed and that is even prohibited by the vendor (the
hood is sealed). The software usually comes with a license that only allows the
use of the software and adaptation and redistribution of the software is prohibited.
This is a problem unknown in the open source community

Open source software is about freedom and independence of monopolistic

vendors. Open source software developers have the opinion that the knowledge
(source-code) has to be shared and be freely available for everyone. However, the
publishing of a book or CD with this knowledge and advising end-users can of
course be charged for. By sharing knowledge we can achieve a lot more in the
end. There is lots of proof of this in the form of projects in which hundreds of
software developers in communities contribute to the development of open source
software. Since everyone produces a part of the software, it can be developed
towards a mature, stable and secure software product. The open source operating
system Linux is living proof of this phenomenon.

4. Open standards
The label open source does not guarantee that the software also uses open
standards. Standards make it possible to use software from different parties to
work together, albeit vendors or open source communities. In order to make this
interoperability work as much as possible, standards have to be as open as
possible. There is no standard definition for the openness of a standard. Among
those that can be found in literature and in use, the definition of the Dutch Program
on Open Standards and Open Source Software is quite useful. This definition has
also been adopted by the European Interoperability Framework of the European
Commission. It consists of the following four criteria:

1. 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.).
2. 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.
3. The intellectual property – i.e. patents possibly present – of (parts of) the
standard is made irrevocably available on a royalty-free basis.
4. There are no constraints on the re-use of the standard.

This definition ensures good accessibility of a future-proof standard, optimal

consensus about the standard and acceptable payment. In this way, there is no
single party that can manipulate the standard for its own purposes. One of the
reasons of confusion is that this definition of open standards can be easily applied
to open source software. Thus, the openness of both concepts is also a similarity.

Open standards do not depend on whether the software in which they are being
applied is open or closed source software. On the other hand, it is very well
possible and from an end-users perspective very desirable to use open standards
at the interfaces of closed source software. This is, however, strongly dependent
on the market forces between end-users and software-vendors. In some sectors,
the competition between different software-vendors is large enough to make them
implement upcoming open standards fairly quickly. In other domains, however,
there are only one or two software-vendors that dominate the market. In that case,
the end-users have to strongly require the use of open standards in their tender
towards the software-venders. When using open source software, this is not an
issue at all.

References

[1] Dutch Program on Open Standards and Open Source Software:

http://www.ososs.nl
[2] IDA Programme: http://europa.eu.int/ida/en/home
[3] European Interoperability Framework:
http://europa.eu.int/ida/en/document/2319
[4] Belgium open standards definition:
http://www.openstandaarden.be/node/view/6
[5] Bruce Perens, open standards definition:
http://perens.com/OpenStandards/Definition.html
[6] Ken Krechmer, open standards definition:
http://www.csrstds.com/openstds.html