UNIT – 2

OPEN SOURCE HISTORY

The open source movement is based on a radical retake on copyright law to create
high quality software whose use and development are guaranteed to the public. The
movement has spawned open source software (OSS) communities where developers and
users meet to create software that meets their needs.
Free software (later renamed “open source software”) appeared even before people
started thinking in terms of proprietary software, at a time when software development was
ruled by open source principles.
In the 1960s and 1970s, software programming was mainly performed in both
academic and corporate laboratories by scientists and engineers who freely gave, exchanged
and modified software.
In the early 80s, as software programming increasingly turned proprietary, Richard
Stallman founded the Free Software Foundation (FSF) to define and 4 diffuse legal
mechanisms and conceptual principles of what he called “free software”.
By writing the GNU Manifesto (Stallman, 1985), he communicated his ideological
view of the nature of intellectual property rights as regards software, and started attracting
convinced developers to join him in his GNU Project (GNU stands for “GNU’s not UNIX”).
In 1989, the FSF released the GNU General Public License (GPL) version 1 (the
updated version 2 was released in 1991) which legalizes copyleft mechanisms and grants
end-user’s freedoms in software copies and derivative works.
Turning copyright around “Copyleft” as expressed by the GPL has had a critical
effect on shaping the very existence of open source software communities. Open source
software uses copyright law to preserve certain freedoms (hence the name, “free software”)
regarding the creation, modification, and sharing of software.
Specifically, all open source software grants users the following key rights:
1. The right to full access to the source code. When a computer programmer sees how a
piece of software actually works, as specified in the source code, they can fully
understand the inner workings and can intelligently modify the software as they deem
appropriate.

2. The right for anyone to run the program for any purpose without restriction. There are
no restrictions against commercial, military, foreign, or any other use, and
discrimination against users for any reason is expressly forbidden.

3. The right to modify the source code. This includes absorbing the software, in whole or
in part, into other pieces of software created by other developers.

4. The right to distribute both the original software and the modified software. A key
difference between “free software” and “freeware” is that while freeware generally
permits 5 and encourages free distribution of the software, it does not permit sale of
the distributed software beyond reasonable distribution costs; free software, in
contrast, permits resale at any price.
 5. The right to know about their open source rights. The open source license must be
prominently displayed and distributed to users, so that they are aware of their rights
(including access to the source code). Practically, since users are aware that they can
obtain the source code for free, the sale price of OSS tends to be zero, or quite low.

While the preceding five rights constitute open source software, the FSF’s
GPL, the first legal document to license open source software, goes further. The GPL
grants users and developers these rights with the intention that developers would
modify the software and share it with others with similar liberality, and in accordance
with Stallman’s personal beliefs on the ethical rightness of sharing software, the GPL
assures sharing by further incorporating the concept of “copyleft”. Copyleft is an
obligation that the distributor of OSS agrees to in order to receive the privileges
mentioned above:

6. The obligation to distribute derivatives under copyleft. Any software modified under
the GPL can be redistributed for sale, but it must be licensed under a copyleft license;
that is, modified derivative works must also be made available under an open source
license. While it does not have to be licensed under the GPL itself, the chosen
distribution license may not restrict any of the five rights listed above.
These copyleft terms are critical to the very existence of OSS communities. When
Richard Stallman posted his manifesto and invited software developers to join him in his
crusade for free software, there was no lack of sympathetic and willing hackers who wanted a
return to the days of free sharing.
With its copyleft mechanism, the GPL guaranteed that any person or corporation who
wanted to benefit from the liberal efforts of computer programmers would be legally bound
to share their work in the same spirit of camaraderie.

OPEN SOURCE INITIATIVES

