Open Source Software:

Background, Licensing and Practical
Implications

Bryan M. Kreft

May 10, 2000

Prof. Friedman

Legal Issues of the 21st
Century

Santa Clara UniversitySchool of Law

Introduction

As of late, the global interest in the United
States Dow Jones Industrial Average and Nasdaq stock exchanges has
increased exponentially. One would think that someone world-famous
was getting married. The most recent volatility of the exchanges is
due in part to the technology heavy Nasdaq. With the majority of
Nasdaq companies hailing from Northern California, the Silicon Valley
is quickly being considered as the worldwide technology leader. New
technology seemingly springs up like weeds in your neighbor’s
backyard. On this spring day in particular, tech stocks have dropped
precipitously and the markets are reeling from the results of the
antitrust lawsuit against Microsoft. In addition, Nasdaq investors
appear to be tiring of the abnormally high market capitalization for
companies that do not plan on reaching profitability anytime in the
next five years.

One category of company being hit harder than most
are the Linux based companies. VA Linux, Red Hat, and Caldera are all
suffering from buyer hesitation. Will the Open Source business models
proposed by these companies propel them to greatness? Or will Open
Source Software be the next passing fad. This paper will analyze some
of the broadest legal issues raised by one of the Valley’s high
growth technologies. The idea of Open Source Software may not be new,
but the legal issues raised are on the cutting edge of legal theory.
To this date, not a single open source license has been tested within
a court of law. Outcomes of pressing legal questions are merely
fanciful speculations on the part of lawyers all around the
U.S..

Background

What is open source software? To answer this, we
must start at the beginning. Computer operating systems,
applications, bug fixes and patches are all written much like any
novel. They are written line by line, and in a certain language. In
the case of software, they are written in a computer programming
language, and are in command line form. The instructions written are
called “source code.” Source code is the human readable
code that makes up computer software. Generally, this human readable
code is compiled to become object code, or machine-readable code.
Object code is not readily changeable by humans as it is in a
computer form that we do not understand, ones and zeros. It is the
object code version of software that proprietary software vendors
distribute to make money.

For a number of reasons, the software coding
community believes proprietary programs to be inadequate. They
believe (and perhaps rightly so) that the best way to make good
software is through a process of peer evaluation and review, however,
proprietary software does not go through this process. The peer
evaluation theory relies on the understanding that the more eyes and
input you have, the better, more accurate, and more complete your
software will be. With this notion in tow, we may look back to the
earliest days of the computer, and a community of code sharing
individuals.

Richard Stallman, considered by some to be the “free
software guru,” has detailed some of the history of the “Free
Software” movement. He initially became part of a software
sharing community at MIT in the early 70’s.[1]
It was within the early 80’s that this sharing community
collapsed. The collapse was a result of a number of factors, most
notably the hiring away of almost all of the engineers to a company
called Symbolics.[2]
It was at this point that competition among computer companies began
to take off. Software was closed, turned into object code, and sold
as proprietary. Not sitting well with Stallman, someone who had come
from an extremely open setting, he began to search for alternative
ways to keep the software sharing community alive. “The answer
was clear: what was needed was an operating system. That is the
crucial software for starting to use a computer . . . With a free
operating system, we could again have a community of cooperating
hackers – and invite anyone to join.”[3]

This was the beginning of the Free Software
movement that parallels today’s Open Source movement. However,
there is a stark moral difference between the two movements. As
Stallman explains, “The term ‘free software’ is
sometimes misunderstood –it has nothing to do with price. It is
about freedom.”[4]
The freedom he refers to is the freedom to run a program, make any
necessary modifications, and redistribute the program. In order to
ensure this freedom remains in place, Stallman et al. decided to
develop a free operating system. Choosing to make the OS compatible
with Unix, so that it would be portable, “the name GNU was
chosen following a hacker tradition, as a recursive acronym for ‘GNU’s
Not Unix.’”[5]

