A major point worth mentioning about the adoption of this standard is its effect on your employees or coworkers. The free software standard causes your engineers, developers and architects to become involved with the larger free and open source software community. The direct benefit of this involvement is not having to maintain patches and source code changes internally. If your company finds a bug in a piece of software and fixes it, you are not required to fix future versions of the software. While you might view this as "work benefiting the many," there is also a strong argument to be made for doing work to benefit yourself.

The indirect benefits of getting your company involved in doing free software and being part of the larger community is the larger pool of expertise. In the closed source business model, cross company communication is rare. For example, a bank and a large manufacturer may both need supporting infrastructure like websites and email servers. In the closed source model there is no real mechanism for them to contact one another regarding these needs. In the open source model they can. By participating with the upstream projects, they meet others doing nearly identical work on systems unrelated to any competitive or differentiating business function. Thus, they can communicate and learn from each other's experiences. Being able to learn from and avoid the mistakes of others produces huge cost savings in a business environment, such as learning something won't work before you've purchased a million dollars in hardare.

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.

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.

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.

There are innumerable potential licenses available for software. Free software in particular has many licensing choices available. Each license has its own benefits and drawbacks, and sometimes licenses are even used together. Keeping licenses straight is a complex job, and as a result, strictly following The Fedora Project's licensing guidelines is recommended. The Fedora Project tracks creation of and changes to free software licenses, and the packages released under these licenses, and takes necessary actions. This set of guidelines is a powerful tool that helps avoid breaking license guidelines. See http://fedoraproject.org/wiki/Licensing:Main for the complete listing.

All free software used by The Fedora Project must meet the following standards. Software which does not meet these standards must not be used.

Forking is a serious subject in free software. The choice to fork an application typically causes the number of developers working on it to drop. If the fork is maintained locally for individual use of The Fedora Project, the long term costs for maintaining that fork rise significantly. Generally a fork should be considered a failure of communication or negotiation.