A Look at Software Licenses:
The Past and Future
By
Justin Erenkrantz
|
Initials |
Checklist for Final Research Paper |
|
|
1. Attractive cover page (legible illustration, title, subtitle, and name) |
|
|
2. This checklist (each item on the checklist must be initialed) |
|
|
3. Title page (title, subtitle, 4-digit UC Irvine ID, and e-mail) |
|
|
4. Table of contents (1st, 2nd, and 3rd level headings with page numbers) |
|
|
5. List of illustrations (figures and tables with page numbers) |
|
|
6. Appropriate quote from an authority figure before the INTRODUCTION |
|
|
7. Body of text beginning with INTRODUCTION (14-16 pages, 300 words/page) |
|
|
8. CONCLUSION |
|
|
9. Bibliography (minimum six references) |
|
|
10. Readability analysis |
|
|
11. Standard format headings and sub-headings that communicate to the reader |
|
|
12. Double-spaced, ragged right margin, and printed on one side of the paper |
|
|
13. Checked for correct grammar and punctuation |
|
|
14. Spell-checked both visually and with software |
|
|
15. Carefully proofread the paper forward and backward |
|
|
16. Read the paper aloud to involve hearing sense |
|
|
17. Subject and verb agree in person and number |
|
|
18. Avoided passive sentence constructs |
|
|
19. Printed on laser quality color printer and bound with tape |
|
|
20. Used 12 points for font size |
|
|
21. Used figures and tables (minimum four) |
|
|
22. Centered figures and tables and properly captioned |
|
|
23. Bordered figures and tables for good visual effect |
|
|
24. This professionally written paper is my original work |
|
|
25. This is the best paper in class! |
A Look at Software Licenses:
The Past and Future
Prepared for
Professor Seth A. Ourfalian
ICS 139W
Justin Erenkrantz
jerenkra@ics.uci.edu
Table of Contents
Illustrations
Table
Figure
Economics is the study of what people do when nothing more important than money is at stake.
-- Richard Stallman
The computer industry is currently undergoing a dramatic revolution. One of the prime forces behind this revolution is the adoption of different software licenses. For those unaware of software licenses, they are the rules a software user abides by. In the past, software licenses have been very restrictive. However, certain changes have occurred in the marketplace so that the software licenses are now becoming less restrictive. This opening up has spurred a new wave of software development.
This paper will first examine what a software license means. Many different software licenses are currently utilized in the market. However, only a few basic types of licenses are actually used. In this paper, the following licenses will be examined
The Traditional Binary-Only License
Public Domain
BSD License
GNU Public License
Sun Community Software License
These licenses have been picked because they form a diverse representation of the current state of software licenses that are in use today. Most other software licenses are a derivation of the ones examined in this paper. However, due to the rapid changes occurring in the industry, new licenses arise every day. This paper should only be considered a starting point to the options available to both developers and end-users.
Definition and Rights Given By a Software License
Before proceeding further, the exact definition of a software license must be examined. Legally, a software license resides in the domain of copyright law. A copyright is not a patent, which is a unique method of invention with no prior art. Many different pieces of software exist that are functionally equivalent. A copyright is not a trademark, because it is more than a name placed on the software. In software, a copyright refers to the specific implementation of a program. If one line is changed, a new copyright can be issued unless specific restrictions under the licenses prohibit this.
An original copyright holder exists who owns the software. This entity initially wrote the software, which was not derived from anothers work. Unless otherwise abdicated by choice or by law, the original author holds the copyright to the program. They can then release the software under any software license that they may choose. The license will dictate the rights that others have to the code.
One important point of copyright law is that a copyright holder can release software under contradictory licenses. Therefore, the copyright holder could release the code under both the BSD license and the GNU Public License. In the case of different licenses, the end-user can determine which license they will utilize. As will be examined later, certain licenses place restrictions on who can and cannot legally use a piece of software.
A software license is a contract between a copyright holder and the licensee. In order to use the license as stated, the prospective licensee must follow the terms specified in the license. Otherwise, the copyright holder can seek legal damages from the licensee. This is one section where copyright law is in agreement with patent law and not with trademark law. Under copyright law, the owner of the copyright can decide if prosecution should be brought against the violator. This is in contrast to trademark law, which requires strict enforcement or the trademark can be permanently revoked (15 USC 22). Unlike patent law, copyrights never expire they are the sole property of the copyright holder until they relinquish it to another party or release it into the public domain.
The software license also determines the restrictions placed on the licensees. Certain licenses prohibit transferring of licenses to other parties. Certain licenses allow complete transfer of the license to another party if certain conditions are met. Others prohibit further restrictions of the terms of the license. Others allow further restriction of the license terms. As can be seen, there are enough variations to support multiple licenses in a marketplace.
A prospective licensee does not necessarily have to accept the terms of the license. In almost all current licenses, the licensee may reject the terms of the license. However, at this point, they have no legal basis for continual use of the software. Therefore, it is not possible to use a piece of software and not abide by the license. The associated privileges are contingent on accepting the terms of the license.
United States copyright law allows for a special type of exemption: fair use. Fair use is defined by the United States government as:
[T]he fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright (17 USC 107).
This clause has been interpreted that commentary about the copyrighted item is not hindered by threat of copyright violation. Therefore, copyrights cannot be infringed by merely discussing the contents of the copyrighted material.
The prevalent form of software license currently utilized by commercial software companies today is binary-only licenses. For the purposes of this paper, binary-only licenses refer to license where the licensee does not have any right to the original source code. This type of license is closed source. All other licenses discussed in this paper are variations on open source licenses those licenses allows varying degrees of access to the source code.
Within the class of binary-only licenses, there are many variations. However, all binary licenses share one feature the copyright holder only provides a pre-compiled executable, which will provide the licensee with the requisite functionality. The end user has no right to modify the original source code used to generate that executable. If the user wishes to port the software to another platform, they must contact the original author and negotiate terms for the source code. All creative control of the original code remains with the copyright holder. No modifications are otherwise allowed. The intellectual property of the original code remains the sole property of the copyright holder.
This is regarded as the most restrictive form of software licensing available. Now, each specific binary-only license may grant or deny certain extra properties to the licensee. For example, Microsoft used to allow employees of a corporation, which had purchased Microsoft Office for corporate use, to install Microsoft Office on their home computer. However, the requirement imposed by Microsoft was that they had to use that copy of Microsoft Office at their residence for at least 20 percent of their job-related duties this rule was called the 80/20 rule (Software Licensing FAQ). However, in recent versions of Microsoft Office, this clause has been removed. Therefore, if you now use a recent version of Microsoft Office in the workplace, you must purchase a separate license for Microsoft Office to work at home.
On the other side of the software-licensing spectrum from binary-only license is the public domain. Public domain is exactly that it resides in the domain of the public. Anyone can use this software. Anyone can modify the source code. Anyone can sell it for a profit. In certain circumstances, they can even release the code under a more restrictive license.
However, a program does not automatically reside in the public domain. The original copyright holder must cede the copyright. After the copyright is removed, it enters the public domain. At that time, there is no copyright placed upon the source code. Any party can modify the source code, use the source code, and even release their changes under a new software license.
A copyright holder may do this when they no longer wish to be associated with the code. The product may have reached the end of its useful life cycle. The product may not have fulfilled the original expectations. Usually, the original copyright holder feels that the program would be best served if another person assumed responsibility. Therefore, the product is released to the public domain so that someone else can continue development. The new developer is able to take the modified code and place a new license and copyright on their modifications.
Berkeley Software Design License
One of the most venerable open software licenses is the Berkeley Software Design License, which is commonly called the BSD license. As the name implies, this particular license originated at University of California, Berkeley. It is a very open license and allows complete redistribution and modification of the source code. It also affords a degree of legal protection to the original copyright holder.
The most prominent use of the BSD license is in BSD-based Unix operating systems. In order to understand why the BSD license originated, the prior state of the software industry must be examined. The BSD license spawned an entire software revolution and a whole generation of software programmers.
Unix was originally developed by Ken Thompson and Dennis Ritchie at Bell Telephone Labs in the late 1960s and early 1970s. Unix was designed to be a robust time-sharing operating system, and it has succeeded at that goal. Yet, some industry insiders question whether Unix would have achieved greater success if it had been licensed under questionably better terms (Raymond). As depicted in Figure 1, the original AT&T Unix has spawned a large number of progeny each one with their own advantages and disadvantages. Originally, the Unix license was very vague, but it was acknowledged that it allowed for redistribution and modification. In 1979, however, AT&T announced plans to commercialize Unix (Seltzer). AT&T then required the purchase of a Unix Source License (USL) to commercially use Unix.
This sent uproar through the Unix community because their operating system was now encumbered by a very restrictive license. However, a group of UC Berkeley graduate students led by Bill Joy (currently Chief Scientist at Sun Microsystems and developer of the SCSL) developed the Berkeley Software Distribution. They added TCP/IP networking and many other features that were missing in the original AT&T version. However, to use the initial BSD variant still required a valid USL.
Since the distribution required the USL, an internal push was made to rewrite the entire code base so that it could be freely distributed without the USL (McKusick). This is known in software development as a clean room implementation. In such a process, the new developers examine the published specifications of the program and reimplement it without consulting the original source code. Therefore, the new program code is property of the new developers. With the exception of six core files, the Networking Release 2 version of BSD did not require a valid USL. Shortly after the release, Bill Jolitz reimplemented those six core files. Now, the entire BSD version did not require a commercial license.
The BSD license has received the greatest degree of legal scrutiny of all open source licenses. In 1992, Unix Systems Laboratories (USL) sued Berkeley Software Distribution, Incorporated (BSDI) for trade secret violations. Both companies were essentially fronts for much larger organizations: USL was controlled by AT&T, and BSDI by the University of California. These companies were responsible for promoting and protecting their parent companies commercial interest in the Unix world.
In the suit, USL alleged that BSDI was infringing on USLs Unix copyright and requested an injunction to prohibit BSDI from further distribution of BSD. BSDI claimed that they were merely redistributing the freely available code from UCB while adding Bill Jolitzs implementation of those six missing files. At that time, UCB was not a defendant in the case, so the judge agreed with BSDI and recommended the dismissal of the UCB portion of the code. However, USL then added the University of California (UC) as a co-defendant in the suit. Eventually, Federal District Judge Dickinson R. Debevoise dismissed all but two of USLs complaints and recommended that USL seek to resolve this matter in state court before reappearing in federal court (McKusick).
That next Monday morning, a critical turn of events occurred. The UC lawyers counter sued USL in California before the USL lawyers had filed their new suit in New Jersey district court. Because of United State law, both sides were now bound to plead the case in the first-to-files jurisdiction, which supercedes all other jurisdictions (28 USC 1407). Therefore, this tactic placed USL at a disadvantage because they had to fight the case in California, not New Jersey, which was where the federal district litigation occurred.
In their counter-suit, UC claimed that USL had failed to give proper credit to UCB for their original networking code (McKusick). UC asked for a public retraction and apology for USLs trade secret violations. During this legal impasse, AT&T sold USL to Novell (AT&T Press Release). Novells CEO Ray Noorda publicly announced that he would prefer to compete in the marketplace instead of the courtroom (McKusick). The suit quietly faded into the background.
Yet, the damage to BSD was almost irreparable. Because of the legal worries, many programmers shied away from BSD and started focusing on other alternatives (McVoy). The core BSD people were tied up with litigation issues and did not have the time required to continue innovation on their project (McKusick). However, BSD remains quite strong in the marketplace, but it lost its chance for market supremacy when USL filed their suit.
The most popular BSD-based operating systems are NetBSD, FreeBSD, and OpenBSD. Each of these operating systems is derived from Bill Jolitzs 386/BSD operating system the first publicly redistributable BSD. Because the BSD license allows forking and free modifications, many splinter groups formed immediately after Bill Jolitzs initial software release.
As described in Table 1, the splinter groups solidified into three groups that still survive today. By examining the splinter groups, it allows us to see a unique aspect of open source code flexibility and the capability to simultaneously pursue tangential goals. This technique is called forking in the software industry two factions of a single group disagree on a common direction, and if each faction deems that the difference is irreconcilable, a new group is formed. This benefit is the key advantage of open source, but at the same time, it is open sources downfall. Forking causes market fragmentation as well as rapid innovation.
Table - Common BSD Variants and Respective Focuses
|
|
NetBSD Robustness and Portability |
|
|
FreeBSD - Intel-based Processors |
|
|
OpenBSD - Security |
The first of the splinter groups is the NetBSD group. The NetBSD founders chose to continue the unique style of innovation that was present at Berkeley. One of their main goals is to promote portability of their code allowing new processor families to be added with minimal effort. The other distinguishing feature of NetBSD is that when faced with a programming dilemma, they tend to choose the more stable and reliable method instead of cutting corners (NetBSD). This pedagogical bent has earned NetBSD a high reputation among administrators looking for a stable and reliable operating system.
A few months later after the initial Jolitz release, another group emerged and they called their distribution FreeBSD. Their focus was on Intel-based PCs, which is markedly different from NetBSDs stated goal of portability. However, in recent years, support for the Alpha platform has emerged. However, the focus on Intel-based computers still dominates and portions of the code are optimized for Intel-based processors. One of the strongest features in FreeBSD is its Linux binary compatibility FreeBSD can now run programs that have been compiled for Linux without any changes or modifications (FreeBSD). This is a tremendous lure for people who are frustrated with Linux and are looking for a compatible alternative.
A few years after NetBSD was formed, a splinter group emerged from the bowels of NetBSD. At the heart of the breakup was a major disagreement about how secure the operating system should be. A faction of the NetBSD group thought that NetBSD was not as secure at it could be. Therefore, this security-driven group left NetBSD and formed a new BSD-based distribution called OpenBSD. Over the past few years, the OpenBSD group has modified the kernel to fit their stringent security requirements. The OpenBSD group has a methodology called proactive security, which means that there are continual audits of their code looking for possible security holes (OpenBSD Security). Their methodology has won the distribution numerous accolades for its security conscious efforts.
The main feature of the BSD license is that it allows free redistribution and modification of the source code. The copyright holder allows the licensee to do whatever they wish with the code, provided they follow a set of guidelines set forth in the license.
One of the most contentious parts of the BSD license is the fact that it required acknowledgement that the BSD Unix source was derived from the University of California, Berkeley (UCB), and its contributors. Therefore, all software based on BSD code required the programmer to display a message at run-time indicating that the code originated at UCB. Many developers refused to acknowledge UCB, and chose another license for their needs. However, on July 22, 1999, this clause was officially removed from the BSD License by UCB officials (BSD Advertising Retraction). Therefore, the BSD license had a hurdle to its widespread acceptance removed.
One of the most striking differences between the BSD license and the GPL is that BSD-licensed code can be included in commercial products. Therefore, a large software development corporation can include BSD-licensed code in their product and sell it for a profit without prior arrangement with the copyright holder. Almost all current debates about the merits of the BSD license center around this aspect of the license. Some developers do not mind if their code is used in commercial projects. Others prefer that their code only be used in open source projects. This is where a preponderance of software licenses allows the copyright holder a great degree of flexibility.
The BSD license forbids the use of the original copyright holders name to endorse or promote the derived product (BSD License). Therefore, if a developer were to write a program and release it under the BSD license, anyone else could then modify the program and then release their new version. That action is expressly permitted and encouraged by the BSD license. However, you cannot use the original developers name to promote the changed product without explicit permission. Since the BSD license derived from work performed at University of California, the UC Regents did not want to be associated with a product in which they did not have a direct involvement.
The last major feature of the BSD license is the absolution of liability. The license indicates that the software is provided as is and that the copyright holder is not liable for any damages that might occur while using the program. This provides a degree of protection for the copyright holder. Again, this clause stems from the licenses university origins and is an attempt to protect the university from people who are financially impaired because of errors in the program.
One of the most publicized software licenses in recent months has been the GNU Public License (GPL). The GNU Project is headed by Richard Stallmans Free Software Foundation (FSF). In 1984, Richard Stallman, an MIT researcher, became disenchanted with the current state of software in the marketplace. Therefore, he started the GNU Project intending to free software for the last time.
Richard Stallman views open source software very differently from free software. According to Stallman, open source software is software where the licensee may be able to see the source code, but is restricted from modifying it for any reason. Free software is under a term called copyleft, which means that the freedoms given to a user can never be taken away under any circumstance (Copyleft). Stallman defines those inalienable rights as the ability to redistribute and modify software.
Richard Stallman is a staunch believer that truly free software is truly superior. He believes that only free software allows true competition in the marketplace (Stallman). He claims that commercialization of software destroys the technical merits of a program. Therefore, if all programs are free, only technically superior solutions will survive. Therefore, the GPL was written to ensure that technically superior code was written and allowed input from all.
At the heart of the GNU Project is the GNU Public License (GPL). As stated in the preamble to the license, the GPL is designed to provide the programmer with freedoms not restrictions (GPL Text). The GPL ensures these freedoms by imposing constraints on the restrictions that can be placed upon GPL-licensed code. This may sound convoluted, but in fact, it is quite simple. Any restrictions placed on GPL software is intended to make sure that the basic freedoms cannot be taken away. However, if any terms of the GPL are violated by the licensee, all rights are immediately forfeited.
The most important aspect of the GPL is that the program must be provided with the complete machine-readable source code. The source code does not have to be included at the time the user receives the program, but can be made available via a medium customarily used for software interchange (GPL Text). This is an intentionally vague clause, which allows the parties to define a mechanism for obtaining the source code (CD-ROM, FTP, Email, etc.). Another alternative to providing the source code immediately is to accompany the product with a written offer that is valid for three years (GPL Text). The GPL allows reimbursement to the copyright holder for the physical cost of distributing the source code.
One of the major complaints about the GPL is that it is a viral license. Any code released under the GPL must remain under the GPL. In order to legally include GPL code in your program, you must release your program under the GPL. As an alternative, the LGPL was issued by the FSF to assuage the minds of those who generally agreed with the GNU Principles, but felt that it went a bit too far by allowing the code to included in non-GPL licenses.
The original intent of the GNU Project was to develop a complete Unix-based operating system around the principles espoused by Richard Stallman. In keeping with the freewheeling sprit of the project, GNU stands for GNU is Not Unix a subtle reference to recursion. Yet, this is in fact what the idea was to create a completely free implementation of Unix and release it as part of the GNU Project. The plan was to provide everything from graphical editors to the Unix kernel.
In that sense, the GNU project has succeeded far beyond Stallmans initial vision. As described in Table 2, there is a tremendous amount of software available for the GNU Project. The wildly popular editor GNU Emacs, which was originally written by Stallman, is released under the GPL. This project initially brought Stallmans ideas to the minds of many software developers. As claimed in the documentation, Emacs provides a free extensible, customizable, self documenting real-time display editor (GNU Emacs). However, it changed the minds of many developers into thinking that free software could be technically superior to closed software solutions.
|
GCC C/C++ Compiler |
GDB Debugger |
Emacs Visual Editor |
|
Mailman Mailing List |
GTK+ - Windowing Library |
GNU Go Game of Go |
|
CVS Version Control |
Texinfo TeX Software |
Bash Unix Shell |
However, Stallmans initial vision for a complete GNU operating system failed, albeit in a rather strange fashion. His plan called for an operating system called GNU/Hurd. It would be the culmination of Stallmans vision. All GNU/Hurd components would be completely written and released under the GPL. The GNU/Hurd project never took off, but instead another project fulfilled the GNU vision: GNU/Linux.
The Linux kernel developed by Linus Torvalds has been the most commercially successful GPL-licensed project. It has been embraced by developers and companies alike. Linux has brought the notion of free software into the mainstream. Due to the GPL, anyone can modify the Linux kernel and submit their changes back for inclusion in the main distribution. Whether or not the patch is included in the main distribution does not affect whether you may or may not legally use your changes. The extreme flexibility has allowed the Linux kernel to remain technically innovative.
There is one point that should be mentioned before we conclude discussion of the GPL - Richard Stallmans insistence that the Linux most people know should be called GNU/Linux. Stallman claims that since Linux uses GNU programs for almost every aspect of its operation (shell, compiler, libraries, etc.), people should understand the role that the GNU Project has played in Linuxs success. Without the robust toolset offered by parts of the GNU Project, the Linux kernel developers would have had to reengineer all facets of the operating system. Since the GNU Project has been so successful, Linus Torvalds and the other Linux kernel programmers can focus solely on the kernel.
The previously discussed licenses have either focused on maintaining complete control by the copyright holder, or those where the copyright holder gives up all rights to the code by making it public. The Sun Community Source License (SCSL) attempts to merge these two seemingly irreconcilable worlds. The SCSL represents a new wave of software licensing. The SCSL is in its infancy, so its success must be closely monitored to gauge the future of software licensing issues.
The SCSL was originally conceived by Sun Microsystems to further Jini, a confederation of heterogeneous appliances cooperating in a network (Jini). Jini defines the protocols by which the entities in the network will communicate. Sun needed to make this protocol public, but wished to maintain authority to maintain the integrity of the system (Gabriel and Joy). The other consideration when SCSL was developed was that the developers leveraging the Jini system might have different software licensing perspectives than Sun. Therefore, the SCSL was designed to accommodate these factors.
The SCSL is detailed in Sun Community Source License Principles by Richard Gabriel and Bill Joy. In the paper, Gabriel and Joy examine closed and open software. They find fault with both strategies, and hypothesize that there is another alternative combine the best attributes of both schools of thought. The SCSL attempts to do this in a realistic fashion. It does not attempt to be the cure-all, but rather is the first step to leverage the power of the Internet while maintaining corporate control. The SCSL itself is released under the SCSL therefore, comments and suggestions can be submitted for inclusion in future releases.
Three types of licenses are associated with the SCSL (Gabriel and Joy). Each license classification has certain associated rights that are given to the licensees. The three licenses described by the SCSL are as follows:
Research Use
Internal Deployment
Commercial Use
Research Use, the first type of license, is a bit of a misnomer because it is intended to serve as the license under which the majority of the software development occurs. As proposed, the Research Use license should be accessible via a very simple web-centric process (Gabriel and Joy). The next license classification is Internal Deployment, which serves to remove all software defects from a program by having a limited distribution. This license is usually distributed with the Research Use license. The final license type is the Commercial Use. At this point, the SCSL is no longer free, and the original copyright holder must receive financial considerations (as dictated by the copyright holder) in order to receive distribution rights.
The conditions of the SCSL allow software development to be unencumbered until the product is delivered. By delaying the financial compensation to the original copyright holder, the software developer can ensure the products success. Only when the product is at the brink of release does the copyright holder must be compensated. As listed in Figure 2, many companies have already commercially licensed Jini under the SCSL.
|
|
|
|
|
|
|
|
The first aspect of the SCSL is that all changes made to the program are the property of the new developer. The original copyright holder has no right to the new code. The SCSL allows for shared modifications, which are when changes are given back to the community. The SCSL also makes a special exemption for error corrections to the original source (Gabriel and Joy). In the event of detection of a program fault, any corrections must be given back to the community. This insures that any errors are detected and fixed and are part of the community.
The SCSL requires that the originating organization provide specifications and test suites to the community (Gabriel and Joy). The originating may also provide reference implementations. These tools allow the interfaces of a program to be well defined. With a reference implementation, the intent of the originating organization is clear. In the case of ambiguities in the interface, the reference code provides a definitive direction. The availability of reference code is an invaluable tool when using a published interface.
The licenses described in this document may not be exactly what a developer seeks for a project. The developer is then free to write a brand new license nothing prevents this from occurring. However, as a practical matter, it is best to consult legal advice to eliminate any loopholes that might be exploited by unscrupulous rivals. This new license can incorporate the best ideas of the GPL along with the best ideas of the Binary-Only license. The market is starting to support compromise licenses, such as the SCSL. Time will tell whether these principles will be successful.
On the same token, a user may not agree with the GPL and its restrictions. The user is then free to not use that product under those terms. If no other available licensing terms are available, then they cannot legally use that particular product. They may be able to use an alternative product licensed under terms that are more agreeable. At times, there are no competing products in the marketplace. Therefore, a new product must emerge.
The incredible communicative force of the Internet is crucial for bringing together people with similar goals and value systems. If developers and users both see a need and unite on the Information Superhighway, new software will be written to fill the void. If desired, new software licenses can also be written to properly articulate the intentions of the new group. In the annals of computing history, this is how things have been accomplished developers and users join forces to rectify marketplace oversights. This new wave of software licenses allows greater flexibility to both developers and end-users. In the end, these licenses will allow the developers to focus on the code and the users to focus on the functionality of the program. Therein, lies the beauty of software licenses - freedom.
BSD Advertising Retraction. University of California, Berkeley July 22, 1999. <ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change>.
FreeBSD. The FreeBSD Project. <http://www.freebsd.org>.
Gabriel, Richard P., and Joy, William N. Sun Community Source License Principles. 8 Dec 1998. <http://www.sun.com/981208/scsl/SCSLPrinciplesPublic.pdf>.
GNU Emacs. Free Software Foundation. 4 Oct 1999. <http://www.gnu.org/software/emacs/emacs.html>.
GNU Public License. Free Software Foundation. 14 Mar 2000. <http://www.gnu.org/copyleft/gpl.html>.
Jini. Sun Microsystems. <http://www.sun.com/jini/>.
Novell signs definitive agreement to buy AT&T's UNIX System Labs. AT&T 16 Feb 1993. <http://www.att.com/press/0293/930216.ula.html>.
McKusick, Marshall K. Twenty Years of Berkeley Unix. OReilly 1 Jan 1999. <http://www.oreilly.com/catalog/opensources/book/kirkmck.html>
McVoy, Larry. The Sourceware Operating System Proposal. 9 Nov 1993. <http://www.bitmover.com/lm/papers/srcos.html>.
NetBSD. The NetBSD Foundation. <http://www.netbsd.org/Misc/about.html>.
OpenBSD Security. OpenBSD. <http://www.openbsd.org/security.html>.
Raymond, Eric S. Homesteading the Noosphere. Apr 1998. <http://www.tuxedo.org/~esr/writings/homesteading/homesteading.html>.
Seltzer, Larry. Milestones in the Open-Source Movement. PC Magazine 23 Mar 1999. <http://www.zdnet.com/pcmag/features/opensource/390819.html>.
Software Licensing FAQ. UC Davis 8 Oct 1999. <http://slc.ucdavis.edu/slc/licfaq.html>.
Stallman, Richard. Copyleft: Pragmatic Idealism. Free Software Foundation 6 Nov 1999. <http://www.gnu.org/philosophy/pragmatic.html>.
Templeton, Brad. 10 Big Myths about copyright explained. <http://www.templetons.com/brad/copymyths.html>.
15 US Code. Sec. 22. 1946.
17 US Code. Sec. 107. 1976.
28 US Code. Sec. 1407. 1968.
