diff options
Diffstat (limited to 'vendor/rustix/ORG_CODE_OF_CONDUCT.md')
| -rw-r--r-- | vendor/rustix/ORG_CODE_OF_CONDUCT.md | 143 |
1 files changed, 0 insertions, 143 deletions
diff --git a/vendor/rustix/ORG_CODE_OF_CONDUCT.md b/vendor/rustix/ORG_CODE_OF_CONDUCT.md deleted file mode 100644 index 6f4fb3f..0000000 --- a/vendor/rustix/ORG_CODE_OF_CONDUCT.md +++ /dev/null @@ -1,143 +0,0 @@ -# Bytecode Alliance Organizational Code of Conduct (OCoC) - -*Note*: this Code of Conduct pertains to organizations' behavior. Please also see the [Individual Code of Conduct](CODE_OF_CONDUCT.md). - -## Preamble - -The Bytecode Alliance (BA) welcomes involvement from organizations, -including commercial organizations. This document is an -*organizational* code of conduct, intended particularly to provide -guidance to commercial organizations. It is distinct from the -[Individual Code of Conduct (ICoC)](CODE_OF_CONDUCT.md), and does not -replace the ICoC. This OCoC applies to any group of people acting in -concert as a BA member or as a participant in BA activities, whether -or not that group is formally incorporated in some jurisdiction. - -The code of conduct described below is not a set of rigid rules, and -we did not write it to encompass every conceivable scenario that might -arise. For example, it is theoretically possible there would be times -when asserting patents is in the best interest of the BA community as -a whole. In such instances, consult with the BA, strive for -consensus, and interpret these rules with an intent that is generous -to the community the BA serves. - -While we may revise these guidelines from time to time based on -real-world experience, overall they are based on a simple principle: - -*Bytecode Alliance members should observe the distinction between - public community functions and private functions — especially - commercial ones — and should ensure that the latter support, or at - least do not harm, the former.* - -## Guidelines - - * **Do not cause confusion about Wasm standards or interoperability.** - - Having an interoperable WebAssembly core is a high priority for - the BA, and members should strive to preserve that core. It is fine - to develop additional non-standard features or APIs, but they - should always be clearly distinguished from the core interoperable - Wasm. - - Treat the WebAssembly name and any BA-associated names with - respect, and follow BA trademark and branding guidelines. If you - distribute a customized version of software originally produced by - the BA, or if you build a product or service using BA-derived - software, use names that clearly distinguish your work from the - original. (You should still provide proper attribution to the - original, of course, wherever such attribution would normally be - given.) - - Further, do not use the WebAssembly name or BA-associated names in - other public namespaces in ways that could cause confusion, e.g., - in company names, names of commercial service offerings, domain - names, publicly-visible social media accounts or online service - accounts, etc. It may sometimes be reasonable, however, to - register such a name in a new namespace and then immediately donate - control of that account to the BA, because that would help the project - maintain its identity. - - For further guidance, see the BA Trademark and Branding Policy - [TODO: create policy, then insert link]. - - * **Do not restrict contributors.** If your company requires - employees or contractors to sign non-compete agreements, those - agreements must not prevent people from participating in the BA or - contributing to related projects. - - This does not mean that all non-compete agreements are incompatible - with this code of conduct. For example, a company may restrict an - employee's ability to solicit the company's customers. However, an - agreement must not block any form of technical or social - participation in BA activities, including but not limited to the - implementation of particular features. - - The accumulation of experience and expertise in individual persons, - who are ultimately free to direct their energy and attention as - they decide, is one of the most important drivers of progress in - open source projects. A company that limits this freedom may hinder - the success of the BA's efforts. - - * **Do not use patents as offensive weapons.** If any BA participant - prevents the adoption or development of BA technologies by - asserting its patents, that undermines the purpose of the - coalition. The collaboration fostered by the BA cannot include - members who act to undermine its work. - - * **Practice responsible disclosure** for security vulnerabilities. - Use designated, non-public reporting channels to disclose technical - vulnerabilities, and give the project a reasonable period to - respond, remediate, and patch. [TODO: optionally include the - security vulnerability reporting URL here.] - - Vulnerability reporters may patch their company's own offerings, as - long as that patching does not significantly delay the reporting of - the vulnerability. Vulnerability information should never be used - for unilateral commercial advantage. Vendors may legitimately - compete on the speed and reliability with which they deploy - security fixes, but withholding vulnerability information damages - everyone in the long run by risking harm to the BA project's - reputation and to the security of all users. - - * **Respect the letter and spirit of open source practice.** While - there is not space to list here all possible aspects of standard - open source practice, some examples will help show what we mean: - - * Abide by all applicable open source license terms. Do not engage - in copyright violation or misattribution of any kind. - - * Do not claim others' ideas or designs as your own. - - * When others engage in publicly visible work (e.g., an upcoming - demo that is coordinated in a public issue tracker), do not - unilaterally announce early releases or early demonstrations of - that work ahead of their schedule in order to secure private - advantage (such as marketplace advantage) for yourself. - - The BA reserves the right to determine what constitutes good open - source practices and to take action as it deems appropriate to - encourage, and if necessary enforce, such practices. - -## Enforcement - -Instances of organizational behavior in violation of the OCoC may -be reported by contacting the Bytecode Alliance CoC team at -[report@bytecodealliance.org](mailto:report@bytecodealliance.org). The -CoC team will review and investigate all complaints, and will respond -in a way that it deems appropriate to the circumstances. The CoC team -is obligated to maintain confidentiality with regard to the reporter of -an incident. Further details of specific enforcement policies may be -posted separately. - -When the BA deems an organization in violation of this OCoC, the BA -will, at its sole discretion, determine what action to take. The BA -will decide what type, degree, and duration of corrective action is -needed, if any, before a violating organization can be considered for -membership (if it was not already a member) or can have its membership -reinstated (if it was a member and the BA canceled its membership due -to the violation). - -In practice, the BA's first approach will be to start a conversation, -with punitive enforcement used only as a last resort. Violations -often turn out to be unintentional and swiftly correctable with all -parties acting in good faith. |