Red Hat’s open source participation guidelines

Red Hat is the world's leading provider of open source software and solutions. We build and support enterprise open source products from open source projects. We participate in the projects and communities our products depend on, often in leadership roles. Red Hat associates are bound by a common purpose: to make sure open source continues to unlock the world's potential. People work at Red Hat because they believe in open source. This intrinsic passion offers an unmatched level of dedication and knowledge to our customers. 

An open development model connects Red Hat associates to open source communities. Participants in these communities work together to identify and elevate the best ideas. Red Hat has created and leads many of these communities, but in numerous other cases, Red Hat contributes to an existing community that is upstream of Red Hat. Red Hat supports these communities primarily through our participation and engagement, which includes but is by no means limited to our contribution of code and other content. Within these open source communities, we build and refine the technologies that make up today’s IT environments. 

As a company, we aim to continuously learn from our experiences in the practice of open source, one effect of which is our adaptation of the underlying principles of open source culture to other aspects of our business, as can be seen in our work on The Open Organization and the Open Decision Framework. 

The following document addresses some topics relating to participation in open source development by Red Hat associates. This is a living document and is not an exhaustive explanation of how we participate in and contribute to open source.

Open source software is software that is available in source code form and provides the freedom to use, study, modify and share the software. Red Hat associates sometimes prefer to call open source “free software,” which emphasizes its ethical foundations. Typically this freedom is provided through an open source license.

The Open Source Initiative (OSI) maintains a 10-part Open Source Definition, which is derived from the Debian Free Software Guidelines. The Free Software Foundation (FSF) maintains a 4-part Free Software Definition. Both the OSI and FSF interpret their definitions in deciding whether certain licenses conform to them or not; they mostly agree as to these determinations. They also agree that the availability of modifiable source code is essential. However, neither organization has comprehensively assessed the hundreds of licenses covering the code that appears in the many thousands of packages making up Red Hat products. Red Hat necessarily makes its own determination of whether a license is open source, looking in part to the FSF and OSI definitions and interpretations for guidance. In the case of Fedora, these determinations are recorded in the publicly-available Fedora license lists.

While open source is fundamentally defined by (mostly) legal criteria, it has also come to be associated with best practices for community software development and creating engaged communities. It is important to understand that software can be open source even if some of these practices are not followed. On the other hand, software that is not under an open source license is not open source, even if some of those practices are otherwise followed. 

In much of our engagement with open source projects, we aspire to meet the highest standards for community development, and indeed over many years we have been leaders in shaping such practices. We acknowledge, though, that in some current and historical situations we have not done so for various business-related or other reasons. The subject of community development best practices is a central concern for many Red Hat associates and is debated both internally and publicly, but it is mostly outside the current scope of this document. 

Red Hat associates are free to use open source software regardless of how it is procured, including open source software not developed by Red Hat or its engineers, subject to any applicable guidelines set out by the Red Hat IT and Legal departments.

Red Hat associates are highly encouraged to participate in open source projects, and of course many Red Hat engineers do so as a direct aspect of their jobs. Participation or collaboration takes many forms. It includes not only contribution of code, documentation, design artifacts and other content, but also many other activities, including less tangible forms of community participation such as mentoring new contributors, project coordination, project event planning, and so on. 

We deliberately do not mandate that associates complete any type of education or training as a prerequisite to participating in open source communities. However, we provide resources and assistance for Red Hat associates who are relatively inexperienced in open source but who wish to or need to get involved in community development. These include: 

• New Hire Orientation, which features content to be read or watched by new Red Hat associates (including videos like those listed below)
• Red Hat University courses on the foundations of open source, open source licensing, and copyright law, as well as more technical content
• Content on our intranet, both from the Open Source Program Office and other groups in Red Hat
• Content on opensource.com (a Red Hat-sponsored project not focused on Red Hat products), such as: 
  • How to become an open source contributor 
  • How to contribute to open source projects (without writing code) 
• Publicly available Red Hat videos, such as:
  • Default to open: The story of open source and Red Hat
  • The Red Hat Way
  • The open development model at Red Hat
  • Open Source: Debunking the myths
  • Software patent challenges and customs
  • Innovation through software licensing and copyright

The amount of official time a Red Hat associate spends working on an open source project varies significantly across teams and roles and with the nature of the project in question and is something an individual associate works out with the associate’s manager. 

It goes without saying that Red Hat associates often contribute to open source projects outside of their job roles, and they need no permission from Red Hat to do so. Unlike the situation at many other companies, when it comes to open source development, the line between work and personal (as well as between “work hours” and “personal time”) is unavoidably blurred for most Red Hat associates. For example, many Red Hat engineers make “personal” contributions, outside of their normal or official work hours, to projects they rely on at work.

We talk a lot about “upstream” at Red Hat. This reflects the perspective that comes from our unique development model, as maintainers of projects that incorporate code from other projects, which in turn serve as the basis for our commercial products. Depending on context, “upstream” may refer to community projects we depend on, participate in or lead. 

