is available online at http://oreilly.com/catalog/opensources/book/toc.html.
OSI open source definition
Linux provides a platform that lets software developers change the operating system as they like and get a wide range of help creating the applications they need. One of the watchdogs of the open source movement is the Open Source Initiative (OSI, http://www.opensource.org).
Although the primary goal of open source software is to make source code available, other goals of open source software are also defined by OSI in its open source definition. Most of the following rules for acceptable open source licenses serve to protect the freedom and integrity of the open source code:
● Free distribution– An open source license can't require a fee from anyone who resells the software.
● Source code– The source code must be included with the software and there can be no restrictions on redistribution.
● Derived works– The license must allow modification and redistribution of the code under the same terms.
● Integrity of the author's source code– The license may require that those who use the source code remove the original project's name or version if they change the source code.
● No discrimination against persons or groups– The license must allow all people to be equally eligible to use the source code.
● No discrimination against fields of endeavor– The license can't restrict a project from using the source code because it is commercial or because it is associated with a field of endeavor that the software provider doesn't like.
● Distribution of license– No additional license should be needed to use and redistribute the software.
● License must not be specific to a product– The license can't restrict the source code to a particular software distribution.
● License must not restrict other software– The license can't prevent someone from including the open source software on the same medium as non–open source software.
● License must be technology-neutral– The license can't restrict methods in which the source code can be redistributed.
Open source licenses used by software development projects must meet these criteria to be accepted as open source software by OSI. About 70 different licenses are accepted by OSI to be used to label software as “OSI Certified Open Source Software.” In addition to the GPL, other popular OSI-approved licenses include:
● LGPL– The GNU Lesser General Public License (LGPL) is often used for distributing libraries that other application programs depend upon.
● BSD– The Berkeley Software Distribution License allows redistribution of source code, with the requirement that the source code keep the BSD copyright notice and not use the names of contributors to endorse or promote derived software without written permission. A major difference from GPL, however, is that BSD does not require people modifying the code to pass those changes on to the community. As a result, proprietary software vendors such as Apple and Microsoft have used BSD code in their own operating systems.
● MIT– The MIT license is like the BSD license, except that it doesn't include the endorsement and promotion requirement.
● Mozilla– The Mozilla license covers the use and redistribution of source code associated with the Firefox web browser and other software related to the Mozilla project (http://www.mozilla.org). It is a much longer license than the others just mentioned because it contains more definitions of how contributors and those reusing the source code should behave. This includes submitting a file of changes when submitting modifications and that those making their own additions to the code for redistribution should be aware of patent issues or other restrictions associated with their code.
The end result of open source code is software that has more flexibility to grow and fewer boundaries in how it can be used. Many believe that the fact that numerous people look over the source code for a project results in higher-quality software for everyone. As open source advocate Eric S. Raymond says in an often-quoted line, “Given enough eyeballs, all bugs are shallow.”
Understanding How Linux Distributions Emerged
Having bundles of source code floating around the Internet that could be compiled and packaged into a Linux system worked well for geeks. More casual Linux users, however, needed a simpler way to put together a Linux system. To respond to that need, some of the best geeks began building their own Linux distributions.
A Linux distribution consists of the components needed to create a working Linux system and the procedures needed to get those components installed and running. Technically, Linux is really just what is referred to as the kernel. Before the kernel can be useful, you must have other software such as basic commands (GNU utilities), services you want to offer (such as remote login or web servers), and possibly a desktop interface and graphical applications. Then, you must be able to gather all that together and install it on your computer's hard disk.
Slackware (http://www.slackware.com) is one of the oldest Linux distributions still being developed today. It made Linux friendly for less technical users by distributing software already compiled and grouped into packages (those packages of software components were in a format called tarballs). You would use basic Linux commands then to do things like format your disk, enable swap, and create user accounts.
Before long, many other Linux distributions were created. Some Linux distributions were created to meet special needs, such as KNOPPIX (a live CD Linux), Gentoo (a cool customizable Linux), and Mandrake (later called Mandriva, which was one of several desktop Linux distributions). But two major distributions rose to become the foundation for many other distributions: Red Hat Linux and Debian.
Choosing a Red Hat distribution
When Red Hat Linux appeared in the late 1990s, it quickly became the most popular Linux distribution for several reasons:
● RPM package management– Tarballs are fine for dropping software on your computer, but they don't work as well when you want to update, remove, or even find out about that software. Red Hat created the RPM packaging format so a software package could contain not only the files to be shared, but also information about the package version, who created it, which files were documentation or configuration files, and when it was created. By installing software packaged in RPM format, that information about each software package could be stored in a local RPM database. It became easy to find what was installed, update it, or remove it.
● Simple installation– The anaconda installer made it much simpler to install Linux. As a user, you could step through some simple questions, in most cases accepting defaults, to install Red Hat Linux.
● Graphical administration– Red Hat added simple graphical tools to configure printers, add users, set time and date, and do other basic administrative tasks. As a result, desktop users could use a Linux system without even having to run commands.
For
