NOTE: Failures of formatting at this time are solely the responsibility of the instructor. -- N.J., May 5, 2003
 

Open Source Software-Open up Copyright?
Table of Contents
I. Introduction                     1
 A. Open Source Software                 2
  1. Characteristics of OSS                3
  2. Examples of OSS-Linux                4
 B. Computer Program Copyright Protection             5
II. Proprietary Software vs. OSS-Differences and Problems         6
A. The Purpose of Copyright Law and Its Incentive for Developers      6
 1. The Economic Implications of Copyright Protection         6
 2. Incentives for OSS Developers              7
B. Length of Copyright Protection                8
C. OSS Copyright Infringement                 9
 1. OSS Model of Development               10
 2. OSS Model of Monitoring and Control            12
3. Copyright Infringement Suit               12
D. OSS Licensing Problems                 14
1. OSS Licensing                  15
2. Incompatibility of OSS Licenses              16
3. Contract Warranty of OSS Licensing             17
III. Solutions to the Problems in OSS               18
A. Licensing Agreement Terms                18
1. Contract Warranty and Enforceability            18
 2. Resolution-Independent Internet Entity            19
B. Legislative Regulation                 20
IV. Conclusion-the Future Development of OSS industry        21
Glossary                      22
 
  The open source movement-a community consisting primarily of software developers and organizations interested in the software industry revolution-poses a profound challenge to the way software is made, reproduced and distributed and the law that regulates it.
Traditional copyright law gives inconsistent or insufficient protection to open source software (OSS) compared with what it gives to proprietary software. How to interpret and update the 1976 Copyright Act in response to the open source movement is the focus of this paper.
It (1) begins with a description of OSS and a representative example: Linux, (2) compares the characteristics of OSS and proprietary software and their inconsistent treatment in terms of copyright protection, (3) analyzes OSS licensing and operation problems; (4) purposes solutions to OSS problems through contract, regulation by the Internet community or copyright law, and (5) predicts the future of OSS development.
I. Introduction
A. Open Source Software
  Open source software (OSS), is sometimes referred to as Free Software (FS). In summary, the licenses for OSS/FS programs permit users the freedom to run the program for any purpose, to study and modify the program, and to freely redistribute copies of the original or modified program.1