In contributing to open source projects as well as building our products, Red Hat strives to follow the principle of “upstream first.” The practical implications of our upstream first philosophy for Red Hat associates are twofold.

First, nearly all changes, features, and documentation for Red Hat-originated software are initially committed to the upstream, community-facing version of the software—an open source project that is typically led or maintained substantially by Red Hat engineers—before being merged into our product code. For example, new Red Hat® Enterprise Linux® features are expected to be submitted to, and released by, the Fedora Project before they show up in a Red Hat Enterprise Linux release. This practice helps ensure that changes and features are fully tested before being incorporated into a subscription product, and it demonstrates our support for and commitment to the community-facing project version of the code on an ongoing basis. If there is not already a community project counterpart to a Red Hat product, we will create one.

Second, for projects that are not led primarily by Red Hat, but which are maintained or administered by an external organization (for example, a foundation such as the Linux Foundation or a partner company) or by a community development team not affiliated with Red Hat, our changes and improvements are first offered to the upstream project before being included in a downstream Red Hat version of the code. If a feature is not first merged upstream, we normally will not ship it. If we need to fix a bug in an upstream project, we will first at least propose merging the patch upstream. For example, most Red Hat OpenShift® features are submitted for inclusion in the Kubernetes project. This promotes productive collaboration with our partners and upstream project communities, and it lets us avoid the costly consequences of maintaining a downstream fork of the main project. Some companies find it tempting to create non-public forks of upstream code as a quick way to address a specific use case, or because they are not inclined to collaborate in a community. However the long-term maintenance burdens of such forks can be prohibitive because of increased development costs, loss of interoperability, and other reasons. By contrast, concentrating development in the original upstream community enables sharing costs of development among all participants. 

There are, of course, special exceptions to the general principle of upstream first, such as those involving embargoed CVE changes, customer proprietary information, stealth or experimental phases of some new projects, or product deadlines requiring us to work on upstream and downstream concurrently. For this reason, associates should check with their managers before pushing changes or content upstream for the first time.

The upstream-first principle also relates to our strategic decisions around creating and participating in open source project communities. Unlike traditional software companies, when we identify a technical problem space, we opt to use an open source, community-developed solution over internal proprietary development. But we typically seek to avoid the cost and inefficiency of developing and maintaining an open source solution by ourselves, where there are existing or potential communities working on the same problem with which we could collaborate. 

There are various Red Hat corporate policies, guidelines, and commitments that are relevant to open source project and product development. These include: 

• Data security policy 
• Export control policy
• Protocol for source availability and open source license compliance
• License selection protocol and guidelines
• Social media guidelines 
• Patent Promise
• GPL Cooperation Commitment

Red Hat associates need no special permission to participate in and make individual contributions to upstream projects not maintained primarily by Red Hat teams, including projects maintained by competitors of Red Hat—assuming those projects are actually open source projects (i.e., the software is under an open source license). This applies regardless of whether the participation formally occurs during the associate’s working hours or on their personal time and regardless of what technologies the associate uses to participate. (This does not mean, however, that you can unilaterally reprioritize how you choose to spend your Red Hat working hours.) Of course, many Red Hat engineers must make such contributions as an everyday function of their roles at Red Hat and in order to fulfill our commitment to upstream first and vendor neutrality. 

A minority of upstream projects not maintained by Red Hat require contributors or their employers to sign a contributor license agreement (CLA) or some other form of special contributor agreement. Please consult the Red Hat guidelines for third-party contributor agreements before taking any further action. Red Hat associates are free to make the certification required by the Developer Certificate of Origin (DCO), used by some projects (however, nonstandard variants of the DCO must be reviewed by the Open Source Legal Team).

While Red Hat associates have very broad approval to contribute to upstream open source projects, this does not extend to the development of software that is not under an open source license, even if the software is maintained using a public source repository and some community development practices (for example, a project that is not licensed at all, or which is under a proprietary license, a non-open-source “source available” license, or some other license not recognized by us as open source, even if the project’s maintainers claim that the license is open source). 

Occasionally Red Hat chooses to formally become a member of a governance body associated with one or more open source projects administered by or affiliated with a nonprofit foundation or consortium. We have historically had some skepticism about the value of such membership, as we believe that influence and leadership over a project is obtained primarily through technical contribution. We therefore generally join such foundations or governance bodies only if we feel we can make a substantial community contribution and when we consider the foundation approach truly necessary to promote collaboration. For further explanation, see “Why Red Hat doesn’t join every foundation and consortium.”

At Red Hat we “default to open” and assume that all software that we develop will be released under an open source license. This means that releasing new open source software does not require any special business justification or involve bureaucratic hurdles. To the contrary, we expect a compelling business and engineering justification for those exceptional cases where we do not release software we develop under an open source license. We aim to place as few obstacles as possible to enabling our associates to rapidly launch new open source projects, regardless of their significance.

