Introduction

In recent years, there is a strong movement for open source licensing. There are a whole variety of open source public licences. The term “open source” commonly refers to a software program or set of software technologies that are made widely available by an individual or group in source code form for use, modification and redistribution under a licence agreement. Open source licensing has been commonly used in connection with large-scale commercial-quality software projects in recent years. This is partly due to the Internet as it has helped make it more cost effective and efficient for programmers to collaborate on development projects and distribute software among themselves and to customers. Examples of such open source software are GNU/Linux, OpenOffice, Apache Web Server and many many more.

Characteristics of Open Source Licences

The generally accepted definition of open source found in http://www.opensource.org doesn’t just say that the software must be distributed with its source code. The distribution terms of open-source software must comply with the following criteria:

1. Free Redistribution – The licence shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The licence shall not require a royalty or other fee for such sale.

2. Source Code – The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost; preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

3. Derived Works – The licence must allow modifications and derived works, and must allow them to be distributed under the same terms as the licence of the original software.

4. Integrity of The Author’s Source Code – The licence may restrict source-code from being distributed in modified form only if the licence allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The licence must explicitly permit distribution of software built from modified source code. The licence may require derived works to carry a different name or version number from the original software.

5. No Discrimination Against Persons or Groups – The licence must not discriminate against any person or group of persons.

6. No Discrimination Against Fields of Endeavour – The licence must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of Licence – The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional licence by those parties.

8. Licence Must Not Be Specific to a Product – The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s licence, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. Licence Must Not Restrict Other Software – The licence must not place restrictions on other software that is distributed along with the licenced software. For example, the licence must not insist that all other programs distributed on the same medium must be open-source software.

10. Licence Must Be Technology-Neutral – No provision of the licence may be predicated on any individual technology or style of interface.

History of Open Source

In the early days of computing (around 1945 to 1975), computer programs were often shared among developers. An important event during this period was the ARPAnet, the predecessor of the Internet. Another critical development was the operating system Unix, developed by AT&T researchers, and distributed as source code (with modification rights) for a nominal fee. However, as years progressed, and especially in the 1970s and 1980s, software developers increasingly closed off their software source code from users. This included the Unix system itself; many had grown accustomed to the freedom of having the Unix source code, but AT&T suddenly increased fees and limited distribution, making it impossible for many users to change the software they used and share those modifications with others.

Richard Stallman, a researcher at the MIT Artificial Intelligence Lab, did not like the closing of software source code. In 1984 he started the GNU project to develop a complete Unix-like operating system which would be Free Software (meaning freedom and not price – in his words “as in free speech, not as in free beer”). In 1985, Stallman established the Free Software Foundation (FSF) to preserve, protect and promote Free Software. The GNU project developed many important software programs, including the GNU C compiler (gcc) and the text editor emacs. A major legal innovation by Stallman was the GNU General Public Licence (GPL), a popular open source software licence. However, the GNU project faced difficulties in developing the free operating system.

Meanwhile, the University of California at Berkeley started efforts to rewrite many Unix components and eventually managed to create a nearly-complete system whose source code could be freely released to the public without restriction. Soon a number of operating systems were developed based on this effort. Unfortunately, these operating systems were held under a cloud of concern from lawsuits and counter-lawsuits for a number of years. Another issue was that the licence used, the BSD Licence, permitted companies to take the code and make it proprietary. Thus companies such as Sun and BSDI did so – continuously siphoning developers from the openly sharable code, and often not contributing back to the publicly available code. Finally, the projects that developed these operating systems tended to be small groups of people who gained a reputation for rarely accepting the contributions by others. The descendents of this effort include operating systems like NetBSD, OpenBSD, and FreeBSD. Proprietary variants of these include Apple’s Mac OS X and Sun’s Solaris.