1. Characteristics of OSS
"Open source" does not mean merely access to the source code or free distribution. The distribution terms of open-source software must comply with the following criteria:
1. An OSS license must not restrict selling or distributing the software as a component of an aggregate software package and must not require a royalty or other fee for its use.
2. The OSS program must include the source code, and allow distribution in source code as well as in a compiled form. The source code must be the preferred form in which a programmer would modify the program.
3. The OSS license must allow modifications and derived works, and allow developers to distribute their programs under the same terms as the license of the original software.
4. The OSS license may restrict source code from being distributed in modified form only if the license allows the distribution of patches with the source code for the purpose of modifying the program at the beginning.
5. The license must not discriminate against any specific person or group of persons and must not restrict use of the program in a specific field of endeavor.
6. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
7. The rights attached to the program cannot depend on the program being a part of a particular software distribution.
8. The license must not place restrictions on other software that is distributed along with the licensed software.
9. The OSS license must be technology-neutral, and no provision of the license may be predicated on any individual technology or style of interface.2
2. Examples of OSS-Linux
  To understand the difference between OSS and proprietary software, it is useful to consider a prominent example that has been developed through the open source process.  Some of the most important members of OSS are Apache, BIND, Mozilla, Perl and Sendmail. The one most familiar is the Linux operating system. In recent years Microsoft Windows-the worldwide use operating system-has been threatened by the breakthrough development of Linux. For this reason a comparison between Windows and Linux is appropriate to our consideration of the issues.
  Linux is a freely distributable version of Unix, it is available for multiple platforms such as x86, Motorola 68k3 and Digital Alpha. It is an implementation that follows closely the POSIX specification that most commercial Unix versions implement. Linux was created by and named after Linus Torvald in Finland and announced its first version as "0.02" in 1991.4 Thanks to the help of the Internet, many developers have devoted their time to debugging and updating the Linux system (the latest Linux kernel5 archive is 2.5.65, which can be freely downloaded at http://kernel.org). Because of its widespread use, Linux can be asserted to be the open source project that has probably undergone the greatest number of publicized tests, reviews and comparisons.6
B. Computer Program Copyright Protection
  The Copyright Act of 1976 7 is Congress' most recent major reform of the Copyright Act "which [with some modifications] governs most works today."8 But the term "computer program" was not included in the copyright law subject matter until the 1980 amendment9.
The copyright clause in the U.S. Constitution provides that copyright aims "(to) promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries."10 The 1980 Amendment grants copyright protection to both source codes and object codes of computer programs.
Although patent protection is also available it is difficult to obtain because most software is only a new expression of an existing process. Therefore, the authors of computer programs usually turn to "original work" copyright protection. The rights granted by Copyright Act include the rights to reproduce the material object, to make derivative works, to distribute the work by selling, leasing and renting it, to make recordings, and to perform or display the underlying work.11
  Once computer programs were included within the definition of "literary work", the Copyright Act came to be applied to software for the purpose of restricting the public from accessing the programs. The result is that the software developer can make a profit by granting licenses or transferring ownership during the copyright protection term. Given the popularity of the Internet, the open source software industry has developed, and has come under traditional copyright regulation even though OSS was never contemplated by the drafters of the 1980 Amendment. But a variety of open source communities, together with the unique characteristics of OSS, have raised a lot of new requirements and problems challenging current copyright law- such as the scope of the copyright restrictions. An analysis of the difference between proprietary software and OSS can help illustrate the problems and the possible solutions.
II. Proprietary Software vs. OSS-Differences and Problems
  Linux is an example of open source software. Its competitor, Windows, is an example of proprietary software. Both operating systems are widely used through the world but have been developed throughout completely different processes and marketed with different strategies. For purposes of the paper, one of the greatest differences between them is that Linux users have been granted what is called a General Public License (GPL) while Microsoft is a strong advocate of proprietary software. As a result, the developers and users of these two kinds of software are working under totally different copyright requirements.
A. The Purpose of Copyright Law and Its Incentive for Developers
1. The Economic Implications of Copyright Protection
The Framers of the Constitution specified two crucial requirements for copyright law. First, the law should be structured to provide creators with economic rewards for their work, rather than to provide them with congressional medals or public monuments. Second, the law should be structured to improve society as a whole, rather than to aid specific authors, inventors, and artists. The immediate effect of copyright law is to secure a fair return for an author's creative labor. But "the ultimate aim is, by this incentive, to stimulate artistic creativity for the general public good".12
Applying the economic model developed by Landes and Posner, the economic effect of copyright law on innovation suggests that authors will continue to develop new works as long as the expected profit exceeds the expected cost of creating the work. The cost of creating a work, called the "cost of expression," rises proportionally with the level of copyright protection because, as copyright protection rises, authors are less free to borrow from and build on prior bodies of work.13 Such a model can be applied to predict the author's incentive to create when the underlying copyrighted work is proprietary software, but it may seem inapplicable to the unique characteristics of OSS.
2. Incentives for OSS Developers
  From an economic perspective, there is a huge divergence in the development of proprietary and OSS software. In the case of proprietary software, the legal uncertainty coupled with marketing risks will greatly deter the proprietor's commercial competitors. Rather than make huge investments in developing and marketing competing software they have great incentives to turn to more fruitful software innovations.14 Market and profit are the major orientation of the developers of proprietary software and the derivative work copyright owners.
The OSS developers have different incentives. First, OSS allows the users to have control over the source code so that the users may change the software to fit their own needs. This interaction between the program owners and users gives the users an appealing encouragement to participate in the modification and improvement of OSS.
In addition to the altruistic motive, the fact that every user can immediately enjoy his software update and debugging patch file is the greatest incentive for users to participate in the industry of OSS.15 Second, "one's work is one's statement"16 for many OSS developers. They may merely pursue the enjoyment of programming, and as well as the esteem in the open source community to which they belong. Knowing that their names will appear on the list of developers of OSS, they strive for higher levels of performance and distribution, which in turn improves the quality of OSS.
Third, the OSS developers may have an urge to compete with the existing proprietary software sellers. By developing free software with fewer restrictions, the OSS developers ultimately force their counterparts to lower their prices.
The competition between Linux and Windows well illustrates the developing trend toward OSS. The antitrust and anti-competitive problems caused by Microsoft's current dominance of the industry further reinforce the perception that OSS, particularly Linux, is a legitimate alternative to Microsoft. In February 2003, one Advanced Server Platform of Linux vendor Red Hat became the first open source application to receive a key U.S. government certification, the Defense Department's Common Operating Environment (COE), clearing the way for its use in critical government applications. This fact dispels yet another myth about the enterprise readiness of open source software.17
  Thus OSS can be seen as inconsistent with the traditional economic mode for intellectual property protection, and this regime of intellectual property has been outmoded by digital technologies. Thus, interpreting intellectual property law narrow to a balance economic incentive of the owner and the public interest would harm the open source movement and frustrate the achievement of its goals.
B. Length of Copyright Protection
According to the economic implications of copyright protection, copyright owners make a profit by using the bundle of rights accompanying the ownership of the copyright, mainly by granting licenses to reproduce, copy and making derivative work. In order to ensure that the copyright owner gets a sufficient economic reward before the copyrighted work enters the public domain, the Copyright Act grants the copyright to the original author "for a term consisting of the life of the author and seventy years after the author's death." 18 Generally, the profitable and useful life of software is much shorter than the life of other works. For example, Windows has undertaken about nine major iterations since its release in 1985. That is to say, one version of Windows becomes obsolete roughly every two years. At the same time, subsequent computer programs always need to be built on existing works, so from the standpoint of encouraging the development of the software industry, with regard to proprietary software, shortening the copyright term would make sense.
OSS licensing appears special in comparison with its counterpart. The basic implication of OSS licensing is it "must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."19 Thus OSS licensing provides OSS users great discretion in the release of newly added features and debugging patch files. What left for the software kernel copyright owners is merely some nominal rights. Except for some software companies such as Red Hat and Bluepoint, which make money from selling the Linux advanced version and its peripheral products, most of the OSS developers have no economic incentive consistent with the purpose of the statutory copyright period. Moreover, because every OSS, such as Linux, can be upgraded and debugged by every user's, generally the useful life of OSS is longer than that of proprietary software, even of some other kinds of copyright subject matter though the author has less economic prospects. In light of the statutory purpose of encouraging the development of the software industry, if copyright law will be amended to shorten its protection term for computer programs, OSS should be treated as an exception. Copyright law should give special protection consideration to OSS authors as an encouragement for their contribution to the software industry.
C. OSS Copyright Infringement
  OSS and proprietary software have different modes of development, which should influence the methods of protecting their copyrights.
1. OSS Model of Development
   The traditional process of software development occurs under a centralized leadership with a hierarchical model. Every project leader plays an important role in a certain step of the software development and is responsible for a specific part of the work. Subsequently the pieces of works of the project leaders will be centralized by other software engineers and organized into a certain program. In the debugging process, some project leaders have the task of handling the logistics of incoming bug reports and bug fixing patch files from users, selecting among them and implementing certain reports, then offering choices of solutions to users. In this highly planned, hierarchical approach of software development, finding and fixing bugs is a long and arduous process, taking "months of scrutiny by a dedicated few."20
The open source process takes advantage of its users for program development. Generally, the users not only offer feedback regarding flaws or shortcomings in the program, but also are major sources and potential programmers of solutions to these bugs. OSS has completely different development process comparing with that of proprietary software. In its initial stage, OSS begins with the desire of a developer to meet some currently unfulfilled or inadequately fulfilled need. The developer then writes the program and puts it on the Internet to be peer-reviewed by various open source communities. Under this decentralized developing model, users of OSS are encouraged to contribute not only their identifications of bugs, but also their potential solutions.
OSS development model has some advantages. First, bugs are easier to find and fix within a shorter release interval than proprietary software. Second, because the consensus of a large number of developers is more reliable than one or two software engineers' opinion, also because debuggers are not always required to conduct significant coordination and communication, therefore the communication and management costs occurred in the centralized model can be minimized in the context of OSS development. Although this cost minimization can be obtained in the hierarchical mode if the hierarchy is properly structured to allow shorter release intervals and to collect bug reports frequently from the Internet so that the bugs can be corrected in a minimum time, 21 the correctness and security level of OSS debugging patch file is always higher. As a conclusion, the more people participating and distributing into a software development, the more efficient and cost saving of the progress update. OSS fits this requirement better than its counterpart.
2. OSS Model of Monitoring and Control
  Another copyright related topic lies on that the monitoring and control model of OSS is different from that of proprietary software. The power of government to regulate and limit the rights to software depends partly on the ownership of the software's code.22 Therefore to some extent whether government can regulate code depends upon who controls the code. When the software is a closed code one, ownership is held by an individual or for-profit organization which is easy to be traced, government power is assured. But OSS makes transparent any control that the code might carry so the code always falls outside of the control of any particular person or company. Therefore the government's power in recognizing copyright owner and imposing relevant regulation or affording protection on the owner is limited in the case of OSS.
  The government's monitoring and control power is of critical significance in the software industry. If software is built under a closed code, the ability of a user to change its code is much more limited than when it is open code. Generally the harder it is for the users to change the code, the easier for the government to set up some standard and enforce the standard on that code. So when an industry standard or government control is imposed on both open source and closed source software, it is more likely that the regulation will be followed by the latter. This gives developers an escape way when they do not like the government monitoring and control: they can easily avoid the regulation by choosing to use open code software.23
3. Copyright Infringement Suits
The lack of regulability of OSS raises some other problems regarding its copyright protection. If a programmer writes his own software based upon an existing copyrighted OSS, undoubtedly this is a derivative work subject to the terms of OSS distribution and reproduction restrictions of OSS licensing.
The first problem is, when a programmer's distribution is believed infringes copyright of OSS, who is eligible to bring a suit? Under the 1976 Copyright Act, only the exclusive legal or beneficial copyright owner may sue for infringement. The legal owner is the person who holds the copyright, and the beneficial owners are those who have parted with legal title to the copyright in exchange for percentage royalties based on sales or license fees.24 In an early leading case Bertolino v. Italian Line25, the court held that in a suit under the copyright laws, it is axiomatic that only the proprietor (legal or beneficial owner) of the copyright has standing to sue for copyright infringement. But as it mentioned above, one important feature of OSS licensing is that it must be distributed solely under a non-exclusive license. This clause, for one hand, restricts the number of eligible plaintiffs who have standing to sue for copyright infringement. In determining whether someone has standing, a critical question is whether the plaintiff is really the programmer or owner of part of the copyrightable work. Set aside the non-exclusive license requirement, relevant evidence of ownership is also hard to collect. Assuming that in a Linux Internet community, every member in it holds a non-exclusive license, the Linux kernel is a collective patchwork of copyrights, a combined effort of multiple individuals26 so who holds ownership is uncertain in the Internet open source community. When one of the members in the community claims copyright ownership of an improvement or patch file, the court will have a potential problem of facing multiple suits although the number of exclusive copyright owners is far less than that of the factual plaintiffs.
The second problem is another procedural one. OSS development is largely related to the Internet, which has erased discrimination, restriction and also, certainty of the identity of users. Consequently apportioning damages among those who allege OSS copyright infringement is difficult. Under the government standard, it is easy to determine whether one's contribution to proprietary software is sufficient to constitute a derivative work copyright because the developers must comply with a series of requirements which are set ahead of time. But for OSS, there is no effective control on the copyrightability of every patch before a developer releases it. Two possible ways are only protecting the plaintiff disregard of the other contributors and alternatively splitting damage evenly, but both of them are unfair to each side. Moreover, when one alleges copyright infringement for a certain patch of program, not every potential programmer may have chance to be given timely notice to participate in the suit due to the uncertainty feature of the Internet, undoubtedly the damages awarded are subject to great decrease.
D. OSS Licensing Problems
 Setting aside the inherent inconsistency in the copyright protection of OSS, one unique aspect of OSS is its non-exclusive licensing. Generally, when the owner of a work "decides to transfer to one or more people the use and enjoyment of part or all of his bundle of legal rights, yet wishes to retain ownership of these rights", he uses a license. The license "defines the nature and extent of [the granted] permission". Both the original owner and a licensee may have the right to grant a license.27
1. OSS Licensing
  Proprietary software licensing usually imposes many restrictions on the licensee. A typical license requires the software to execute only format and limits the number of installations allowed per copy of software. Moreover, developers or developing organizations rarely make the source code available. If they do release the source code for some limited purpose, an extra charge is needed to maintain their market share and ensure maximum return.28 In contrast, as mentioned above, OSS licensing gives more discretion to the users. OSS licensing criteria prohibit the code from being used in proprietary or commercial software for profit; require the authors of every version of OSS to be recognized and kept their names integrity on the list; and require the future improvements or modifications to be distributed under the same terms of the OSS licensing, and so forth.
  Here are some examples of some widely used types of OSS licensing existing on the Internet, which have different licensing terms and restrictions:
Type
Name
Terms
GPL
The GNU General Public License
Allows users to copy and modify and distribute source code. Users must pass on, unimpaired, to other users the licensing rights with all derivative versions of the code.
BSD
The Berkeley Software Distribution License
Resembles GPL but does not require that any modifications or enhancements of the original code be contributed back to the open source community.
Aladdin
The Aladdin License
Resembles GPL but provides additional restrictions.
MPL & NPL
The Mozilla Public License and the Netscape Public License
A balance between BSD and GPL. Developers should return their modifications to the open source community but the owner retain specific rights that allow developers to continue proprietary development of other packages and maintain existing contracts with third parties.
SCSL
Sun's Community Source License
Sun requires and enforces compatibility among released versions of the software, and allows proprietary modifications and extensions to the software.

2. Incompatibility of OSS Licenses
  As shown in the chart above, the diverse level of Internet development leads to the existence of several types of OSS licenses in the open source communities. "The propagation of many different and incompatible licenses works to the detriment of OSS because fragments of one program cannot be used in another program with an incompatible license."29 These inconsistent OSS licenses pose many problems.
Technically, the incompatibility may lead to a number of patches or packages for one OSS in order to make it compatible with some other types of license or running environment, which results a potential ineffective and time-consuming work. A further technical problem is the OSS developers are more unlikely than those of proprietary software to take advantage of the experience learned in the prior open source programs because of the inconsistency among different licenses. Legally, the developers of OSS could be deterred by potential copyright infringement suits. For example, their retention of enhancement of OSS as derivative works may be allowed by BSD, but such retention infringes the copyright of original OSS developers under the terms of GPL. For this reason the uncertainty of copyright infringement from the standpoint of derivative software owner is a huge encumbrance of OSS communication in the Internet. So a good OSS license should devote to ensure minimal conflict among the existing software licenses and avoid the chaos in the OSS licensing.
3. Contract Warranty of OSS Licensing
Other than OSS licensing inconsistency, there is another problem exists in the terms of OSS license. The license fundamentally plays the role as an agreement between the original developers and users. Comparing the GPL terms of Linux with license terms of Microsoft Windows, we can find out that the greatest difference between them is their warranty clause. Microsoft warrants the software on condition that the software will "perform substantially in accordance with the accompanying written materials for a period of ninety days..."30. Microsoft allows use of Windows product on only one computer at one time and disallows reverse engineering and disassembly to remove any component part. So beyond the warranty clause, there is no other discretion warrant. Linux GPL is "without warranty of any kind" for any amount of time31.
The main reason that OSS vendors tend not to provide warranties for their products is that no single person or group as a member in the Internet open source community can be responsible for the defects in OSS. This is also due to the lack of government and centralized control as discussed above. Such difference in the licensing terms has both positive and negative aspects: for one hand, OSS users have to burden the risk of potential bugs and security problems that always happen in software development. On the other hand, OSS users at least have the privilege of modifying the source code when certain bug arises during their use of software.
In summary, the problems existing in the copyright protection of OSS are multifaceted, but the focus is the conflicting between traditional copyright law protection and the unique requirement of OSS and the incompatibility within various types of OSS licenses existing in the Internet.
III. Solutions to the Problems in OSS
  Related to the above analysis, there are several alternative ways to resolve the copyright protection problems existing in the OSS industry. Generally, some important ways are agreement, Internet open source community standard and copyright regulation.
A. Licensing Agreement Terms
1. Contract Warranty and Enforceability
  Mutual agreement between the OSS original developers and users is the most direct way to resolve the warranty problem inherent in OSS development. This can be seen as the result of free negotiation and better off through the software market. More and more Internet and OSS users are used to the fact that there is no warranty thus no single person can be responsible for OSS. But the facts that even proprietary software license sometimes bears no warranty in the terms and open source development is more interactive and transparent between the developers and users than the case of proprietary software make users choose OSS though it has no warranty. Because they are compensated by more security and frequent updated patch files.
  In addition, the OSS licensing provisions lead to a license enforceability problem. Even though the OSS license is binding between the parties, it still is not as enforceable as that of proprietary software. The Copyright Act grants derivative work authors copyright on the newly added part to preexisting works, so relevant use beyond this scope constitutes copyright misuse. But OSS license, such as GPL for Linux, requires that OSS provision extend to independent work that does not totally come from the open source code, consequently the independent work should be licensed back to the licensor. This provision makes the derivative software authors easy to conduct copyright misuse and infringe the copyright of the licensor. But because such provision is inconsistent with the requirements in Copyright Act, the licensor should recognize the potential danger that his license clause is lack of copyright enforceability and he has to face the risk that the relevant provisions in the OSS license may be unenforceable.
  Even though assuming all the clauses in OSS license are enforceable, such license still cannot fully prevent certain modifications from being taken as private. Many types of OSS licenses such as GPL and BSD permit modifications provided certain conditions are met. But the premise is that the derivative codes and the original codes should be distributed under notice of the same license. If the code is modified under a different license, "then the right to create modifications is lost or never arose due to the failure of the condition. In other words, for any work you distribute, the right to modify is only valid if you distribute the work under the GPL."32 So no matter the license of the original OSS code is enforceable or not, the coexistence of a variety of licenses makes licensors burden the risk of insufficient copyright protection all along.
2. Resolution-Independent Internet Entity
Beyond the contractual relationship between developers and users, market provides almost no further solution to guaranty OSS quality in contractual concerns. There are some alternative ways to resolve this problem in the market. The most persuasive one is forming a separate, non-profit entity in the Internet to verify application compatibility. One role of the entity is offering independent verification, and it also can test new OSS products on criteria based on their compatibility with other products, platforms or devices. Another role of the entity is operating on the user end as a report and information collecting center of the bugs related to software compatibility and enforceability standard. To ensure the impartial standard and independence of the entity, the Internet provides a best anonymous space in the current world.
B. Legislative Regulation
  Imposing governmental authority on regulating OSS Internet community and copyright licensing is another possible way. With legal regulation, the whole OSS development may goes more orderly with more certainty. Comparing with the law for financing and contract of sale of goods, which is compiled in Uniform Commercial Code, the various licenses concerning the right to transfer OSS are far less settled so it is hard to put OSS license into any existing legal doctrine. For example, if we apply fair use doctrine to OSS, a lot of problems may arise from this application because fair use is a very vague doctrine which authorizes certain socially beneficial uses of copyrighted material that would otherwise constitute an infringement. Whether a certain conduct is fair use should be determined case by case upon four statutory criteria.33 When a infringer wants to apply fair use doctrine to his modification or reproduction of the original open code to assert his conduct is protected by the copyright law, as analyzed above, the problem of inconsistency between OSS license provision and copyright law becomes a tough issue to resolve.
  The most straightforward way to change the situation is that, government can consider setting up a set of direct regulation concerning distribution, monitoring and norms of OSS. The feasibility can be inferred from the nature of OSS. It should be very difficult for government to access the source code of proprietary software and it also is not necessary to intervene its industry standard. But tracing every modification during the life of OSS is more feasible due to its transparency nature. Governmental organization can always freely access Linux in the Internet and recognize exactly how OSS is modified every time so that the necessary evidence is sufficient for legislators to set up certain norms particularly in regulating one kind of OSS such as Linux. Once the standard is set up, its enforceability depends on the mutual effort of every user and Internet community.
  Another theory supporting the feasibility of such regulation is public choice theory, which holds that broad, diffuse groups, like OSS developers and Internet open source communities are less likely to be effective in achieving a certain goal than a centralized interest group, like proprietary software developers.34 Based upon the existing huge user and developer basis of OSS development, if OSS are directed and protected by legal certainty, the future improvement will be more efficient and cost saving.
IV. Conclusion-the Future Development of OSS
  Cyberspace provides OSS the widest improvement possibilities, the largest developer and user basis and the fastest updating speed. The features of OSS determine that OSS has much more advantages and developing space than proprietary software.
The trend that OSS might step into and occupy more market of proprietary software can be seen from some important recent events. One of them is that from the year 2002, Microsoft has opened its Windows source code to systems integrators in a move to appease both large customers and a federal judge. This is a move that analysts say is more symbolic than material. Microsoft allows customers and partners to view the source code without changing it or sharing the code with others. The goal of Windows is to provide them with more in-depth knowledge of Windows and to let users troubleshoot problems more quickly.35 Another impressive event is Microsoft is predicted to add its proprietary software into Linux environment by the year 2004. Facing the threat that by 2007, 45 percent of new servers will use Linux instead of Windows-based applications, Microsoft would change its pricing structure to become more competitive with Linux, including repricing Windows or separating the operating system into a "kernel" with "add-on" components.36
If some more appropriate vehicles of protection such as copyright provision and Internet independent entity standard can be applied on OSS, it will become a better encouragement of OSS development through the Internet open source communities. Consequently, the competition between OSS and proprietary software will ultimately benefit the public software users and improve the software industry.
Glossary
Apache: Apache began as an effort to address problems that were perceived in the NCSA http web server. The Apache has been the most popular web server since April, 1996 and today is more widely used than all other web servers combined. The advantages of Apache include the fact that it is free (as in costless), that it is free (as in open source), and that it provides high quality performance.
BIND:  The Berkeley Internet Name Domain package (BIND) is the software that provides domain name service (DNS) for the vast majority of name serving machines on the Internet. BIND was originally developed at Berkeley under a grant from the Defense Advanced Research Projects Agency (DARPA). However, the development and maintenance of BIND has been taken over by the Internet Software Consortium (ISC).
Debug: To make (a hidden microphone, for example) ineffective; to locate and correct errors in a computer program code-"debug this program".
Digital Alpha: Alpha is both a microprocessor and the name of a computer system from the Digital Equipment Corporation (DEC), which is now part of Compaq. The Alpha processor uses a newer and more advanced architecture than DEC's flagship computer line, the VAX. The Alpha is based on reduced instruction set computer (reduced instruction set computing) architecture and handles 64 bits at a time.
Motorola 68k:
Mozilla:  Mozilla is the open source version of Netscape's Communicator. On January 23, 1998, Netscape announced that, in addition to giving away its Communicator product, its previously closed source Communicator software was going to become open source. Not long after the source code was made available, a group of developers added 128-bit encryption capabilities, releasing a "Cryptozilla" product. Netscape's official Communicator version 5.0 incorporated modifications suggested by open source contributors.
Perl: Perl is a programming language that has become one of the most popular languages for Web page development, Internet services, graphical programming and many other purposes.
POSIX: Acronym for portable operating system interface for computer environments. A Federal Information Processing Standard Publication (FIPS PUB 151-1) for a vendor-independent interface between an operating system and an application program, including operating system interfaces and source code functions.
Sendmail: Sendmail is a utility that routes about 80% of the e-mail on the Internet.
Unix: A popular multi-user, multitasking operating system developed at Bell Labs in the early 1970s. Created by just a handful of programmers, UNIX was designed to be a small, flexible system used exclusively by programmers. It was one of the first operating systems to be written in a high-level programming language, namely C.
x86: x86 is a generic name for the series of Intel microprocessor families that began with the 80286 microprocessor. This series has been the provider of computing for personal computers since the 80286 was introduced in 1982. x86 microprocessors include the 386DX/SX/SL family, the 486DX/SX//DX2/SL/DX4 family, and the Pentium 3 family.

1 See Open Source Software / Free Software (OSS/FS) References, http://www.dwheeler.com/oss_fs_refs.html
2 See The Open Source Definition, http://www.opensource.org/docs/definition_plain.html
3 See Motorola 68K Instruction Definitions, http://debuffer.sourceforge.net/table68k.html
4 See Miguel Torrealba, What is Linux? http://www.linuxfocus.org/English/November1997/article1.html
5 See About Linux Kernel, http://sources.redhat.com/ml/bug-gdb/2000-07/msg00006.html
6 See Marcus Maher, Open Source Software: the Success of an Alternative Intellectual Property Incentive Paradigm, 10 Fordham Intell. Prop. Media & Ent. L.J. 619, 623 (2000).
7 17 U.S.C. §§101-1332, 1994 & Supp. IV 1998.
8 Robert P. Mergeset AL., Intellectual Property in the New Technological Age, 323 (1997).
9 See Pub. L. No. 96-517 §10(a), 94 Stat. 3028 (1980) (amending §101 of the Copyright Act).
10 U.S. Const. art. I, §8, cl. 8
11 17 U.S.C. §106, 1994 & Supp. IV 1998
12 A. Michael Warnecke, The Art of Applying the Fair Use Doctrine: the Post-Modern Art Challenge the Copyright Law, 13 Rev. Litig. 685, 695-696 (1994).
13 On the application of economic analysis by legal scholars to specific copyright law doctrines, see William M. Landes & Richard A. Posner, An Economic Analysis of Copyright Law, 18 J. Legal Stud. 325 (1989).
14 See Stephen M. McJohn, The Paradoxes of Free Software, 9 Geo. Mason L. Rev. 25, 36 (2000).
15 See Marcus Maher, supra note 4, at 633-634.
16 Eric S. Raymond, Homesteading the Noosphere: The Value of Humility,
http: tuxedo.org/esr/writings/homesteading/homesteading-11.html
17 See Red Hat Gets Thumbs-Up from U.S. Government, http://www.newsfactor.com/perl/story/20742.html
18 17 U.S.C. §§302(a), 1994 & Supp. IV 1998
19 See Bruce Perens, supra note 4.
20 Eric S. Raymond, The Cathedral and the Bazaar: The Importance of Having Users, http://www.tuxedo.org/esr/writings/cathedral-bazaar-3.htm.
21 See Eric, supra note 15, and see Eric S. Raymond, The Cathedral and the Bazaar: Release Early, Release Often, http://www.tuxedo.org/esr/writings/cathedral-bazaar-4.htm.
22 See Jerome H. Saltzer et al., End-to-End Arguments in Systems Design, in Integrated Broadband Networks, 30 (Amit Bhargava ed., 1991).
23 See Lawrence Lessig, The Limits in Open Code: Regulatory Standards and the Future of the Net, 14, Berkeley Tech. L.J. 759, 765-766(1999)
24 See 17 U.S.C §501, 201 (1994).
25 Bertolino v. Italian Line, 414 F. Supp. 279, 284 (S.D.N.Y.1976)
26 Shawn W. Potter, Open up to Open Source, 6 Rich. J.L. & Tech. 24, 68 (2000).
27 Natasha T. Horne, Open Source Software Licensing: Using Copyright Law to Encourage Free Use, 17 Ga. St. U. L. Rev. 863, 871 (2001)
28 See Richard P. Gabriel & William N. Joy, Sun Community Source License Principles, http://www.sun.com/981208/scsl/principles.html.
29 See Bruce Perens, The Open Source Definition, in Open Sources: Voices from the Open Source Revolution, 185 (Chris Dibona et al. eds., 1999).
30 See Microsoft Corporation, Microsoft End User License Agreement (EULA): Windows 98-Online, http://www.linuxmall.com/misc/refund/eula/online032698.html.
31 See GNU General Public License, http://www.opensource.org/licenses/gpl-license.html.
32 Christian H. Nadan, Open Source Licensing: Virus or Virtue? 10 Tex. Intell. Prop. L.J. 349, 370 (2002)
33 See 17 U.S.C. §107 (1994).
34 For a detailed analysis, see Stephen, supra note 10, at 64-66. And see Lawrence Lessig, Open Code and Open Society: Values of Internet Governance, 74 Chi.-Kent L. Rev. 1405, (1999)
35 See Tiffany Kary, Microsoft extends shared-code effort, http://news.com.com/2100-1001-841933.html.
36 See Lisa Gill, Research Firm: Microsoft Will Use Linux by 2004, http://www.newsfactor.com/perl/story/20210.html.

Open Source Software-Open up Copyright?       Ying Yu


[20030505]




1
 
 
 

Web Analytics Made Easy - Statcounter