Proposing the BSD License for the Open Hyperdocument System

Doug has decided that an open source development process is the best way to facilitate the evolution of the Open Hyperdocument System. The next step is to choose a license.    1A  (02)

The BSD license and the GPL represent opposites ends of the open source spectrum. On the one hand, the BSD license is about as liberal as it can get, allowing unlimited use and redistribution of source code as long as there is proper attribution. The GPL, on the other hand, tries to guarantee that the source code will remain open source forever by placing restrictions on modifications and redistribution of source code.    1B  (03)

On the surface, the GPL seems to be the better license for our goals. One thing we want to avoid is for innovation to be stymied by proprietary interests. The GPL prevents source code from being hijacked into a closed, proprietary system.    1C  (04)

I will argue, on the other hand, that the BSD license is better for our goals of maximizing evolution by eliminating restrictions rather than enforcing them.    1D  (05)

The biggest myth about the GPL is that it is an anti-commercial license. The GPL does not prevent people from selling software; it prevents people from making software proprietary. The reason for this myth is that people associate anti-proprietary with anti-commercial. There is some truth to this assertion, but less than one might imagine. One could even make an argument for the GPL being commercially advantageous. Cygnus, for example, did in fact make such an argument, and it was very successful developing, selling, and supporting GPLed software for over a decade before it was acquired by Red Hat.    2A  (07)

Despite the misconceptions about the GPL, the reality is that this stigma, rightly or wrongly, exists. And because of this stigma, many companies choose to steer clear of GPLed software. This alone is not a good reason to avoid the GPL. The GPL's charter to keep software free in perpetuity seems compelling enough to adopt the license and try to correct companies' misconceptions. However, what exactly falls under the terms of the GPL can be somewhat ambiguous.    2B  (08)

The GPL states, "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." The problem is, what constitutes a derived work?    2C  (09)

The simplest examples of a derived work are when you modify GPLed source code and when you cut and past GPLed source code into your own source code. Both cases clearly constitute derived works.    2D  (010)

However, suppose you have a set of GPLed functions compiled into a library on your system. Suppose you write some code that links to this library at compile time. Is your code derived from that library?    2E  (011)

Or, consider operating systems. Most software relies on the operating system for some functionality, such as the allocation of memory. So if an operating system is GPLed, does the software that runs on this operating system fall under the terms of the GPL?    2F  (012)

Or, suppose some GPLed software has an API for extending its functionality with modules. Suppose that in order to install a new module, you must statically link the module with the software. If you write a module, is it a derivation? Now suppose that the software dynamically loads modules, meaning that the module may be compiled separately and linked to the software at run-time. Is that same module now a derivation?    2G  (013)

Unfortunately, all of the above are very real scenarios, and there are no clear answers. In some cases, authors have explicitly addressed permissible situations with their own GPLed software. For example, the Linux kernel is GPLed. However, Linus Torvalds, Linux's creator and maintainer, has said that writing proprietary kernel modules are okay, and some have done so. However, despite Linus's decree, it's not clear that this would be allowed if it were challenged in court.    2H  (014)

One of the ways Richard Stallman, the creator of the GPL, addressed this ambiguity was by creating a new license called the LGPL, or the Library GPL. This license explicitly differentiated between linking to precompiled libraries and deriving from source code. However, the distinction between the GPL and LGPL is somewhat weak, and Stallman even started calling the LGPL the "Lesser Public License" because of his dissatisfaction over its compromise.    2I  (015)

The GPL's restrictions placed on derived works, while well-intentioned, are not legally rigorous. Even so, there are many cases of derived works that are not ambiguous, and many significant open source projects use the GPL with no significant problems. On the one hand, the strength of the GPL (and all other open source licenses, for that matter) are dubious until tested by the judicial system. On the other hand, the lack of legal squabbles related to such a widely used license demonstrates that, despite its ambiguities, it seems to serve its purpose quite well.    2J  (016)

Choosing between the BSD license and the GPL often boils down to philosophy. Are you willing to restrict freedom in order to preserve freedom, or would you rather avoid restrictions altogether at the risk of future, proprietary systems derived from your work?    3A  (018)

In the case of the Open Hyperdocument System, our goal is to maximize the evolutionary potential of our software. While an open source license and effort is a prerequisite, in my opinion, for accomplishing this goal, it will not in and of itself drive this evolution.    3B  (019)

