Product SiteDocumentation Site

Chapter 2. Free Software Introduction

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
2.1. Crash Course About Free Software
2.1.1. Upstream
2.1.2. Distribution
2.1.3. Users
2.2. Choosing Free Software
2.2.1. Free Software Licensing
2.2.2. Free Software Use Policy (Checklist)
2.3. Making Changes
2.3.1. Forking
2.4. Distribution Partnership
2.5. External Sources and References
This chapter focuses on how to become a Free Software friendly professional. As an engineer, developer, architect or administrator, using free software can greatly increase your efficiency for a minimum of cost. By following the guidelines included in this document you can stay legally compliant when using free software and have the best possible chance for a successful implementation.

2.1. Crash Course About Free Software

The Free Software Foundation defines free software as “software that gives you the user the freedom to share, study and modify it. We call this free software because the user is free.” Having the code is only one element of software freedom. Being allowed to do useful things with that code is the main difference between free software and open source software. The free software ecosystem consists of three basic layers:
  • Upstream, where individual applications are created (e.g. Apache's httpd)
  • Distribution, where the upstream applications are packaged and then distributed (e.g. Red Hat Enterprise Linux)
  • Free software users, people who consume and give back to free software (e.g. you)
The rest of this section describes how each of these layers work, what is expected from each, and how to contribute to each. One benefit of free software is that a free software user can contribute in any aspect of the ecosystem they wish. The overall theme you'll be reading is that changes need to happen upstream.

2.1.1. Upstream

Upstream projects are where the bulk of free software development happens. There are literally thousands of upstream projects and many of them have no communication with each other. This includes how the projects are structured, how bugs are reported to them, how they communicate (often by mailing list). Some sites like sourceforge.net, code.google.com or fedorahosted.org bring common tools together to aid upstream projects. Some projects are just a couple of people or even one person. Some projects, like the Linux kernel are significantly larger and have a complex organizational structure.

2.1.2. Distribution

Distributions serve two primary roles. The first is to convert all of the applications from the thousands of upstream projects and turn them into packages. These packages are generally designed not to conflict with each other and to be easily installable. In the case of Red Hat family distributions, yum is what people use to install packages. These packages are often patched to work better with each other so what is installed may not be identical to what upstream ships. These changes are common and often required for proper functionality of the distribution.
The second function of distributions is to actually distribute the packages. When most users install software they do not grab it from the upstream projects, they grab the software from the distribution. This is typically done via a vendors servers or a set of mirrors.

2.1.3. Users

The final group is considered users. These are consumers, participants, and contributors. By being directed to this standard you have been asked or have agreed to be more then just a consumer of free software. So in the rest of this document, focus not just on consumption but also participation and contribution. This group uses the packages that distributions have put together. They should report bugs, aid developers in finding solutions or work directly on solutions to problems themselves.