There is normally no formal management approval or process for new open source projects done as part of an associate’s Red Hat role and certainly none for projects of personal interest that are not work-related and are done on personal time. 

New open source projects started by Red Hatters vary in scope and commercial and technical significance. At one extreme, a Red Hatter might push the initial version of a small script to a public repository. At another extreme, a major open source project may be launched by a Red Hat team based on what was previously proprietary product code.

When thinking about starting a new project, you are encouraged to consider existing open source alternatives first, to avoid reinventing the wheel.

7.1 Legal guidelines when starting a new project

We recommend that Red Hat associates who are relatively inexperienced in open source development work more closely with the Red Hat Legal team when starting new projects. The vast majority of new projects are considered to be pre-approved from a legal perspective, assuming certain criteria are met. Red Hat Legal encourages individuals or teams starting new work-related open source projects to do the following: 

Open a ticket with the Open Source Legal Team to review the repository you wish to make public and to get advice on such issues as license selection and license compliance matters. You can also generate a ticket using the license selection web form.

Request a trademark clearance for your proposed project name (but in some cases this is not necessary; check with the Open Source Legal Team).

We do not conduct patent-related reviews or approvals before releasing new open source software (whether to assess the impact on our own patent portfolio, which is covered by our Patent Promise, or to assess the risk posed by third-party patents). This applies even to major new project launches, such as the open sourcing of proprietary product code from acquisitions. The view of the Red Hat Patent Team is that the benefits to Red Hat of releasing new open source software invariably outweigh any appreciable patent-related risk or other impact resulting from such activity. 

7.1.1 License selection

License selection for new open source projects is a decision that is normally delegated to the individual developer or team involved. When choosing a license, Red Hat developers are expected to give special weight to the licensing preferences and expectations of your project’s target contributor and user community. In practice, Red Hatters nearly always choose from a small set of standard, relatively widely-used open source licenses, ranging from strong copyleft (GPLv2-or-later, GPLv3-or-later, AGPLv3-or-later) to weak copyleft (LGPLv2.1-or-later, LGPLv3-or-later, EPL 2.0) to permissive (Apache License 2.0, MIT, 2-clause BSD). Unlike some other companies, Red Hat does not have a corporate preference for permissive over copyleft licensing, or vice versa, though individual teams often adopt particular licensing preferences or strategies. Projects selecting GPLv2 or LGPLv2.1 are now also asked to adopt the GPL Cooperation Commitment.

7.1.2 Handling contributions from the community

Red Hat-led projects do not use contributor license agreements (CLAs), copyright assignment, or other formal contributor agreements, apart from rare exceptions specifically approved by Red Hat Legal. We have learned from experience that these mechanisms can be a significant barrier to building communities around the projects we sponsor. However, we encourage all Red Hat-led projects to use the DCO. 

7.1.3 Codes of Conduct

Red Hat-led projects may choose to adopt a code of conduct that has been approved by Red Hat Legal, such as the Contributor Covenant version 1.4, but are not required or expected to do so. However, there is an emerging open source community expectation that projects adopt codes of conduct, and for at least some projects, failure to do so may create a barrier to growth. 

7.1.4 Open sourcing of acquired proprietary codebases

When Red Hat acquires a company with an actively-maintained proprietary product, we have a practice of open sourcing the code and building a community around it at the earliest appropriate opportunity. These special kinds of open source project releases generally require signoff from senior management and a higher degree of legal review. See also subsection 7.2.

7.2 Major Open Source Project Launches

“Starting an open source project” or “open sourcing” code may be as simple as making the code available on GitHub. However, when considering a serious and resource-intensive community launch, to accelerate code adoption and the development of a new community, a business case is in order for your management team’s consideration. Some considerations include: articulating the strategic relationship of the project to product, identifying community goals (adopters versus contributors or both, for example), resource requirements, and timing in relationship to other public events.

The Open Source Program Office’s charter includes assisting engineering and product managers with the development of the business case, recommending minimum resource commitments, recommendations for inclusion of community plans into the business unit’s strategic plan, and co-development of launch plans (provision of infrastructure, events, media). 

7.3 Other issues

Red Hat-led projects are not required to adopt any particular form of technical governance or decision-making process or to use any specific tools or services. However, particular teams may choose to adopt requirements or preferences concerning tools and services. 

All companies developing software today make substantial use of open source dependencies, and a number of companies base the core of their commercial products on open source project code releases. Red Hat is very different from nearly every other company, however, in that our products themselves are entirely open source in the strictest sense. They are licensed to our customers under open source licenses, which we pass through from upstream to the customer, and we provide customers with the source code. 

Red Hat takes open source license compliance very seriously. Both our practice of having completely open source products and our leadership in the open source community magnify our responsibilities around open source license compliance, and the open source community holds us to a higher compliance standard than other companies. For our products, we normally achieve compliance with the requirements of open source licenses by making available the complete corresponding source code to our customers.