In 1991, Linus Torvalds began developing a small operating system kernel called “Linux”, at first primarily for learning about the Intel 80386 chip. Unlike the BSD efforts, Torvalds eventually settled on the GPL licence, which forced competing companies working on the kernel code to work together. Advocates of the BSDs dispute that this is an advantage. However today, major Linux distributions hire key kernel developers to work together on the common Linux code. Contrast this to the corresponding commercial companies in the *BSDs effort which often do not share their improvements to a common program. Torvalds made a number of design decisions that in retrospect were remarkably wise: using a traditional monolithic kernel design (instead of the “microkernel approach” that slowed the GNU project), using the Intel 386 line as the primary focus, working to support user requests (such as “dual booting”), and supporting hardware that was technically poor but widely used. And finally, Torvalds stumbled into a development process rather different from traditional approaches by exploiting the Internet. He publicly released new versions extremely often (sometimes more than once a day, allowing quick identification when regressions occurred), and he quickly delegated areas to a large group of developers (instead of sticking to a very small number of developers). Instead of depending on rigid standards, rapid feedback on small increments and Darwinian competition were used to increase quality.

When the Linux kernel was combined with the already-developed GNU operating system components and some components from other places (such as from the BSD systems), the resulting operating system was surprisingly stable and capable. Such systems were called GNU/Linux systems or simply Linux systems. Note that there is a common misconception in the media that needs to be countered here: Linus Torvalds never developed the so-called “Linux operating system”. Torvalds was the lead developer of the Linux kernel, but the kernel is only one of many pieces of an operating system; most of the GNU/Linux operating system was developed by the GNU project and by other related projects.

In 1996, Eric Raymond realized that Torvalds had stumbled upon a whole new style of development, combining the sharing possibilities of open source with the speed of the Internet into a new development process. His essay “The Cathedral and the Bazaar” identifies that process, in a way that others could try to emulate the approach. The essay was highly influential, and in particular convinced Netscape to switch to an open source approach for its next generation web browser.

In spring of 1997, a group of leaders in the Free Software community gathered. They were concerned that the term “Free Software” was too confusing and unhelpful (for example, many incorrectly thought that the issue was having no cost). The group coined the term “open source” as an alternative term.

Major Unix server applications (such as the Apache web server) were easily moved to GNU/Linux or the *BSDs, since they all essentially implemented common standards. As a result, GNU/Linux and the *BSDs rapidly gained significant market share in the server market. A number of major initiatives began to fill in gaps to create completely open source modern operating systems, including graphical toolkits, desktop environments, and major desktop applications. In 2002, the first user-ready versions of capable and critical desktop applications (Mozilla for web browsing and OpenOffice for an office suite) were announced.

Major Types of Open Source Licences

There are many types of open source licences, but the vast majority of open source software uses one of the four major licences: the GNU General Public Licence (GPL), the GNU Lesser General Public Licence (LGPL), the MIT (aka X11) licence, and the BSD-new licence. These 4 licences as often referred to as the classic open source licences. The GPL and LGPL are termed “copyleft” licences, that is, these licences are designed to prevent the code from becoming proprietary. A short description of each of these licences are as follows:

1. GNU General Public Licence (GPL) allows anyone to use the program and modify it, but prevents code from becoming proprietary once distributed. Modifications to the software must also be distributed under the GPL. The use of proprietary programs with GPL programs are restricted under GPL.

2. MIT and BSD-new Licences let anyone do almost anything with the code except sue the authors. There are actually two “BSD” licences, sometimes called “BSD-old” and “BSD-new”; new programs should use BSD-new instead of BSD-old licence. There is a major shortcoming of the BSD-old licence, it allows for codes already released under BSD-old licences to be ‘converted’ into proprietary software.

3. GNU Lesser General Public Licence (LGPL) is a compromise between the GPL and the MIT/BSD-new approaches, and was originally intended for code libraries. Like the GPL, LGPL-licenced software cannot be changed and made proprietary, but the LGPL does permit proprietary programs to link to the library, like the MIT/BSD-new licences.

Contrary to popular belief, all of these licences (the GPL, MIT, BSD-new, and LGPL) permit the commercial sale and the commercial use of the software, and many such programs as sold and used that way.

Benefits of Open Source

Open Source proponents cite the following as the benefits of Open Source:-

1. Reliability: The Open Source community generally responses quickly to fix bugs and problems identified by users. This explains in part, why such programs have such an edge in reliability; if problems are found, they’re often fixed. Even more intriguingly, the person who spearheaded ensuring that these problems were fixed wasn’t an original developer of the programs – a situation only possible with Open Source.