In 1984 Stallman began working on GNU software
programs. In order to remain free, Stallman “needed to use
distribution terms that would prevent GNU software from being turned
into proprietary software.”[6]
The method of distribution developed was deemed “copyleft.”
“Copyleft uses copyright law, but flips it over to serve the
opposite of its usual purpose: instead of a means of privatizing
software, it becomes a means of keeping software free.”[7]
The idea is that copyleft licenses do not give people permission to
add their own restrictions. In this, they keep the software free for
everyone. This is generally handled by licensing the program under a
license that has come to be known as the GPL. The GNU General Public
License (GPL) will be discussed in detail later in this paper, but
remains one of the most effective means to keep software
free.

At present, most of the GNU software is running on
an operating system called Linux. “In 1991, Linus Torvalds
developed a Unix-compatible kernel and called it Linux. Around 1992,
combining Linux with the not-quite-complete GNU system resulted in a
complete free operating system.”[8]

Moving ahead in time to 1998, part of the free
software community decided to stop using the term “free”
and adopted the term “open source” instead. Leading to
heated debate in various purist circles, the term open source
software has been used to “appeal to executives and business
users, many of whom hold an ideology that places profit above
freedom, above community, above principle.”[9]
As a result, proprietary software vendors have jumped on the open
source bandwagon. Partially driven by a hatred of Microsoft and that
which it stands for (closed software), Linux and open source software
has been embraced by dozens of communities. To a businessman, the
rhetoric of open source “focuses on the potential to make high
quality, powerful software, but shuns the ideas of freedom,
community, and principle.”[10]
It is at this point that we find ourselves today. Currently, there
remain differing views on free vs. open software, software whose
source code may be subjected to peer review and is available for
anyone to modify.

Open Source Definition

Attempting to define the most characteristic
properties of what makes software open source, Bruce Perens wrote the
first draft of the Open Source Definition (OSD) as a document
entitled, The Debian Free Software Guidelines. It was refined
in a month-long e-mail conference in late June of 1997. Removing the
Debian references throughout the paper, he developed what has been
embraced as the Open Source Definition.[11]
In order to comply with the OSD, distribution terms of open-source
software must comply with the following nine points.

Point one revolves around the notion of “free
redistribution”. “The license may not restrict any party
from selling or giving away the software as a component of an
aggregate software distribution containing programs from several
different sources.”[12]
The purpose of this statement is to minimize the temptation of making
money off open source software.

Point two of the OSD states the program “must
include source code, and must allow distribution in source code as
well as compiled form.”[13]
This idea is a simple one. If software is not distributed in source
code form, it cannot be modified very easily.

Point three requires the OSD compliant license to
allow modifications and derived works to be distributed under the
same terms of the original license. This statement is used to promote
the ease of subjecting code to peer review. The easier it is to
distribute modified works, the easier it is for source code to be
altered.

Fourth, should the license restrict source code
from being distributed in modified form, the license must require the
distribution of “patch files” with the source code. These
must be distributed for the purpose of modifying the program at build
time. The rationale of this requirement goes to the protection of an
author’s reputation. In the open source community, certain
people have achieved great reputations for their intelligence and
dedication to a given project. In order to save this reputation, it
may be critical to distribute unofficial changes separately from the
base source.

Fifth is a non-discrimination clause against any
person, or group of persons. This requirement is an attempt to
address export laws of countries around the world. Any license
complying with the OSD may not incorporate export
restrictions.

Sixth, the OSD requires that a compliant license
not restrict anyone from “making use of the program in a
specific field of endeavor.”[14]
This requirement ensures that commercial users feel comfortable using
open source software.

The seventh point requires the rights attached to
the program to apply to all that receive the program. This means that
no other license may accompany the original license.

The eighth point requires that the license not be
specific to a certain product. This closes up a “trap”
that is seen by some open source proponents. Should source code be
tied to a certain product, the only way to redistribute the source
would be in conjunction with the given product.

