Version 0.1
Maintained by: Nah Soo Hoe (email:nsh@pop.jaring.my)

Last updated: 21 February 2005

This work is licensed under the
Creative
Commons Attribution License. To view a copy of this license, visit
http://creativecommons.org/licenses/by/2.0/ or send a letter to
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305,
USA

This document was written as it was felt there is a necessity for a
short, simple, yet comprehensive document that one can use to answer
many of the myths and realities surrounding FOSS. Some of these
issues are well-founded but many come about because there have been
many myths circulated about FOSS. This is brought about in part
by people who do not understand FOSS and the way it works and also in
part by the detractors of FOSS to sow the seeds of fears,
uncertainties and doubts (FUDs) into the minds of the users.

There is no accountability and ownership for FOSS

Myth: FOSS is
developed/maintained on a best effort basis by volunteers.
Therefore there is no single party responsible and fully accountable
for the software.

Fact: The mainstream FOSS
projects (software) are all run by a tightly knit developer
community. There are legally established non-profit foundations
or normal businesses supporting the software. For example, Apache
is supported through the Apache Software Foundation and Red Hat Linux
is supported and maintained by Red Hat Corporation. The former is
a well-established non-profit foundation while the latter is a
commercial business entity listed on NASDAQ.

Fact: It is true that a FOSS
project, when it starts off, is sometimes carried out by enthusiasts
and volunteers on a best effort basis only. However once it
becomes popular enough and is considered mainstream software in use all
over the world by many people, a responsible body will step forward (or
be created) to take charge of it.

There is no warranty for FOSS

Myth: FOSS is always licensed
“available as is” and without any warranty.

Fact: While this is usually
true, it does not mean that commercial close source is much
better. Warranty clause in the latter usually offers scant
protection only and often limited to 90 days upon receipt. Most
close-source software licenses come with disclaimers in the end-user
licensing agreement (EULA) to exempt the vendor from any liabilities
arising from the use and misuse of the software.

Fact: There are commercial
vendors which have a separate service offering warranties for the FOSS
software that they support. Examples of vendors which offer this
include Suse Linux ( a subsidiary of Novell Corporation) and IBM.

Fact: Some FOSS have dual
licensing, a FOSS license and a commercial license. The
commercial license offers warranty. A good example of this is the
MySQL database product.

There is no one to turn to for support of FOSS

Myth: Since FOSS software is
not owned by anyone there is no reliable support for it.

Fact: While the original
software author/owner may or may not offer support, many other sources
do. These include the local vendors that the user deals with, the
user communities worldwide and the huge Internet resources available
like mailing lists, forums, websites etc.

Fact: Commercial
proprietary software users still mainly rely on their local vendor for
support. So the key question to ask here if you are the type of
user who relies almost exclusively on your vendor for support is
whether the local vendor that you deal with can support the FOSS
software that you intend to use. In relation to this, the local
vendor will find it easier to resolve some technical problem with FOSS
software as it has, in addition to the software author, the Internet
resources to turn to and very often the problem had been encountered
before by others and a resolution available. The culture of FOSS
development and usage is such that there is a lot of experience and
information being shared by users and developers among the FOSS
communities worldwide over the Internet.

FOSS is not secure

Myth: As source code is
readily available FOSS is inherently not secure since the bad guys can
scrutinise the code and find vulnerabilities more easily

Fact: The availability of
source code has several security advantages. It facilitates the
scrutiny by many people to flush out weaknesses in the design and
code. Also, when a vulnerability is found, fixes and/or
workarounds can be made without waiting for the code authors if the
vulnerability is a critical one. The fixes made also can be
studied and scrutinised to ensure that they are made correctly.

Independent checks and audits can only be made with source code
availability.

Fact: Another advantage
of source code availability is that in the event that the platform on
which one uses the application has been obsoleted by the vendor, it is
still possible to continue using the application safely on the
obsoleted platform even if vulnerabilities have been discovered for the
application in question since one can download the updated source and
re-compile it for the obsoleted platform. For close-source
applications one has no choice but to upgrade to the newer supported
platforms.

Fact: Unavailability of
source code does not mean vulnerabilities cannot be discovered.
Modern debugging and software development tools can be used to examine,
disassemble and reverse-engineer the close-source executables to look
for bugs and vulnerabilities. The most glaring illustration of
this is the never-ending vulnerabilities being discovered for Microsoft
products like IIS, IE and Outlook.