In 1991, Linus Torvalds, a 21-year-old Finnish programmer, started the famous Linux
Project, released under the GPL, which implements a Unix-like operating system on Intel-
based microcomputers.
The project has grown rapidly to produce a powerful, fast, efficient, stable, reliable,
and scalable operating system. The number of Linux users and developers has expanded
rapidly. Not including free downloads and installations of Linux, “25% of servers and 2.8%
of desktop computers ran paid distributions of Linux as of 2002.
The Linux market is rapidly growing and is projected to exceed $35.7 billion by
2008”. Moreover, version 2.2.10 of the kernel lists 190 names, though the total number of
contributors was estimated at around 1,200.
A major paradigm shift occurred in 1998, when Bruce Perens and Eric Raymond
expressed their suspicion that firms may not be convinced by GPL due to Stallman’s term,
“free” software, “which might understandably have an ominous ring to the ears of business
people”.
The “open source” software movement was created based on the integrating of all the
previous licensing that had been prior designed. As a result, a major chasm appeared between
Stallman’s free software view, which was more ideological and philosophical, and
Perens/Raymond’s open source view, whose purpose was more business-oriented.
 Several major OSS projects have marked people’s mind in such software revolution.
The Apache web-server project started in early 1995 and has become the most popular Web
server software, controlling over 60 percent of the market, much more than Microsoft and
Netscape both combined.
Inspired by Eric Raymond’s paper “The Cathedral and the Bazaar”, Netscape, one of
the main actors in the Internet browser industry, decided to release its source code by creating
Mozilla, its first open source version of its former Communicator. In November 2004, the
Mozilla Foundation announced the worldwide availability of the Mozilla Firefox 1.0 web
browser.
Today, all major hardware and software vendors have at least forayed into the open
source approach. For example, Apple Computer surprisingly followed this model in 2000
when they released the kernel of their Unix-based Mac OS X operating system to the open
source community as Darwin 1.0.
In 2005, IBM announced their plan to spend $100 million over the next three years to
build support for Linux into desktop applications for its Workplace software. Meanwhile,
IBM has planned to spread Linux worldwide.
In 2004, IBM concentrated on implementing Linux in Brazil, Russia, India and China.
Since 2005, the company has planned to increase its efforts in those countries but will also
begin extend its programs in Eastern Europe.

PRINCIPLES AND METHODOLOGY OF THE OPEN SOURCE

Principles of the open source
Transparency: Whether we're developing software or solving a business problem, we all
have access to the information and materials necessary for doing our best work. And when
these materials are accessible, we can build upon each other's ideas and discoveries. We can
make more effective decisions and understand how decisions affect us.
Collaboration: When we're free to participate, we can enhance each other's work in
unanticipated ways. When we can modify what others have shared, we unlock new
possibilities. By initiating new projects together, we can solve problems that no one can solve
alone. And when we implement open standards, we enable others to contribute in the future.
Release early and often: Rapid prototypes can lead to rapid discoveries. An iterative
approach leads to better solutions faster. When we're free to experiment, we can look at
problems in new ways and seek answers in new places. We can learn by doing.
Inclusive meritocracy: good ideas can come from anywhere, and the best ideas should win.
Only by including diverse perspectives in our conversations, from that we have identified the
best ideas, and decision-makers continually seek those perspectives.
Community: Communities form when different people unite around a common purpose.
Shared values guide decision making, and community goals supersede individual interests
and agendas.
 Methodology of the open source
Open-source software development creates many interesting legal and business issues
methodologically, open source is the best-known element its use of extensive peer review and
decentralized contributions to a code base.
example: Create a kernel of code by ourself; make it available on the Internet for
review; screen changes to the code base; and, when the code base becomes too big for one
person to manage, delegate responsibility for major components to trusted lieutenants.
 Bug Me Now or Bug Me Later
In Open Sources: According to Vixie, open-source projects typically have sketchy
marketing requirements, no system-level design, little detailed design, virtually no design
documentation, and no system-level testing.
The software industry has collected reams of data on this phenomenon: generally, we
can expect to spend from 10 to 100 times as much to correct an upstream defect downstream
as we would spend to fix the same defect upstream.
As Vixie points out, open source’s methodology focuses on fixing all bugs at the
source code level—in other words, downstream. Error by error, without upstream reviews,
the open-source project will require more total effort to fix each design error downstream
than the closed-source project will require to fix it upstream.
The implications of open source’s code-and-fix approach might be more significant
than they at first appear. By the time Linux came around, requirements and architecture
defects had already been flushed out during the development of many previous generations of
Unix.
Open-source advocates claim that giving users the source code reduces the time
needed for downstream defect correction—the person who first experiences the problem can
also debug it.—But they have not published any data to support their assertion that this
approach reduces overall defect correction costs.
By largely ignoring upstream defect removal and emphasizing downstream defect
correction, open source’s methodology is a step backwards—back to Code and Fix instead of
forward to more efficient, early defect detection and correction.
 Not All Eyeballs Are Shallow
