Chapter 2. Introduction to IPCop

Before we look at how we use IPCop, we need to first look at the background of IPCop and the tools it is built with. We also need to look at the licenses those tools are distributed under, and therefore the IPCop license. This chapter will be less beneficial for those who would like to get straight to the installation and configuration and already know the background of open-source software, the GPL, and Linux. We will, however, also look at the reasons to choose IPCop in this chapter and the unique features it has, which will be useful when deciding whether to or how to deploy IPCop. It is, therefore, extremely important.

Free and Open Source Software

Many people might have heard of several common types of software, such as freeware, which is software you are allowed to use for free and (more generically), commercial software such as Microsoft Windows or Adobe Photoshop. Commercial software, generally, comes with a license restricting you to use the software in a certain way, and usually banning you from copying or modifying it.

IPCop is a type of software known as Open Source Software (OSS). As a piece of OSS, IPCop is released under a license called the GNU General Public License (GPL).

As with all Open Source Software packages distributed under this license and others like it, IPCop affords its users some basic freedoms.

Under the GPL, IPCop users are given the freedom to read, modify, and redistribute the source code of the software. The only caveat attached to this is that if you decide to redistribute this software (for instance, if you make a copy of IPCop with some improvements and give it to a friend) you must provide the modified work under the same license, and provide access to the source code. As we will see when we look at the history of IPCop, this can be very beneficial for users who would like to take a project in a new direction.

The GPL is one of the best-known open-source licenses. There are many others, however, such as the Berkeley Software Distribution License (BSD License). Each license differs in exactly what freedom it gives you, but all of them must allow at least the ability to read, modify, and redistribute the source code in order to be considered an open-source license by the Open Source Initiative.

Note

What is Source Code?

Source code is a set of instructions written by a computer programmer in a human-readable language. This set of instructions is usually then converted by a compiler into an executable program that the computer can run. With closed-source software such as Microsoft Windows and ISA Server, you don't get to see this. With Open Source Software such as Linux and IPCop, you do!

The Open Source Initiative is a non-profit organization involved in promoting open-source software and aiding developers in creating and using open-source licenses. It also maintains a list of all licenses accepted as open source.

You can find all of the licenses recognized by the Open Source Initiative at http://www.opensource.org/.

The GPL itself can be found on the GNU website, http://www.gnu.org/copyleft/gpl.html.

In addition to being the best-known OSS license, the GPL is also the license chosen by the best-known piece of OSS, the Linux kernel, which is a key component of IPCop. The release of the Linux kernel under the GPL is what makes systems like IPCop possible. The Linux kernel is the core of a Linux-based operating system (such as any of the Linux distributions that are variants of GNU/Linux). The kernel is developed by a team of developers mostly comprising volunteers around the world, but including many developers who are paid by companies that rely on Linux for some of their business, such as Red Hat Linux, Canonical, IBM, Novell, and Sun Microsystems.

As we are now aware, creating Open Source Software means giving our users the ability to modify our source code and then redistribute their modifications. This is what has been done with IPCop. IPCop has taken the Linux kernel as well as a large number of other tools, bundled them into a distribution of software and enabled users to create a feature-rich easy-to-use firewall system. This is how a lot of Open Source Software is created and is a function of the philosophy behind OSS.

Forking IPCop

Not only can you build your software on top of other components with OSS, but you can take it a step further and take one of those components (or a collection of those—called a distribution) and modify it to become something that suits your needs better than the design of the original developers. For example, if the users and developers of a particular piece of software decide they want something more from the software or want the software to be taken in another direction, they have the full freedom to do so. This is what happened with IPCop.

Before IPCop was created, SmoothWall existed (http://www.smoothwall.org). SmoothWall is a very similar distribution to IPCop at the present time and all of the initial code in IPCop was SmoothWall code. SmoothWall, however, employed dual licensing to release variants of its free firewall commercially. The commercial variants of SmoothWall had greater functionality, possibly causing conflict between the development goals of the free and commercial packages as there is a disincentive to improve a free product if it will cause your non-free product to make less money.

This led to tension between users of the software and some of the developers. The current IPCop developers decided to develop the system based on the work already put in to SmoothWall but they didn't want to follow SmoothWall's current philosophy and direction. As such, there was a decision to create a new branch of the software—to fork it. One of the main reasons behind the fork was a desire to create a firewall with the features available in commercial SmoothWall and then release this as a purely non-commercial piece of OSS.

Creating a new branch of software like this is called forking for quite obvious reasons. A fork is generally carried out by users and/or current developers by taking a snapshot of the source code and deciding to develop it in a different direction. They add different features, possibly remove some things that are not important for the project, and an alternative piece of software is created, which often competes with the original software, or provides an alternative to it.

Other examples of forked software are the many different distributions of the GNU tools and Linux such as Mandrake, Debian, Slackware, Ubuntu, and so on. Some of them are derived from their own packaging of the Linux kernel and GNU tools and some of them are derived from each other. For example Adamantix and Ubuntu are derived from Debian and they feature different design goals from each other and from their parent software.

Forking is also a process that commercial software undergoes—the many different versions of the Windows operating system, for instance, are ultimately forked from the same source code. By forking the source code and developing server versions of Windows (such as Windows 2003 Server) and client versions of Windows (such as Windows XP), Microsoft is better able to provide functionality in each version that is fitting to the purpose of the version, and the price charged for it.

There is a rich diversity of OSS, and without the freedom involved in licensing IPCop itself wouldn't exist, since it is derived from the GNU tools, Linux, SmoothWall, and many other open-source packages. This is by no means an exhaustive list and the number of developers involved in creating all of the code involved in such a system is very hard to estimate.

The license that IPCop is released under means that if a company chooses to use the system internally and subsequently decides that it would like to make some changes to it, it is free to do this—modifications are a right that is taken for granted under the license, and there is no obligation for you to redistribute changes you make that are only used internally. If you do decide to redistribute your modifications (to a friend, partner, or another company), all that is asked is that you afford your users the same benefits you received initially; i.e. if you decide to release the software, then you must release the software under the GPL. The license even makes a provision to charge a (reasonable) distribution fee to cover costs (although the people you redistribute it to are themselves free to redistribute the software to whomever they want, at no cost!). The added power this gives a piece of software is hard to measure, but it is very easy to see how this could be beneficial.

The example of forking in OSS was that of IPCop forking from SmoothWall. There is logically nothing to stop that happening again and in the opinion of the authors, diversity and choice when it comes to software is a good thing.

If we don't yet have a handle on the power of this license, one excellent example is that of highly secure installations. In a situation in which you need complete source code control and the ability to modify software at will to accommodate a secure environment, having IPCop with its source code gives you a firewall that is fully functional from which you can create a more customized system in order to secure your network if you need that sort of flexibility. This can be a change to the kernel underneath the system or changes to the configuration options, or even adding and removing firewall capabilities. Since there is no requirement to redistribute you can decide to keep this fully private and essentially have an in-house system where only a small amount of development investment was needed. There are a lot of software options that offer this and this is one of the biggest benefits OSS such as IPCop has over closed-source and commercial competitors in the marketplace.

If you don't need this flexibility, you still benefit from the developers that did use this flexibility in order to create a very useful system. The open nature of the development process is a direct consequence of the open nature of the code, and the sheer number of people who are able to get their hands on projects such as IPCop, the Linux kernel, or the Apache web server, means that these software packages can be highly polished and kept free of bugs, which commercial products with development teams that are comparatively tiny might not be so assiduous about.

上一章目录下一章