There have been situations when groups who initially wrote software under the BSD license later switched to proprietary licenses. In this situation, the source code released under the BSD license remains under the BSD license, and this code can be adopted and developed under the same terms by another group. This causes what is known as a fork, which some believe is a bad thing. I disagree with this assessment; in my opinion, evolution requires forking.    3C  (020)

What is potentially bad is that one branch of the fork results in a closed system. Forks can happen and have happened to software under both the GPL and BSD, but in the case of GPLed code, all branches stay GPLed. Now the question becomes, is proprietary software conducive to evolution?    3D  (021)

In general, I would say the answer is no, but I feel that case studies prove otherwise. Consider the following scenario. Suppose a company is deciding whether or not to use some open source software as the basis for its own software. Suppose that software is GPLed, and this company shares the aforementioned concerns about the commercial viability of the GPL. In many cases, the company is likely to choose a different route entirely, possible building a closed system from scratch. However, what if that software was under the BSD license, and the company decided to build a proprietary system on top of that software? In this case, there has been evolutionary change, and although that change is closed for the moment, it is conceivable that the change may be made freely available in the future.    3E  (022)

This is not an entirely fictional scenario. The best example of something like this happening is with BSD UNIX itself, which has been remarkably evolving for over two decades. BSD UNIX forked many times throughout its lifespan, including many proprietary branches. Indeed, most of the commercial versions of UNIX in the 1980s were based on BSD UNIX, and near the end of Berkeley's direct involvement with BSD, several of the key developers founded the company BSDI to develop and sell their own proprietary fork. However, versions of UNIX under the BSD license continued to flourish, and many of the commercial vendors continued to contribute to the free versions of BSD. Last March, BSDI merged with Walnut Creek, which employed several key FreeBSD contributors, and announced that it would start contributing to and supporting FreeBSD.    3F  (023)

Additionally, having a restrictive license does not seem to be the key reason why people contribute to open source projects. The Apache project, which uses a BSD-style license, is an excellent example of this. Several large companies, including IBM and Sun, have been active contributors to the Apache project, and have been making all of their contributions freely available, even though they are not required to do so. This is even more remarkable in the case of Sun, which has shown great reluctance with its other software to adopt such a liberal license.    3G  (024)

There are a number of other open source licenses that are worthy of consideration. Some of them, like the Apache and MIT X licenses, are essentially equivalent to the BSD license. Most of the others tend to fall somewhere between the BSD license and the GPL -- more restrictive than the former but less than the latter.    4A  (026)

The BSD license and the GPL are the oldest open source licenses, and are widely used and understood. Those are compelling reasons to weigh these licenses more strongly than others. However, the Mozilla Public License (MPL), while only two years old, has garnered quite a bit of interest because of the high profile of the Mozilla project and its relationship to Netscape/AOL, and as such deserves serious consideration.    4B  (027)

The MPL tries to ensure that modifications remain open source without being as restrictive as the GPL. The key distinction is that with the MPL, you may create "larger works" that combine code covered by the MPL with code not covered by the MPL, with each bodies of code retaining its own license. While this is somewhat less ambiguous than the GPL, and clearly makes this license more appealing to companies, it still suffers from lack of technical rigor.    4C  (028)

One interesting feature of the MPL is that it grants developers implicit licenses to any software patents that may be covered by code contributed by the patent-holder. Is this the best way to approach the problem of software patents in open source software? I'm not sure. However, it is certainly not the only way to handle software patents, and I feel that these different avenues need to be explored before we can come to any reasonable conclusion. Including patent-related clauses in open source licenses may be somewhat premature.    4D  (029)

Ultimately, I believe that these middle-of-the-spectrum licenses create restrictions that only show marginal, if any return, at the cost of increased complexity. In many of these cases, the restrictions are addressing symptoms, such as the amibguity of what constitutes a derived work, without addressing the underlying problem. These restrictions are more likely to create unintended and undesirable complications.    4E  (030)

This essay is not meant to be a closet criticism of the GPL or any other license. There are situations in which I would argue that the GPL is the most appropriate licenses, despite its deficiencies.    5A  (032)

I believe that for the Open Hyperdocument System, the BSD license will best serve our goals of facilitating the evolution of this system. It maximizes the potential community, with some risk of proprietary forks. However, the license will not be the ultimate force behind the evolution of the Open Hyperdocument System. The key to this project's evolution is how well we foster community. Community will ultimately determine the fate of this project.    5B  (033)