Lastly, the ninth point states that 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.”[15]
It is this requirement, also seen within the GPL, which has become
the most controversial. The question is one of contamination. At what
point, on a technological level, does proprietary code become
contaminated by open source software? This appears to depend on the
license terms and will be addressed later in this paper.

In order to achieve some basic standards as to
which licenses may be classified as OSD compliant, the Open Source
Initiative has developed a certification program. The very nature of
today’s open source popularity has threatened to break up what
has already been developed. For example, as proprietary vendors wish
to become part of the open source community, and help promote Linux,
they are developing their own open source licenses. These licenses
are all on the cutting edge of legal practice, but none are
litigation tested. As a result of the huge disparities of terms
within these proprietary vendor software licenses, the Open Source
Initiative has attempted to help vendors by offering the license
certification program. Unfortunately, since new open source licenses
are being made available every day, the open source movement cannot
keep up with all of the changes. It is the process of staying
knowledgeable on a topic that is on the forefront of the Silicon
Valley.

Licensing

With the necessary background on the Open Source
movement now firmly in place, we can discuss the topic of open source
licensing. After developing a software program, if any amount of
control is to be kept over the product, one must license it. The only
other option available is to allow the software to reside in the
public domain, requiring the owner to give up all rights and control
of the product. However, the vast majority of companies that wish to
open source proprietary software do not understand what they are
doing when they choose a specific license. Often, the term GPL is
thrown into the mix as a catchall for open source licenses. This
misguided notion often leads companies down an incorrect path that
may take valuable compute cycles.

Finally, before getting into the different
licenses themselves, it is important to reiterate that none of these
licenses have yet to be tested in an actual courtroom setting. As
such, the legal field revolving around open source software is in its
infancy stages. With this infancy comes a certain amount of
creativity. There are quite a few open source licenses currently out
there, but not all of them might accomplish what is needed. If this
is the case, I encourage one to add clauses that achieve the given
objective. Perhaps through practice and peer review, we may very well
find out what works and what does not, much like the open source
software community itself.

The various licenses currently available vary
widely in scope and effect on code that is a derivative of, or used
with an open source program. One of the most important differences
between licenses is the degree of control granted over derivative
code. Some licenses require that the derivative work be treated the
same as the original code, while some licenses allow the derivative
work to be closed and become proprietary. This is the most basic
question that needs to be asked when a company is thinking about open
sourcing software. How much control do they wish to have over their
code, and derivative code?

One should picture the licenses spanning over a “degree
of control” continuum from “restrictive” to “flexible.”
The restrictive licenses attempt to control the derivative code as
closely as possible, as well as keep open, that which is currently
open source. On the other end, the more flexible licenses permit the
creation of proprietary works from the original code. In this, code
that once was open, may be closed. The most restrictive of all the
licenses thus far is the GPL, or General Public License. The GPL is
so good at keeping that which is already open, that it is considered
to have certain viral qualities. On the other end of the continuum,
the most open licenses include the BSD license. The BSD license
(Berkeley Standard Distribution) contains no restrictions on the
creation of proprietary derivative works. In between these extremes,
we have the Lesser GPL (LGPL), the Artistic License, the popular
Mozilla Public License (MPL), and the X-Consortium license. In recent
months, a whole host of open source licenses have cropped up.
Currently, Sun Microsystems, IBM, Silicon Graphics and others all use
the licenses mentioned, as well as their own. With so much selection
available, it is imperative that a company reviews each license in
detail, in order to decide which will best achieve the necessary
goals.

General Public License

The term GPL is often used in business circles as
a catchall for open source licensing. What those that use the term do
not readily comprehend is that the GPL is an extremely restrictive,
specific type of license. The GPL is designed to prevent open source
software from being used to create proprietary derivative works. “The
GNU General Public License is intended to guarantee your freedom to
share and change free software- to make sure the software is free for
all its users.”[16]
The founders of the GNU Project, as discussed earlier, believe that
the GPL is more free than any other license available. This can be
seen in their reluctance to recommend the use of any other license.
However, from a proprietary software vendor viewpoint, the GPL is the
most restrictive license available.