Open-source advocates emphasize the value of extensive peer review. Indeed, peer
reviews have established themselves as one of the most useful practices in software
engineering.
About 1,200 programmers have contributed bug fixes and other code to Linux. What
this means in practice is that if a bug is reported in Linux, a couple dozen programmers might
begin looking for it, and many bugs are corrected within hours. From this, open-source
advocates conclude that large numbers of reviewers lead to “efficient” development.
This answer confuses “fast” and “effective” with “efficient.” To one of those people,
the bug will turn out to be shallow. Fast is having two dozen people look for a bug for one
day for a total cost of 24 person-days. Efficient is having one person look for a bug eight
hours a week for a month for a total cost of four person-days.
  Economic Shell Game
Considering open source’s focus on downstream defect correction with significantly
redundant peer reviews, for now the approach looks more like a shell game than a better
mousetrap. It is appealing at first glance because so many people contribute effort that is free
or unaccounted for.
The results of this effort are much more visible than the effort itself. But when you
add up the total effort contributed—both seen and unseen—open source’s use of labour looks
awfully inefficient.
Open source is most applicable when we need to trade efficiency for speed and
efficacy. This makes it applicable to mass-distribution products like operating systems where
development cost hardly matters and reliability is paramount.
But it also suggests that open source will be less applicable for vertical-market
applications where the reliability requirements are lower, profit margins are slim enough that
development cost does matter, and it’s impossible to find 1,200 people to volunteer their
services in support of our application.
 One-Hit Wonder or Formidable Force?
The open-source movement has not yet put its methodology under the opensource
review process. The methodology is currently so loosely defined that it can hardly even be
called a “methodology.” At this time, the strength of the open-source approach arises largely
from its massive code-level peer review, and little else.
For open source to establish itself as a generalizable approach that applies to more
than a handful of projects and that rises to the level of the most effective closed-source
projects, it needs to fix four major problems:
1. Create a central clearinghouse for the open-source methodology so it can be fully
captured and evolved.
2. Kick its addiction to Code and Fix.
3. Focus on eliminating upstream defects earlier.
4. Collect and publish data to support its claims about the effectiveness of the open-
source development approach.
None of these weaknesses in open source’s current development practices are fatal in
principle, but if the methodology can’t be evolved beyond its current kludgy practices,
history will record open source’s development approach as a one hit wonder.
If open source can focus the considerable energy at its disposal into defining and
using more efficient development practices, it will be a formidable force indeed.
PHILOSOPHY: SOFTWARE FREEDOM
A program is free software if the program's users have the four essential freedoms

 The freedom to run the program as our wish, for any purpose (freedom 0).
 The freedom to study how the program works, and change it. So, it does our
computing as our wish (freedom 1). Access to the source code is a precondition for
this.
 The freedom to redistribute copies. So, we can help others (freedom 2).
  The freedom to distribute copies of our modified versions to others (freedom 3). By
doing this we can give the whole community a chance to benefit from our changes.
Access to the source code is a precondition for this.

 The freedom to run the program as our wish

The freedom to run the program means the freedom for any kind of person or
organization to use it on any kind of computer system, for any kind of overall job and
purpose, without being required to communicate about it with the developer or any other
specific entity.
In this freedom, it is the user's purpose that matters, not the developer's purpose; A
user is free to run the program for our purposes, and if we distribute it to someone else, she is
then free to run it for her purposes, but we are not entitled to impose our purposes on her.
The freedom to run the program as our wish means that we are not forbidden or
stopped from making it run. This has nothing to do with what functionality the program has,
whether it is technically capable of functioning in any given environment, or whether it is
useful for any particular computing activity.
For example, if the code arbitrarily rejects certain meaningful inputs—or even fails
unconditionally—that may make the program less useful, perhaps even totally useless, but it
does not deny users the freedom to run the program, so it does not conflict with freedom 0.
If the program is free, the users can overcome the loss of usefulness, because
freedoms 1 and 3 permit users and communities to make and distribute modified versions
without the arbitrary nuisance code.
 The freedom to study the source code and make changes
