Community Services Infrastructure Standards

Legal Notice

Copyright (c) 2009 by Fedora Project. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at

Community Services Infrastructure Standards
1. CSI Introduction
1.1. Introduction
1.2. What to do
1.3. External Sources and References
2. Language and Terms
2.1. Introduction
2.2. External Sources and References
Free Software Policy
1. Free Software Rationale
1.1. Free Software Rationale Target
1.2. Free Software Rationale Details
1.2.1. Free Software Benefits
2. Free Software Introduction
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

Community Services Infrastructure Standards

Chapter 1. CSI Introduction

1.1. Introduction

The Community Services Infrastructure standards or CSI standards are a group of documents designed to be implemented by the biggest set of technology users in the world. They focus entirely around Red Hat compatable operating systems (Red Hat Enterprise Linux, Fedora, and CentOS for example). Unlike most documentation, CSI aims to be standards based. Often checklists can be printed up and checked off one by one to ensure compliance. There are three typical target audiences. Administrators, end users and management / legal.
CSI is developed using open source methods. Any changes or suggestions should be directed to the CSI mailing list. Any questions regarding details on how to implement these changes or why should be directed to

1.2. What to do

You have been directed to read this document because it contains instructions and steps that you are now expected to follow. Read through the items below and make note of any confusing or less then clear steps. It is important that each step is followed carefully. Do not assume something is done just because it might be right. It is recommended to print up a copy of these checklists and mark off each one as they are completed. Should a time come that an item becomes non-compliant, make note of that and work to become compliant once again.

Free Software Policy

Chapter 1. Free Software Rationale

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
Free Software is more than just an application to be downloaded and used. There are also licensing issues and legal obligations to consider.


Please note that at present this document is of draft quality and subject to change!
When people talk about free software they are talking about more than just software that has no monetary cost. They are also talking about more than simply "Open Source," meaning available source code. In addition to code and binaries that come with free software, it also grants certain rights. Someone in The Fedora Project who makes changes to free software may also be giving up certain rights. This standard discusses details of the rights and responsibilities that come with free software, and sets out a framework for which licenses are acceptable.
All of the licenses included in Fedora are considered "free," as that term is used in this standard. This freedom means that any individuals can use this software as is for any purpose including profit. When a recipient of the software wants to alter licensed materials, however, certain restrictions apply. The standard instructs developers and other technical professionals how to remain legally compliant while also ensuring that they do not accidentally give away company trade secrets or other property.

1.2.1. Free Software Benefits

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.

Chapter 2. Free Software Introduction

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
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, or 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.

2.2. Choosing Free Software

All Red Hat compatible distributions ship with thousands of packages. Additional packages can be found via third party repositories. For example, users of CentOS and Red Hat Enterprise Linux can optionally add the Extra Packages for Enterprise Linux (EPEL) repository - The use of any of these packages has already been vetted from a licensing point of view.
Any package that ships with the distribution is typically legally vetted and ok to use for any purposes you see fit. Fedora in particular has a strict licensing guidelines. This does prevent many applications from being in the operating system. This is both good and bad depending on what you as a user are looking for. A package that has been submitted to Fedora but rejected for legal or licensing reasons may not be safe for The Fedora Project to use. While this is a tough position to be in, it is also a safe position to be in. Especially if you work for a company that has money and can get sued.

2.2.1. Free Software Licensing

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 for the complete listing. Common Mistakes

Most licensing issues arise when one tries to make changes or redistribute packages and code. The easiest way to avoid these issues is to submit all package changes upstream, and ensure that all packages you use are available in your distribution. See Section 2.3, “Making Changes” for more details on these use cases. Another way to avoid these issues is to ensure that any software you write works with the stock packages available from your distribution. Licensing Internal Software

