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 fedora-infrastructure-list@redhat.com.
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 uncomplaint, make note of that and work to become compliant once again.
Free Software is more then just an application that is to be downloaded and used. There's licensing considerations and legal obligations to consider.
Draft
Please note that at present this document is of draft quality and subject to change!
1.1. Free Software Rationale Target
This rationale should be read by managers and legal teams who are considering the use of free software in The Fedora Project. Engineers and architects who are looking to adopt or install Free Software should read the standards chapter below.
1.2. Free Software Rationale Details
When people talk about free software they are talking about more then just software that has no monetary cost. Nor are not simply talking about Open Source. In addition to the code and binaries that come with free software, certain rights are granted. When someone in The Fedora Project makes changes to free software, they may also be giving up certain rights. This standard discusses various themes that come with free software. It discusses what licenses are acceptable and which ones are not.
The free software standard gives an explicit list of licenses deemed acceptable for Fedora's distribution. It is important to remember that Fedora is the basis for all Red Hat compatible distributions. As such the licensing choices made in Fedora affects the whole family. Because of this, CSI focuses on these licenses. The current list of acceptable licenses can be found at: http://fedoraproject.org/wiki/Licensing:Main. These license may be vetted by your legal team as well though, many of these licenses are already found in Red Hat based distributions it is likely they are already being used.
All of the licenses included in Fedora are considered Free as we use the term in this standard. This freedom means that any individuals can use this software as is for any purpose including profit. The trick comes when people want to alter materials covered by these licenses. The standard instructs developers and other technical professionals how to remain legally compliant while also ensuring that they don't accidentally give away company secrets.
1.2.1. Free Software Benefits
A major point worth mentioning about adopting this standard is that is causes your engineers, developers and architects to get involved with the larger open source and free software community. The direct benefit of this is not having to maintain patches and source code changes internally. Meaning, if your company finds a bug in a piece of software and fix it, they don't also have to fix future versions of the software. While many view this as the "work benefiting the many" there is also a strong argument to be made for you doing work to benefit yourself.
The indirect benefits of getting your company involved in doing free software and being part of the larger community can be known as the larger expert pool. In the closed source business model, cross company communication was rare. For example, a bank and a large manufacturer both have needs for things like websites and email servers. In the closed source model there was no real mechanism for them to get in touch with one another. In the open source model they can. By participating with the upstream projects, they meet others who are doing nearly identical work to what you are doing with your email server. Thus, they can communicate, share in each other's mistakes and victories. Being able to learn from the mistakes of others is a huge cost saver. Especially if it means learning something won't work before you've purchased a million dollars in hardware.
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 be sure to stay legally compliant when using free software as well has having the best possible chance if successful implementation.
2.1. Crash Course About Free Software
The free software ecosystem consists of three basic areas:
Upstream - Where individual applications are created. (Apache's httpd)
Distribution - Where the upstream applications are packaged and then distributed (Red Hat Enterprise Linux)
Free Software Users - Where people consume and give back to free software (You)
The rest of this section describes the roles each of these areas work, what is expected, and how to contribute. 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 eachother. 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 significnatly 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 eachother 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 eachother 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 - http://fedoraproject.org/wiki/EPEL. 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.3. Free Software Licensing
There are hundreds if not thousands of potential licenses availble for software. Free software in particuar has many choices availble. Each license has its own pros and cons. Some licenses are even used together. Keeping licenses straight is a complex job, as a result it is recommended to strictly follow The Fedora Project's licensing guidelines. As licenses are changed, updated and created, The Fedora Project tracks this and the packages released under these licenses and takes actions as needed. Using these guidlines are a powerful tool to not accidentally breaking some license guidelines. See http://fedoraproject.org/wiki/Licensing:Main for the complete listing matrix.
2.3.1. Common Mistakes
Most licensing issues come up when people try to make changes or re-distribute packages and code. The easiest way to avoid these issues is to submit all package changes upstream and make sure all of the packages you use are available in your distribution. See the section below called "Making Changes" for more details on these use cases. Also make sure that any software you write, works with the stock packages available from your distribution.
2.3.2. Licensing Internal Software
Any and all software written internally should come with a license. Ideally all software written internally would also be written in and released under a free software license listed in Fedora's licensing matrix. If, for some reason, this cannot be done. Pick a license that makes sense for the software. But do ensure all of your software has a license of some kind.