In order for freedoms 1 and 3 (the freedom to make changes and the freedom to
publish the changed versions) to be meaningful, we need to have access to the source code of
the program. Therefore, accessibility of source code is a necessary condition for free
software. Obfuscated “source code” is not real source code and does not count as source
code.
Freedom 1 includes the freedom to use our changed version in place of the original. If
the program is delivered in a product designed to run someone else's modified versions but
refuse to run ours — a practice known as “tivoization” or “lockdown”, or as “secure boot” —
freedom 1 becomes an empty pretence rather than a practical reality. These binaries are not
free software even if the source code they are compiled from is free.
One important way to modify a program is by merging in available free subroutines
and modules. If the program's license says that we cannot merge in a suitably licensed
existing module — for instance, if it requires, we to be the copyright holder of any code we
add — then the license is too restrictive to qualify as free.
 Whether a change constitutes an improvement is a subjective matter. If we have rights
to modify a program is limited, in substance, to changes
that someone else considers an improvement, that program is not free.
 The freedom to redistribute if we wish: basic requirements
Freedom to distribute (freedoms 2 and 3) means we are free to redistribute copies,
either with or without modifications, either gratis or charging a fee for distribution, to
 anyone anywhere. Being free to do these things means (among other things) that we
do not have to ask or pay for permission to do so.
We should also have the freedom to make modifications and use them privately in our
own work or play, without even mentioning that they exist. If we do publish our changes, we
should not be required to notify anyone in particular, or in any particular way.
Freedom 3 includes the freedom to release our modified versions as free software. A
free license may also permit other ways of releasing them; in other words, it does not have to
be a copyleft license. However, a license that requires modified versions to be non-free does
not qualify as a free license.
The freedom to redistribute copies must include binary or executable forms of the
program, as well as source code, for both modified and unmodified versions.
OPEN SOURCE DEVELOPMENT MODEL LICENSES AND PATENTS
What is a Licence?
The simplest explanation is that open source licenses are legal and binding contracts
between the author and the user of a software component, declaring that the software can be
used in commercial applications under specified conditions. The license is what, it turns as a
code into an open source component. Without an open source license, the software
component is unusable by others, even if it has been publicly posted on GitHub.
Each open source license states what users are permitted do with the software
components, their obligations, and what they cannot do as per the terms and conditions.
Varying in complexity and requirements, it is up to organizations to choose which licenses
are most compatible with their policies to ensure that they remain compliant.
These licenses are intended to permit, and indeed, to encourage the contributions of
others to the project. This project was Richard Stallman’s plan to develop a complete
operating system modelled after the Unix operating system but written entirely in free code.
IMPORTANT FOSS LICENSES
 GNU General Public License (GPL)
GNU General Public License is the most popular open source license around. Richard
Stallman created the GPL to protect the GNU software from becoming proprietary, and it is a
specific implementation of his "copyleft" concept. GPL is a copyleft license. This means that
any software that is written based on any GPL component must be released as open source.
The result is that any software that uses any GPL open source component (regardless
of its percentage in the entire code) is required to release its full source code and all of the
rights to modify and distribute the entire code.
GPL is a copyleft license. This means that any software that is written based on any
GPL component must be released as open source. The result is that any software that uses
any GPL open source component required to release its full source code and all of the rights
to modify and distribute the entire code.
 The Apache License
The Apache License is an open source software license released by the Apache
Software Foundation (ASF). It’s a popular and widely deployed license packed by a strong
community. The Apache License allows us to freely use, modify, and distribute any Apache
licensed product. However, while doing so, we’re required to follow the terms of the Apache
License.
The Apache Group (later named the Apache Software Foundation) released the first
version of its license in 1995, but it’s rare that we’ll come across components that still carry
this license.
In 2000, when Berkeley accepted the argument put to it by the Free Software
Foundation and retired their advertising clause from the BSD license and formed the
modified BSD license, Apache did likewise and created the Apache License version 1.1.
Removing the advertising clause meant that the advertising materials of the derivative
works of any Apache licensed product were no longer required to include the Apache License
attribution. It became ok to include the attribution in the documentation alone.
In 2004, the ASF decided to depart from the BSD model a little more radically and
produced the Apache License version 2.0 by granting patents rights and defining solid
definitions of the concepts.
 Berkeley Software Distribution (BSD)
