third_party/rust/linux-raw-sys/ORG_CODE_OF_CONDUCT.md

   1 # Bytecode Alliance Organizational Code of Conduct (OCoC)
   2
   3 *Note*: this Code of Conduct pertains to organizations' behavior. Please also see the [Individual Code of Conduct](CODE_OF_CONDUCT.md).
   4
   5 ## Preamble
   6
   7 The Bytecode Alliance (BA) welcomes involvement from organizations,
   8 including commercial organizations.  This document is an
   9 *organizational* code of conduct, intended particularly to provide
  10 guidance to commercial organizations.  It is distinct from the
  11 [Individual Code of Conduct (ICoC)](CODE_OF_CONDUCT.md), and does not
  12 replace the ICoC. This OCoC applies to any group of people acting in
  13 concert as a BA member or as a participant in BA activities, whether
  14 or not that group is formally incorporated in some jurisdiction.
  15
  16 The code of conduct described below is not a set of rigid rules, and
  17 we did not write it to encompass every conceivable scenario that might
  18 arise.  For example, it is theoretically possible there would be times
  19 when asserting patents is in the best interest of the BA community as
  20 a whole.  In such instances, consult with the BA, strive for
  21 consensus, and interpret these rules with an intent that is generous
  22 to the community the BA serves.
  23
  24 While we may revise these guidelines from time to time based on
  25 real-world experience, overall they are based on a simple principle:
  26
  27 *Bytecode Alliance members should observe the distinction between
  28  public community functions and private functions — especially
  29  commercial ones — and should ensure that the latter support, or at
  30  least do not harm, the former.*
  31
  32 ## Guidelines
  33
  34  * **Do not cause confusion about Wasm standards or interoperability.**
  35
  36    Having an interoperable WebAssembly core is a high priority for
  37    the BA, and members should strive to preserve that core.  It is fine
  38    to develop additional non-standard features or APIs, but they
  39    should always be clearly distinguished from the core interoperable
  40    Wasm.
  41
  42    Treat the WebAssembly name and any BA-associated names with
  43    respect, and follow BA trademark and branding guidelines.  If you
  44    distribute a customized version of software originally produced by
  45    the BA, or if you build a product or service using BA-derived
  46    software, use names that clearly distinguish your work from the
  47    original.  (You should still provide proper attribution to the
  48    original, of course, wherever such attribution would normally be
  49    given.)
  50
  51    Further, do not use the WebAssembly name or BA-associated names in
  52    other public namespaces in ways that could cause confusion, e.g.,
  53    in company names, names of commercial service offerings, domain
  54    names, publicly-visible social media accounts or online service
  55    accounts, etc.  It may sometimes be reasonable, however, to
  56    register such a name in a new namespace and then immediately donate
  57    control of that account to the BA, because that would help the project
  58    maintain its identity.
  59
  60    For further guidance, see the BA Trademark and Branding Policy
  61    [TODO: create policy, then insert link].
  62
  63  * **Do not restrict contributors.** If your company requires
  64    employees or contractors to sign non-compete agreements, those
  65    agreements must not prevent people from participating in the BA or
  66    contributing to related projects.
  67
  68    This does not mean that all non-compete agreements are incompatible
  69    with this code of conduct.  For example, a company may restrict an
  70    employee's ability to solicit the company's customers.  However, an
  71    agreement must not block any form of technical or social
  72    participation in BA activities, including but not limited to the
  73    implementation of particular features.
  74
  75    The accumulation of experience and expertise in individual persons,
  76    who are ultimately free to direct their energy and attention as
  77    they decide, is one of the most important drivers of progress in
  78    open source projects.  A company that limits this freedom may hinder
  79    the success of the BA's efforts.
  80
  81  * **Do not use patents as offensive weapons.** If any BA participant
  82    prevents the adoption or development of BA technologies by
  83    asserting its patents, that undermines the purpose of the
  84    coalition.  The collaboration fostered by the BA cannot include
  85    members who act to undermine its work.
  86
  87  * **Practice responsible disclosure** for security vulnerabilities.
  88    Use designated, non-public reporting channels to disclose technical
  89    vulnerabilities, and give the project a reasonable period to
  90    respond, remediate, and patch.  [TODO: optionally include the
  91    security vulnerability reporting URL here.]
  92
  93    Vulnerability reporters may patch their company's own offerings, as
  94    long as that patching does not significantly delay the reporting of
  95    the vulnerability.  Vulnerability information should never be used
  96    for unilateral commercial advantage.  Vendors may legitimately
  97    compete on the speed and reliability with which they deploy
  98    security fixes, but withholding vulnerability information damages
  99    everyone in the long run by risking harm to the BA project's
 100    reputation and to the security of all users.
 101
 102  * **Respect the letter and spirit of open source practice.** While
 103      there is not space to list here all possible aspects of standard
 104      open source practice, some examples will help show what we mean:
 105
 106    * Abide by all applicable open source license terms.  Do not engage
 107      in copyright violation or misattribution of any kind.
 108
 109    * Do not claim others' ideas or designs as your own.
 110
 111    * When others engage in publicly visible work (e.g., an upcoming
 112      demo that is coordinated in a public issue tracker), do not
 113      unilaterally announce early releases or early demonstrations of
 114      that work ahead of their schedule in order to secure private
 115      advantage (such as marketplace advantage) for yourself.
 116
 117    The BA reserves the right to determine what constitutes good open
 118    source practices and to take action as it deems appropriate to
 119    encourage, and if necessary enforce, such practices.
 120
 121 ## Enforcement
 122
 123 Instances of organizational behavior in violation of the OCoC may
 124 be reported by contacting the Bytecode Alliance CoC team at
 125 [report@bytecodealliance.org](mailto:report@bytecodealliance.org). The
 126 CoC team will review and investigate all complaints, and will respond
 127 in a way that it deems appropriate to the circumstances. The CoC team
 128 is obligated to maintain confidentiality with regard to the reporter of
 129 an incident. Further details of specific enforcement policies may be
 130 posted separately.
 131
 132 When the BA deems an organization in violation of this OCoC, the BA
 133 will, at its sole discretion, determine what action to take.  The BA
 134 will decide what type, degree, and duration of corrective action is
 135 needed, if any, before a violating organization can be considered for
 136 membership (if it was not already a member) or can have its membership
 137 reinstated (if it was a member and the BA canceled its membership due
 138 to the violation).
 139
 140 In practice, the BA's first approach will be to start a conversation,
 141 with punitive enforcement used only as a last resort.  Violations
 142 often turn out to be unintentional and swiftly correctable with all
 143 parties acting in good faith.