The GPL gives users the ability to copy and form
works “based on the [original] program.” The
derivative work may be distributed but must meet certain criteria.
These includes a provision that states, “You must cause any
work that you distribute or publish, that in whole or in part
contains or is derived from the Program or any part thereof, to be
licensed as a whole at no charge to all third parties under the terms
of this License.”[17]
This clause forces the derivative work to be available for
distribution under the exact same terms as the original, thus
maintaining the open nature of the original. A careful read of the
above section shows just how restrictive this license can be. For
example, if at any point in time, some code that is subject to the
GPL is linked (used loosely) with proprietary code, the proprietary
code will become subject to the GPL. It is this idea that gives the
GPL it’s viral nature, for it keeps open anything that it
touches. Under certain circumstances, it has the ability to affect
completely independent code.

There are few instances where the GPL does not
affect anything around it. One example is given in the license
itself. “If identifiable sections of that [modified]
work are not derived from the Program, and can be reasonable
considered independent and separate works in themselves, then this
License, and its terms, do not apply to those sections when you
distribute them as separate works.” The distinction lies in the
distribution method. If independent code is distributed as part of a
whole, then it is covered by the GPL. However, if independent code is
distributed as a separate work, then it may avoid coverage by the
GPL.

The authors left us two clues to work with when
deciding whether some potentially infected code may be subject to the
GPL. The first states that the intent of the section is not to claim
rights against an original author, but rather to protect the
distribution of derivative works based on the Program. Secondly, they
indicate that “mere aggregation of another work not based on
the Program with the Program (or with a work based on the Program) on
a volume of a storage or distribution medium does not bring the other
work under the scope of this License.”[18]
Thus, simply distributing a separate work together on one medium does
not subject the separate work to the GPL. Due to the fact that
derivative works are not allowed to be made proprietary, this license
may be considered the most restrictive currently
available.

Lesser General Public License

A slightly less restrictive license, but one that
still holds to all the requirements of the OSD, is the Lesser General
Public License (LGPL). The GPL and the LGPL are similar in that they
require both derived and independent code to be distributed as part
of a whole with the original code. However, the LGPL is less viral
than the GPL. This is due to the fact that the LGPL explicitly
permits linking LGPL code with proprietary code. The license states, “you
may also combine or link a ‘work that uses the Library’
with the Library to produce a work containing portions of the
Library, and distribute that work under terms of your choice,
provided that the terms permit modification of the work for the
customer’s own use and reverse engineering for debugging such
modifications.”[19]
In plain language, this clause permits linking libraries into
proprietary programs without the viral take over effects of the
GPL.

From a realistic business perspective, the LGPL
has only a few uses, but seems to have gathered favor when looking at
linking specific open source libraries with code that is proprietary.
If this license were not available, the library could be subject to
the GPL, and when linked, would bring the proprietary code under its
umbrella. With only a few minor exceptions, the LGPL remains a
restrictive license, keeping open source code, open.

Artistic License

The Artistic License was created for use with Perl
and attempts to soften the more controversial aspects of the GPL. “The
intent of this document is to state the conditions under which a
Package may be copied such that the Copyright Holder maintains some
semblance of artistic control over the development of the package,
while giving the users of the package the right to use and distribute
the Package in a more-or-less customary fashion, plus the right to
make reasonable modifications."[20]
This license is less restrictive than the LGPL. The Artistic License
allows the user to make modifications, but restricts the way in which
the changes may be distributed. This has the effect of prohibiting a
user from making changes and turning them into proprietary code. Once
a change is made, the user must either make the change available in
the public domain, or use it internally. The user does have the
ability to distribute the object code modified version, but only if
it is accompanied with the Standard version. The Artistic License
speaks to a few other options, but all are relatively minor in scope
compared to the above.