BSD Licenses or the original BSD License and its two variants - the Modified BSD
License (3-clause), and the Simplified BSD License/FreeBSD License (2-clause) are a
family of permissive free software licenses.
The BSD License lets we freely modify and distribute our software’s code in the
source or binary format as long as we retain a copy of the copyright notice, list of conditions,
and the disclaimer.
The original BSD License or the 4-clause BSD License also contains an advertising
clause and a non-endorsement clause.
The modified BSD License or the 3-clause BSD License was formed by removing the
advertising clause from the original BSD License.
Further, the FreeBSD version or the 2-clause BSD License was formed by removing
the non-endorsement clause from the modified BSD License or the 3- clause BSD License.
 Common Development and Distribution License (CDDL)
CDDL is an open source license published by Sun Microsystems to replace the Sun
Public License (SPL).
The CDDL license is considered by Sun Microsystem (now Oracle) to be the SPL
version 2. It is inspired by the Mozilla Public License (MPL).
Sun Microsystem used to release its free software / open source projects under its Sun
Public License (SPL) before it turned to rely upon the CDDL in 2004.
CDDL is often dubbed as a cleaned up version of the MPL and is made to facilitate
reusability.
We’re free to reproduce and distribute any original or derivative works of any
software licensed under the CDDL. However, we must not remove or make any changes to
any copyright, patent or trademark notices contained in the software. We must also retain any
notices of licensing or any descriptive text giving attribution to any contributor or the initial
developer.
When we distribute our software in an executable form, we are required to make the
source code available under the CDDL. The executable form may be released under the
CDDL or any CDDL compatible licenses.
In addition, we must include a copy of the CDDL with any source code that we
distribute. For each modification that we make, we must identify ourself as the modifier by
including a notice in our modified files.
 Eclipse Public License (EPL)
The Eclipse Public License (EPL) is an open source license developed by the Eclipse
Foundation. It’s derived from the Common Public License (CPL). The Eclipse codebase now
available under the EPL was formerly licensed under the CPL.
The EPL license is a copyleft license. If we modify an EPL component and distribute
it in the source code form as part of our program, we’re required to disclose the modified
code under the EPL. If we distribute such a program in its object code form, we’re required to
state that the source code can be made available to the recipient upon request. We’re also
required to share the method for requesting the source code.
The Eclipse Foundation makes clear that, in their opinion, ‘merely interfacing or
interoperating’ with an Eclipse plugin does not make our code a derivative work of the
plugin.
If we redistribute a program with an EPL component, we are obligated to include the
full license text and the copyrights.
The EPL protects the author from possible lawsuits or damages caused if a company
used his/her component in a commercial product. It also offers a patent grant.
 MIT License
MIT is one of the most permissive free software licenses. Basically, we can do
whatever we want with software licensed under the MIT license - only if we add a copy of
the original MIT license and copyright notice to it. Its simplicity is the reason behind its high
adoption rate among developers.
COPYRIGHTS AND COPYLEFTS
Copyright ©
Copyright is a bundle of rights granted to a creator providing him with exclusive
rights over his original artistic and literary creation. It is not necessary that a copyright be
registered, it is attached automatically to any original artistic work.
When the idea of a creator is converted to a material form, the same immediately gets
protected under the copyright. For a work to be copyrighted, it is necessary that the work is
original work of literature, drama, music, or any other art having artistic value.
While copyright protects the material form of an idea it does not protect the idea in
itself. It is essential and of significant importance, that permission is sought and the same is
granted by the copyright owner before it is republished or reproduced.
 The bundle of rights granted to the copyright owner includes the rights to reproduce,
copy, publish, communicate, and translate the copyrighted work. Such a right is a natural
right granted to the owner of the artistic work immediately on the making of the same.