It is easy to hide backdoors in FOSS

Myth: As FOSS software is
usually available from more than one source, it is easy for
someone to offer FOSS software with hidden backdoors for downloading
and distribution.

Fact: This is possible
and so one should not download software from unknown and untrusted
sites. One should also ensure that the software security checksum
corresponds with the published value from a recognised official
downloading site.

Fact: FOSS offers the
ability to examine the source and re-compile to ensure that there
are no backdoors. Also, if it is known that a FOSS
development/distribution site had been compromised, there is no
need to depend on the author/vendor alone to check the software.

Fact: Commercial
proprietary software have been known to ship infected with virus and
backdoors. Backdoors are also possible in close source and
they will be more difficult to detect as the source code is not readily
available. Experience has shown that a backdoor incorporated into
a mainstream FOSS project does not stay undetected for long while there
are examples of proprietary software having a backdoor in it for years
and only upon open-sourcing is the backdoor found. A good example
is the case of the database software Interbase which was found to have
a backdoor within six months of it being released under an
open-source license.

There is no copyright and licensing for
FOSS

Myth: As source code is
available freely, there is no copyright and licensing in FOSS.

Fact: Almost all the
popular and widely used FOSS software are copyrighted. The
ownership stays with the author(s) unless they have relinquished their
claims to it or transfer the copyright to another party.

Fact: There are over 30
Open Source Licenses recognised by the Open Source Initiative
(OSI). The Free Software Foundation (FSF) has successfully
pursued and enforced the General Public License (GPL) on
several commercial violators.

Copies of FOSS cannot be sold for money

Myth: FOSS software
cannot be charged for a profit.

Fact: Whether one is
allowed to charge for a FOSS software will depend on the license under
which it is distributed. The commonly accepted FOSS definition
does not specify that one cannot charge for FOSS. The �free� in
Free Software refers to �freedom� and not �no charge�!

Source code must be given to everyone for FOSS

Myth: If I release my
software under a FOSS license, I must make the source code easily
available to the whole world.

Fact: You are only
obligated to give the source code to the users of your software.
So if you are releasing the software for the general public to use,
then of course you have to make available the source code to
everyone. However, if the software is to be used only by a
private group of users , then you need to provide access to the source
code to these users only. However note that these users are
allowed to distribute your software and source code to others.

Software available on FOSS platforms must be released as FOSS too

Myth: Only FOSS software is
allowed to run on FOSS operating platforms and software developed on a
FOSS platform has to be released as FOSS too.

Fact: The software
available for use on FOSS platforms may or may not be FOSS
themselves. So while the majority of the software running on FOSS
platforms like Linux, FreeBSD etc. are FOSS, there is also available a
substantial number of close-source commercial software e.g DB2, Oracle,
Netware etc.

Fact: If one uses FOSS
software development tools and environment to develop a piece of
original software, one need not release it under a FOSS license if the
software is complete in itself, i.e. it can exist and run on its own
without invoking other parts of the system which are covered by a FOSS
license, e.g. libraries etc. If it does or if portions of the
developed software contain source code from a FOSS software, then the
specific terms of incorporation and usage of the software invoked has
to be looked at to ascertain whether the developed software needs to be
made FOSS too.

FOSS operating platforms are not user-friendly

Myth: FOSS platforms
suffer from their Unix-legacy in that the main user interface is
command-line oriented (CLI); so there is a need to remember archaic
commands.

Fact: This may be
possibly true in the past but all modern FOSS operating
platforms support GUI windowing systems and these are very
much the default interface. The user has a choice of using either
GUI or CLI to run most of the applications where applicable.

There are many versions of the same FOSS software

Myth: The ability to fork off a
FOSS software project will lead to many incompatible different versions
and the open nature of FOSS encourages forking.

Fact: Most FOSS have one
project only and forking happens only as a last resort, after all
attempts at reconciliation fail.

Fact: When forking does
take place, over some time, either the new project becomes dominant and
widely used or it dies off due to lack of support/usage or it
eventually gets folded back into the original project. It is thus
akin to a natural selection process favouring the majority of the
users. The ability to fork off a different project can be viewed
as a good thing as it ensures that ultimately the surviving project
will have the features that the majority of the users want.