Realistically, a license of this nature could be
an option for a company looking for a license less restrictive than
the GPL, and more encouraging of derivative works. Section 7 of the
license states that “C or Perl subroutines supplied by you and
linked into this Package shall not be considered part of this
Package.” Thus, any original subroutines do not automatically
fall under the umbrella of the GPL style licenses. This style of
license is better, but still forces the user to distribute original
copies of the code along with modified versions, and ONLY in object
code form.

Mozilla Public License

In response to negative statements about Netscape’s
original public license (the NPL), Netscape created the MPL, or
Mozilla Public License. Even though the overall license is less
restrictive than the GPL or Artistic License, there are sections of
similar language. For example, any modifications of new source code
that incorporate parts from the original MPL code are considered to
fall under the MPL. The MPL continues to prevent someone from taking
his or her modifications and converting the overall product to
proprietary code. However, unlike the GPL, the MPL permits MPL code
to be combined with separate proprietary code to create a proprietary
program, which does not fall under the MPL. The Initial Developer
Grant of the MPL grants users a license to “use, reproduce,
modify, display, perform, sublicense and distribute the Original Code
with or without Modifications, and/or as part of a Larger Work.”[21]
“Larger Work” is defined to mean a work that combines
covered code with portions of code not governed by the
MPL.

The practical effect of the above section is to
allow a user to license, for a fee, proprietary source code that uses
a section of MPL code without needing to make the source publicly
available. To help pursue this end, the MPL requires the distribution
of the Larger Work to make certain that the work not licensed by the
MPL, is compatible with the MPL. A natural result of this requirement
is that MPL code may not be combined with GPL code. The GPL would
generally take the MPL code under its umbrella and usurp the MPL. The
MPL should be considered when a software vendor seeks to create an
open source product from scratch and wishes to retain the open
character of the code. It would also be good for a situation in which
proprietary code is to be open sourced. As a result, when a company
chooses to open source some of the crown jewels, others will not be
able to close up their modifications, which are considered to fall
under the MPL.

X-Consortium (MIT) and BSD Licenses

On the least restrictive end of the open source
license spectrum, we have the X-Consortium (MIT) and BSD licenses.
These two types of licenses allow the maximum amount of freedom in
development, without going so far as to put the software in the
public domain. Unlike other licenses that are several pages in
length, the MIT license takes up half of one page. The MIT license
allows “any person obtaining a copy of this software and
associated documentation files, to deal in the Software without
restriction, including and without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software.”[22]

There are really only three requirements of a MIT
licensee. One, the licensee must ensure that a copyright notice is
included in all copies or substantial portions of the Software. Two,
the permission notice quoted earlier must also be included. Three,
any and all warranties must be disclaimed. The process is concluded
with a standard “as is” style legal statement. This
allows the maximum amount of flexibility with what a licensee wishes
to accomplish.

The BSD license is similar in style and scope.
With the BSD license, other than ensuring that developers receive
proper credit, there are no real restrictions on the use of the
software. There are four conditions associated with the BSD license.
One, much like the MIT license, redistribution of source code must
retain a copyright notice. Two, redistribution of binary forms must
also retain the copyright notice. Three, the names of the
contributors may not be used to “endorse or promote products
derived from this software without specific prior written permission.”[23]
Fourth, an “as is” warranty statement must be included
along with the software.

These two licenses allow the user to take open
source software and create a proprietary product for which source
code need not be made available. One can not only make these
derivatives proprietary, but one can redistribute them without
applying the BSD license. Any proprietary software vendor interested
in making money from open source derivatives or modifications should
not use these licenses. Indeed, there is no way for a vendor who is
open sourcing proprietary software to take back or monitor any
changes to their software. All control is lost.

