The Open Source Definition

Fri, 2006-07-07 15:49 Ken Coar

Introduction
Open source doesn't just mean access to the source code. The
distribution terms of open-source software must comply with
the following criteria:

1. Free Redistribution(phn phi li)

The license shall not restrict (hn ch) any party from selling or
giving away the software as a component (thnh phn) of an
aggregate(tng th) software distribution containing programs
from several different sources. The license shall not require a
royalty or other fee for such sale.

2. Source Code
The program must include source code, and must allow
distribution in source code as well as compiled form. Where
some form of a product is not distributed with source code,
there must be a well-publicized (qung co) means of obtaining
the source code for no more than a reasonable reproduction
cost preferably, downloading via the Internet without charge.
The source code must be the preferred form in which a
programmer would modify the program. Deliberately (cn
nhc) obfuscated (rc ri) source code is not allowed.
Intermediate forms such as the output of a preprocessor or
translator are not allowed.

6. No Discrimination(s phn bit) Against Fields

of Endeavor(s c gng)
The license must not restrict anyone from making use of the
program in a specific field of endeavor. For example, it may
not restrict the program from being used in a business, or from
being used for genetic (ngun gc) research.

7. Distribution of License
The rights attached to the program must apply to all to whom
the program is redistributed without the need for execution (s
thi hnh)of an additional license by those parties.

8. License Must Not Be Specific to a Product

The rights attached to the program must not depend on the
program's being part of a particular software distribution. If the
program is extracted from that distribution and used or
distributed within the terms of the program's license, all parties
to whom the program is redistributed should have the same
rights as those that are granted in conjunction (cho php lin
kt) with the original software distribution.

9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the
license must not insist that all other programs distributed on the
same medium must be open-source software.

3. Derived Works

10. License Must Be Technology-Neutral(trung

lp)

The license must allow modifications and derived works, and

must allow them to be distributed under the same terms as the
license of the original software.

No provision (s chun b) of the license may be predicated on

any individual technology or style of interface.

4. Integrity(tnh nguyn vn) of The Author's

Source Code
The license may restrict source-code from being distributed in
modified form only if the license allows the distribution of
"patch files" with the source code for the purpose of modifying
the program at build time. The license must explicitly (r rng)
permit (giy php) distribution of software built from modified
source code. The license may require derived works to carry a
different name or version number from the original software.

5. No Discrimination Against Persons or Groups

The license must not discriminate against any person or group
of persons.

Open source vs commercial apps: the differences

that matter
By Goh Seow Hiong, Special to ZDNet Asia
Wednesday, October 06 2004 02:01 PM
The open-source movement has been one of the most dramatic
changes to impact (tc ng) the software industry in recent
memory.
Few technical subject matters today are as passionately debated
(cuc tranh lun gay gt) as that of the controversy surrounding
open-source and commercial software--two prominent (ni ln)
models of software licensing and development. Amidst ( gia)
their differences relating to cost benefits, there are, in fact, a
number of commonalities and similarities that are often
overlooked (xem xt) in this debate.

agreements, but is usually not distributed to the general public,

and may not be copied or modified except in a manner
provided for in such agreements.
It should be recognized that each of these models can translate
into a viable business strategy for companies in the software
industry. The models are not mutually exclusive, and
companies are increasingly finding ways to embrace both
approaches, and allowing both to co-exist.
For example, there have been instances where proprietary
operating system platforms that have benefited from the opensource development by adopting an open source approach for
the lower levels of the system (e.g. device drivers) while
keeping the higher levels proprietary (e.g. user interface).
This approach allows greater focus to be placed at development
of the higher level components, where innovation may bring
greater benefits to customers.

To help decision makers discern (nhn thc) the facts in this

debate, let's look at the key considerations in this area and how
appropriate software policy decisions should be made.

Conversely, there are software providers who have contributed

commercially developed code to the open source community to
allow open source solutions to operate on a broader range of
platforms. Increased competition and a larger number of viable
alternatives between products on the server and desktop
platforms have brought about a significant push for both open
source and commercial software solutions to become more
innovative, and for software providers to focus and improve
substantially on emerging issues like security and reliability.

Comparing the two models

For the purposes of our discussion below, we will refer to the
terms as follows:

Licensing Approaches
One main underlying difference between both models lies with
the approach towards licensing adopted by each model.

Open source refers to a software licensing model where the

source code of the software is typically made available
royalty-free to its users, under terms allowing
redistribution, modification and addition, though often with
certain restrictions.

It is necessary to understand these licensing approaches to fully

appreciate the fundamental starting points of the models and to
discern the validity and weight of any particular argument for
or against either software model.

Policy issues surrounding commercial and open-source

software have also gripped (kp cht) government bodies
around the world. In Asia Pacific, open source is often seen as
a viable solution, especially for developing nations.

Open-source programs are often, though not exclusively,

developed through a collaborative effort(s c gng ca
nhiu ngi) in which a number of persons, often with no
formal association with each other, contribute elements(yu
t) of the final software. Increasingly, software companies
are also contributing programs developed in-house to the
open source community.
Commercial software refers to the model where the software
developed by a commercial entity (s tn ti) is typically sold
or licensed to a customer in object or executable code, either
directly or through channels. The commercial entity often
provides support, training, updates and other similar services
needed by customers to use that software.
The source code of the software may be made available to
certain users of the software through special licensing or other

Commercial software providers typically adopt the traditional

software licensing approach where permission to use the
software is granted to a customer in return for a fee. The
customer is usually permitted to use, reproduce or adapt the
software according to the terms of the permitted activities
under the license.
While open source software is made available under a variety
of approaches in licensing, these approaches have certain
features in common. They rely on the copyright within the
software to form the licensing contract. They each grant rights
and permissions subject to conditions.
In general, these conditions restrict how the software may be
further changed or distributed, rather than imposing a
requirement that a fee be paid for it.
GPL and BSD
There are two principal open source licensing approaches--the

GNU General Public License (GPL) and the Berkeley Software

Distribution (BSD) License.

When making the comparisons, it is instructive to look from

the standpoints of cost, security and flexibility.

Under the GPL, all derivative works of the software must be

licensed and distributed on the same terms as the original
software. Source code subject to the GPL cannot be
disassociated with that license and permanently remains as
such.

A. Cost
The argument that open source software is cheaper than
commercial software should be considered in the context of the
lifetime costs of a product, which proponents of commercial
software would argue are at least comparable between both
models.

Under the BSD License, developers are allowed to integrate the

licensed software with the developers own source code to
create new products with few restrictions.
The BSD License, for example, allows programmers to use,
modify and redistribute source code and binaries of the original
software. But unlike the GPL approach, programs containing
code subject to the BSD License do not have to be distributed
under the BSD License. Derivative works can be distributed
either in an open source manner, or in a more traditional
commercial license.
Another characteristic of the GPL approach relates to
distribution. The GPL prohibits charging money for the
distribution of source code, other than to cover the
administrative cost of copying and shipping. However,
charging fees for system setup, system management, support,
maintenance and other related services is permitted.

In terms of purchase price, it is reasonable to assert that open

source solutions tend to be cheaper than commercial software.
However, it is also valid to consider the cost of software as a
total cost involving the entire lifecycle of the software, rather
than the one time purchase price.
Increasingly, new business models are being introduced to
attract customers with lower up-front costs, but with higher
recurring costs (e.g. cheap mobile phones in exchange for
recurring subscription packages). Accordingly, the cost of
software should not be assessed merely on the start up purchase
price, but also on the long term support and maintenance needs,
in addition to other less tangible issues like usability of the
product and productivity gains from the use of the products.

It is on this basis that commercial support for Linux is

available from some organizations operating under the open
source business model.

In addition, it is often necessary to consider the cost of

retraining users for an alternative product. Such retraining costs
may be quite significant when one takes into account the total
time spent by the users undergoing such retraining and the
initial lower productivity levels while the users familiarize
themselves with the alternative product.

Open source vs commercial apps: the differences

that matter II

While there are many studies and surveys in this area offering
different costs analysis models, technology decision makers
should ultimately weigh the full range of costs, including
lifetime costs and migration costs, when evaluating their own
choices in this area.

By Goh Seow Hiong, Special to ZDNet Asia