A possible explanation is that the open source model encourages several behaviors that are uncommon in the development of commercial code. First, many users don’t just report bugs, as they would do with proprietary software, but actually track them down to their root causes and fix them. Second, many developers are reviewing each other’s code, if only because it is important to understand code before it can be changed or extended. It has long been known that peer review is the most effective way to find defects. Third, the open source model seems to encourage a meritocracy, in which programmers organise themselves around a project based on their contributions. The most effective programmers write the most crucial code, review the contributions of others, and decide which of these contributions make it into the next release. Fourth, open source projects don’t face the same type of resource and time pressures that proprietary projects do. Open source projects are rarely developed against a fixed timeline, affording more opportunity for peer review and extensive beta testing before release.

2. Performance & Scalability: The process of peer review also encourages open source developers to design their source codes and thus their programs to run on a variety of platforms. Constant tweaking by a large number of developers mean constant, albeit, small improvements in performance and scalability. Such small improvement add up over time resulting in better performing programs.

3. Security: It has been argued that a serious problem with proprietary software is that there are strong economic disincentives for them to make their software secure. Vendors are often under economic pressure to be ‘first to market’, often at the expense of making their software more secure. Since it is extremely difficult for customers to distinguish proprietary software with strong security from those with poor security, the poor products tend to eliminate the good ones since they are usually cheaper to develop and thus cost less.

It is not clear if open source is able to avoid these disincentives, but it appears in at least some cases it does. Since the source code is public, so the difference in level of security is far more visible than in proprietary products. Thus defective or malicious code can be found by anyone and there are incentives for arbitrary people to review it, such as to add new features or perform a security review of a product they intend to use.

4. Total Cost of Ownership (TCO): TCO is an important measure, it doesn’t matter if a product starts out cheaply if it costs you more down the line. However, TCO is extremely sensitive to the set of assumptions you make. Indeed, whatever product you use or support, you can probably find a study to show it has the lowest TCO for some circumstance. However, it has been stated that open source has many strong cost advantages in many cases that will result in it having the smallest TCO. They are:-

1. Open source costs less to initially acquire although it isn’t cost-free, because you’ll still spend money for paper documentation, support, training, system administration, and so on, just as you do with proprietary systems.
2. Upgrade/maintenance costs are typically far less in open source. Long-term upgrade costs are far less for open source systems. An anti-trust lawyer would say that open source technical support is “contestable.” In short, if you don’t like your GNU/Linux supplier (e.g., they’ve become too costly), you can switch.
3. Open source can often use older hardware more efficiently than proprietary systems, yielding smaller hardware costs and sometimes eliminating the need for new hardware.
4. Open source does not impose license management costs and avoids nearly all licensing litigation risks. Proprietary vendors make money from the sale of licenses, and are imposing increasingly complex mechanisms on consumers to manage these licenses. Customers who cannot later prove than they paid for every installed copy of proprietary software (e.g., due to copying by an employee or losing the license paperwork) risk stiff penalties. In short: by using proprietary software, you run the risk of having the vendor to sue you. To counter these risks, organisations must keep careful track of license purchases. This means that organisations must impose strict software license tracking processes, purchase costly tracking programs, and pay for people to keep track of these licenses and perform occasional audits.

5. Other Factors: Not all factors can be quantitatively measured, and to many they are the most important factors. The factors most important to many include freedom, protection from license litigation, and flexibility.

1. Open source protects its users from the risks and disadvantages of single source solutions. Users do not want to be held hostage by any one vendor. Businesses often prefer to buy products in which there is a large set of competing suppliers, because it reduces their risk; they can always switch to another supplier if they’re not satisfied, the supplier raises their prices substantially, or the original supplier goes out of business.
2. Open source protects its users from licensing litigation and management costs. Proprietary vendors make money from the sale of licenses, and are imposing increasingly complex mechanisms on consumers to manage these licenses. Proprietary vendors also litigate against those who don’t comply with their complex licensing management requirements, creating increased legal risks for users.<br
   In contrast, it is claimed that open source users have no fear of litigation from the use and copying of open source. Licensing issues do come up when open source software is modified and then redistributed, but to be fair, proprietary software essentially forbids this action (so it’s a completely new right). Even in this circumstance, redistributing modified open source software generally requires following only a few simple rules (depending on the license), such as giving credit to previous developers and releasing modifications under the same license as the original program. Because of the way open source projects are organized, there is however a danger of proprietary codes ‘slipping’ into open source codes. The SCO Linux litigation is a case in point.