A final option that must be mentioned in passing
is putting software into the public domain. When software is placed
in the public domain, the developer has surrendered all copyrights to
the software. This option grants the maximum amount of freedom to end
users and developers and truly satisfies ideals of the free software
community. However, from a proprietary vendor perspective, this could
not be a worse solution. This allows anyone to work with the public
domain software, copyright the derivative, and sell the modified
version. When a company wishes to open source some closed software,
this option allows others to close the software once
opened.

Having looked at the major open source licenses
currently available, we must now look to problems that can arise when
a company decides to open source proprietary software.

Practical Considerations when Open Sourcing
Software

For the proprietary software vendor, open source
software represents a new frontier. Imagine a community in which
people participate in peer evaluation, send in bug fixes by the
hundreds, and generally improve the operational functionality of
previously closed software. To some vendors, this appears to be the
pot of gold at the end of the proverbial rainbow. The next question
is, how do we (proprietary vendors) make money off of something that
basically propagates because of its free nature? For the proprietary
vendor, when open sourcing previously closed software, there are
dozens of considerations. Practical problems arise based on the
interplay between copyright law and the open source model of “taking
back” modifications. Other considerations a business must
consider includes what type of license to use, how to make money off
of the software, and a consideration of whether they should use both
open source and/or proprietary versions.

Assignment vs. License Back

The process of peer review occurs as a result of
the proprietary vendor making the source code available for download
from a web-site or an FTP site. As we are already aware, once
downloaded, the source code is subject to the license that
accompanies it. As changes are made and sent back to the “gatekeeper,”
or person/company maintaining the source base, the gatekeeper has the
decision of whether or not to accept the changes into the source
base. Accepting modifications has the benefit of correcting the
original source base and eliminating some of the bugs in the
software. From a legal standpoint, the author of the bug fix has
copyrights in the bug fix. Upon creation, these rights vested in the
work. In order for the gatekeeper to accept the changes sent to them
and include them in the original source base, the gatekeeper must
either look for an assignment of rights from the author of the fix,
or a license back.

The smoothest transition occurs when the
gatekeeper waives the license the modified code was completed under,
and demands an assignment of rights from the author back to the
gatekeeper. In this, the code is then no longer subject to the
original license, and the author relinquishes their rights in the bug
fix. This relinquishing generally is in exchange for some credit in
the note section of the code. This credit can be given with the
addition of a line that says “portions of this software
contributed by” and the name of the contributor.

The other option is for the author of the bug fix
to license back the fix to the gatekeepers. With this, the author
retains copyright in the additional code, but licenses the rights to
include the code with the gatekeepers. This is not a very practical
consideration for the simple fact that the more complex a program
becomes, the more difficult it will become to comply with the
multiple licenses associated with the code, as well as track the
changes. One also needs to be careful because certain portions of
code may be licensed under a different license than the software is
licensed under. It is imperative that the gatekeeper ensures that the
licenses are compatible. As was mentioned earlier, the MPL and GPL
are incompatible licenses.

Multiple Contributors

A slightly different problem occurs if the
gatekeeper wishes to take back some code, and there were either
multiple contributors/authors, or several successive authors that
have made changes.

Should there be multiple contributors to one piece
of code, it becomes necessary for the gatekeeper to waive the
original license for each contributor and have every contributor
assign their rights to the gatekeeper. This is due to the fact that
copyrights for multiple authors reside in each author.

Another problem occurs when multiple people have
made changes to the software and distributed it down a line of
successive contributors. If the gatekeeper has not taken back any
modifications to the original source base but instead has let the
derivative work continue to be propagated, and the gatekeeper then
wants to take back a modification five modifications down the line,
we must deal with a great amount of paperwork. It becomes necessary
for the gatekeeper to get an assignment from every contributor that
worked on a given section of code down the line of succession. From a
practical viewpoint, this can cause quite a paper trail. However this
method of waiver and assignment appears to cause less headaches than
the separate licensing method.

GPL Deficiencies

“How close is too close?”

