news/vulnerabilities*.md
news/*.html
newsflash.inc
+policies/*.html
+policies/general/*.html
+policies/general/*.inc
+policies/technical/*.html
+policies/technical/*.inc
source/*.gz*
source/*.patch
source/.htaccess
H_COMMUNITY = $(addsuffix .html,\
$(basename $(shell git ls-files -- community/*.md)))
H_NEWS = $(addsuffix .html,$(basename $(shell git ls-files -- news/*.md)))
-H_SUPPORT = $(addsuffix .html,$(basename $(shell git ls-files -- support/*.md)))
H_POLICIES = $(addsuffix .html,\
- $(basename $(shell git ls-files -- policies/general/*.md \
+ $(basename $(shell git ls-files -- policies/*.md \
+ policies/general/*.md \
policies/technical/*.md)))
+H_SUPPORT = $(addsuffix .html,$(basename $(shell git ls-files -- support/*.md)))
SIMPLE = $(H_TOP) \
newsflash.inc \
+++ /dev/null
-<!DOCTYPE html>
-<html lang="en">
-<!--#include virtual="/inc/head.shtml" -->
-
-<body>
-<!--#include virtual="/inc/banner.shtml" -->
-
- <div id="main">
- <div id="content">
- <div class="blog-index">
- <article>
- <header><h2>Contributor Agreements</h2></header>
- <div class="entry-content">
- <p>
- Every non-trivial contribution needs to be
- covered by a signed
- Contributor License Agreement (CLA) from all original authors.
- We have modelled our policy based on the practice of
- <a href="https://www.apache.org">the Apache Software Foundation</a>.
- You can see their CLA policy
- <a href="https://www.apache.org/licenses/#clas">here</a>.
- Our policy is:
- </p>
-
- <p>
- OpenSSL requires that all non-trivial contributors of ideas, code, or
- documentation complete, sign, and submit (via postal mail, fax
- or email) an
- <a href="openssl_icla.pdf">Individual Contributor License Agreement (ICLA)</a>.
- The purpose of this agreement is to clearly define
- the terms under which intellectual property has been contributed
- to OpenSSL and thereby allow us to defend the project should
- there be a legal dispute regarding the software at some future
- time.
- </p>
-
- <p>
- A submission is trivial if it is considered trivial under copyright
- law. Since we are not lawyers, we place the bar for trivial
- contributions very high. For example: corrections of grammatical or
- typographical errors (including misspelled function names in manual
- pages), simple whitespace changes and in some cases one-line
- bugfixes might be accepted as trivial without requiring a CLA.
- </p>
-
- <p>
- In practice, it is required that the author (in the git commit
- message) and all approving team members (in the pull request thread)
- agree that a change is trivial. The author has to add "CLA: trivial"
- in the commit message separated by an empty line from the rest of the
- message. The reviewers will normally post a statement to the effect
- of "I agree that it is a trivial change."
- </p>
-
- <p>
- <em>When filling in the CLA, please make sure that the email
- address matches the one that you use for the "Author" in your
- git commits. List multiple email addresses if necessary.</em>
- </p>
-
- <p>
- For a corporation that has assigned employees to work on OpenSSL, a
- <a href="openssl_ccla.pdf">Corporate Contributor License Agreement (CCLA)</a>
- is available for contributing intellectual property via
- the corporation, that may have been assigned as part of an
- employment agreement. Note that a Corporate CLA does not
- remove the need for every developer to sign their own ICLA as
- an individual.
- </p>
-
- <p>
- If you have not already done so, please complete and sign a printout of the above
- ICLA (and CCLA if necessary), then scan and email a pdf file of the Agreement(s) to
- <a href="mailto:legal@opensslfoundation.org">legal@opensslfoundation.org</a>.
- </p>
-
- <p>
- If you prefer snail mail, send an original signed Agreement to the
- </p>
-
- <p>
- OpenSSL Software Foundation<br>
- 40 East Main Street<br>
- Suite 744<br>
- Newark, DE 19711<br>
- United States
- </p>
-
- Please read the document(s) carefully before signing and keep a copy for your records.
- </p>
-
- <p>
- Your Full name will be published unless you provide an alternative
- Public name. For example if your full name is Andrew Bernard Charles
- Dickens, but you wish to be known as Andrew Dickens, please enter
- the latter as your Public name. If you do not wish to have your
- name listed as a contributor, use <em>Anonymous</em>.
- We reserve the right to reject rude or obscene nick-names.
- The email address and other contact details are not published.
- </p>
-
- </div>
- <footer>
- You are here: <a href="/">Home</a>
- : <a href=".">Policies</a>
- : <a href="">Contributor Agreements</a>
- <br/><a href="/sitemap.txt">Sitemap</a>
- </footer>
- </article>
- </div>
- <!--#include virtual="sidebar.shtml" -->
- </div>
- </div>
-
-<!--#include virtual="/inc/footer.shtml" -->
-</body>
-
-</html>
-
-
--- /dev/null
+---
+breadcrumb: Contributor Agreements
+---
+# Contributor Agreements
+
+Every non-trivial contribution needs to be covered by a signed
+Contributor License Agreement (CLA) from all original authors. We have
+modelled our policy based on the practice of [the Apache Software
+Foundation](https://www.apache.org). You can see their CLA policy
+[here](https://www.apache.org/licenses/#clas). Our policy is:
+
+OpenSSL requires that all non-trivial contributors of ideas, code, or
+documentation complete, sign, and submit (via postal mail, fax or email)
+an [Individual Contributor License Agreement (ICLA)](openssl_icla.pdf).
+The purpose of this agreement is to clearly define the terms under which
+intellectual property has been contributed to OpenSSL and thereby allow
+us to defend the project should there be a legal dispute regarding the
+software at some future time.
+
+A submission is trivial if it is considered trivial under copyright law.
+Since we are not lawyers, we place the bar for trivial contributions
+very high. For example: corrections of grammatical or typographical
+errors (including misspelled function names in manual pages), simple
+whitespace changes and in some cases one-line bugfixes might be accepted
+as trivial without requiring a CLA.
+
+In practice, it is required that the author (in the git commit message)
+and all approving team members (in the pull request thread) agree that a
+change is trivial. The author has to add `CLA: trivial` in the commit
+message separated by an empty line from the rest of the message. The
+reviewers will normally post a statement to the effect of "I agree that
+it is a trivial change."
+
+*When filling in the CLA, please make sure that the email address
+matches the one that you use for the "Author" in your git commits.
+List multiple email addresses if necessary.*
+
+For a corporation that has assigned employees to work on OpenSSL, a
+[Corporate Contributor License Agreement (CCLA)](openssl_ccla.pdf) is
+available for contributing intellectual property via the corporation,
+that may have been assigned as part of an employment agreement. Note
+that a Corporate CLA does not remove the need for every developer to
+sign their own ICLA as an individual.
+
+If you have not already done so, please complete and sign a printout of
+the above ICLA (and CCLA if necessary), then scan and email a pdf file
+of the Agreement(s) to <legal@opensslfoundation.org>.
+
+If you prefer snail mail, send an original signed Agreement to the
+
+OpenSSL Software Foundation\
+40 East Main Street\
+Suite 744\
+Newark, DE 19711\
+United States
+
+Please read the document(s) carefully before signing and keep a copy for
+your records.
+
+Your Full name will be published unless you provide an alternative
+Public name. For example if your full name is Andrew Bernard Charles
+Dickens, but you wish to be known as Andrew Dickens, please enter the
+latter as your Public name. If you do not wish to have your name listed
+as a contributor, use *Anonymous*. We reserve the right to reject rude
+or obscene nick-names. The email address and other contact details are
+not published.
---
-title: OpenSSL General Policies
+breadcrumb: OpenSSL General Policies
---
These are the general policies and procedures established by the OMC.
+++ /dev/null
-<!DOCTYPE html>
-<html lang="en">
-<!--#include virtual="/inc/head.shtml" -->
-
-<body>
-<!--#include virtual="/inc/banner.shtml" -->
-
- <div id="main">
- <div id="content">
- <div class="blog-index">
- <article>
- <header><h2>Policies</h2></header>
- <div class="entry-content">
- <p>
- In this section we try to document as many of our
- policies and procedures as possible.
- We do this for two reasons:
- <ul>
- <li>
- First, we want to to make sure everyone knows how the project is
- run. For example, when we announce a forthcoming fix for a
- high-severity bug, the
- <a href="general/security-policy.html">Security Policy</a> explains
- what that means.</li>
- <li>
- Second, it helps us be consistent. For example,
- the <a href="releasestrat.html">Release Strategy</a> defines the
- plan of record of when, and how long, various releases will be
- supported.</li>
- </ul>
- <p>
- By being as transparent as possible,
- we hope to reduce the chance that people are surprised by
- what we do, and we hope to help maintain predictable
- behavior within the project. This includes how spend some
- money, as detailed in the
- <a href="travel.html">travel reimbursement policy</a>.
- </p>
- <p>
- If you want to contribute code or fixes to the project, please
- read the <a href="technical/coding-style.html">Coding Style</a>
- page. For legal obligations of contributors, see the page on
- <a href="cla.html">Contributor Agreements</a>.
- If you want to become a committer, make sure to also read our
- <a href="general/committer-policy.html">Guidelines for Committers</a>.
- </p>
- <p>
- The OpenSSL project is managed by the OpenSSL Management Committee
- (OMC), as defined by the <a href="omc-bylaws.html">project bylaws</a>.
- It is
- represented in most legal and formal capacities by the
- OpenSSL Software Foundation, a Delaware (US) non-profit corporation
- which has its own <a href="osf-bylaws.pdf">bylaws</a> as a legal
- document.
- Signing one of our CLA's grants certain rights to OSF.
- </p>
- <p>
- In addition, the OMC establishes and maintains the
- <a href="general/">general policies</a>, and a
- <a href="glossary.html">general glossary</a> of terms and
- what we mean with them.
- </p>
- <p>
- The technical aspects of the OpenSSL project are managed by the
- OpenSSL Technical Committee (OTC) which establishes and maintains
- the <a href="technical/">technical policies</a> based on the
- project bylaws and the requirements specified by the OMC.
- </p>
- <p>
- We are pleased to mention that
- <a href="https://bestpractices.coreinfrastructure.org/projects/54">we follow</a>
- the
- <a href="https://bestpractices.coreinfrastructure.org">best practices</a>
- of the Core Infrastructure Initiative.
- </p>
- </div>
-
- <footer>
- You are here: <a href="/">Home</a>
- : <a href="">Policies</a>
- <br/><a href="/sitemap.txt">Sitemap</a>
- </footer>
- </article>
- </div>
- <!--#include virtual="sidebar.shtml" -->
- </div>
- </div>
-
-<!--#include virtual="/inc/footer.shtml" -->
-</body>
-
-</html>
-
--- /dev/null
+---
+breadcrumb: Policies
+---
+# Policies
+
+In this section we try to document as many of our policies and
+procedures as possible. We do this for two reasons:
+
+- First, we want to to make sure everyone knows how the project is run.
+ For example, when we announce a forthcoming fix for a high-severity bug,
+ the [Security Policy](general/security-policy.html) explains what that
+ means.
+- Second, it helps us be consistent.
+ For example, the [Release Strategy](releasestrat.html) defines the plan
+ of record of when, and how long, various releases will be supported.
+
+By being as transparent as possible, we hope to reduce the chance that
+people are surprised by what we do, and we hope to help maintain
+predictable behavior within the project. This includes how spend some
+money, as detailed in the [travel reimbursement policy](travel.html).
+
+If you want to contribute code or fixes to the project, please read the
+[Coding Style](technical/coding-style.html) page. For legal obligations
+of contributors, see the page on [Contributor Agreements](cla.html). If
+you want to become a committer, make sure to also read our
+[Guidelines for Committers](general/committer-policy.html).
+
+The OpenSSL project is managed by the OpenSSL Management Committee
+(OMC), as defined by the [project bylaws](omc-bylaws.html). It is
+represented in most legal and formal capacities by the OpenSSL Software
+Foundation, a Delaware (US) non-profit corporation which has its own
+[bylaws](osf-bylaws.pdf) as a legal document. Signing one of our CLA's
+grants certain rights to OSF.
+
+In addition, the OMC establishes and maintains the [general policies](general/),
+and a [general glossary](glossary.html) of terms and what we mean with them.
+
+The technical aspects of the OpenSSL project are managed by the OpenSSL
+Technical Committee (OTC) which establishes and maintains the [technical
+policies](technical/) based on the project bylaws and the requirements
+specified by the OMC.
+
+We are pleased to mention that
+[we follow](https://bestpractices.coreinfrastructure.org/projects/54)
+the [best practices](https://bestpractices.coreinfrastructure.org) of the
+Core Infrastructure Initiative.
+++ /dev/null
-<!DOCTYPE html>
-<html lang="en">
-<!--#include virtual="/inc/head.shtml" -->
-
-<body>
-<!--#include virtual="/inc/banner.shtml" -->
-
-<div id="main">
- <div id="content">
- <div class="blog-index">
- <article>
- <header>
- <h2>OpenSSL Bylaws</h2>
- <h5>
- First issued 13th February 2017<br/>
- Last modified 10th December 2019
- </h5>
- </header>
-
- <div class="entry-content">
-
- <p>This document defines the bylaws under which the OpenSSL Project
- operates. It defines the different project roles, how they contribute
- to the project, and how project decisions are made.</p>
-
- <h2>Roles and Responsibilities</h2>
-
- <h3>Users</h3>
-
- <p>Users include any individual or organisation that downloads,
- installs, compiles, or uses the OpenSSL command line applications or
- the OpenSSL libraries or the OpenSSL documentation. This includes
- OpenSSL-based derivatives such as patched versions of OpenSSL provided
- through OS distributions, often known as "downstream" versions.</p>
-
- <p>Users may request help and assistance from the project through any
- appropriate forum as designated by the OpenSSL Management Committee
- (OMC). Users may also report bugs, issues, or feature requests; or
- make pull requests through any OMC designated channel.</p>
-
- <h3><a name="committers">Committers</a></h3>
-
- <p>Committers have the ability to make new commits to the main OpenSSL
- Project repository. Collectively, they have the responsibility for
- maintaining the contents of that repository. They must ensure that any
- committed contributions are consistent with all appropriate OpenSSL
- policies and procedures as defined by the OMC.</p>
-
- <p>Committers also have a responsibility to review code submissions in
- accordance with OpenSSL project policies and procedures.</p>
-
- <p>Commit access is granted by invitation from the OTC and requires
- a prior OMC vote of acceptance. It may be withdrawn at any time by
- a vote of the OMC.</p>
-
- <p>A condition of commit access is that the committer has signed an
- Individual Contributor Licence Agreement (ICLA). If contributions may
- also be from the employer of an individual with commit access then a
- Corporate Contributor Licence Agreement (CCLA) must also be signed and
- include the name of the committer.</p>
-
- <p>In order to retain commit access a committer must have authored or
- reviewed at least one commit within the previous two calendar
- quarters. This will be checked at the beginning of each calendar
- quarter. This rule does not apply if the committer first received
- their commit access during the previous calendar quarter.</p>
-
- <h3><a name="OMC">OpenSSL Management Committee (OMC)</a></h3>
-
- <p>The OMC represents the official voice of the project. All official
- OMC decisions are taken on the basis of a vote.</p>
-
- <p>The OMC:</p>
- <ul>
- <li>makes all decisions regarding management and strategic direction
- of the project; including:
- <ul>
- <li>business requirements;</li>
- <li>feature requirements;</li>
- <li>platform requirements;</li>
- <li>roadmap requirements and priority;</li>
- <li>end-of-life decisions;</li>
- <li>release timing and requirement decisions;</li>
- </ul>
- </li>
- <li>maintains the project infrastructure;</li>
- <li>maintains the project website;</li>
- <li>maintains the project code of conduct;</li>
- <li>sets and maintains all project Bylaws;</li>
- <li>sets and maintains all non-technical policies and non-technical procedures;</li>
- <li>nominates and elects OMC members as required;</li>
- <li>approves or rejects OTC nominations for committers and OTC members;</li>
- <li>adds or removes OMC, OTC, or committers as required;</li>
- <li>adjudicates any objections to OTC decisions;</li>
- <li>adjudicates any objections to any commits to project repositories;</li>
- <li>ensures security issues are dealt with in an appropriate
- manner;</li>
- <li>schedules releases and determines future release plans and the
- development roadmap and priorities;</li>
- <li>maintains all other repositories according to the policies and
- procedures they define.</li>
- </ul>
-
- <p>Membership of the OMC is by invitation only from the existing OMC
- following a passing vote. OMC members may or may not be committers as
- well. If an OMC member is also a committer then all rules that apply
- to committers still apply.</p>
-
- <p>The OMC makes decisions on behalf of the project. In order to have
- a valid voice on the OMC, members must be actively contributing to the
- project. Note that there are many ways to contribute to the project
- but the ones that count in order to participate in the OMC
- decision-making process are the ones listed below.</p>
-
- <p>In general, the OMC will leave technical decisions to the OpenSSL
- Technical Committee (OTC, see below) and not participate in
- discussions related to development and documention of the OpenSSL
- Toolkit. In exceptional cases however an OTC vote can be overruled
- by an OMC vote. Such an exceptional case would be for example if an
- OTC decision stands contrary to OMC policies or decisions.</p>
-
- <p>OMC members may become inactive. In order to remain active a member
- must, in any calendar quarter, contribute by:</p>
- <ul>
- <li>a) Having authored, or been recorded as a reviewer of, at least
- one commit made to any OpenSSL repository (including non-code based
- ones) and</li>
- <li>b) vote in at least two-thirds of the OMC votes closed in the
- first two months of the quarter and the last month of the preceding
- quarter.</li>
- </ul>
-
- <p>The above rules will be applied at the beginning of each calender
- quarter. It does not apply if the OMC member was first appointed, or
- became active again during the previous calendar quarter. The voting
- requirement only includes those votes after the time the member joined
- or was made active again.</p>
-
- <p>If an OMC member remains inactive for one calendar quarter then
- they will no longer be considered an OMC member, but will be listed as
- an OMC Alumni. OMC Alumni have no access to OMC internal resources
- (including email lists) but may request a vote at any time to
- reinstate their membership in the OMC.</p>
-
- <p>Any OMC member can propose a vote to declare another member
- inactive or remove them from OMC membership entirely.</p>
-
- <p>An OMC member can declare themselves inactive, leave the OMC, or
- leave the project entirely. This does not require a vote.</p>
-
- <p>An inactive OMC member can propose a vote that the OMC declare them
- active again. Inactive OMC members cannot vote but can propose issues
- to vote on and participate in discussions. They retain access to OMC
- internal resources.</p>
-
- <h4><a name="omc-voting">OMC Voting Procedures</a></h4>
-
- <p>A vote to change these bylaws will pass if it obtains an in favour
- vote by more than two thirds of the active OMC members and less than
- one quarter votes against by the active OMC members. A vote that does
- not change these bylaws will pass if it has had a vote registered from
- a majority of active OMC members and has had more votes registered in
- favour than votes registered against.</p>
-
- <p>Only active OMC members may vote. A registered vote is a vote in
- favour, a vote against, or an abstention.</p>
-
- <p>Any OMC member (active or inactive) can propose a vote. OMC Alumni
- may only propose a vote to reinstate themselves to the OMC. Each vote
- must include a closing date which must be between seven and fourteen
- calendar days after the start of the vote. Votes to change these
- bylaws must be fourteen calendar days in duration.</p>
-
- <p>In exceptional cases, the closing date for non-bylaw changing votes
- could be less than seven calendar days; for example, a critical issue
- that needs rapid action. A critical issue is hard to define precisely
- but would include cases where a security fix is needed and the details
- will soon be made public. At least one other active OMC member besides
- the proposer needs to agree to the shorter timescale.</p>
-
- <p>A vote closes on its specified date. In addition, any active OMC
- member can declare a vote closed once the number of uncast votes could
- not affect the outcome. Any active OMC member may change their vote up
- until the vote is closed. No vote already cast can be changed after
- the vote is closed. Votes may continue to be cast and recorded after a
- vote is closed up until fourteen days after the start of the vote.
- These votes will count for the purposes of determining OMC member
- activity, but will otherwise not affect the outcome of the vote.</p>
-
- <p>All votes and their outcomes should be recorded and available to
- all OMC members.</p>
-
- <h3><a name="OTC">OpenSSL Technical Committee (OTC)</a></h3>
-
- <p>The OTC represents the official technical voice of the project. All
- OTC decisions are taken on the basis of a vote.</p>
-
- <p>The OTC:</p>
- <ul>
- <li>makes all technical decisions of the code and documentation for OpenSSL including:
- <ul>
- <li>design;</li>
- <li>architecture;</li>
- <li>implementation;</li>
- <li>testing;</li>
- <li>documentation;</li>
- <li>code review;</li>
- <li>quality assurance;</li>
- <li>classification of security issues in accordance with the security policy;</li>
- </ul>
- </li>
-
- <li>produces releases according to OMC requirements;</li>
- <li>establishes and maintains technical policies and technical procedures such as:
- <ul>
- <li>GitHub labels and milestone usage;</li>
- <li>coding style;</li>
- </ul>
- </li>
- <li>nominates to the OMC, addition or removal of OTC members and committers;</li>
- <li>ensures technical aspects of security issues are dealt with in an appropriate
- manner;</li>
- </ul>
-
- <p>Membership of the OTC is by invitation from the OTC and requires
- a prior OMC vote of acceptance. OTC members must be committers and
- hence all rules that apply to committers also apply.
- OTC members may be OMC members and in which case all rules that apply
- to OMC members also apply.</p>
-
- <p>The OTC makes technical decisions on behalf of the project based on
- requirements specified by the OMC. In order to have
- a valid voice on the OTC, members must be actively contributing to the
- technical aspects of the project. Note that there are many ways to contribute to the project
- but the ones that count in order to participate in the OTC
- decision-making process are the ones listed below.</p>
-
- <p>OTC members may become inactive. In order to remain active a member
- must, in any calendar quarter, contribute by:</p>
- <ul>
- <li>a) Having authored, or been recorded as a reviewer of, at least
- one commit made to any OpenSSL repository (including non-code based
- ones) and</li>
- <li>b) vote in at least two-thirds of the OTC votes closed in the
- first two months of the quarter and the last month of the preceding
- quarter and </li>
- <li>c) maintain committer status.</li>
- </ul>
-
- <p>The above rules will be applied at the beginning of each calender
- quarter. It does not apply if the OTC member was first appointed, or
- became active again during the previous calendar quarter. The voting
- requirement only includes those votes after the time the member joined
- or was made active again.</p>
-
- <p>If an OTC member remains inactive for one calendar quarter then
- they will no longer be considered an OTC member.</p>
-
- <p>An OTC member can declare themselves inactive, leave the OTC, or
- leave the project entirely. This does not require a vote.</p>
-
- <p>An inactive OTC member can propose a vote that the OTC declare them
- active again. Inactive OTC members cannot vote but can propose issues
- to vote on and participate in discussions. They retain access to OTC
- internal resources.</p>
-
- <h4><a name="otc-voting">OTC Voting Procedures</a></h4>
-
- <p>A vote will pass if it has had a vote registered from
- a majority of active OTC members and has had more votes registered in
- favour than votes registered against.</p>
-
- <p>Only active OTC members may vote. A registered vote is a vote in
- favour, a vote against, or an abstention.</p>
-
- <p>Any OTC member (active or inactive) can propose a vote.
- Each vote must include a closing date which must be between seven and fourteen
- calendar days after the start of the vote. </p>
-
- <p>In exceptional cases, the closing date
- could be less than seven calendar days; for example, a critical issue
- that needs rapid action. A critical issue is hard to define precisely
- but would include cases where a security fix is needed and the details
- will soon be made public. At least one other active OTC member besides
- the proposer needs to agree to the shorter timescale.</p>
-
- <p>A vote closes on its specified date. In addition, any active OTC
- member can declare a vote closed once the number of uncast votes could
- not affect the outcome. Any active OTC member may change their vote up
- until the vote is closed. No vote already cast can be changed after
- the vote is closed. Votes may continue to be cast and recorded after a
- vote is closed up until fourteen days after the start of the vote.
- These votes will count for the purposes of determining OTC member
- activity, but will otherwise not affect the outcome of the vote.</p>
-
- <p>All votes and their outcomes should be recorded and available to
- all OTC and OMC members.</p>
-
- <h4><a name="otc-transparency">OTC Transparency</a></h4>
- <p>
- The majority of the activity of the OTC will take place in public.
- Non-public discussions or votes shall only occur for issues such as:
- <ul>
- <li>pre-disclosure security problems</li>
- <li>pre-agreement discussions with third parties that require confidentiality</li>
- <li>nominees for OTC or committer roles</li>
- <li>personal conflicts among project personnel</li>
- </ul>
- </p>
-
- <p>Full details (topic, dates, voting members, specific votes cast, vote result) of
- all public votes shall be made available in a public repository.</p>
-
- <h3>OpenSSL Software Foundation (OSF)</h3>
-
- <p>The OpenSSL Software Foundation represents the OpenSSL project in
- legal and most official formal capacities in relation to external
- entities and individuals. This includes, but is not limited to,
- managing contributor license agreements, managing donations,
- registering and holding trademarks, registering and holding domain
- names, obtaining external legal advice, and so on.</p>
-
- <p>Any OMC member may serve as a director of OSF if they wish. To do
- so they should send a request to any existing OSF director.</p>
-
- <h3>OpenSSL Software Services (OSS)</h3>
-
- <p>OpenSSL Software Services represents the OpenSSL project for most
- commercial and quasi-commercial contexts, such as providing formal
- support contracts and brokering consulting contracts for OpenSSL
- committers.</p>
-
- <p>Any OMC member may serve as a director of OSS if they wish, subject
- to certain contractual requirements. To do so they should send a
- request to any existing OSS director.</p>
-
-
- <h2><a name="leave">Leave of absence</a></h2>
-
- <p>An active OMC member, OTC member, or committer may request a leave of absence
- from the project. A leave of absence from the OMC, OTC or committer shall
- suspend inactivity determination for the specified role. All access to
- OMC, OTC or committer resources shall be suspended (disabled) and the OMC
- or OTC member shall be excluded from voting and the committer shall be excluded
- from reviewing or approving source changes. On return from a leave of
- absence, the OMC or OTC member or committer will be deemed to have become active
- as of the date of return.</p>
-
- <p>All of the following criteria must be met in order to qualify as a
- leave of absence:</p>
- <ul>
- <li>a) the member must request via email to the OMC a leave of
- absence at least one week in advance of the requested
- period of leave;</li>
- <li>b) only one leave of absence is permitted per calendar year;</li>
- <li>c) the leave of absence must specify the date of return from
- the leave of absence; </li>
- <li>d) the length of the leave of absence shall be a minimum of one calendar
- month and shall not exceed three calendar months (one quarter); and </li>
- <li>e) the leave of absence applies to all the roles within the
- project (i.e. OMC, OTC and committer if all three roles apply).</li>
- </ul>
-
- <h2><a name="update">Bylaws Update History</a></h2>
- <p>
- The following changes have been made since the bylaws were first
- issued 13-February-2017.
- </p>
- <ul>
- <li>21-November-2019.
- Added <i>OTC</i>. and other related changes.</li>
- <li>20-December-2017.
- Added <i>Leave of absence</i> section.</li>
- </ul>
-
- </div>
- <footer>
- You are here: <a href="/">Home</a>
- : <a href="/policies">Policies</a>
- : <a href="">Bylaws</a>
- <br/><a href="/sitemap.txt">Sitemap</a>
- </footer>
- </article>
- </div>
- <!--#include virtual="sidebar.shtml" -->
- </div>
-</div>
-
-<!--#include virtual="/inc/footer.shtml" -->
-</body>
-
-</html>
-
--- /dev/null
+---
+breadcrumb: Bylaws
+---
+# OpenSSL Bylaws
+
+#### First issued 13th February 2017 Last modified 10th December 2019
+
+This document defines the bylaws under which the OpenSSL Project
+operates. It defines the different project roles, how they contribute to
+the project, and how project decisions are made.
+
+# Roles and Responsibilities
+
+## Users
+
+Users include any individual or organisation that downloads, installs,
+compiles, or uses the OpenSSL command line applications or the OpenSSL
+libraries or the OpenSSL documentation. This includes OpenSSL-based
+derivatives such as patched versions of OpenSSL provided through OS
+distributions, often known as "downstream" versions.
+
+Users may request help and assistance from the project through any
+appropriate forum as designated by the OpenSSL Management Committee
+(OMC). Users may also report bugs, issues, or feature requests; or make
+pull requests through any OMC designated channel.
+
+## Committers
+
+Committers have the ability to make new commits to the main OpenSSL
+Project repository. Collectively, they have the responsibility for
+maintaining the contents of that repository. They must ensure that any
+committed contributions are consistent with all appropriate OpenSSL
+policies and procedures as defined by the OMC.
+
+Committers also have a responsibility to review code submissions in
+accordance with OpenSSL project policies and procedures.
+
+Commit access is granted by invitation from the OTC and requires a prior
+OMC vote of acceptance. It may be withdrawn at any time by a vote of the
+OMC.
+
+A condition of commit access is that the committer has signed an
+Individual Contributor Licence Agreement (ICLA). If contributions may
+also be from the employer of an individual with commit access then a
+Corporate Contributor Licence Agreement (CCLA) must also be signed and
+include the name of the committer.
+
+In order to retain commit access a committer must have authored or
+reviewed at least one commit within the previous two calendar quarters.
+This will be checked at the beginning of each calendar quarter. This
+rule does not apply if the committer first received their commit access
+during the previous calendar quarter.
+
+## [OpenSSL Management Committee (OMC)]{#OMC}
+
+The OMC represents the official voice of the project. All official OMC
+decisions are taken on the basis of a vote.
+
+The OMC:
+
+- makes all decisions regarding management and strategic direction of
+ the project; including:
+ - business requirements;
+ - feature requirements;
+ - platform requirements;
+ - roadmap requirements and priority;
+ - end-of-life decisions;
+ - release timing and requirement decisions;
+- maintains the project infrastructure;
+- maintains the project website;
+- maintains the project code of conduct;
+- sets and maintains all project Bylaws;
+- sets and maintains all non-technical policies and non-technical
+ procedures;
+- nominates and elects OMC members as required;
+- approves or rejects OTC nominations for committers and OTC members;
+- adds or removes OMC, OTC, or committers as required;
+- adjudicates any objections to OTC decisions;
+- adjudicates any objections to any commits to project repositories;
+- ensures security issues are dealt with in an appropriate manner;
+- schedules releases and determines future release plans and the
+ development roadmap and priorities;
+- maintains all other repositories according to the policies and
+ procedures they define.
+
+Membership of the OMC is by invitation only from the existing OMC
+following a passing vote. OMC members may or may not be committers as
+well. If an OMC member is also a committer then all rules that apply to
+committers still apply.
+
+The OMC makes decisions on behalf of the project. In order to have a
+valid voice on the OMC, members must be actively contributing to the
+project. Note that there are many ways to contribute to the project but
+the ones that count in order to participate in the OMC decision-making
+process are the ones listed below.
+
+In general, the OMC will leave technical decisions to the OpenSSL
+Technical Committee (OTC, see below) and not participate in discussions
+related to development and documention of the OpenSSL Toolkit. In
+exceptional cases however an OTC vote can be overruled by an OMC vote.
+Such an exceptional case would be for example if an OTC decision stands
+contrary to OMC policies or decisions.
+
+OMC members may become inactive. In order to remain active a member
+must, in any calendar quarter, contribute by:
+
+- a\) Having authored, or been recorded as a reviewer of, at least
+ one commit made to any OpenSSL repository (including non-code
+ based ones) and
+- b\) vote in at least two-thirds of the OMC votes closed in the
+ first two months of the quarter and the last month of the preceding
+ quarter.
+
+The above rules will be applied at the beginning of each calender
+quarter. It does not apply if the OMC member was first appointed, or
+became active again during the previous calendar quarter. The voting
+requirement only includes those votes after the time the member joined
+or was made active again.
+
+If an OMC member remains inactive for one calendar quarter then they
+will no longer be considered an OMC member, but will be listed as an OMC
+Alumni. OMC Alumni have no access to OMC internal resources (including
+email lists) but may request a vote at any time to reinstate their
+membership in the OMC.
+
+Any OMC member can propose a vote to declare another member inactive or
+remove them from OMC membership entirely.
+
+An OMC member can declare themselves inactive, leave the OMC, or leave
+the project entirely. This does not require a vote.
+
+An inactive OMC member can propose a vote that the OMC declare them
+active again. Inactive OMC members cannot vote but can propose issues to
+vote on and participate in discussions. They retain access to OMC
+internal resources.
+
+### [OMC Voting Procedures]{#omc-voting}
+
+A vote to change these bylaws will pass if it obtains an in favour vote
+by more than two thirds of the active OMC members and less than one
+quarter votes against by the active OMC members. A vote that does not
+change these bylaws will pass if it has had a vote registered from a
+majority of active OMC members and has had more votes registered in
+favour than votes registered against.
+
+Only active OMC members may vote. A registered vote is a vote in favour,
+a vote against, or an abstention.
+
+Any OMC member (active or inactive) can propose a vote. OMC Alumni may
+only propose a vote to reinstate themselves to the OMC. Each vote must
+include a closing date which must be between seven and fourteen calendar
+days after the start of the vote. Votes to change these bylaws must be
+fourteen calendar days in duration.
+
+In exceptional cases, the closing date for non-bylaw changing votes
+could be less than seven calendar days; for example, a critical issue
+that needs rapid action. A critical issue is hard to define precisely
+but would include cases where a security fix is needed and the details
+will soon be made public. At least one other active OMC member besides
+the proposer needs to agree to the shorter timescale.
+
+A vote closes on its specified date. In addition, any active OMC member
+can declare a vote closed once the number of uncast votes could not
+affect the outcome. Any active OMC member may change their vote up until
+the vote is closed. No vote already cast can be changed after the vote
+is closed. Votes may continue to be cast and recorded after a vote is
+closed up until fourteen days after the start of the vote. These votes
+will count for the purposes of determining OMC member activity, but will
+otherwise not affect the outcome of the vote.
+
+All votes and their outcomes should be recorded and available to all OMC
+members.
+
+## [OpenSSL Technical Committee (OTC)]{#OTC}
+
+The OTC represents the official technical voice of the project. All OTC
+decisions are taken on the basis of a vote.
+
+The OTC:
+
+- makes all technical decisions of the code and documentation for
+ OpenSSL including:
+ - design;
+ - architecture;
+ - implementation;
+ - testing;
+ - documentation;
+ - code review;
+ - quality assurance;
+ - classification of security issues in accordance with the
+ security policy;
+- produces releases according to OMC requirements;
+- establishes and maintains technical policies and technical
+ procedures such as:
+ - GitHub labels and milestone usage;
+ - coding style;
+- nominates to the OMC, addition or removal of OTC members and
+ committers;
+- ensures technical aspects of security issues are dealt with in an
+ appropriate manner;
+
+Membership of the OTC is by invitation from the OTC and requires a prior
+OMC vote of acceptance. OTC members must be committers and hence all
+rules that apply to committers also apply. OTC members may be OMC
+members and in which case all rules that apply to OMC members also
+apply.
+
+The OTC makes technical decisions on behalf of the project based on
+requirements specified by the OMC. In order to have a valid voice on the
+OTC, members must be actively contributing to the technical aspects of
+the project. Note that there are many ways to contribute to the project
+but the ones that count in order to participate in the OTC
+decision-making process are the ones listed below.
+
+OTC members may become inactive. In order to remain active a member
+must, in any calendar quarter, contribute by:
+
+- a\) Having authored, or been recorded as a reviewer of, at least one
+ commit made to any OpenSSL repository (including non-code based
+ ones) and
+- b\) vote in at least two-thirds of the OTC votes closed in the first
+ two months of the quarter and the last month of the preceding
+ quarter and
+- c\) maintain committer status.
+
+The above rules will be applied at the beginning of each calender
+quarter. It does not apply if the OTC member was first appointed, or
+became active again during the previous calendar quarter. The voting
+requirement only includes those votes after the time the member joined
+or was made active again.
+
+If an OTC member remains inactive for one calendar quarter then they
+will no longer be considered an OTC member.
+
+An OTC member can declare themselves inactive, leave the OTC, or leave
+the project entirely. This does not require a vote.
+
+An inactive OTC member can propose a vote that the OTC declare them
+active again. Inactive OTC members cannot vote but can propose issues to
+vote on and participate in discussions. They retain access to OTC
+internal resources.
+
+### [OTC Voting Procedures]{#otc-voting}
+
+A vote will pass if it has had a vote registered from a majority of
+active OTC members and has had more votes registered in favour than
+votes registered against.
+
+Only active OTC members may vote. A registered vote is a vote in favour,
+a vote against, or an abstention.
+
+Any OTC member (active or inactive) can propose a vote. Each vote must
+include a closing date which must be between seven and fourteen calendar
+days after the start of the vote.
+
+In exceptional cases, the closing date could be less than seven calendar
+days; for example, a critical issue that needs rapid action. A critical
+issue is hard to define precisely but would include cases where a
+security fix is needed and the details will soon be made public. At
+least one other active OTC member besides the proposer needs to agree to
+the shorter timescale.
+
+A vote closes on its specified date. In addition, any active OTC member
+can declare a vote closed once the number of uncast votes could not
+affect the outcome. Any active OTC member may change their vote up until
+the vote is closed. No vote already cast can be changed after the vote
+is closed. Votes may continue to be cast and recorded after a vote is
+closed up until fourteen days after the start of the vote. These votes
+will count for the purposes of determining OTC member activity, but will
+otherwise not affect the outcome of the vote.
+
+All votes and their outcomes should be recorded and available to all OTC
+and OMC members.
+
+### [OTC Transparency]{#otc-transparency}
+
+The majority of the activity of the OTC will take place in public.
+Non-public discussions or votes shall only occur for issues such as:
+
+- pre-disclosure security problems
+- pre-agreement discussions with third parties that require
+ confidentiality
+- nominees for OTC or committer roles
+- personal conflicts among project personnel
+
+Full details (topic, dates, voting members, specific votes cast, vote
+result) of all public votes shall be made available in a public
+repository.
+
+## OpenSSL Software Foundation (OSF)
+
+The OpenSSL Software Foundation represents the OpenSSL project in legal
+and most official formal capacities in relation to external entities and
+individuals. This includes, but is not limited to, managing contributor
+license agreements, managing donations, registering and holding
+trademarks, registering and holding domain names, obtaining external
+legal advice, and so on.
+
+Any OMC member may serve as a director of OSF if they wish. To do so
+they should send a request to any existing OSF director.
+
+## OpenSSL Software Services (OSS)
+
+OpenSSL Software Services represents the OpenSSL project for most
+commercial and quasi-commercial contexts, such as providing formal
+support contracts and brokering consulting contracts for OpenSSL
+committers.
+
+Any OMC member may serve as a director of OSS if they wish, subject to
+certain contractual requirements. To do so they should send a request to
+any existing OSS director.
+
+# [Leave of absence]{#leave}
+
+An active OMC member, OTC member, or committer may request a leave of
+absence from the project. A leave of absence from the OMC, OTC or
+committer shall suspend inactivity determination for the specified role.
+All access to OMC, OTC or committer resources shall be suspended
+(disabled) and the OMC or OTC member shall be excluded from voting and
+the committer shall be excluded from reviewing or approving source
+changes. On return from a leave of absence, the OMC or OTC member or
+committer will be deemed to have become active as of the date of return.
+
+All of the following criteria must be met in order to qualify as a leave
+of absence:
+
+- a\) the member must request via email to the OMC a leave of absence
+ at least one week in advance of the requested period of leave;
+- b\) only one leave of absence is permitted per calendar year;
+- c\) the leave of absence must specify the date of return from the
+ leave of absence;
+- d\) the length of the leave of absence shall be a minimum of one
+ calendar month and shall not exceed three calendar months (one
+ quarter); and
+- e\) the leave of absence applies to all the roles within the project
+ (i.e. OMC, OTC and committer if all three roles apply).
+
+# [Bylaws Update History]{#update}
+
+The following changes have been made since the bylaws were first issued
+13-February-2017.
+
+- 21-November-2019. Added *OTC*. and other related changes.
+- 20-December-2017. Added *Leave of absence* section.
+++ /dev/null
-<!DOCTYPE html>
-<html lang="en">
- <!--#include virtual="/inc/head.shtml" -->
-
- <body>
- <!--#include virtual="/inc/banner.shtml" -->
-
- <div id="main">
- <div id="content">
- <div class="blog-index">
- <article>
- <header>
- <h1>Platform Policy</h1>
- </header>
- <div class="entry-content">
- <p>Platforms are classified as "primary", "secondary", "community"
- and "unadopted". Support for a new platform should only be
- added if it is being adopted as a primary, secondary or
- community platform.</a></p>
- <dl>
- <dt>Primary</dt>
- <dd>
- <em>Definition:</em> A platform that is regularly tested
- through project CI on a project owned and managed system
- <br/><br/>
-
- New Pull Requests (PRs) should not be merged unless the
- primary platforms are showing as "green" in CI. If the CI
- breaks for a branch (such as for a stable version or master)
- then it should be fixed as a priority.<br/><br/>
- </dd>
- <dt>Secondary</dt>
- <dd>
- <em>Definition:</em> A platform that is regularly tested
- through project CI on a system that is not owned or managed by
- the project. At least one project committer must have access
- to the system and be able and willing to support it.<br/><br/>
-
- New Pull Requests (PRs) should avoid introducing new breaks to
- CI in secondary platforms where possible but may still be
- merged where a resolution is not easily achievable without
- access to the platform. If the CI for a branch (such as for a
- stable version or master) on a secondary platform breaks, then
- a resolution should be sought as soon as is practically
- possible and before a release is made from the branch.<br/><br/>
- </dd>
- <dt>Community</dt>
- <dd>
- <em>Definition:</em> Platforms that one or more members of the
- OpenSSL community have volunteered to support. May or may not
- be in project CI. Members of the community providing support
- do not have to be committers.<br/><br/>
-
- Where a community platform is in project CI then new Pull
- Requests (PRs) should avoid introducing new breaks to CI on
- such platforms where possible but may still be merged where a
- resolution is not easily achievable without access to the
- platform. If the CI for a branch (such as for a
- stable version or master) on a community platform breaks, then
- an attempt should be made to contact the community maintainer
- to request a fix. In the event that a community platform is
- broken in CI for a protracted period then it may be dropped
- from CI.<br/>
-
- If defects are raised that are specific to a community
- platform then the community maintainer may be contacted to
- help find a resolution. If a community maintainer is
- unresponsive, or unable to provide fixes then the platform may
- be moved to "unadopted".<br/><br/>
- </dd>
- <dt>Unadopted</dt>
- <dd>
- <em>Definition:</em> Platforms that no one has volunteered to
- support.<br/><br/>
- Support may still be provided for such platforms where
- possible without access to the platform itself. Platform
- specific issues may be left unresolved where it is not
- feasible to find a suitable fix. Support for such platforms
- may be removed entirely from the OpenSSL code base in future
- releases.
- </dd>
- </dl>
- <p>
- The current primary platforms are:
-
- <table summary="Primary Platforms">
- <tr>
- <th>Target</th>
- <th> </th>
- <th>O/S</th>
- <th> </th>
- <th>Architecture</th>
- <th> </th>
- <th>Toolchain</th>
- </tr>
- <tr>
- <td>linux-x86_64</td>
- <td> </td>
- <td>Ubuntu Server 20.04.3</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>gcc 9.3.0</td>
- </tr>
- <tr>
- <td>linux-generic64</td>
- <td> </td>
- <td>Ubuntu Server 20.04.3</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>gcc 9.3.0</td>
- </tr>
- <tr>
- <td>linux-x86</td>
- <td> </td>
- <td>Debian 11.2</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc 11.2.0</td>
- </tr>
- <tr>
- <td>linux-generic32</td>
- <td> </td>
- <td>Debian 11.2</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc 11.2.0</td>
- </tr>
- <tr>
- <td>BSD-x86_64</td>
- <td> </td>
- <td>FreeBSD 13.0</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>Clang 11</td>
- </tr>
- <tr>
- <td>VC-WIN64A</td>
- <td> </td>
- <td>Windows 10</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>Visual Studio 2019 Community Edition</td>
- </tr>
- <tr>
- <td>mingw64</td>
- <td> </td>
- <td>Windows 10</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>MinGW (64 bit) and MSYS2</td>
- </tr>
- <tr>
- <td>darwin64-x86_64</td>
- <td> </td>
- <td>Mac OS Big Sur (11)</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>clang 12.?</td>
- </tr>
- <tr>
- <td>darwin64-arm64</td>
- <td> </td>
- <td>Mac OS Big Sur (11)</td>
- <td> </td>
- <td>AArch64 (M1)</td>
- <td> </td>
- <td>clang 12.?</td>
- </tr>
- </table>
- </p>
- <p>
- The current secondary platforms are:
-
- <table summary="Secondary Platforms">
- <tr>
- <th>Target</th>
- <th> </th>
- <th>O/S</th>
- <th> </th>
- <th>Architecture</th>
- <th> </th>
- <th>Toolchain</th>
- <th> </th>
- <th>Nominated Committer(s)</th>
- </tr>
- <tr>
- <td>??</td>
- <td> </td>
- <td>??</td>
- <td> </td>
- <td>??</td>
- <td> </td>
- <td>??</td>
- <td> </td>
- <td>??</td>
- </tr>
- </table>
- </p>
- <p>
- The current community platforms are:
-
- <table summary="Community Platforms">
- <tr>
- <th>Target</th>
- <th> </th>
- <th>O/S</th>
- <th> </th>
- <th>Architecture</th>
- <th> </th>
- <th>Toolchain</th>
- <th> </th>
- <th>Nominated Community Member(s)</th>
- </tr>
- <tr>
- <td>vms-alpha</td>
- <td> </td>
- <td>OpenVMS 8.4</td>
- <td> </td>
- <td>alpha</td>
- <td> </td>
- <td>VSI C 7.4</td>
- <td> </td>
- <td>@levitte</td>
- </tr>
- <tr>
- <td>vms-alpha-p32</td>
- <td> </td>
- <td>OpenVMS 8.4</td>
- <td> </td>
- <td>alpha</td>
- <td> </td>
- <td>VSI C 7.4<br />
- (32 bit pointer build)</td>
- <td> </td>
- <td>@levitte</td>
- </tr>
- <tr>
- <td>vms-alpha-p64</td>
- <td> </td>
- <td>OpenVMS 8.4</td>
- <td> </td>
- <td>alpha</td>
- <td> </td>
- <td>VSI C 7.4<br />
- (64 bit pointer build)</td>
- <td> </td>
- <td>@levitte</td>
- </tr>
- <tr>
- <td>vms-ia64</td>
- <td> </td>
- <td>OpenVMS 8.4 8.4</td>
- <td> </td>
- <td>ia64</td>
- <td> </td>
- <td>VSI C 7.4</td>
- <td> </td>
- <td>@levitte</td>
- </tr>
- <tr>
- <td>vms-ia64-p32</td>
- <td> </td>
- <td>OpenVMS 8.4</td>
- <td> </td>
- <td>ia64</td>
- <td> </td>
- <td>VSI C 7.4<br />
- (32 bit pointer build)</td>
- <td> </td>
- <td>@levitte</td>
- </tr>
- <tr>
- <td>vms-ia64-p64</td>
- <td> </td>
- <td>OpenVMS 8.4</td>
- <td> </td>
- <td>ia64</td>
- <td> </td>
- <td>VSI C 7.4<br />
- (64 bit pointer build)</td>
- <td> </td>
- <td>@levitte</td>
- </tr>
- <tr>
- <td>vms-x86_64</td>
- <td> </td>
- <td>OpenVMS 8.4</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>VSI C X7.4<br />
- (cross compile on ia64,<br />
- currently build only)</td>
- <td> </td>
- <td>@levitte</td>
- </tr>
- <tr>
- <td>nonstop-nsx</td>
- <td> </td>
- <td>NonStop OSS L21.06</td>
- <td> </td>
- <td>x86_64 ilp32</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nsx_put</td>
- <td> </td>
- <td>NonStop OSS L21.06</td>
- <td> </td>
- <td>x86_64 ilp32</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nsx_64</td>
- <td> </td>
- <td>NonStop OSS L21.06</td>
- <td> </td>
- <td>x86_64 lp64</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nsx_64_put</td>
- <td> </td>
- <td>NonStop OSS L21.06</td>
- <td> </td>
- <td>x86_64 lp64 PUT</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nsx_spt</td>
- <td> </td>
- <td>NonStop OSS L21.06</td>
- <td> </td>
- <td>x86_64 ilp32 SPT</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nsx_spt_floss</td>
- <td> </td>
- <td>NonStop OSS L21.06</td>
- <td> </td>
- <td>x86_64 ilp32 SPT FLOSS</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nsv</td>
- <td> </td>
- <td>NonStop OSS L21.06</td>
- <td> </td>
- <td>x86_64 ilp32</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nse</td>
- <td> </td>
- <td>NonStop OSS J06.22</td>
- <td> </td>
- <td>ia64 ilp32</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nse_put</td>
- <td> </td>
- <td>NonStop OSS J06.22</td>
- <td> </td>
- <td>ia64 ilp32 PUT</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nse_64</td>
- <td> </td>
- <td>NonStop OSS J06.22</td>
- <td> </td>
- <td>ia64 lp64</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nse_64_put</td>
- <td> </td>
- <td>NonStop OSS J06.22</td>
- <td> </td>
- <td>ia64 lp64 PUT</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nse_spt</td>
- <td> </td>
- <td>NonStop OSS J06.22</td>
- <td> </td>
- <td>ia64 ipl32 SPT</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>nonstop-nse_spt_floss</td>
- <td> </td>
- <td>NonStop OSS J06.22</td>
- <td> </td>
- <td>ia64 ipl32 SPT FLOSS</td>
- <td> </td>
- <td>c99</td>
- <td> </td>
- <td>@rsbeckerca</td>
- </tr>
- <tr>
- <td>linux64-loongarch64</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>loongarch64</td>
- <td> </td>
- <td>gcc</td>
- <td> </td>
- <td>@shipujin</td>
- </tr>
- <tr>
- <td>BSD-ppc</td>
- <td> </td>
- <td>FreeBSD</td>
- <td> </td>
- <td>ppc</td>
- <td> </td>
- <td>LLVM</td>
- <td> </td>
- <td>@pkubaj</td>
- </tr>
- <tr>
- <td>BSD-ppc64</td>
- <td> </td>
- <td>FreeBSD</td>
- <td> </td>
- <td>ppc64</td>
- <td> </td>
- <td>LLVM</td>
- <td> </td>
- <td>@pkubaj</td>
- </tr>
- <tr>
- <td>BSD-ppc64le</td>
- <td> </td>
- <td>FreeBSD</td>
- <td> </td>
- <td>ppc64le</td>
- <td> </td>
- <td>LLVM</td>
- <td> </td>
- <td>@pkubaj</td>
- </tr>
- <tr>
- <td>BSD-riscv64</td>
- <td> </td>
- <td>FreeBSD</td>
- <td> </td>
- <td>riscv64</td>
- <td> </td>
- <td>LLVM</td>
- <td> </td>
- <td>@pkubaj</td>
- </tr>
-
- <tr>
- <td>solaris64-x86_64-gcc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>gcc</td>
- <td> </td>
- <td>@orcl-jlana @cernoseka</td>
- </tr>
- <tr>
- <td>solaris64-x86_64-cc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>Sun C</td>
- <td> </td>
- <td>@orcl-jlana @cernoseka</td>
- </tr>
- <tr>
- <td>solaris64-sparcv9-gcc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>Sparc V9 64 bit</td>
- <td> </td>
- <td>gcc</td>
- <td> </td>
- <td>@orcl-jlana @cernoseka</td>
- </tr>
- <tr>
- <td>solaris64-sparcv9-cc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>Sparc V9 64 bit</td>
- <td> </td>
- <td>Sun C</td>
- <td> </td>
- <td>@orcl-jlana @cernoseka</td>
- </tr>
- <tr>
- <td>linux64-s390x</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>s390x</td>
- <td> </td>
- <td>gcc</td>
- <td> </td>
- <td>@juergenchrist @ifranzki</td>
- </tr>
- <tr>
- <td>linux-aarch64</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>aarch64</td>
- <td> </td>
- <td>gcc</td>
- <td> </td>
- <td>@zorrorffm @daniel-hu-arm @xkqian @tom-cosgrove-arm</td>
- </tr>
- </table>
- </p>
- <p>
- The current unadopted platforms are:
-
- <table summary="Unadopted Platforms">
- <tr>
- <th>Target</th>
- <th> </th>
- <th>O/S</th>
- <th> </th>
- <th>Architecture</th>
- <th> </th>
- <th>Toolchain</th>
- </tr>
- <tr>
- <td>vos-gcc</td>
- <td> </td>
- <td>VOS</td>
- <td> </td>
- <td>??</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>solaris-x86-gcc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>solaris-sparcv7-gcc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>Sparc V7</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>solaris-sparcv8-gcc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>Sparc V8</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>solaris-sparcv9-gcc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>Sparc V9 32 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>solaris-sparcv7-cc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>Sparc V7</td>
- <td> </td>
- <td>Sun C</td>
- </tr>
- <tr>
- <td>solaris-sparcv8-cc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>Sparc V8</td>
- <td> </td>
- <td>Sun C</td>
- </tr>
- <tr>
- <td>solaris-sparcv9-cc</td>
- <td> </td>
- <td>Solaris</td>
- <td> </td>
- <td>Sparc V9 32 bit</td>
- <td> </td>
- <td>Sun C</td>
- </tr>
- <tr>
- <td>irix-mips3-gcc</td>
- <td> </td>
- <td>Irix 6.x</td>
- <td> </td>
- <td>mips64 n32</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>irix-mips3-cc</td>
- <td> </td>
- <td>Irix 6.x</td>
- <td> </td>
- <td>mips64 n32</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>irix64-mips4-gcc</td>
- <td> </td>
- <td>Irix 6.x</td>
- <td> </td>
- <td>mips64 n64</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>irix64-mips4-cc</td>
- <td> </td>
- <td>Irix 6.x</td>
- <td> </td>
- <td>mips64 n64</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>hpux-parisc-gcc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>parisc</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>hpux-parisc1_1-gcc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>parisc 1.1 32 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>hpux64-parisc2-gcc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>parisc 2.0 64 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>hpux-parisc-cc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>parisc</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>hpux-parisc1_1-cc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>parisc 1.0 32 bit</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>hpux64-parisc2-cc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>parisc 2.0 64 bit</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>hpux-ia64-cc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>IA64 32 bit</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>hpux64-ia64-cc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>IA64 64 bit</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>hpux-ia64-gcc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>IA64 32 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>hpux64-ia64-gcc</td>
- <td> </td>
- <td>HP-UX</td>
- <td> </td>
- <td>IA64 64 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>MPE/iX-gcc</td>
- <td> </td>
- <td>MPE/iX</td>
- <td> </td>
- <td>parisc?</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>tru64-alpha-gcc</td>
- <td> </td>
- <td>Tru64</td>
- <td> </td>
- <td>alpha</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>tru64-alpha-cc</td>
- <td> </td>
- <td>Tru64</td>
- <td> </td>
- <td>alpha</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>linux-ppc</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>ppc32</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-ppc64</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>ppc64 big endian</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-ppc64le</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>ppc64 little endian</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-armv4</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>armv4</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-arm64ilp32</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>aarch64-ilp32</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-mips32</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>mips32 o32</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-mips64</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>mips64 n32</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux64-mips64</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>mips64 64 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux64-riscv64</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>riscv64</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-x86-clang</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>clang</td>
- </tr>
- <tr>
- <td>linux-x86_64-clang</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>clang</td>
- </tr>
- <tr>
- <td>linux-x32</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>x86_64 x32</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-ia64</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>ia64</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux32-s390x</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>s390x 31 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-sparcv8</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>sparc v8</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-sparcv9</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>sparc v9 32 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux64-sparcv9</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>sparc v9 64 bit</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-alpha-gcc</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>alpha</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-c64xplus</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>c64xplus</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>linux-c64xplus</td>
- <td> </td>
- <td>Linux</td>
- <td> </td>
- <td>c64xplus</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>BSD-x86</td>
- <td> </td>
- <td>FreeBSD / OpenBSD / NetBSD / ?</td>
- <td> </td>
- <td>x86 a.out</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>BSD-x86-elf</td>
- <td> </td>
- <td>FreeBSD / OpenBSD / NetBSD / ?</td>
- <td> </td>
- <td>x86 elf</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>BSD-sparcv8</td>
- <td> </td>
- <td>?</td>
- <td> </td>
- <td>Sparc v8</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>BSD-sparcv9</td>
- <td> </td>
- <td>?</td>
- <td> </td>
- <td>Sparc v9 32 bit</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>BSD-ia64</td>
- <td> </td>
- <td>?</td>
- <td> </td>
- <td>IA64</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>BSD-x86_64</td>
- <td> </td>
- <td>OpenBSD / NetBSD / ?</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>bsdi-elf-gcc</td>
- <td> </td>
- <td>BSDi</td>
- <td> </td>
- <td>??</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>unixware-2.0</td>
- <td> </td>
- <td>unixware 2.0</td>
- <td> </td>
- <td>??</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>unixware-2.1</td>
- <td> </td>
- <td>unixware 2.1</td>
- <td> </td>
- <td>??</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>unixware-7</td>
- <td> </td>
- <td>unixware 7</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>unixware-7-gcc</td>
- <td> </td>
- <td>unixware 7</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>sco5-cc</td>
- <td> </td>
- <td>Open Server 5?</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>sco5-gcc</td>
- <td> </td>
- <td>Open Server 5?</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>aix-gcc</td>
- <td> </td>
- <td>AIX</td>
- <td> </td>
- <td>ppc32</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>aix64-gcc</td>
- <td> </td>
- <td>AIX</td>
- <td> </td>
- <td>ppc64</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>aix64-gcc-as</td>
- <td> </td>
- <td>AIX</td>
- <td> </td>
- <td>ppc64</td>
- <td> </td>
- <td>gcc with as?</td>
- </tr>
- <tr>
- <td>aix-cc</td>
- <td> </td>
- <td>AIX</td>
- <td> </td>
- <td>ppc32</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>aix64-cc</td>
- <td> </td>
- <td>AIX</td>
- <td> </td>
- <td>ppc64</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>BS2000-OSD</td>
- <td> </td>
- <td>BS2000/OSD</td>
- <td> </td>
- <td>??</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>VC-WIN64I</td>
- <td> </td>
- <td>Windows XP / Windows Server 2008?</td>
- <td> </td>
- <td>ia64</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-WIN32</td>
- <td> </td>
- <td>Windows 10</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-CE</td>
- <td> </td>
- <td>Windows CE</td>
- <td> </td>
- <td>x86 / armv4?</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-WIN64A-masm</td>
- <td> </td>
- <td>Windows 10</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>Visual C with masm</td>
- </tr>
- <tr>
- <td>mingw</td>
- <td> </td>
- <td>Windows 10?</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>UEFI-x86</td>
- <td> </td>
- <td>UEFI</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>UEFI-x86_64</td>
- <td> </td>
- <td>UEFI</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>??</td>
- </tr>
- <tr>
- <td>UWIN</td>
- <td> </td>
- <td>UWIN</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>Cygwin-x86</td>
- <td> </td>
- <td>Windows 10</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>Cygwin-x86_64</td>
- <td> </td>
- <td>Windows 10</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>darwin-ppc</td>
- <td> </td>
- <td>MacOS?</td>
- <td> </td>
- <td>ppc32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>darwin64-ppc</td>
- <td> </td>
- <td>MacOS?</td>
- <td> </td>
- <td>ppc64</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>darwin-i386</td>
- <td> </td>
- <td>MacOS?</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>darwin-i386</td>
- <td> </td>
- <td>MacOS?</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>hurd-x86</td>
- <td> </td>
- <td>Hurd</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>vxworks-ppc60x</td>
- <td> </td>
- <td>vxworks</td>
- <td> </td>
- <td>ppc32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>vxworks-ppcgen</td>
- <td> </td>
- <td>vxworks</td>
- <td> </td>
- <td>ppc32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>vxworks-ppc405</td>
- <td> </td>
- <td>vxworks</td>
- <td> </td>
- <td>ppc32 405</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>vxworks-ppc750</td>
- <td> </td>
- <td>vxworks</td>
- <td> </td>
- <td>ppc32 750</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>vxworks-ppc860</td>
- <td> </td>
- <td>vxworks</td>
- <td> </td>
- <td>ppc32 860</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>vxworks-simlinux</td>
- <td> </td>
- <td>vxworks</td>
- <td> </td>
- <td>x86?</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>vxworks-mips</td>
- <td> </td>
- <td>vxworks</td>
- <td> </td>
- <td>mips32 o32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>uClinux-dist</td>
- <td> </td>
- <td>uClinux</td>
- <td> </td>
- <td>?</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>uClinux-dist64</td>
- <td> </td>
- <td>uClinux</td>
- <td> </td>
- <td>?</td>
- <td> </td>
- <td>gcc</td>
- </tr>
- <tr>
- <td>android-arm</td>
- <td> </td>
- <td>android</td>
- <td> </td>
- <td>armv4</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>android-arm64</td>
- <td> </td>
- <td>android</td>
- <td> </td>
- <td>aarch64</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>android-mips</td>
- <td> </td>
- <td>android</td>
- <td> </td>
- <td>mips32 o32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>android-mips64</td>
- <td> </td>
- <td>android</td>
- <td> </td>
- <td>mips64</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>android-x86</td>
- <td> </td>
- <td>android</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>android-x86_64</td>
- <td> </td>
- <td>android</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>ios-xcrun</td>
- <td> </td>
- <td>iOS</td>
- <td> </td>
- <td>armv7</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>ios64-xcrun</td>
- <td> </td>
- <td>iOS</td>
- <td> </td>
- <td>aarch64</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>iossimulator-xcrun</td>
- <td> </td>
- <td>iOS</td>
- <td> </td>
- <td>?</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>iphoneos-cross</td>
- <td> </td>
- <td>iphoneos?</td>
- <td> </td>
- <td>?</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>ios-cross</td>
- <td> </td>
- <td>iOS</td>
- <td> </td>
- <td>armv7</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>ios64-cross</td>
- <td> </td>
- <td>iOS</td>
- <td> </td>
- <td>aarch64</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>BC-32</td>
- <td> </td>
- <td>Windows 10?</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>Borland C, C++ Builder?</td>
- </tr>
- <tr>
- <td>DJGPP</td>
- <td> </td>
- <td>DOS?</td>
- <td> </td>
- <td>x86?</td>
- <td> </td>
- <td>djgpp</td>
- </tr>
- <tr>
- <td>haiku-x86</td>
- <td> </td>
- <td>Haiku</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>gcc?</td>
- </tr>
- <tr>
- <td>haiku-x86_64</td>
- <td> </td>
- <td>Haiku</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>gcc?</td>
- </tr>
- <tr>
- <td>nonstop-nsx_g</td>
- <td> </td>
- <td>NonStop Guardian</td>
- <td> </td>
- <td>x86_64 ilp32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>nonstop-nsx_g_tandem</td>
- <td> </td>
- <td>NonStop Guardian</td>
- <td> </td>
- <td>x86_64 ilp32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>nonstop-nse_g</td>
- <td> </td>
- <td>NonStop Guardian</td>
- <td> </td>
- <td>ia64 ipl32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>nonstop-nse_g_tandem</td>
- <td> </td>
- <td>NonStop Guardian</td>
- <td> </td>
- <td>ia64 ipl32</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>OS390-Unix</td>
- <td> </td>
- <td>zOS</td>
- <td> </td>
- <td>s390</td>
- <td> </td>
- <td>?</td>
- </tr>
- <tr>
- <td>VC-WIN32-ONECORE</td>
- <td> </td>
- <td>Windows OneCore</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-WIN64A-ONECORE</td>
- <td> </td>
- <td>Windows OneCore</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-WIN32-ARM</td>
- <td> </td>
- <td>Windows OneCore</td>
- <td> </td>
- <td>arm</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-WIN64-ARM</td>
- <td> </td>
- <td>Windows OneCore</td>
- <td> </td>
- <td>aarch64</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-WIN32-UWP</td>
- <td> </td>
- <td>Windows UWP</td>
- <td> </td>
- <td>x86</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-WIN64A-UWP</td>
- <td> </td>
- <td>Windows UWP</td>
- <td> </td>
- <td>x86_64</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-ARM-UWP</td>
- <td> </td>
- <td>Windows UWP</td>
- <td> </td>
- <td>arm</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- <tr>
- <td>VC-ARM64-UWP</td>
- <td> </td>
- <td>Windows UWP</td>
- <td> </td>
- <td>aarch64</td>
- <td> </td>
- <td>Visual C</td>
- </tr>
- </table>
- </p>
- </div>
- <footer>
- You are here: <a href="/">Home</a>
- : <a href="/policies"> Policies</a>
- : <a href="">Platform Policy</a>.
- <br><a href="/sitemap.txt">Sitemap</a>
- </footer>
- </article>
- </div>
- <!--#include virtual="sidebar.shtml" -->
- </div>
- </div>
- <!--#include virtual="/inc/footer.shtml" -->
- </body>
-</html>
--- /dev/null
+---
+breadcrumb: Platform Policy
+---
+# Platform Policy
+
+Platforms are classified as "primary", "secondary", "community"
+and "unadopted". Support for a new platform should only be added if it
+is being adopted as a primary, secondary or community platform.
+
+## Primary
+
+*Definition:* A platform that is regularly tested through project CI
+on a project owned and managed system.
+
+New Pull Requests (PRs) should not be merged unless the primary
+platforms are showing as "green" in CI. If the CI breaks for a branch
+(such as for a stable version or master) then it should be fixed as a
+priority.
+
+
+## Secondary
+
+*Definition:* A platform that is regularly tested through project CI
+on a system that is not owned or managed by the project. At least one
+project committer must have access to the system and be able and
+willing to support it.
+
+New Pull Requests (PRs) should avoid introducing new breaks to CI in
+secondary platforms where possible but may still be merged where a
+resolution is not easily achievable without access to the platform. If
+the CI for a branch (such as for a stable version or master) on a
+secondary platform breaks, then a resolution should be sought as soon
+as is practically possible and before a release is made from the
+branch.
+
+## Community
+
+*Definition:* Platforms that one or more members of the OpenSSL
+community have volunteered to support. May or may not be in project
+CI. Members of the community providing support do not have to be
+committers.
+
+Where a community platform is in project CI then new Pull Requests
+(PRs) should avoid introducing new breaks to CI on such platforms
+where possible but may still be merged where a resolution is not
+easily achievable without access to the platform. If the CI for a
+branch (such as for a stable version or master) on a community
+platform breaks, then an attempt should be made to contact the
+community maintainer to request a fix. In the event that a community
+platform is broken in CI for a protracted period then it may be
+dropped from CI.\
+If defects are raised that are specific to a community platform then
+the community maintainer may be contacted to help find a
+resolution. If a community maintainer is unresponsive, or unable to
+provide fixes then the platform may be moved to "unadopted".
+
+## Unadopted
+
+*Definition:* Platforms that no one has volunteered to support.
+
+Support may still be provided for such platforms where possible
+without access to the platform itself. Platform specific issues may be
+left unresolved where it is not feasible to find a suitable fix.
+Support for such platforms may be removed entirely from the OpenSSL
+code base in future releases.
+
+------------------------------------------------------------
+
+The current primary platforms are:
+
+| Target | | O/S | | Architecture | | Toolchain |
+|------------------|--------|-----------------------|--------|--------------|--------|--------------------------------------|
+| linux-x86\_64 | | Ubuntu Server 20.04.3 | | x86\_64 | | gcc 9.3.0 |
+| linux-generic64 | | Ubuntu Server 20.04.3 | | x86\_64 | | gcc 9.3.0 |
+| linux-x86 | | Debian 11.2 | | x86 | | gcc 11.2.0 |
+| linux-generic32 | | Debian 11.2 | | x86 | | gcc 11.2.0 |
+| BSD-x86\_64 | | FreeBSD 13.0 | | x86\_64 | | Clang 11 |
+| VC-WIN64A | | Windows 10 | | x86\_64 | | Visual Studio 2019 Community Edition |
+| mingw64 | | Windows 10 | | x86\_64 | | MinGW (64 bit) and MSYS2 |
+| darwin64-x86\_64 | | Mac OS Big Sur (11) | | x86\_64 | | clang 12.? |
+| darwin64-arm64 | | Mac OS Big Sur (11) | | AArch64 (M1) | | clang 12.? |
+
+The current secondary platforms are:
+
+| Target | | O/S | | Architecture | | Toolchain | | Nominated Committer(s) |
+|--------|--------|-----|--------|--------------|--------|-----------|--------|------------------------|
+| ?? | | ?? | | ?? | | ?? | | ?? |
+
+The current community platforms are:
+
+| Target | | O/S | | Architecture | | Toolchain | | Nominated Community Member(s) |
+|-------------------------|--------|--------------------|--------|-------------------------|--------|-----------------|--------|---------------------------------------------------------|
+| vms-alpha | | OpenVMS 8.4 | | alpha | | VSI C 7.4 | | \@levitte |
+| vms-alpha-p32 | | OpenVMS 8.4 | | alpha | | VSI C 7.4 [^1] | | \@levitte |
+| vms-alpha-p64 | | OpenVMS 8.4 | | alpha | | VSI C 7.4 [^2] | | \@levitte |
+| vms-ia64 | | OpenVMS 8.4 | | ia64 | | VSI C 7.4 | | \@levitte |
+| vms-ia64-p32 | | OpenVMS 8.4 | | ia64 | | VSI C 7.4 [^1] | | \@levitte |
+| vms-ia64-p64 | | OpenVMS 8.4 | | ia64 | | VSI C 7.4 [^2] | | \@levitte |
+| vms-x86\_64 | | OpenVMS 8.4 | | x86\_64 | | VSI C X7.4 [^3] | | \@levitte |
+| nonstop-nsx | | NonStop OSS L21.06 | | x86\_64 ilp32 | | c99 | | \@rsbeckerca |
+| nonstop-nsx\_put | | NonStop OSS L21.06 | | x86\_64 ilp32 PUT | | c99 | | \@rsbeckerca |
+| nonstop-nsx\_64 | | NonStop OSS L21.06 | | x86\_64 lp64 | | c99 | | \@rsbeckerca |
+| nonstop-nsx\_64\_put | | NonStop OSS L21.06 | | x86\_64 lp64 PUT | | c99 | | \@rsbeckerca |
+| nonstop-nsx\_spt | | NonStop OSS L21.06 | | x86\_64 ilp32 SPT | | c99 | | \@rsbeckerca |
+| nonstop-nsx\_spt\_floss | | NonStop OSS L21.06 | | x86\_64 ilp32 SPT FLOSS | | c99 | | \@rsbeckerca |
+| nonstop-nsv | | NonStop OSS L21.06 | | x86\_64 ilp32 | | c99 | | \@rsbeckerca |
+| nonstop-nse | | NonStop OSS J06.22 | | ia64 ilp32 | | c99 | | \@rsbeckerca |
+| nonstop-nse\_put | | NonStop OSS J06.22 | | ia64 ilp32 PUT | | c99 | | \@rsbeckerca |
+| nonstop-nse\_64 | | NonStop OSS J06.22 | | ia64 lp64 | | c99 | | \@rsbeckerca |
+| nonstop-nse\_64\_put | | NonStop OSS J06.22 | | ia64 lp64 PUT | | c99 | | \@rsbeckerca |
+| nonstop-nse\_spt | | NonStop OSS J06.22 | | ia64 ipl32 SPT | | c99 | | \@rsbeckerca |
+| nonstop-nse\_spt\_floss | | NonStop OSS J06.22 | | ia64 ipl32 SPT FLOSS | | c99 | | \@rsbeckerca |
+| linux64-loongarch64 | | Linux | | loongarch64 | | gcc | | \@shipujin |
+| BSD-ppc | | FreeBSD | | ppc | | LLVM | | \@pkubaj |
+| BSD-ppc64 | | FreeBSD | | ppc64 | | LLVM | | \@pkubaj |
+| BSD-ppc64le | | FreeBSD | | ppc64le | | LLVM | | \@pkubaj |
+| BSD-riscv64 | | FreeBSD | | riscv64 | | LLVM | | \@pkubaj |
+| solaris64-x86\_64-gcc | | Solaris | | x86\_64 | | gcc | | \@orcl-jlana \@cernoseka |
+| solaris64-x86\_64-cc | | Solaris | | x86\_64 | | Sun C | | \@orcl-jlana \@cernoseka |
+| solaris64-sparcv9-gcc | | Solaris | | Sparc V9 64 bit | | gcc | | \@orcl-jlana \@cernoseka |
+| solaris64-sparcv9-cc | | Solaris | | Sparc V9 64 bit | | Sun C | | \@orcl-jlana \@cernoseka |
+| linux64-s390x | | Linux | | s390x | | gcc | | \@juergenchrist \@ifranzki |
+| linux-aarch64 | | Linux | | aarch64 | | gcc | | \@zorrorffm \@daniel-hu-arm \@xkqian \@tom-cosgrove-arm |
+
+[^1]: [VMS] 32 bit pointer build
+[^2]: [VMS] 64 bit pointer build
+[^3]: [VMS] cross compile on ia64, currently build only
+
+The current unadopted platforms are:
+
+| Target | | O/S | | Architecture | | Toolchain |
+|------------------------|--------|-----------------------------------|--------|---------------------|--------|-------------------------|
+| vos-gcc | | VOS | | ?? | | gcc |
+| solaris-x86-gcc | | Solaris | | x86 | | gcc |
+| solaris-sparcv7-gcc | | Solaris | | Sparc V7 | | gcc |
+| solaris-sparcv8-gcc | | Solaris | | Sparc V8 | | gcc |
+| solaris-sparcv9-gcc | | Solaris | | Sparc V9 32 bit | | gcc |
+| solaris-sparcv7-cc | | Solaris | | Sparc V7 | | Sun C |
+| solaris-sparcv8-cc | | Solaris | | Sparc V8 | | Sun C |
+| solaris-sparcv9-cc | | Solaris | | Sparc V9 32 bit | | Sun C |
+| irix-mips3-gcc | | Irix 6.x | | mips64 n32 | | gcc |
+| irix-mips3-cc | | Irix 6.x | | mips64 n32 | | ?? |
+| irix64-mips4-gcc | | Irix 6.x | | mips64 n64 | | gcc |
+| irix64-mips4-cc | | Irix 6.x | | mips64 n64 | | ?? |
+| hpux-parisc-gcc | | HP-UX | | parisc | | gcc |
+| hpux-parisc1\_1-gcc | | HP-UX | | parisc 1.1 32 bit | | gcc |
+| hpux64-parisc2-gcc | | HP-UX | | parisc 2.0 64 bit | | gcc |
+| hpux-parisc-cc | | HP-UX | | parisc | | ?? |
+| hpux-parisc1\_1-cc | | HP-UX | | parisc 1.0 32 bit | | ?? |
+| hpux64-parisc2-cc | | HP-UX | | parisc 2.0 64 bit | | ?? |
+| hpux-ia64-cc | | HP-UX | | IA64 32 bit | | ?? |
+| hpux64-ia64-cc | | HP-UX | | IA64 64 bit | | ?? |
+| hpux-ia64-gcc | | HP-UX | | IA64 32 bit | | gcc |
+| hpux64-ia64-gcc | | HP-UX | | IA64 64 bit | | gcc |
+| MPE/iX-gcc | | MPE/iX | | parisc? | | gcc |
+| tru64-alpha-gcc | | Tru64 | | alpha | | gcc |
+| tru64-alpha-cc | | Tru64 | | alpha | | ?? |
+| linux-ppc | | Linux | | ppc32 | | gcc |
+| linux-ppc64 | | Linux | | ppc64 big endian | | gcc |
+| linux-ppc64le | | Linux | | ppc64 little endian | | gcc |
+| linux-armv4 | | Linux | | armv4 | | gcc |
+| linux-arm64ilp32 | | Linux | | aarch64-ilp32 | | gcc |
+| linux-mips32 | | Linux | | mips32 o32 | | gcc |
+| linux-mips64 | | Linux | | mips64 n32 | | gcc |
+| linux64-mips64 | | Linux | | mips64 64 bit | | gcc |
+| linux64-riscv64 | | Linux | | riscv64 | | gcc |
+| linux-x86-clang | | Linux | | x86 | | clang |
+| linux-x86\_64-clang | | Linux | | x86\_64 | | clang |
+| linux-x32 | | Linux | | x86\_64 x32 | | gcc |
+| linux-ia64 | | Linux | | ia64 | | gcc |
+| linux32-s390x | | Linux | | s390x 31 bit | | gcc |
+| linux-sparcv8 | | Linux | | sparc v8 | | gcc |
+| linux-sparcv9 | | Linux | | sparc v9 32 bit | | gcc |
+| linux64-sparcv9 | | Linux | | sparc v9 64 bit | | gcc |
+| linux-alpha-gcc | | Linux | | alpha | | gcc |
+| linux-c64xplus | | Linux | | c64xplus | | gcc |
+| linux-c64xplus | | Linux | | c64xplus | | gcc |
+| BSD-x86 | | FreeBSD / OpenBSD / NetBSD / ? | | x86 a.out | | ?? |
+| BSD-x86-elf | | FreeBSD / OpenBSD / NetBSD / ? | | x86 elf | | ?? |
+| BSD-sparcv8 | | ? | | Sparc v8 | | ?? |
+| BSD-sparcv9 | | ? | | Sparc v9 32 bit | | ?? |
+| BSD-ia64 | | ? | | IA64 | | ?? |
+| BSD-x86\_64 | | OpenBSD / NetBSD / ? | | x86\_64 | | ?? |
+| bsdi-elf-gcc | | BSDi | | ?? | | ?? |
+| unixware-2.0 | | unixware 2.0 | | ?? | | ?? |
+| unixware-2.1 | | unixware 2.1 | | ?? | | ?? |
+| unixware-7 | | unixware 7 | | x86 | | ?? |
+| unixware-7-gcc | | unixware 7 | | x86 | | gcc |
+| sco5-cc | | Open Server 5? | | x86 | | ?? |
+| sco5-gcc | | Open Server 5? | | x86 | | gcc |
+| aix-gcc | | AIX | | ppc32 | | gcc |
+| aix64-gcc | | AIX | | ppc64 | | gcc |
+| aix64-gcc-as | | AIX | | ppc64 | | gcc with as? |
+| aix-cc | | AIX | | ppc32 | | ?? |
+| aix64-cc | | AIX | | ppc64 | | ?? |
+| BS2000-OSD | | BS2000/OSD | | ?? | | ?? |
+| VC-WIN64I | | Windows XP / Windows Server 2008? | | ia64 | | Visual C |
+| VC-WIN32 | | Windows 10 | | x86 | | Visual C |
+| VC-CE | | Windows CE | | x86 / armv4? | | Visual C |
+| VC-WIN64A-masm | | Windows 10 | | x86 | | Visual C with masm |
+| mingw | | Windows 10? | | x86 | | gcc |
+| UEFI-x86 | | UEFI | | x86 | | ?? |
+| UEFI-x86\_64 | | UEFI | | x86\_64 | | ?? |
+| UWIN | | UWIN | | x86 | | |
+| Cygwin-x86 | | Windows 10 | | x86 | | gcc |
+| Cygwin-x86\_64 | | Windows 10 | | x86\_64 | | gcc |
+| darwin-ppc | | MacOS? | | ppc32 | | |
+| darwin64-ppc | | MacOS? | | ppc64 | | |
+| darwin-i386 | | MacOS? | | x86 | | |
+| darwin-i386 | | MacOS? | | x86 | | |
+| hurd-x86 | | Hurd | | x86 | | gcc |
+| vxworks-ppc60x | | vxworks | | ppc32 | | |
+| vxworks-ppcgen | | vxworks | | ppc32 | | |
+| vxworks-ppc405 | | vxworks | | ppc32 405 | | |
+| vxworks-ppc750 | | vxworks | | ppc32 750 | | |
+| vxworks-ppc860 | | vxworks | | ppc32 860 | | |
+| vxworks-simlinux | | vxworks | | x86? | | |
+| vxworks-mips | | vxworks | | mips32 o32 | | |
+| uClinux-dist | | uClinux | | ? | | gcc |
+| uClinux-dist64 | | uClinux | | ? | | gcc |
+| android-arm | | android | | armv4 | | |
+| android-arm64 | | android | | aarch64 | | |
+| android-mips | | android | | mips32 o32 | | |
+| android-mips64 | | android | | mips64 | | |
+| android-x86 | | android | | x86 | | |
+| android-x86\_64 | | android | | x86\_64 | | |
+| ios-xcrun | | iOS | | armv7 | | |
+| ios64-xcrun | | iOS | | aarch64 | | |
+| iossimulator-xcrun | | iOS | | ? | | |
+| iphoneos-cross | | iphoneos? | | ? | | |
+| ios-cross | | iOS | | armv7 | | |
+| ios64-cross | | iOS | | aarch64 | | |
+| BC-32 | | Windows 10? | | x86 | | Borland C, C++ Builder? |
+| DJGPP | | DOS? | | x86? | | djgpp |
+| haiku-x86 | | Haiku | | x86 | | gcc? |
+| haiku-x86\_64 | | Haiku | | x86\_64 | | gcc? |
+| nonstop-nsx\_g | | NonStop Guardian | | x86\_64 ilp32 | | |
+| nonstop-nsx\_g\_tandem | | NonStop Guardian | | x86\_64 ilp32 | | |
+| nonstop-nse\_g | | NonStop Guardian | | ia64 ipl32 | | |
+| nonstop-nse\_g\_tandem | | NonStop Guardian | | ia64 ipl32 | | |
+| OS390-Unix | | zOS | | s390 | | |
+| VC-WIN32-ONECORE | | Windows OneCore | | x86 | | Visual C |
+| VC-WIN64A-ONECORE | | Windows OneCore | | x86\_64 | | Visual C |
+| VC-WIN32-ARM | | Windows OneCore | | arm | | Visual C |
+| VC-WIN64-ARM | | Windows OneCore | | aarch64 | | Visual C |
+| VC-WIN32-UWP | | Windows UWP | | x86 | | Visual C |
+| VC-WIN64A-UWP | | Windows UWP | | x86\_64 | | Visual C |
+| VC-ARM-UWP | | Windows UWP | | arm | | Visual C |
+| VC-ARM64-UWP | | Windows UWP | | aarch64 | | Visual C |
+++ /dev/null
-<!DOCTYPE html>
-<html lang="en">
-<!--#include virtual="/inc/head.shtml" -->
-
-<body>
-<!--#include virtual="/inc/banner.shtml" -->
-
-<div id="main">
- <div id="content">
- <div class="blog-index">
- <article>
- <header>
- <h2>Release Strategy</h2>
- <h5>
- First issued 23rd December 2014<br/>
- Last modified 7th January 2020
- </h5>
- </header>
-
- <div class="entry-content">
-
- <p>
- As of release 3.0.0, the OpenSSL versioning scheme is changing
- to a more contemporary format: MAJOR.MINOR.PATCH
- </p>
-
- <p>
- With this format, API/ABI compatibility will be guaranteed
- for the same MAJOR version number. Previously we guaranteed
- API/ABI compatibility across the same MAJOR.MINOR combination.
- </p>
-
- <ul>
- <li>MAJOR: API/ABI incompatible changes will increase this number</li>
- <li>MINOR: API/ABI compatible feature releases will change this</li>
- <li>PATCH: Bug fix releases will increment this number. We also
- allow backporting of accessor functions in these releases.</li>
- </ul>
-
- <p>
- This more closely aligns with the expectations of users who are
- familiar with semantic versioning. However, we have not adopted
- semantic versioning in the strict sense of its rules, because it
- would mean changing our current LTS policies and practices.
- </p>
-
- <p>
- The current 1.1.1 versioning scheme remains unchanged:
-
- <blockquote><i>
- As of release 1.0.0 the OpenSSL versioning scheme was improved
- to better meet developers' and vendors' expectations. Letter
- releases, such as 1.0.2a, exclusively contain bug and security
- fixes and no new features. Releases that change the last digit,
- e.g. 1.1.0 vs. 1.1.1, can and are likely to
- contain new features, but in a way that does not break binary
- compatibility. This means that an application compiled and
- dynamically linked with 1.1.0 does not need to be recompiled
- when the shared library is updated to 1.1.1. It should be
- noted that some features are transparent to the application
- such as the maximum negotiated TLS version and cipher suites,
- performance improvements and so on. There is no need to
- recompile applications to benefit from these features.
- </i></blockquote>
- </p>
-
- <hr />
-
- <p>With regards to current and future releases the OpenSSL
- project has adopted the following policy:</p>
-
- <ul>
- <li>Version 3.0 will be supported until 2026-09-07 (LTS).</li>
- <li>Version 1.1.1 will be supported until 2023-09-11 (LTS).</li>
- <li>Version 1.0.2 is no longer supported. Extended support
- for 1.0.2 to gain access to security fixes for that version is
- <a href="/support/contracts.html">available</a>.</li>
- <li>Versions 1.1.0, 1.0.1, 1.0.0 and 0.9.8 are no longer supported.</li>
- </ul>
-
- <p>We may designate a release as a Long Term Support (LTS)
- release. LTS releases will be supported for at least five years
- and we will specify one at least every four years. Non-LTS
- releases will be supported for at least two years.</p>
-
- <p>During the final year
- of support, we do not commit to anything other than security
- fixes. Before that, bug and security fixes will be applied
- as appropriate.</p>
-
- <p>The addition of new platforms to LTS branches is acceptable so
- long as the required changes consist solely of additions to
- configuration.</p>
-
- <hr />
-
- <p>
- Before a major release, we make a number of pre-releases, labeled
- <i>alpha</i> and <i>beta</i>.
- </p>
-
- <p>An <i>alpha</i> release means:</p>
- <ul>
- <li>Not (necessarily) feature complete</li>
- <li>Not necessarily all new APIs in place yet</li>
- </ul>
-
- <p>A <i>beta</i> release means:</p>
- <ul>
- <li>Feature complete/Feature freeze</li>
- <li>Bug fixes only</li>
- </ul>
-
- <p>
- For any major or minor release, we have defined the following
- release criteria:
- </p>
-
- <ul>
- <li>
- All open github issues/PRs older than 2 weeks at the time of
- release need to be assessed for relevance to the version being
- released. Any flagged with the a milestone for the version
- to be released must be closed (see below).
- </li>
- <li>
- Clean builds in Travis and Appveyor for two days.
- </li>
- <li>
- run-checker.sh succeeds on 2 consecutive days before release.
- </li>
- <li>
- No open Coverity issues (not flagged as "False Positive" or
- "Ignore").
- </li>
- </ul>
-
- <p>
- Valid reasons for closing an issue/PR with a milestone for the
- version might be:
- </p>
-
- <ul>
- <li>
- We have just now or sometime in the past fixed the issue
- </li>
- <li>
- Unable to reproduce (following discussion with original reporter
- if possible)
- </li>
- <li>
- Working as intended
- </li>
- <li>
- Deliberate decision not to fix this issue until a later release (this
- wouldn't actually close the issue/PR but change the milestone
- instead)
- </li>
- <li>
- Not enough information and unable to contact reporter
- </li>
- </ul>
-
- <hr />
-
- <p>No API or ABI breaking changes are allowed in a minor or patch release.
- The following stability rules apply to all changes made to code
- targeted for a major release from version 3.0.0 or later:</p>
- <ul>
- <li>No existing public interface can be modified except where changes
- are unlikely to break source compatibility or where structures are made
- opaque.
- <li>No existing public interface can be removed until its replacement
- has been in place in an LTS stable release. The original interface must
- also have been documented as deprecated for at least 5 years. A public
- interface is any function, structure or macro declared in a public
- header file.</li>
- <li>When structures are made opaque, any newly required accessor
- macros or functions are added in a feature release of the extant LTS
- release and all supported intermediate successor releases.</li>
- </ul>
-
- </div>
- <footer>
- You are here: <a href="/">Home</a>
- : <a href="/policies">Policies</a>
- : <a href="">Release Strategy</a>
- <br/><a href="/sitemap.txt">Sitemap</a>
- </footer>
- </article>
- </div>
- <!--#include virtual="sidebar.shtml" -->
- </div>
-</div>
-
-<!--#include virtual="/inc/footer.shtml" -->
-</body>
-
-</html>
-
--- /dev/null
+---
+breadcrumb: Release Strategy
+---
+# Release Strategy
+
+#### First issued 23rd December 2014 Last modified 7th January 2020
+
+As of release 3.0.0, the OpenSSL versioning scheme is changing to a more
+contemporary format: MAJOR.MINOR.PATCH
+
+With this format, API/ABI compatibility will be guaranteed for the same
+MAJOR version number. Previously we guaranteed API/ABI compatibility
+across the same MAJOR.MINOR combination.
+
+- MAJOR: API/ABI incompatible changes will increase this number
+- MINOR: API/ABI compatible feature releases will change this
+- PATCH: Bug fix releases will increment this number. We also allow
+ backporting of accessor functions in these releases.
+
+This more closely aligns with the expectations of users who are familiar
+with semantic versioning. However, we have not adopted semantic
+versioning in the strict sense of its rules, because it would mean
+changing our current LTS policies and practices.
+
+The current 1.1.1 versioning scheme remains unchanged:
+
+> *As of release 1.0.0 the OpenSSL versioning scheme was improved to
+> better meet developers' and vendors' expectations. Letter releases,
+> such as 1.0.2a, exclusively contain bug and security fixes and no new
+> features. Releases that change the last digit, e.g. 1.1.0 vs. 1.1.1,
+> can and are likely to contain new features, but in a way that does not
+> break binary compatibility. This means that an application compiled
+> and dynamically linked with 1.1.0 does not need to be recompiled when
+> the shared library is updated to 1.1.1. It should be noted that some
+> features are transparent to the application such as the maximum
+> negotiated TLS version and cipher suites, performance improvements and
+> so on. There is no need to recompile applications to benefit from
+> these features.*
+
+------------------------------------------------------------------------
+
+With regards to current and future releases the OpenSSL project has
+adopted the following policy:
+
+- Version 3.0 will be supported until 2026-09-07 (LTS).
+- Version 1.1.1 will be supported until 2023-09-11 (LTS).
+- Version 1.0.2 is no longer supported. Extended support for 1.0.2 to
+ gain access to security fixes for that version is
+ [available](/support/contracts.html).
+- Versions 1.1.0, 1.0.1, 1.0.0 and 0.9.8 are no longer supported.
+
+We may designate a release as a Long Term Support (LTS) release. LTS
+releases will be supported for at least five years and we will specify
+one at least every four years. Non-LTS releases will be supported for at
+least two years.
+
+During the final year of support, we do not commit to anything other
+than security fixes. Before that, bug and security fixes will be applied
+as appropriate.
+
+The addition of new platforms to LTS branches is acceptable so long as
+the required changes consist solely of additions to configuration.
+
+------------------------------------------------------------------------
+
+Before a major release, we make a number of pre-releases, labeled
+*alpha* and *beta*.
+
+An *alpha* release means:
+
+- Not (necessarily) feature complete
+- Not necessarily all new APIs in place yet
+
+A *beta* release means:
+
+- Feature complete/Feature freeze
+- Bug fixes only
+
+For any major or minor release, we have defined the following release
+criteria:
+
+- All open github issues/PRs older than 2 weeks at the time of release
+ need to be assessed for relevance to the version being released. Any
+ flagged with the a milestone for the version to be released must be
+ closed (see below).
+- Clean builds in Travis and Appveyor for two days.
+- run-checker.sh succeeds on 2 consecutive days before release.
+- No open Coverity issues (not flagged as "False Positive" or
+ "Ignore").
+
+Valid reasons for closing an issue/PR with a milestone for the version
+might be:
+
+- We have just now or sometime in the past fixed the issue
+- Unable to reproduce (following discussion with original reporter if
+ possible)
+- Working as intended
+- Deliberate decision not to fix this issue until a later release
+ (this wouldn't actually close the issue/PR but change the milestone
+ instead)
+- Not enough information and unable to contact reporter
+
+------------------------------------------------------------------------
+
+No API or ABI breaking changes are allowed in a minor or patch release.
+The following stability rules apply to all changes made to code targeted
+for a major release from version 3.0.0 or later:
+
+- No existing public interface can be modified except where changes
+ are unlikely to break source compatibility or where structures are
+ made opaque.
+- No existing public interface can be removed until its replacement
+ has been in place in an LTS stable release. The original interface
+ must also have been documented as deprecated for at least 5 years. A
+ public interface is any function, structure or macro declared in a
+ public header file.
+- When structures are made opaque, any newly required accessor macros
+ or functions are added in a feature release of the extant LTS
+ release and all supported intermediate successor releases.
+++ /dev/null
-<!-- sidebar.inc -->
-<aside class="sidebar">
- <section>
- <h1><a href=".">Policies</a></h1>
- <ul>
- <li>
- <a href="omc-bylaws.html">OpenSSL Bylaws</a>
- </li>
- <li>
- <a href="general/">General Policies</a>
- </li>
- <li>
- <a href="technical/">Technical Policies</a>
- </li>
- <li>
- <a href="cla.html">Contributor Agreements</a>
- </li>
- </ul>
- </section>
-</aside>
-<!-- end -->
---
-title: OpenSSL Technical Policies
+breadcrumb: OpenSSL Technical Policies
---
These are the technical policies and procedures established by the OTC
in accordance with the [project bylaws].
+++ /dev/null
-<!DOCTYPE html>
-<html lang="en">
-<!--#include virtual="/inc/head.shtml" -->
-
-<body>
-<!--#include virtual="/inc/banner.shtml" -->
-
- <div id="main">
- <div id="content">
- <div class="blog-index">
- <article>
- <header>
- <h2>Trademark Policy</h2>
- <h5>
- Last modified 27th October 2017
- </h5>
- </header>
- <div class="entry-content">
-
- <h2>Introduction</h2>
- <p>This policy is derived from the
- <a href="https://www.debian.org/trademark">Debian Trademark Policy</a>,
- with thanks.</p>
-
- <p>OpenSSL is committed to protect and ensure consistent usage
- of its trademark, logos, and styles and also make it easier for
- every <em>bonafide</em> user to use. As a part of this process,
- the OpenSSL trademark is a registered United States trademark
- of the OpenSSL Software Foundation. For registration outside the
- United States, we have filed a <a
- href="http://en.wikipedia.org/wiki/Madrid_system">Madrid Protocol</a>
- application to extend the protection in the European Union,
- China and Japan.</p>
-
- <h2>Trademark Policy</h2>
-
- <p>This policy encompasses all marks, in word and logo form,
- collectively referred to as <q>OpenSSL trademarks.</q></p>
-
- <p>The objective of this trademark policy is:</p>
-
- <ol>
- <li>to encourage widespread use and adoption of the OpenSSL
- trademarks,</li>
- <li>to clarify proper usage of OpenSSL trademarks by third
- parties,</li>
- <li>to prevent misuse of OpenSSL trademarks that can confuse
- or mislead users
- with respect to OpenSSL or its affiliates.</li>
- </ol>
-
- <p>Please note that it is not the goal of this policy to limit
- commercial activity around OpenSSL. We encourage businesses
- to work on OpenSSL while being compliant with this policy.</p>
-
- <p>Following are the guidelines for the proper use of OpenSSL
- trademarks by publishers and other third parties. Any use of or
- reference to OpenSSL trademarks that is inconsistent with these
- guidelines, or other unauthorized use of or reference to OpenSSL
- trademarks, or use of marks that are confusingly similar to
- OpenSSL trademarks, is prohibited and may violate OpenSSL
- trademark rights.</p>
-
- <p>Any use of OpenSSL trademarks in a misleading and false manner
- or in a manner that disparages OpenSSL, such as untruthful
- advertising, is always prohibited.</p>
-
- <h3>When You Can Use the OpenSSL Trademarks Without Asking Permission</h3>
-
- <ol>
- <li>You can use OpenSSL trademarks to make true factual
- statements about OpenSSL or communicate compatibility with your
- product truthfully.</li>
- <li>Your intended use qualifies as <q>nominative fair use</q> of
- the OpenSSL trademarks, i.e., merely identifying that you are
- talking about OpenSSL in a text, without suggesting sponsorship
- or endorsement.</li>
- <li>You can use OpenSSL trademarks to describe or advertise your
- services or products relating to OpenSSL in a way that is not
- misleading.</li>
- <li>You can use OpenSSL trademarks to describe OpenSSL in
- articles, titles or blog posts.</li>
- <li>You can make t-shirts, desktop wallpapers, caps, or other
- merchandise with OpenSSL trademarks for
- <em>non-commercial usage</em>.</li>
- <li>You can also make merchandise with OpenSSL trademarks for
- <em>commercial usage</em>. In case of commercial usage, we
- recommend that you truthfully advertise to customers which part
- of the selling price, if any, will be donated to the OpenSSL
- project.</li>
- </ol>
-
- <h3>When You Can NEVER Use the OpenSSL Trademarks Without Asking Permission</h3>
-
- <ol>
- <li>You cannot use OpenSSL trademarks in any way that suggests
- an affiliation with or endorsement by the OpenSSL project or
- community, if the same is not true.</li>
- <li>You cannot use OpenSSL trademarks in a company or
- organization name or as the name of a product or service.</li>
- <li>You cannot use a name that is confusingly similar to OpenSSL
- trademarks.</li>
- <li>You cannot use OpenSSL trademarks in a domain name, with or
- without commercial intent.</li>
- </ol>
-
- <h3>How to Use the OpenSSL Trademarks</h3>
-
- <ol>
- <li>Use the OpenSSL trademarks in a manner that makes it clear
- that your project is related to the OpenSSL project, but that it
- is not part of OpenSSL, produced by the OpenSSL project, or
- endorsed by the OpenSSL project.</li>
- <li>Acknowledge OpenSSL Software Foundation's ownership of the
- OpenSSL trademark prominently. For example:<br/><br/>
- <p>[TRADEMARK] is a (<q>registered,</q> if applicable) trademark
- owned by the OpenSSL Software Foundation.</p></li>
- <li>Include a disclaimer of sponsorship, affiliation, or
- endorsement by OpenSSL on your website and on all related
- printed materials. For example:<br/><br/>
- <p>X PROJECT is not affiliated with OpenSSL. OpenSSL is a
- registered trademark owned by OpenSSL Software
- Foundation.</p></li>
- <li>Distinguish the OpenSSL trademarks from the surrounding
- words by italicizing, bolding or underlining it.</li>
- <li>Use the OpenSSL trademarks in their exact form, neither
- abbreviated or hyphenated, nor combined with any other word or
- words.</li>
- <li>Do not create acronyms using the OpenSSL trademarks.</li>
- </ol>
-
- <h3>Permission To Use</h3>
-
- <p>When in doubt about the use of OpenSSL trademarks, or to
- request permission for uses not allowed by this policy, please
- send an email to
- <a href="mailto:osf-contact@openssl.org">osf-contact@openssl.org</a>.
- Be sure to include the following information in the body of your
- message:</p>
- <ul>
- <li>Name of the User</li>
- <li>Name of the organization/project</li>
- <li>Purpose of Use (commercial/non-commercial)</li>
- <li>Nature of Use</li>
- </ul>
-
- <h3>Guidelines for Using Logos</h3>
-
- <ul>
- <li>Any scaling must retain the original proportions of the
- logo.</li>
- <li>Do not use the OpenSSL logos as part of your company logo or
- product logo or branding itself. They can be used as part of a
- page describing your products or services.</li>
- <li>You need not ask us for permission to use logos on your own
- website solely as a hyperlink to the OpenSSL project
- website.</li>
- </ul>
-
- <p>
- For any queries with respect to these guidelines, please send an
- email to
- <a href="mailto:osf-contact@openssl.org">osf-contact@openssl.org</a>.</p>
-
- <h2>Organisations Licensed to Use OpenSSL Trademarks</h2>
-
- <p>The following organisations have been licensed to use
- the OpenSSL trademark through a License Agreement:</p>
-
- <ol>
- <li>OpenSSL Validation Services, Inc., while not affiliated with
- the OpenSSL project, has historical rights to use the OpenSSL
- trademark.</li>
- </ol>
-
- </div>
- <footer>
- You are here: <a href="/">Home</a>
- : <a href=".">Policies</a>
- : <a href="">Trademark Policy</a>
- <br/><a href="/sitemap.txt">Sitemap</a>
- </footer>
- </article>
- </div>
- <!--#include virtual="sidebar.shtml" -->
- </div>
- </div>
- <!--#include virtual="/inc/footer.shtml" -->
- </body>
- </html>
-
--- /dev/null
+---
+breadcrumb: Trademark Policy
+---
+# Trademark Policy
+
+#### Last modified 27th October 2017
+
+# Introduction
+
+This policy is derived from the [Debian Trademark
+Policy](https://www.debian.org/trademark), with thanks.
+
+OpenSSL is committed to protect and ensure consistent usage of its
+trademark, logos, and styles and also make it easier for every
+*bonafide* user to use. As a part of this process, the OpenSSL trademark
+is a registered United States trademark of the OpenSSL Software
+Foundation. For registration outside the United States, we have filed a
+[Madrid Protocol](http://en.wikipedia.org/wiki/Madrid_system)
+application to extend the protection in the European Union, China and
+Japan.
+
+# Trademark Policy
+
+This policy encompasses all marks, in word and logo form, collectively
+referred to as "OpenSSL trademarks."
+
+The objective of this trademark policy is:
+
+1. to encourage widespread use and adoption of the OpenSSL trademarks,
+2. to clarify proper usage of OpenSSL trademarks by third parties,
+3. to prevent misuse of OpenSSL trademarks that can confuse or mislead
+ users with respect to OpenSSL or its affiliates.
+
+Please note that it is not the goal of this policy to limit commercial
+activity around OpenSSL. We encourage businesses to work on OpenSSL
+while being compliant with this policy.
+
+Following are the guidelines for the proper use of OpenSSL trademarks by
+publishers and other third parties. Any use of or reference to OpenSSL
+trademarks that is inconsistent with these guidelines, or other
+unauthorized use of or reference to OpenSSL trademarks, or use of marks
+that are confusingly similar to OpenSSL trademarks, is prohibited and
+may violate OpenSSL trademark rights.
+
+Any use of OpenSSL trademarks in a misleading and false manner or in a
+manner that disparages OpenSSL, such as untruthful advertising, is
+always prohibited.
+
+## When You Can Use the OpenSSL Trademarks Without Asking Permission
+
+1. You can use OpenSSL trademarks to make true factual statements about
+ OpenSSL or communicate compatibility with your product truthfully.
+2. Your intended use qualifies as "nominative fair use" of the OpenSSL
+ trademarks, i.e., merely identifying that you are talking about
+ OpenSSL in a text, without suggesting sponsorship or endorsement.
+3. You can use OpenSSL trademarks to describe or advertise your
+ services or products relating to OpenSSL in a way that is not
+ misleading.
+4. You can use OpenSSL trademarks to describe OpenSSL in articles,
+ titles or blog posts.
+5. You can make t-shirts, desktop wallpapers, caps, or other
+ merchandise with OpenSSL trademarks for *non-commercial usage*.
+6. You can also make merchandise with OpenSSL trademarks for
+ *commercial usage*. In case of commercial usage, we recommend that
+ you truthfully advertise to customers which part of the selling
+ price, if any, will be donated to the OpenSSL project.
+
+## When You Can NEVER Use the OpenSSL Trademarks Without Asking Permission
+
+1. You cannot use OpenSSL trademarks in any way that suggests an
+ affiliation with or endorsement by the OpenSSL project or community,
+ if the same is not true.
+2. You cannot use OpenSSL trademarks in a company or organization name
+ or as the name of a product or service.
+3. You cannot use a name that is confusingly similar to OpenSSL
+ trademarks.
+4. You cannot use OpenSSL trademarks in a domain name, with or without
+ commercial intent.
+
+## How to Use the OpenSSL Trademarks
+
+1. Use the OpenSSL trademarks in a manner that makes it clear that your
+ project is related to the OpenSSL project, but that it is not part
+ of OpenSSL, produced by the OpenSSL project, or endorsed by the
+ OpenSSL project.
+
+2. Acknowledge OpenSSL Software Foundation's ownership of the OpenSSL
+ trademark prominently. For example:
+
+ \[TRADEMARK\] is a ("registered," if applicable) trademark owned by
+ the OpenSSL Software Foundation.
+
+3. Include a disclaimer of sponsorship, affiliation, or endorsement by
+ OpenSSL on your website and on all related printed materials. For
+ example:
+
+ X PROJECT is not affiliated with OpenSSL. OpenSSL is a registered
+ trademark owned by OpenSSL Software Foundation.
+
+4. Distinguish the OpenSSL trademarks from the surrounding words by
+ italicizing, bolding or underlining it.
+
+5. Use the OpenSSL trademarks in their exact form, neither abbreviated
+ or hyphenated, nor combined with any other word or words.
+
+6. Do not create acronyms using the OpenSSL trademarks.
+
+## Permission To Use
+
+When in doubt about the use of OpenSSL trademarks, or to request
+permission for uses not allowed by this policy, please send an email to
+<osf-contact@openssl.org>. Be sure to include the following information
+in the body of your message:
+
+- Name of the User
+- Name of the organization/project
+- Purpose of Use (commercial/non-commercial)
+- Nature of Use
+
+## Guidelines for Using Logos
+
+- Any scaling must retain the original proportions of the logo.
+- Do not use the OpenSSL logos as part of your company logo or product
+ logo or branding itself. They can be used as part of a page
+ describing your products or services.
+- You need not ask us for permission to use logos on your own website
+ solely as a hyperlink to the OpenSSL project website.
+
+For any queries with respect to these guidelines, please send an email
+to <osf-contact@openssl.org>.
+
+# Organisations Licensed to Use OpenSSL Trademarks
+
+The following organisations have been licensed to use the OpenSSL
+trademark through a License Agreement:
+
+1. OpenSSL Validation Services, Inc., while not affiliated with the
+ OpenSSL project, has historical rights to use the OpenSSL trademark.
+++ /dev/null
-<!DOCTYPE html>
-<html lang="en">
-<!--#include virtual="/inc/head.shtml" -->
-
-<body>
-<!--#include virtual="/inc/banner.shtml" -->
-
-<div id="main">
- <div id="content">
- <div class="blog-index">
- <article>
- <header>
- <h2>Travel Reimbursement Policy</h2>
- <h5>
- First issued 28th February 2018<br/>
- </h5>
- </header>
-
- <div class="entry-content">
-
- <p>The OpenSSL project may pay travel expenses for OMC members when
- pre-approved by the OMC or when it is an official OMC meeting (as
- determined by vote). Project members may seek to be reimbursed if
- their employer is not covering the expense. The requirements for
- reimbursement are:</p>
-
- <ul>
- <li>An email sent to openssl-omc, including scanned attachments of
- all receipts over 30 Euros.</li>
- <li>Barring exceptional circumstances, for an all-day meeting the
- project will pay for arrival the day before and departure the
- following morning.</li>
- <li>When presenting at a conference, the project will pay the
- expenses for the entire conference provided the attendee agrees
- to act as representative of the project during that time.</li>
- <li>Reasonable lodging and meal expenses during the travel time
- will be covered.</li>
- <li>Barring exceptional circumstances, room service, minibar,
- in-room movies, and other similar amenities are not
- covered.</li>
- </ul>
-
- </div>
- <footer>
- You are here: <a href="/">Home</a>
- : <a href="/policies">Policies</a>
- : <a href="">Travel Reimbursement Policy</a>
- <br/><a href="/sitemap.txt">Sitemap</a>
- </footer>
- </article>
- </div>
- <!--#include virtual="sidebar.shtml" -->
- </div>
-</div>
-
-<!--#include virtual="/inc/footer.shtml" -->
-</body>
-
-</html>
-
--- /dev/null
+---
+breadcrumb: Travel Reimbursement Policy
+---
+# Travel Reimbursement Policy
+
+#### First issued 28th February 2018
+
+The OpenSSL project may pay travel expenses for OMC members when
+pre-approved by the OMC or when it is an official OMC meeting (as
+determined by vote). Project members may seek to be reimbursed if their
+employer is not covering the expense. The requirements for reimbursement
+are:
+
+- An email sent to openssl-omc, including scanned attachments of all
+ receipts over 30 Euros.
+- Barring exceptional circumstances, for an all-day meeting the
+ project will pay for arrival the day before and departure the
+ following morning.
+- When presenting at a conference, the project will pay the expenses
+ for the entire conference provided the attendee agrees to act as
+ representative of the project during that time.
+- Reasonable lodging and meal expenses during the travel time will be
+ covered.
+- Barring exceptional circumstances, room service, minibar, in-room
+ movies, and other similar amenities are not covered.
projects / openssl-web.git / commitdiff