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.