Now let s take a quick look at the free and open source licenses. We ll look at a few different examples that provide different aspects of licensing (from preventing commercial distribution to supporting it).
The GNU General Public License is one of the most popular licenses used in free software. The GPL provides the user with three basic rights :
The right to copy the software and give it away
The right to change the software
The right to access the source code
Within these rights is the catch with GPL software. Any changes that are made to GPL software are covered by the GPL and must be made available to others in source form. This makes the GPL unattractive from a commercial perspective because it means that if a company changes GPL software, that source code must be made available to everyone (including competitors ). This is what s called the tainting effect of GPL software. What touches GPL software becomes GPL software ( otherwise known as a derivative work, something derived from the GPL).
There also exists a variation of the GPL called the LGPL (Library GPL, or what is now called the Lesser GPL to indicate the loss of freedom). A library released under the LGPL makes it possible for proprietary software to be linked with the libraries without the tainting effect. For example, the GNU C library is released under the LGPL, allowing proprietary software to be developed on GNU/Linux systems.
Software built into the Linux kernel is automatically GPL, though differences of opinion exist in the case of kernel modules (which can be viewed both ways). The issue of kernel modules has yet to be challenged in court .
The Qt Public License (QPL) is an oddity in the open source community because it breaks the openness created by other public licenses. The QPL permits two types of licenses: a free license and a commercial license. In the free version, any software that links to the Qt framework must be opened using either the QPL or GPL. A developer could instead purchase a commercial license for Qt, which allows him to build an application using the Qt framework and keep it closed (it s not required to be released to the open source community).
From the perspective of openness, buying-out of the license makes the Qt framework less useful.
If one could identify a spectrum of licenses with the GPL on the left, the BSD license would exist on the right. The BSD license offers a more commercial friendly license because a program can be built with BSD licensed software and not be required to then be BSD licensed itself. The BSD community encourages returning modified source code, but it s not required. Despite this, the BSD UNIX operating system is as advanced, if not more so, as the GNU/Linux operating system.
The issue of the BSD license is what s called forking (two or more versions of source code existing from a single source distribution). A commercial incentive exists to fork rather than make your hard work available to your competitors. The BSD UNIX operating system has itself been forked into a number of variants, including FreeBSD, NetBSD, and OpenBSD.
The lack of distribution restrictions defines the primary difference between the BSD and GPL. GPL specifies that if one uses the GPL in a program, then that program becomes a derivative work and therefore is GPL itself. BSD has no concept of a derivative work, and developers are free to modify and keep their changes.
Many licenses exist and can be viewed at the Open Source Initiative or in reference [ gnu.org 04], which also identifies their relation to the GPL and free software.
How one defines freedom determines how one views these licenses. If freedom means access to source code and access to source code that uses the original code, then the GPL is the license to use. If freedom is viewed from a commercial perspective (the freedom to build a product without distributing any changes to the source base), then BSD is a fantastic choice. From our short list, the QPL tries to straddle both extremes. If a commercial license is purchased, then the application using the Qt can be distributed without source. Otherwise, without a commercial license (using the so-called free license), source code must be made available.
The reader is encouraged to read the available references and license resources discussed at the end of this section. Like anything legal, nothing is really black and white, and a careful review is suggested.
It wouldn t be fair to discuss the open source development paradigm without mentioning any of the problems that exist. Open source is a wonderful development paradigm, but it does suffer from many of the same problems as proprietary software development.
The early days of the GNU/Linux operating system were not for the faint of heart. Installing GNU/Linux was not a simple task, and commonly, source changes were necessary to get a system working. The operating system, after all, was simply a hobby in the early days and did not have the plethora of drivers and hardware support that exists today. New open source projects mirror some of these same issues. Early adoption can be problematic if one is not willing to get one s hands dirty. But if an application is truly of interest, just wait a few releases, and someone will make it more usable.
Documentation on any software project is one of the last elements to be done. Open source is no different in that respect. Some have claimed that the only real way to make money from open source is to sell documentation (such as what the Free Software Foundation does today, though it s also freely downloadable).
Like proprietary software, ego plays a large part in the architecture and development direction. Ego is a key reason for the failure of many open source projects, probably more than technical failings, but this is a personal opinion. Related to ego are the conflicts that can arise in open source development. One developer sees an application moving in one direction, while another sees a different path . A common result is forking of an application, which in itself can be beneficial if viewed from the perspective of natural selection.
The open source movement is filled with fanatically committed people. Phrases such as GNU Zealot and Linux Zealot are not uncommon from those on the outside. Arguments over, for example, which operating system is better mirror many of the political debates to which we ve become accustomed. The danger of fanaticism is that we don t see the real issues and focus on what s really important. One can use both Windows and Linux and lead a full and productive life. It s not an either/or argument, it s more about the best tool for the job.
Note | Many of the deeply fervent debates on open source result in arguments such as open source is better, just because it is. The argument becomes a disjunctive syllogism, such as Windows or GNU/Linux; definitely not Windows, therefore GNU/Linux. One could argue the merits of the vi editor over Emacs (or vice versa), but ultimately what s most important is that the editor does what one needs it to do. Can one operate efficiently using it? From personal experience, engineers are aghast that someone would use such an editor as vi. But if one can edit as efficiently in vi as in any other editor, why not? Personal preference definitely plays a part in the use of open source software. |