The chief distinguishing feature or unique value of Free or Open Source software lies in the licenses under which it is offered. All parties in the software industry, whether on the Open Source side or the proprietary side, support the idea of copyrighted software, and of licenses to control the transfer of those rights in copyright to second and third parties. There are over a dozen licenses in general use in the Open Source software market, and a further couple dozen have been invented, although they are not widely used. Some are tightly crafted by lawyers, and others would make a lawyer laugh. All of them seek to provide just the right measure of freedom and control that accords with the licensors’ ideology and (in some cases) business purposes. Unfortunately, the licensing theorists disparage the experiments of the pragmatists, while proposing subtle refinements that serve to discourage business people.
The licenses themselves reflect the engineering minds of the developers who wrote most of them, and employ varying degrees of precision and shades of subtlety in differentiating themselves from all the other licenses. Some licenses cause unforeseen (but perhaps not unintended) problems for users and developers, and poorly written ones protect no one. In Open Source software, licensing dependencies have become as important to watch as software dependencies (see Chapter 7, "Unforeseen Complications of Open Source Licensing: Forking and Licensing Dependencies").
A number of large companies have joined the hunt for the perfect license. Netscape was the first, with its Mozilla Public License (MozPL), and Sun Microsystems now releases source code for several products under its Sun Community Source License (SCSL). More recently, IBM published its IBM Public License 1.0 (IBM PL).
Any business opened in the Open Source marketplace needs to understand the licenses in use, and in particular the licenses that affect its own business, whether that business is software development, sales, or support. This chapter will discuss and compare the most important licenses; the texts of some of the licenses are in Appendix A, "Public Software Licenses."
Independent software vendors (ISVs), like any other business, want to recover their investment in development costs, cover current expenses, and make a profit. Because software is so easily propagated, the most effective means to control its dissemination are legal, not physical. The actual right of ownership in software is traditionally established through copyright, partly by tradition and convenience, and partly because the short life of software technologies rarely justifies the large cost of obtaining a patent on it.
Any author’s expression of an idea is automatically copyrighted, whether published or unpublished, regardless of whether the authors mark it as such or take the small trouble to register the copyright. Authors or vendors who take the disposition of their software seriously will both mark it as copyrighted and register that copyright (http://lcweb.loc.gov/copyright/); the registered copyright owner’s case will be stronger in any eventual court appearance regarding its ownership.
The copyright itself confers a bundle of rights (so-called, to emphasize that they are separable according to the choices of their owner), which include three that are crucial to software: copying, distribution, and preparation of derivative works. The rights to display and to perform the work in public apply more to music and representational art than to software, but it is conceivable that someone could violate Microsoft’s copyright of Flight Simulator by charging admission to watch fly-throughs, thus publicly displaying and performing the work.
Software vendors want their customers to possess and use the copies they have purchased, but vendors also have a financial interest in limiting the users’ rights to copying, distribution, and preparation of derivative works. So the user’s rights must be carefully defined, according to the purposes of the copyright holder. Yes, you may make a copy, but only one copy solely for backup; or, Yes, you may make three backup copies. No, you may not distribute any copies whatsoever. Yes, you may make derivative works, but only in the sense that the data you prepare in the program’s proprietary format is derivative. No, you may not decompile the code, make improvements, and pass on the results to other persons, even if you use only a little of the original code, and charge nothing for copies of the new program. Only a carefully worded license will achieve the goals of the vendor.
The GNU GPL does not warrant in any way the software it covers; the user simply receives it "as is." Anyone who wishes to, however, is free to sell warranty coverage. All the Open Source licenses disclaim warranty and liability, including for incidental damages. This practice is not really different from the usual shrinkwrap license, which does not offer more than return of the money paid by the customer.
In Open Source software, which generally allows copying, distribution, and modification, the license is even more critical, since passing along the bundle of rights is not meant merely as conferral of them on the next party, but as a restriction of those rights down the line through successive parties. Prof. Pamela Samuelson of the University of California at Berkeley points out that a license is not simple contract law, which binds only the actual parties to the agreement, but that licenses borrow from real estate law, under which third and successive parties are bound to a contract they had no part in originally making. Thus a piece of land may have its use restricted according to the original deed of sale, taking the form of a restrictive covenant on the land.
The GNU General Public License (GPL) of the Free Software Foundation (FSF) is the most venerable of the public licenses. Respected for its avowed determination to make all software free, its chief fame is that Linus Torvalds put his Linux kernel under its protection, making it possible for the many contributors to that project to know that their code would remain free for anyone to use, modify, and distribute.
The Linux kernel, in fact, was built largely by tools licensed under the GNU GPL, and the complete Linux operating system consists of many GNU GPL-licensed utilities and applications. The GNU GPL itself often serves as a reference point for discussion of Open Source licenses and makes a good place to begin.
Because freedom for software and its users is the aim of the Free Software Foundation, the GPL, as it is commonly called, places no restrictions at all on most of the rights belonging to copyright. Most importantly, there is no restriction on use, and public display and performance are likewise unfettered. Just as the owner of the software program or code has copyrighted the work to provide it maximum protection, "copylefting" the code under the GPL places strict licensing terms on copying, modification, and distribution of the software. Derivative works are left uncovered, unless the output is a work based on the program. The following sections take these points in order.
Copying and Distribution
There is no restriction on copying and distribution so long as the following conditions are met:
* The source code must either be provided or made easily available to the user.
* The text of the GNU GPL and all notices referring to it must be copied and distributed along with the software, as well as the copyright notice(s) and disclaimer of warranty, unless the distributor provides a warranty.
* Interactive programs must display the notices at startup.
The distributor may charge for the distribution service, and for providing warranty service; this concession to commercial activity shows that the FSF is concerned with the free propagation of source code, and is not hostile to commercial activity per se in connection with Free Software.
Modification and Derivative Works
Anyone may modify the software, but may distribute the modifications only with a notice of what these are, who made them, and when. The modifications must be distributed under the GPL.
The license specifically states that certain output from programs will not be considered derivative works requiring use of the GPL for their distribution: binary output from a GPL-protected compiler or data organized by a GPL-licensed database would be examples of this exemption. Derivative works are any works containing code already covered by the GPL; these can only be distributed under the GPL. Developers must be careful, however, in how they combine GPL-protected code with code under other licenses. (This is discussed further in the upcoming "The ‘Viral’ or ‘Contaminating’ Effect" section).
The hand of an attorney is clearly visible in the closing provisions of the GPL. Third parties who receive the software are considered to have received direct licenses under the GPL. A person who modifies the code may distribute it only under the GPL. The only rights any licensee has are granted in the GPL, and not adhering to the license both terminates the license and is a violation of copyright, which is actionable in court. The termination of a license in the case of one offender does not terminate the licenses of those who received the software from the offender, provided the recipients are in compliance with the GPL. Finally, any copying, modification, sublicensing, or distribution of the software may not take place except under the terms of the GPL.
The GNU GPL has been successful in all its aims. Although the license has never been tested in court, the Free Software Foundation has managed to force every poacher either to back off or to adopt the GPL. The pressure applied consists not only of the threat of copyright suit, but also of the bad publicity attendant on trying to steal the intellectual property of the nonprofit FSF. On the advice of counsel, the Foundation requires that the copyrights to improvements to GNU code be signed over to it before they are incorporated in releases of Foundation software. The concentration of ownership maximizes the standing of the Foundation as the aggrieved party in a lawsuit, as opposed to the collective complaints of hundreds of developers. Linus Torvalds, on the other hand, allows developers to retain their own copyrights in the code submitted to and adopted into the Linux kernel.
Note that just as a developer can hold a copyright on the code and distribute it under the GPL, it is also possible to distribute the code in other ways under other licenses at the same time. The developer could license the code on an OEM basis to a large software firm for incorporation into other software, or even for distribution as a separate product, and still put it out as Open Source software under the GPL. If the developer, however, later incorporates improvements that users have contributed under the GPL, those improvements not only remain under the GPL, but cannot be issued under any license other than one approved by their copyright holders. Thus, although it is theoretically possible for the original developer who likes a certain GPL modification to obtain permission of the contributing copyright holder to distribute the software under a commercial license, the practical effect is to discourage such mixed licensing arrangements owing to the difficulty of securing permission for all the improvements that need to be incorporated in improving the original code. This is an example of what some call the "viral effect" of the GPL.
The "Viral" or "Contaminating" Effect
The unpleasant terms, "viral" and "contaminating," describe what the Free Software Foundation prefers to see as a "liberating" effect. The GPL’s terms prevent the incorporation of GPL’d code into software that is not under the GPL. The net effect is to steadily increase the amount of Open Source software made available as developers prefer to take advantage of GPL’d code in building their own products. This situation, while a boon for Open Source, continues to be misunderstood by the business world. The most common myth is that getting too close to GPL’d software will cause proprietary software to be lost forever to its owners. Actually, it takes the compilation of GPL’d software with other software to require that the resultant derivative product be distributed under the GPL. There is no obstacle to distributing GPL’d software on the same disk with proprietary software. Some companies fear that if an employee picks up any GPL’d code into their proprietary product, the company will be forced to GPL the entire product. Worse, they fear that if an employee takes a company’s proprietary code and contributes it to a GPL project, the company will not be able to recover it.
These are false fears. An employee who steals property and then brings it to his or her company to use does not make the company liable for his or her actions, nor does an employee who steals company property and pawns it make it impossible for the company to recover its property. In both cases the employee has acted against company policy, and does not have the power to commit the company to his or her unlawful course of action. In all the cases above, the stolen property must be returned to its lawful owners. Companies need to be aware, however, that when they accept GPL’d improvements to their GPL’d software they cannot issue those improvements under a proprietary license without the copyright holders’ permission.
Somewhat more legitimate are the fears that somewhere in Linux there may be code that is actually someone’s property, and which will be someday detected and reclaimed, crippling Linux systems around the world. There are in fact responsible persons who claim to know of such cases, and who believe that the copyright holders are merely biding their time to cause trouble. Linux fans, on the other hand, point out that Linux consists of many small packages or files of code, and that any offending code can be rewritten to remove copyright concerns. These Linux defenders allay the even greater fear of patent infringement in the same terms, saying that a workaround is always possible. The super confident believe that any challenge will only be a desperate act by the hidden hand of a weakening Microsoft, unable to resist Linux in any other way.
The Perpetuity Effect
Some cautious companies apparently fear the GNU GPL because it does not provide a perpetual right to the license. Sam Byassee, a partner at Smith, Helms, Mullis & Moore, suggests that these fears are groundless. A termination of the license of one licensee does not terminate the licenses of the others, provided they are not violating the provisions of the GPL. Further, he believes that an argument in equity may be made that an arbitrary "ability to terminate (or revoke) is antithetical to the purpose and intent of the GPL."
Richard Stallman actually provided a workaround for the "viral" problem by issuing some software under the Library General Public License (LGPL). Stallman has always been uncomfortable with this stepchild of the Free Software Movement, and has recently taken to calling it the Lesser GPL, while urging people not to use it. The original purpose was to spread the popularity of the GNU C libraries by allowing proprietary products to make calls to them, showing that Stallman understands the value of market penetration in the early days of a product. Lately, he believes in using the attraction of the unique properties of some of the GNU libraries such as Readline to compel proprietary software to accept the GPL to use those libraries.
Under the LGPL, the key to the use of proprietary code with GPL’d code is that they not be compiled together, or statically linked. They may instead be dynamically linked; that is, software under one kind of license may make calls to the application programming interface (API) of software distributed under the other kind of license. This way the GPL’d and proprietary software may work together, keeping their separate places and licenses. Some will argue that there is no legal distinction between dynamic and static linking, but the past declarations of Richard Stallman and the customs of the community have laid out the current practices of this useful symbiosis, and it has provided the model for more than one sort of mine-and-thine license down the path of Open Source.
Stallman’s growing reservations concerning the use of the LGPL stem from recent changes in technology that increase the complexity of copyright enforcement congruent with GNU licenses. Object-oriented technologies such as CORBA (Common Object Request Broker Architecture) allow the mixing of software components without compiling them together, further muddling the already shaky distinction between dynamic and static linking.
The kernel-loadable module has its origins in the need to add hardware devices to a system without having to recompile the kernel. The problem is solved by having the kernel load a module that carries a list of function names and virtual addresses for these, so that the kernel can make calls to the device driver and manipulate the device (such as a printer, sound card, or graphics card). These modules are in binary format (that is, compiled to work on the system); if they are Open Source software, the source code is available or shipped with the drivers. Linus Torvalds holds that this dynamic linking — the loading of modules into an already-compiled kernel — is covered by the LGPL, making it possible to use proprietary driver software from companies that wish to protect the secrets of the workings of their devices. Although Stallman does not approve of this solution (because his legal advisors tell him there is no distinction between static and dynamic linking), he concedes that the copyrights in question are not his, and that he has no say in the matter.
Kernel-loadable modules have done much to extend the reach of Linux to cover many hardware devices, because of the ability to use non-Open Source software drivers.
Concerned that the antibusiness ideology of the Free Software Foundation was a barrier to interesting the business community in Linux and other source-available software, a group of leaders in what came to be called the Open Source Community met in February 1998 to discuss the situation. The immediate occasion was the recent announcement of Netscape that the source code for their Communicator product, particularly the Navigator browser portion, would soon be available to developers for free. Christine Peterson of the Foresight Institute suggested the group use the term Open Source software in place of Free Software, and the Open Source Initiative (OSI) was born.
As part of its effort to reach accommodation with the business community, the OSI drew up the Open Source Definition (OSD), a guideline to the principles underlying Open Source software licensing. The original document was taken from Bruce Perens’ "Debian Free Software Guidelines [http://www.debian.org/social_contract.html], which stated the principles underlying the distribution of the Debian version of Linux (Debian GNU/Linux). The original intent was to copyright the term Open Source, and to certify licenses as Open Source licenses, but the plan proved not to be practical. As a result, the OSI lists certain licenses as "approved," and it also certifies software as being distributed under an Open Source license.
The first difficulty the OSI faced was the wide range of licenses claiming to be Open Source — some of these will be discussed shortly. As a result of the latitudinarian attitude of the Open Source Initiative towards some of the licenses offering themselves as Open Source, Bruce Perens resigned, stating that the OSI had come too far from the principles of the Free Software Movement. Perens is now back in the Stallmanist camp.
The document he left behind, "The Open Source Definition," is now in its seventh revision, and provides a guide to the principles of the OSI. There are a wide variety of organizations with licenses that consider themselves Open Source operations; that is, they make source code available and then set rules governing its use. So far the OSI has approved few licenses and gives no indication of whether this lack of approval stems from limited resources, lack of application by some license authors, or from quiet rejection of some licenses. Because of the broad range of terms of licenses approved by the OSI, there is little to be gained from our examining licenses in terms of their conforming or not to the OSD. It is important, however, that the GNU GPL and LGPL are approved by the OSI, as are the BSD (or X) style licenses, the Mozilla and Netscape Public Licenses, and the IBM Public License.
If you are leading an Open Source project, it is usually best to pick a well-known license and use its terms. This will save people from the trouble of having to read a new license and then figure out how it will fit with software distributed under other licenses. Unless a new license (or a variant on a familiar one) is done with great care for a particular purpose, it is more likely to be a hindrance to the project’s acceptance. The licenses described in this section have been successful in protecting and promoting the software they cover; it is more than likely that one of them will suit your purposes.
The BSD-Type or X-Type Licenses
When AT&T was broken up by court order, the company undertook an evaluation of all its assets. One of these was the UNIX operating system, popular in universities and research institutions because its cost was low or free, its source code available, and because AT&T was willing to incorporate improvements sent in from all over the world. When AT&T set a high monetary value on UNIX, resulting in their charging large sums of money for a source license, this happy symbiosis came to an end. The sudden disappearance of UNIX source code from the universities particularly rankled programmers because they felt they had developed much of the code for which AT&T was charging such a high price. The resulting movement to clone UNIX centered on the University of California at Berkeley, and thus the Berkeley Software Distribution (BSD) was born.
BSD has a distinguished history, and at this time is probably a stronger and more scalable operating system than Linux. One of the reasons for the rapid growth of Linux was that AT&T tied up BSD in lawsuits for several years, causing some users to fear for its survival. Having successfully purged all AT&T code from its system, BSD today powers such large sites as Yahoo!, and was the basis for the original Sun operating system.
Sun’s ability to take the BSD source code and turn it into proprietary, binary-only software depended on the very liberal BSD license, of which a number of variants exist, such as those covering FreeBSD, OpenBSD, and NetBSD. These licenses originally varied from the Massachusetts Institute of Technology (MIT) X license (MIT X license), which was developed to cover the X Window graphics system (variants of the MIT X license include the XFree86 and XOpen licenses) by requiring the mention of copyright holder(s) in advertising and other locations, but even that restriction has fallen by the wayside. The FreeBSD license, for example, is short; apart from the disclaimers, the longest of which disclaims warranty, the relevant terms are:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Cross-ReferenceFor the complete text of the disclaimer mentioned in the extract, see Appendix A, "Public Software Licenses."
Any recipient of one of the BSD distributions is entitled to take the code, modify it, and to distribute it in either source or binary form; many software vendors choose this type of license because it allows distribution of binary-only versions. Unlike the GNU GPL, there is no programmatic statement of agenda in the BSD-type licenses; BSD providers state that their object is simply to see that the software is distributed as widely as possible, and that no person or endeavor is restricted from using, distributing, or even selling it. The result is that Linux contains helpings of BSD code, as do Windows NT and the new Apple operating system, Mac OS X.
The Open Source Initiative approves BSD- and X-type licenses because the original distributor makes the source code available, and does not prohibit modification or further distribution. The license also allows the making and free distribution of derivative works. Although there are many critics of the binary-only privilege, nevertheless these distributions still receive voluntary modifications from developers, who hope the BSD distributor will incorporate the modifications and thus spare the developer the burden of individually supporting them. Because the BSD distributions themselves always include source code, developers don’t believe their contributions will be subsequently unavailable to them.
The Netscape Public License
The Netscape Public License (NPL) covers the source code that Netscape released for its Communicator product, material referred to in the NPL as the "Covered" code. Part of the delay in releasing this code was the time it took either to drop third-party proprietary code from the package, or to secure distribution rights for that software. Further hindrances to immediate release were the sharing of some code between Communicator and Netscape’s server products that remained proprietary, as well as the existence of obligations to supply source code to third parties for inclusion in proprietary products. Choosing the GNU GPL would have negated the value of exporting code for the community to improve, because the GPL would have prevented the contributed improvements from being used in proprietary products.
Accordingly, Netscape devised a pragmatic license that would protect their proprietary interests while allowing the incorporation of contributed code, and at the same time enable outside developers both use of the source code and protection for their own proprietary technology. The NPL gives Netscape special privileges in the Covered code for a limited time. By that time the company will have reengineered its proprietary server products so that they will either no longer be dependent on the Covered files, or will use them on the same terms as everyone else. Netscape will then retain only one other special right: that of distributing Covered file code to those customers whose contracts provide for their receiving this client-side code for use under non-NPL terms in proprietary products.
Netscape’s released client-side code, called collectively Mozilla, consists of several files, each of which has a header stating its licensing terms: the NPL. Developers can make modifications to these Covered files and distribute them as they please, provided they include the source code for the modifications (it need not be the source code for the entire modified file). The modifications will probably consist of either bug fixes or extensions to the application programming interface (API) that add functionality to the product. Thus bug fixes and improvements to the Covered code are required to be turned back to the community once these changes are distributed outside the developer’s organization.
New code, however, may remain proprietary; it might, for instance, be libraries called by the new API functions inserted in the Covered code as modifications. These new files in the distribution may have their source code included — or not — as the developer chooses. The choice of binary-only distribution and the licensing is up to the developer. But the developer who wishes to contribute them to the Mozilla community can place a header in the files stating that they are distributed under the Mozilla Public License, and include the source code.
The Mozilla Public License
The Mozilla Public License (MozPL) is just like the Netscape Public License, except that it includes no special privileges for Netscape. The MozPL makes it simple and easy for proprietary and Mozilla software to work and be distributed together while protecting the openness of the Mozilla code by requiring that further redistribution of it be under the terms of the MozPL.
As an example of how the Covered code and proprietary code could work together, the developer could modify Covered code to call added binary or proprietary software and disclose only the changes to the Covered code needed to enable these calls. The developer’s own software that is called by the changes in Mozilla can remain private.
Although the basic concept is simple, the twin licenses add complexity as they add flexibility. Because of potential copyright and patent problems, the license requires that a text file, LEGAL, accompany all distributions of Mozilla code. This file must contain notices and details concerning all software that is subject to intellectual property claims by third parties, including patented software. For this reason, every developer who works with Mozilla software — and particularly with derivative software — must pay attention to the other licensing involved, and to the resulting licensing dependencies.
The GNU GPL allows a developer to issue new source code under a particular version of the license, and optionally to allow the code to be distributed under "any later version." A user who receives GPL’d code with no version number specified may pass it on under any version of the GNU GPL. The NPL/MozPL, on the other hand, allows users to choose whether to use received code under the license version that covered it when received, or to choose instead to use any later version of the license. Over time, this will be another area that will need watching.
If the GNU GPL is the product of careful lawyering to impose absolutely the will of the Free Software Foundation on Free Software and to force the liberation of as much other software as possible, the MozPL is the result of careful consultation among business managers, lawyers, and the Open Source community to balance the interests of all parties. MozPL language regarding arbitration, termination, breach, cure, and named jurisdiction for litigation sounds like other business contracts. The MozPL pays particular attention to possible patent infringement claims, and includes the provision that if any licensee brings an infringement suit against any contributor to Mozilla, that licensee’s license in Mozilla and in any patented software of the defendant are subject to termination, with the further provision that anyone who has received Mozilla software from the plaintiff shall continue to hold valid licenses as received from both the plaintiff and the defendant, as appropriate.
Although the MozPL cannot prevent patent infringement suits from outside the Mozilla community, the focused weapon of license termination should discourage such suits originating within the community, and reflects the Open Source community’s aversion to software patents of any kind.
The IBM Public License
Just as Netscape’s MozPL showed that a large commercial software vendor was willing to experiment with the benefits of Open Source licensing and development, the size of IBM makes the issuing of its Public License an even louder and more public endorsement. Like the MozPL, the IBM Public License (IBM PL) separates the code into two types: Contributions (the original IBM-supplied code and that added to it from other contributors), which must be offered with source code, and other — proprietary — software, provided it is in separate modules and is not derivative or a modification of contributor code.
The IBM PL handles potential patent problems in a manner similar to the MozPL: Each "Contributor" grants all users ("Recipients") licenses for the Contributor’s patented software, which is included in the Contributions. This licensing does not include the right to use the patented software except with the Contributions. If any Recipient brings any software patent infringement suit against any Contributor, the Recipient (but not users downstream from the Recipient) automatically suffers termination of patent licenses of the Contributions as of the date of the suit.
The Sun Community Source License
The best-known Sun license is the Sun Community Source License (SCSL), which has reaped so much criticism from the Open Source Community. Critics should notice that Sun is feeling its way along in Open Source matters, and that the company recently issued a basic version of the Forte tool under a recognized Open Source license. Sun distributes Forte for Java, Community Edition, under the Mozilla Public License (MozPL). The SCSL, however, continues as the license for picoJava and some other Sun products, most notably for Java itself.
IBM and Mozilla/Netscape, although they are not full Copyleft licenses, at least represent an accommodation to the Open Source community. IBM learned from studying the Netscape licenses and produced its own, only half as long; Sun, on the other hand, produced its own attempt at an Open Source license, twice as long as the Mozilla/Netscape document. The length and obscurity of the SCSL make it difficult to be clear about all its provisions. The version for Java source code, SCSL 2.3, contains many provisions that tightly control the code and its distribution.
The chief restrictive differences of the SCSL from the MozPL and the IBM PL are the SCSL requirement of royalties for any deployment, including internal, and the positive duty to return to Sun any error corrections, whether distributed or not, made in the source code, as well as to report any errors found in the specification. Developers may keep private their modifications to the source code and distribute only binaries, but Sun encourages them to share their source code. Persons who develop implementations of the Java specification for internal use will still have to pay royalties to Sun as if they had used Sun’s code. The lowest level of license is free, and is for research only; any modification in the source code requires the use of the Technology Compatibility Kit (TCK) for testing to ensure that Java functionality remains unbroken by the developer’s changes. It is unclear whether the purchase of a paid support contract is necessary to obtain the TCK. The sort of pilot implementation that many developers would regard as part of testing seems to fall under the Deployment category for Sun, requiring paid support and licenses. Finally, it appears from the SCSL that no one would be able to start a third-party business to provide Java Development Kit (JDK) support.
The extreme retentiveness of the SCSL is probably a result of the company’s experiences with Java forking; on the positive side it reflects Sun’s strong interest in compatibility testing, which it promotes for Solaris by giving away binary compatibility testing tools to anyone who asks.
Even after they understand the provisions of the GPL and how it is applied in practice, businesspeople always ask one question: Is the GPL, or for that matter, are any of the other licenses in the Open Source world, enforceable? Do they have any standing in law?
The short answer is that the GPL is enforceable, but only by virtue of its leaning on copyright law. The license grants no rights in copyright to a violator of the GPL, effectively stymieing copying, modification, and distribution of the copyrighted software. But since the license is enforced by the roundabout means of a copyright suit or a threat to sue, the question follows: Does the license itself have any validity?
Under current commercial codes, as interpreted by courts, the answer is generally no, for several reasons. First, the courts frown on licenses associated with products that are part of mass commerce (Pamela Samuelson points out that Edison shipped his phonograph cylinders with licenses, and that these were held to be invalid). An individual license negotiated between parties is one matter; one that is the same for everyone and comes with every copy of the product will find that it takes a back seat to the laws of the marketplace. A seller takes his goods to market and exposes them for sale; the buyer agrees on a price with the seller and takes the goods away. The transaction is ended. A license that is accessible only after breaking the shrink-wrap on the box is a one-sided amendment to the terms of sale agreed on between buyer and seller, and not considered binding.
There is a further licensing problem, taken up in the GNU GPL, but ignored in some of the other Open Source licenses: the binding of third parties who were not part of the original license agreement. The GPL is careful to state that with each transfer of the software according to the GPL, there comes a direct license from the copyright holders (licensor) to each recipient. Although this provision is probably unenforceable by the courts, the Free Software Foundation has taken every legal care to make the GPL as strong as possible.
The question of whether the GNU GPL and other Open Source licenses are legal cannot be given a simple answer. Steve H. Lee, a student at Harvard Law School, has produced an extensive study of Open Source licensing, and shows how to construct a legal case for their legality, using both precedents and interpretation of the law. Unfortunately this study has not been published. Lee believes that Open Source licenses are enforceable as a matter of contract law, and cites some evidence to that effect. Whether his arguments would carry in every court is another matter.
There is a change in the wind, however, that might give Open Source licenses more standing in court. The changes to the Universal Commercial Code originally proposed as UCC Article 2B have undergone rewriting and emerged as the model Uniform Computer Information Transactions Act (UCITA; see Chapter 14, "Intellectual Property"). The general effect of the Act when adopted would be to tighten intellectual property law with regard to software, and as a result give standing to shrink-wrap licenses. This change would automatically give standing to Open Source licenses as well.
That’s the good news. The bad news is that UCITA has been rejected by an original sponsor, the American Law Institute (ALI), as a murky work that will come into conflict with current federal copyright law. Although rejected by the ALI, UCITA has nevertheless been approved by the National Conference of Commissioners on Uniform State Laws, and will now begin, state by state, to seek legislative adoption across the land.
You now have a sense of the legal issues of the various Open Source licenses. Some of these licenses can be used together. For instance, the GNU GPL can take in BSD code with no problem, but distribution of the final product must be only under the GNU GPL. The NPL/MozPL and IBM PL were all devised to enable Open Source code and proprietary code to work together. The next chapter will deal further with this issue of license interaction, or licensing dependency.
Next chapter: Complications of Open Source Licensing
Table of Contents
Copyright © 2000 by IDG Books Worldwide, Inc. Published under IDG Books Worldwide, Inc. Open Content License.