Any and all software written internally should be created under a specific license. Ideally, that license should be a free software license listed in Fedora's licensing matrix. If this is not possbile, pick a sensible license for the software, but ensure that all your software has a license of some kind attached.
This table refers to all content or software written specifically for use by The Fedora Project.
Internal Licensing
MustSoftware License RequirementAll custom written software must have an associated license.
MustContent License RequirementAll content must have an associated license.
ShouldOpen Source LicenseAll custom written software and content should have a free software compatible license as listed on
MayProprietary LicensesSoftware that has no general purpose, or that contains proprietary information, business secrets, or other private information, may be licensed under a non-free or proprietary license.
Must NotProprietary DependenceService level software (like web applications) must not depend on or link to proprietary software or services to function properly.

2.2.2. Free Software Use Policy (Checklist)

All free software used by The Fedora Project must meet the following standards. Software which does not meet these standards must not be used.
Free Software Use Policy
MustFree Software LicenseAll deployed software must match a license on the approved license list
MustDistribution PackagingAny software package that is not a part of your distribution (e.g. Red Hat Enterprise Linux, Fedora, EPEL, CentOS) must be submitted for review to be included. Exceptions to this rule include non-general use applications that are deemed specific to The Fedora Project. See Section 2.4, “Distribution Partnership” for details.
MayFeasibility ExceptionIn cases where implementation of free software is not feasible, proprietary software may be used at the discretion of Mike McGrath mmcgrath Examples include diagnostic tools provided by a hardware vendor, and software required for firmware updates.
MayGrandfatherDuring the transition from proprietary software to free software, the proprietary software may remain in place until a suitable free software replacement is identified and activated.

2.3. Making Changes

The packages that ship with your distribution may not always fully meet your needs. This deficiency may be due to a missing flag during build time, or missing or incomplete functionality. This section focuses on how to implement package changes correctly, often with a higher front-end cost but a much lower long term cost.
Changes to a package or software application must meet the following standards. Refer to each upstreams project's preferred method of communication before requesting a feature or offering a patch.
Free Software Change Policy
MustSource/Content PatchesAll changes to an upstream application must be offered to the upstream project.
MustCompilation/Packaging ErrorsErrors found in the compilation or packaging of an application must be sent to package owner via the distribution's bug tracking or ticketing system.
MayWorkless RequestWhen sending a feature request or change it is customary to send a patch or suggested solution with the initial report. If this approach is not feasible because of time or technical constraints, the request may be sent without further work from the requestor. Any questions from upstream must be answered in a timely manner.
ShouldDistribution NotificationAny changes sent upstream should also be sent to the distribution with a link to the related upstream ticket or list if applicable.

2.3.1. Forking

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.
Free Software Forking Policy
MustLocal RepositoryAll forked packages must be kept in a local yum repository. The repository layout should match that of the distribution in terms of version, architecture, and other segmenting. Then install an additional yum.repo file for your local repositories.
MayVersion ForkIf the distribution's package maintainer has refused or is unable to do a version update, you may fork and maintain a local forked copy of the package.
MayFeature ForkIf the distribution's package maintainer has refused or is incapable of enabling a feature, you may fork and maintain a local forked copy of the package.
MayFork MaintenenceIndividuals who chose to fork a package are responsible for maintaing that package and back-porting security patches.
MayUpstream ForkIf an upstream software project's direction has taken a direction that causes incompatibilities with the infrastructure environment or the platform needs, a project fork may occur. Consult related licenses and ensure that legal steps are taken to properly rename the project. The forked project should be developed in free software fashion, and efforts must be made to develop a community around it.
ShouldFork RemovalEach local fork should regularly be checked to determine if the distribution's package has comes into compliance with platform needs. If so, the local fork should be removed in favor of the distribution's package.

2.4. Distribution Partnership

Joining communities related to your distribution is an essential part of being a free software professional. CentOS, Red Hat Enterprise Linux, Fedora, and EPEL all have mailing lists, IRC channels and ticketing systems. Become a contributor to the distribution you use, and learn the policies and procedures for making changes. See the referenced links below for more information.

2.5. External Sources and References