When distributing code under the GPL, the default
license for most businesses attempting to break into the open source
market, a major practical consideration is the viral nature of the
license. The problem was elucidated earlier but it is necessary to
expand on it. On one hand, the mere aggregation of proprietary and
open source code “on a volume of a storage or distribution
medium does not bring the other work under the scope of [the
GPL].”[24]
On the other hand, “You must cause any work that you distribute
or publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge
to all third parties under the terms of [the GPL].”[25]
In between these two extremes, we may encounter a situation where we
have proprietary code and open source code working together in some
fashion. The GPL is extremely unclear as to the point when
proprietary code becomes infected by the GPL, thus ending up subject
to the GPL. Does the way the code is linked have something to do with
it? Is there a difference between statically linking the code and
dynamically linking the code?

This question has not yet been litigated or
answered. Although it may be decided in the very near future as more
proprietary vendors use open source code to enhance their proprietary
code. Resolution may come in the form of a “reasonableness”
test. This test would look towards the motives of both companies and
whether or not it is reasonable to assume that under a certain set of
conditions, proprietary code becomes subject to the GPL. It may
ultimately be a very fact specific situation, or depending on the
judge’s technical competencies, we may actually get some
resolution on a technical level.

Maintaining Dual Source Bases

Another practical problem occurs when a
proprietary vendor decides to maintain two source bases. This
situation most often occurs when a vendor plans on open sourcing a
version of their software for open source operating systems. Acting
as gatekeeper for the code base, the vendor maintains two bases. All
of the usual problems while playing gatekeeper and taking back
modifications occur, but the gatekeeper must be acutely aware of the
different bases. Should any of the open source modifications find
their way accidentally into the proprietary tree, the proprietary
base would become infected by the code subject to the open source
license (GPL). If the modifications are to be taken back by the
proprietary vendor and added to the proprietary version, it is
imperative for the author of the change to assign all rights back to
the gatekeeper, or place the code in the public domain. Placing code
in the public domain would release all copyright obligations and
allow the vendor to incorporate the code into both the open source as
well as proprietary source trees.

Normally, the vendor who plans on open sourcing a
version of his or her software for open source operating systems
generally just maintains one source base. This is so that the
proprietary and open versions retain roughly the same level of
functionality. However, the gatekeeper must be even more careful not
to infect when maintaining just one base.

Business Considerations

Any proprietary software vendor must ask
themselves several business questions regarding open sourcing
software before they actually do it. The first question should
revolve around why they wish to open source their product, as
generally they do not make any money from distribution. Are they
planning on recouping this money through service or support
contracts? Or will the money come in through distribution of a box
product? Once the company develops a business plan for why they wish
to open source their software, they need to ask themselves what they
believe others will want with the software.

Asking this question focuses the company on which
type of license they should distribute with the software. Do you wish
to allow others to take modifications private for their own personal
gain? Do you wish to keep the software as open as possible to adhere
to the free software ideals? What if what they wish to accomplish may
not be accomplished with a standard license? In the first and second
instance, the BSD and GPL licenses would match the needs of the
licensor, respectively. However, in the third instance, it becomes
necessary for the licensor to develop a new license. This practice is
occurring in just about every large software/hardware vendor, as well
as some smaller vendors. IBM, Sun Microsystems and Silicon Graphics
are all currently putting together open source licenses that suit
their licensing needs.

Conclusion

As Linux and the open source community grow in
popularity, more licenses will become available for the licensor to
choose from. As none of the licenses have been directly tested in a
courtroom, we have little legal precedent to analyze. The GPL has
been noted as prior art in one patent infringement
case[26]
and the issue of open source licensing has shown up in the background
of a few decisions,[27]
but no case has directly addressed the legality of open source
licenses. Hopefully with the background addressed in this paper, as
well as some thorough business discussions around strategy of the
proprietary vendor and open source movement, companies will be able
to make a more informed decision with regard to choosing an open
source license.