3. Open source has greater flexibility. Users can tailor the product as necessary to meet their needs in ways not possible without source code. Users can tailor the product themselves, or hire whoever they think can solve the problem (including the original developer). Some have claimed that this creates the “danger of forking,” that is, of multiple incompatible versions of a product. This is “dangerous” only to those who think competition is evil – we have multiple versions of cars as well. And in practice, the high cost of maintaining software yourself has resulted in a process in which the change is contributed back to the community. If it’s not contributed (e.g., it solves a problem that needed solving but only for a specialised situation), then it’s still a win for the user – because it solved a user’s problem which would have been unsolved otherwise.

Dangers of Open Source

However open source come with a number of risks. The most obvious risk is potential liability for Intellectual Property Rights infringement. An example is the litigation started by SCO Linux claiming that IBM had released SCO’s proprietary codes into versions of Linux. The typical open source project is an effort that contains contributions from many people. It creates multiple opportunities for contributors to introduce infringing code and makes it almost impossible to audit the entire code base. The risks of this development process are largely borne by the licencees. Contributors do not vouch for the cleanliness of the code they contribute to the project. In fact, the typical open source licence is designed to be very protective of the contributor and does not include any intellectual property representations, warranties or indemnities. It contains a broad disclaimer of all warranties that benefits the licensor/contributors. Further, it would be difficult to recover against the licensor for having licenced infringing code. Many of the most prominent open source projects appear to be owned by entities that do not have the financial means to answer an IPR infringement lawsuit.

Open source licences also do not contain the kinds of representations and warranties of quality or fitness for a particular purpose that commercial software agreements have. Again, the process of developing open source software can contribute to problems in this area. Some open source software projects (like GNU Linux) have one or more stewards who monitor code quality and track bugs. Other initiatives, however, are really more the product of weekend and after-hours hobbyists and do not enjoy the same code quality. Without contractual commitments of quality or fitness, the licencee must accept the risk that the software contains fatal errors, viruses or other problems that may have business consequences.

Developers looking to build a business on open source software also need to consider the problems associated with derivative works created by them. Some open source licence forms, such as the GNU GPL, require developers to provide free copies of their derivative works in source code form for others to use, modify and redistribute in accordance with the terms of the GPL for the unmodified program. Developers must be concerned that their “value added” programs might some day be viewed as “derivative works” and need to be made available to the world in source code form for free.

Conclusion

Open source software has significant market share in many markets. Often it is a more reliable software and in many cases has the best performance. Open source software often have far better security, perhaps due to the possibility of worldwide review. Total cost of ownership for open source software is often far less than proprietary software, especially as the number of platforms increases.

Realising these potential open source benefits may require approaching problems in a different way. This might include using thin clients, deploying a solution by adding a feature to an open source product, and understanding the differences between the proprietary and open source models. Acquisition processes may need to change to include specifically identifying open source alternatives, since simply putting out a “request for proposal” may not yield all the viable candidates. Open source products are not the best technical choice in absolutely all cases, of course; even organisations which strongly prefer open source generally have some sort of waiver process for proprietary programs. However, it’s clear that considering open source alternatives can be beneficial.

Of course, before deploying any program you need to evaluate how well it meets your needs, and some organisations do not know how to evaluate open source programs.

While there are benefits, there are also significant dangers to open source. The uncertainty of clean code without proprietary code wrongfully included in the open source software, the uncertainty of support, especially when the original or key developers leave a project and develop a ‘fork’, the uncertainty of ‘fitness for purpose’ since almost all open source licences specifically exclude such warranties and many more ‘uncertainties’.

As in all projects, careful evaluation is necessary, weighing the benefits against the dangers of going the ‘open source way’. In some situations, it would be beneficial to use open source software especially where they are more established with local support. In other situations, proprietary software should be used.