Copyleft
Most of the creative works, including software programs and codes, comes within the
domain of copyright protection and therefore can be copyrighted.
However, it is to be noted that software and programming is an area where already
existing programs many-a-times are used as a base to build new software or program. Many
software owners tend to grant a license to its users a license allowing them to modify and
alter their work. Such permission and license can be referred to as Copyleft.
Copyleft can be said to be a specific kind of a license that allows free use of
copyrighted material but under certain terms and conditions, granted by the owner of the
copyright himself. For instance, software having a copylefted license can be modified, used,
distributed, or reproduced provided the source code kept open and available to the public.
A copylefted software must be transferred with a similar copyleft license to all its
successive users and the license also shall mandate any modification to the software shall be
copylefted in a similar manner.
In simpler words, copyleft is a license that provides original work to a third person
giving him certain rights like that of copying and modifying and any new work carved out
based on such original work shall have a copyleft license in a similar manner.
The main objective of a copyleft license is to provide people with opportunities to use
and modify an original work, and later grant a similar set of rights to all other interested
people.
Thus, any person who receives a copylefted work and then modifies the same, he
cannot restrict the rights to himself alone over the modified work.
PATENTS ECONOMICS OF FOSS
Unlike the holder of an Open Source license, the owner of a patent has exclusive
rights over the patented software. No one else can make, use, modify, or sell patented
software, and the source code is not available to the public.
Patent rights give the holder control over who uses software and for what purpose.
Though software developers can protect their work using both copyrights and patents,
copyrights only protect the code itself. Patents, however, protect the program's functionality.
Patents are better than copyrights for software developers because they protect the
program regardless of the code and language used. In comparison, copyrights aren't very
practical for developers. If we want to release Open Source software while retaining some
rights, a copyright only gives we power over someone who steals our work verbatim.
The original idea of a patent was to give the innovator who develops the idea a
monopoly of time in which she/he can benefit by commercial exploitation of the patent,
protect by legal means from other wishing to copy the idea. But long ago, this has become
buried in legal, cultural, administrative and practical difficulties – and this is making waves.
 We have been patents being used (as with copyright) as a means of proxy business-
competition – with a recent Wired article exposing the battle lines of patent-warfare in the
smart phone market as the big player jostle for position – so Apple sues HTC (used in many
Android phones), Nokia sues Apple, Kodak sues Apple, Research in Motion (makers of the
BlackBerry) & Samsung while Palm and Apple argue over patents.
The intention is to promote the rapid adoption and adaptation of ideas, benefit the
inventors and reward the whole process of research and development. However, over the past
two decades, changes in the way patents are attributed and patent holders’ increasingly
aggressive tactics have created a situation that some claim is choking, rather than promoting,
innovation. What makes the problem intractable is that today it is impossible to design a
high-end tech product that does not include others’ patents.
Software patents do not appear to show a strong effect on FOSS developer motivation
in general. This is true for both camps in the software patent debate: the presence of software
patents has no positive effects on monetary and skills-related motivation, as argued by
proponents; it also does not show negative effects on joy and self-expression-related
motivation, as argued by opponents. In contrast and counter-intuitively, joy-related
motivation seems to be positively influenced by the presence of software patents.
ZERO MARGINAL COST
At the core of the financial aspects of Free and Open Source is the zero negligible
expense of merchandise in an environment that is digital. Right now, the rise of Free and
Open Source speaks to an affirmation of old-style microeconomic value hypothesis - that a
marginal cost in an ideal market approximates the minimal expense.
From this point of view, Free and Open Source can be comprehended as a pioneer in
arriving at what can be comprehended as a developmentally steady powerful Nash balance in
a genuinely free market.
Marginal cost is the term utilized in the study of financial aspects and business to
allude to the increment in the actual development cost coming about because of delivering
one extra unit of the product.
While Free and Open Source is allowed to the end client, there is an expense related
to building up the product. These expenses might be littler than creating exclusive
programming since building up the task under Free and Open Source permit implies that:
Various online interfaces like Source Forge would offer web facilitating, content store,
mailing records and other basic highlights for nothing.
The expense of promoting a Free and Open Source venture (like introducing it in the
related gatherings) is typically lower.
All things considered; improvement of any product initially requires the designer
time. Without a doubt, extremely famous activities may hope to get an excellent code
commitment for nothing.
INCOME-GENERATION OPPORTUNITIES
While contributing time and exertion in creating, improving and documenting Free
and Open Source doesn't give any immediate salary, the improvement of skill in Free and
Open Source gives an expansive scope of revenue generation opportunities - from producing
in-house investment funds from upgrades to Free and Open Source to counselling openings in
installing, preparing, customizing and the arrangement of Technical Support for Free and
Open Source establishments.
Yochai Benkler furnishes a fantastic investigation - with IBM's strategy as a key
model - of ways that salary and riches are being created through open source and open
substance techniques.
With IT budgets increasingly strained, more and more companies are looking to open
source software to help lower costs. And while many people associate open source with free
software, the movement provides resellers and System Integrators (SIs) with significant
services revenue, analysts say.
As the Open Source India panel's theme, one natural aspect for discussion involved
opportunities for angel investors, business accelerators, venture capitalists, and others to
benefit financially from funding commercial FOSS companies or investing in publicly traded
companies with a significant role in FOSS.