Monday, October 25 2004 05:07 PM
The ongoing debate on commercial software versus open
source has sometimes centered on whether one approach to the
software licensing and development model is inherently
superior to the other.
In truth, there is nothing inherent in the models that makes one
better than the other.
Both models each serve the specific needs and circumstances
of the environment where the software is to be deployed. And
such needs and circumstances ultimately determine what
factors are relevant and applicable, and whether certain
advantages and disadvantages of the open source or
commercial software model should be given more weight and
consideration in determining the approach for that
implementation and deployment.

B. Security
It has been argued that open source solutions, with their source
code available for public scrutiny, is inherently more secure
than commercial software solutions, whose source code is not
published.
On the other hand, it has also been argued that it is easier to
find and exploit flaws in software whose source code is
published. The debate in this area rages on.
The truth of the matter is that the security of any technological
product and implementation is not predetermined by the
method of development or distribution. Some commercial
products are less secure than their community-developed
counterparts, just as some open source products are less secure
than their commercial counterparts. While the design of
security features matters significantly, it is even more important
how well the software is deployed, configured and maintained,
including upgrading the products to fix flaws as they are
discovered.

These variables are contingent on the customer taking due

care--not the licensing or development model.
In considering whether making source code available for public
scrutiny makes the code more secure, one needs to understand
the genesis behind this argument. This line of thought is
consistent with the oft-cited axiom that "security by obscurity
is no security". However, the fundamental basis of that axiom
is not that obscurity (or the absence of public knowledge) of
the security mechanism is inherently insecure, but that a
security mechanism cannot be considered secure on the basis
that no one knows how it works.
Clearly, a security mechanism that relies on a secret
mechanism (as opposed to, say, a secret key) that no one knows
will quickly fall apart once the secret mechanism is made
known. This is a separate issue from keeping a security
mechanism confidential. Still, its security does not exist by
virtue of its mechanism being kept a secret.
Security may be derived from the use of an appropriate secret
key that may be changed from time to time. A concealed
security mechanism may potentially be more secure, as it is
necessary to discover the security mechanism as well as the
secret key before the mechanism can be broken or defeated.
In the open source community, where voluminous quantities of
source code are available, it is not realistic to expect that every
single line of the code has been scrutinized by a wide range of
security experts. New packages and add-on software are
developed and distributed regularly, but they may not have
undergone the same level of scrutiny as, for example, that of
the core kernel of Linux. Users who obtain such packages are
likely to compile, install and use the software even before
taking a look at the source code, even though it may have been
provided with the software. Only a very small minority of the
community will indeed scrutinize the source code of every
program before using it. Given such a scenario, it appears
premature to declare that open source is superior in security.
The concern over the lack of access to source code is
increasingly also being addressed by commercial software
vendors who make available such access to source code for
specific purposes. For instance, a number of Asian
Governments and security agencies have had access to the
source code of commercial software products, and have
undertaken security review of such products. This access
provides the Government with the opportunity to rigorously
review the source code of the product, as they would also do so
with the source code of an open source solution. With time,
there are also increasing instances of the source code of other
commercial software products being released publicly. The
availability of source code for the purposes of undertaking a
security review is hence no longer a compelling basis to
prejudge commercial software and open source solutions.
Another argument in this area of security focuses on the
assertion that there have been many more reported cases of
security flaws in commercial software solutions compared to

open source solutions. Here, it should be borne in mind that the

problems may be more prevalent and widespread as a result of
the popularity of a platform or software, and not due to its
design or the method of software development. The platform
that is more commonly in use will be the platform that security
attacks are more likely to be launched, as hackers arguably
have a greater incentive to hit a larger target than a smaller one.
Security flaws are a result of a combination of factors,
including the software design and implementation as well as
user behavior and usage, coupled with the skill and expertise of
the user in installing, deploying and maintaining the software.
Anecdotal experiences relating to the number of attacks borne
by commercial platforms are not necessarily testimonies to the
notion that open source solutions are less vulnerable or that
commercial software solutions are more vulnerable.
Taken in totality, it is not at all clear that one can draw any
reliable conclusions about whether a product is more or less
secure on the basis of the software development model on
which the product is built or its licensing model. The security
of any software product and implementation is not predetermined by the method of development or distribution, but
by the proper design of security features, and more importantly
by the correct deployment, configuration and maintenance of
the software by the customer.
Bottomline? Each product and implementation should be
assessed on its own merits and strengths.