Bryan M. Kreft
May 10, 2000
Prof. Friedman
Legal Issues of the 21st Century
Santa Clara University School of Law
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..
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.
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.
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. 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.Licensing
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[1]
http://www.fsf.org/gnu/the–gnu-project.html
[2] Id.
[3] Id.
[4] Id.
[5] Id.
[6] Id.
[7] Id.
[8] Id.
[9] Id.
[10] Id.
[11] http://www.opensource.org/osd.html
[12] Id. at 1
[13] Id. at 2
[14] Id. at 6
[15] Id. at 9
[16] http://www.gnu.org/copyleft/gpl.html
[17] Id. at 2(b)
[18] Id. at 2
[19] http://www.gnu.org/copyleft/lesser.html
[20] http://www.opensource.org/licenses/artistic-license.html
[21] http://www.mozilla.org/MPL/MPL-1.0.html
[22] http://www.opensource.org/licenses/mit-license.html
[23] http://www.opensource.org/licenses/bsd-license.html
[24] http://www.gnu.org/copyleft/gpl.html
[25] Id. at 2(b)
[26] Pfund v. U.S., 178 F.3d 1313 (Fed.Cir., Jan 20, 1999)
[27] Sun Microsystems, Inc. v Microsoft Corp., 999 F.Supp. 1301, 46 U.S.P.Q.2d 1531, 98 Daily Journal D.A.R. 9158 (N.D.Cal., Mar 24, 1998)
Back to Class Web Page