PROBLEMS WITH TRADITIONAL COMMERCIAL SOFTWARE

First, it ought to be noticed that the business software industry is one of the biggest
and most significant ventures on the planet. The ascent of the Open Source development
doesn't spell the finish of the business software industry.
Numerous individuals contend that business software can be strengthened by the
utilization of open-source strategies. Business software is intended to give an item worth
paying to and its majority is. Regardless of its sticker price, business software is frequently in
demand.
Business products will be refreshed much of the time to mirror the fluctuating
requests of the market and client needs. These necessities can prompt software rehearses that
rework and change the product too as often as possible, or disperse beta forms as business
attempts bringing about high paces of bugs in early forms.
Some business programs are over structured and written in messy code prompting
enlarged, slow, running projects. Open Source by differentiating is driven by the necessities
of the end clients. Along these lines, their code is regularly of a predominant bore than that of
software engineers in the business condition. There is likewise generally an extremely broad
level of input as the software engineers test their products with a wide system of individuals.
At the point when source code is accessible, it tends to be checked against different
"secondary passages" and other security openings that might be deliberately or accidentally
left in the closed source programming.
In the past, such gaps have been found in different exclusive items, including
software, utilized by the legislature. Having source code additionally implies that the product
can be effectively ported to run under various processors, gadget or OS.
Another issue with customary business software is its closed nature. There is
generally no or restricted opportunity to alter the copyrighted item.
Additionally, organizations frequently power clients to follow update ways that they
may not wish to follow. Open-source Software empowers the person to tweak the product to
his end needs in all opportunities.
 Another vigorously censured part of business software is that clients are regularly
secured to an item because to continue utilizing information documents we are frequently
compelled to keep on utilizing a similar program.
If we wish to impart documents to clients that have overhauled, we frequently need to
update ourself or be discounted as unessential.
Since open-source programming permits contending projects to share various
information record types, there is no motivation to be caught into any one program.
If a more current adaptation has another record group, at that point there regularly are
converters that permit clients of more established variants to keep up their information
documents forward thinking.
INTERNATIONALIZATION
Internationalized software must enable easy porting to other locales. A locale defines
language and specific cultural conventions.
In the private international law rules for transfer and license contracts has shown that
it is hardly possible to anticipate the applicable law for Copyright Assignment (CAs) or
Copyright License Agreement (CLAs) when it comes to legal disputes.
The first source of uncertainty is the lack of internationally accepted principles of
private international law. European, US and Japanese courts apply different conflict-of-law
rules for the different legal issues raised by CAs/CLAs.
A second source of ambiguity is the lack of precise conflict rules in legislation or case
law within the analysed jurisdictions with regard to transfer or license contracts. This makes
it hard to predict which law will finally be applicable to the legal questions at stake, even if
one could anticipate whether a European, US or Japanese court will be called to hear the case.
A third source of legal problems relates to the boundaries of party autonomy in
international copyright law. For some of the most crucial aspects of CAs/CLAs, e.g. the
question of whether copyright or” joint authorship” in a work can be assigned, the
territoriality principle precludes any choice of law. Thus, the parties’ latitude to reduce the
complexity of their relationship by a contractual choice is restricted.