adding community specification license materials to cover patent licensing for openvex spec

Signed-off-by: jorydotcom <[email protected]>

Author: jorydotcom

governance/0._CS_Contributor_License_Agreement.md

@@ -0,0 +1,18 @@
+# Community Specification Contributor License Agreement 1.0
+
+By making a Contribution to this repository, I agree to the terms of the following documents located at [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0):
+
+(a) Community Specification License 1.0 (.0_Community_Specification_License-v1.md)
+
+(b) Community Specification Governance Policy 1.0 (5._Governance.md)
+
+(c) Community Specification Contribution Policy 1.0 (6._Contributing.md)
+
+(d) Community Specification Code of Conduct (8._Code_of_Conduct.md)
+
+
+In addition, for source code contributions, I certify that:
+
+(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best  of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this working group and the contribution may be public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this agreement or the open source license(s) involved.
+
+I represent that I am legally entitled to make the grants set forth in the documents above.  If my employer(s) has rights to intellectual property that may be infringed by the materials developed by this Working Group, I represent that I have received permission to enter these agreements on behalf of that employer.

governance/1._Community_Specification_License-v1.md

@@ -0,0 +1,5 @@
+# Scope
+
+[Include a detailed description of this Working Group’s Scope.  This Scope is important is it establishes the bounds of each contributor's and licensee's patent commitment. For guidance on drafting an appropriate Scope, you may find [ISO's guidance (see page 5)](https://www.iso.org/files/live/sites/isoorg/files/developing_standards/docs/en/how-to-write-standards.pdf "ISO How To Write Standards Guide") helpful.]
+
+Any changes of Scope are not retroactive. 

governance/2._Scope.md

@@ -0,0 +1,58 @@
+# Notices
+
+## Code of Conduct
+
+Contact for Code of Conduct issues or inquires:  _________________
+
+[Ideally list two different individuals above (not a generic mailing list) as someone submitting a Code of Conduct complaint will want to know exactly who is receiving the complaint. We recommend two individuals in the case one of the individuals is the subject of or directly involved in the subject of a complaint.]
+
+
+## License Acceptance
+
+Per Community Specification License 1.0 Section 2.1.3.3, Licensees may indicate their acceptance of the Community Specification License by issuing a pull request to the Specification’s repository’s Notice.md file, including the Licensee’s name, authorized individuals' names, and repository system identifier (e.g. GitHub ID), and specification version.
+
+A Licensee may consent to accepting the current Community Specification License version or any future version of the Community Specification License by indicating "or later" after their specification version.
+
+---------------------------------------------------------------------------------
+
+Licensee’s name:
+
+Authorized individual and system identifier:
+
+Specification version:
+
+---------------------------------------------------------------------------------
+
+## Withdrawals
+
+Name of party withdrawing:
+
+Date of withdrawal:  
+
+---------------------------------------------------------------------------------
+
+## Exclusions
+
+This section includes any Exclusion Notices made against a Draft Deliverable or Approved Deliverable as set forth in the Community Specification Development License.  Each Exclusion Notice must include the following information:
+
+-	Name of party making the Exclusion Notice:
+
+-	Name of patent owner:
+
+-	Specification:
+
+-	Version number:
+
+**For issued patents and published patent applications:**
+
+	(i)	patent number(s) or title and application number(s), as the case may be:
+
+	(ii)	identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim.
+
+**For unpublished patent applications must provide either:**
+
+	(i) the text of the filed application; or
+    
+	(ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim.
+
+-----------------------------------------------------------------------------------------

governance/3._Notices.md

@@ -0,0 +1,13 @@
+# Licenses
+
+## Specification License
+
+Specifications in the repository are subject to the **Community Specification License 1.0** available at [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0).
+
+## Source Code License
+
+If source code is included in this repository, or for sample or reference code included in the specification itself, that code is subject to the MIT license unless otherwise designated. In the case of any conflict or confusion within this specification repository between the Community Specification License and the MIT or other designated license, the terms of the Community Specification License shall apply.
+
+If source code is included in this repository, or for sample or reference code included in the specification itself, that code is subject to the MIT license unless otherwise marked.
+
+In the case of any conflict or confusion within this specification repository between the Community Specification License and the designated source code license, the terms of the Community Specification License shall apply.

governance/4._License.md

@@ -0,0 +1,51 @@
+# Community Specification Governance Policy 1.0
+
+This document provides the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”).  Each Working Group and must adhere to the requirements in this document.
+
+## 1.	Roles.
+
+Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group.
+
+**1.1.	Maintainer.** “Maintainers” are responsible for organizing activities around developing, maintaining, and updating the specification(s) developed by the Working Group.  Maintainers are also responsible for determining consensus and coordinating appeals.  Each Working Group will designate one or more Maintainer for that Working Group.  A Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants.  
+
+**1.2.	Editor.**  “Editors” are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines. Each Working Group will designate an Editor for that Working Group.  A Working Group may select a new Editor upon Approval of the Working Group Participants.
+
+**1.3.	Participants.**  “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License.
+
+## 2.	Decision Making.
+
+**2.1.	Consensus-Based Decision Making.**  Working Groups make decisions through a consensus process (“Approval” or “Approved”).  While the agreement of all Participants is preferred, it is not required for consensus.  Rather, the Maintainer will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and nature of support and objections.  The Maintainer will document evidence of consensus in accordance with these requirements. 
+
+**2.2.	Appeal Process.**  Decisions may be appealed be via a pull request or an issue, and that appeal will be considered by the Maintainer in good faith, who will respond in writing within a reasonable time.
+
+## 3.	Ways of Working.
+
+Inspired by [ANSI’s Essential Requirements for Due Process](https://share.ansi.org/Shared%20Documents/Standards%20Activities/American%20National%20Standards/Procedures,%20Guides,%20and%20Forms/2020_ANSI_Essential_Requirements.pdf), Community Specification Working Groups must adhere to consensus-based due process requirements.  These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of Community Specifications.  Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus.
+
+**3.1.	Openness.**  Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements.  Membership in a Working Group’s parent organization, if any, may be required.
+
+**3.2.	Lack of Dominance.**  The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints.
+
+**3.3.	Balance.**  The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance.
+
+**3.4.	Coordination and Harmonization.**  Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards.
+
+**3.5.	Consideration of Views and Objections.**  Prompt consideration shall be given to the written views and objections of all Participants.
+
+**3.6.	Written procedures.**  This governance document and other materials documenting the Community Specification development process shall be available to any interested person.
+
+## 4.	Specification Development Process.  
+
+**4.1.	Pre-Draft.**  Any Participant may submit a proposed initial draft document as a candidate Draft Specification of that Working Group.  The Maintainer will designate each submission as a “Pre-Draft” document.
+
+**4.2.	Draft.**  Each Pre-Draft document of a Working Group must first be Approved to become a” Draft Specification”.  Once the Working Group approves a document as a Draft Specification, the Draft Specification becomes the basis for all going forward work on that specification.
+
+**4.3.	Working Group Approval.**  Once a Working Group believes it has achieved the objectives for its specification as described in the Scope, it will Approve that Draft Specification and progress it to “Approved Specification” status. 
+
+**4.4.	Publication and Submission.**  Upon the designation of a Draft Specification as an Approved Specification, the Maintainer will publish the Approved Specification in a manner agreed upon by the Working Group Participants (i.e., Working Group Participant only location, publicly available location, Working Group maintained website, Working Group member website, etc.).  The publication of an Approved Specification in a publicly accessible manner must include the terms under which the Approved Specification is being made available under.
+
+**4.5.	Submissions to Standards Bodies.**  No Draft Specification or Approved Specification may be submitted to another standards development organization without Working group Approval. Upon reaching Approval, the Maintainer will coordinate the submission of the applicable Draft Specification or Approved Specification to another standards development organization. Working Group Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions.
+
+## 5. Non-Confidential, Restricted Disclosure.
+
+Information disclosed in connection with any Working Group activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary.  Notwithstanding the foregoing, if the Working Group is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group.  

governance/5._Governance.md

@@ -0,0 +1,85 @@
+# Community Specification Contribution Policy 1.0
+
+This document provides the contribution policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”).  Additional or alternate contribution policies may be adopted and documented by the Working Group.
+
+## 1.	Contribution Guidelines. 
+
+This Working Group accepts contributions via pull requests. The following section outlines the process for merging contributions to the specification
+
+**1.1.	Issues.**  Issues are used as the primary method for tracking anything to do with this specification Working Group.
+
+**1.1.1.	Issue Types.**  There are three types of issues (each with their own corresponding label):
+
+**1.1.1.1.	Discussion.** These are support or functionality inquiries that we want to have a record of for future reference. Depending on the discussion, these can turn into "Spec Change" issues.
+
+**1.1.1.2.	Proposal.** Used for items that propose a new ideas or functionality that require a larger discussion. This allows for feedback from others before a specification change is actually written. All issues that are proposals should both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become a "Spec Change" and does not require a milestone.
+
+**1.1.1.3.	Spec Change:** These track specific spec changes and ideas until they are complete. They can evolve from "Proposal" and "Discussion" items, or can be submitted individually depending on the size. Each spec change should be placed into a milestone.
+
+## 2.	Issue Lifecycle.
+
+The issue lifecycle is mainly driven by the Maintainer. All issue types follow the same general lifecycle. Differences are noted below.
+
+**2.1.	Issue Creation.**
+
+**2.2.	Triage.**
+
+o	The Editor in charge of triaging will apply the proper labels for the issue. This includes labels for priority, type, and metadata.
+
+o	(If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that proposals are prefaced with "Proposal".
+
+**2.3.	Discussion.**
+
+o	"Spec Change" issues should be connected to the pull request that resolves it.
+
+o	Whoever is working on a "Spec Change" issue should either assign the issue to themselves or make a comment in the issue saying that they are taking it.
+
+o	"Proposal" and "Discussion" issues should stay open until resolved.
+
+**2.4.	Issue Closure.**
+
+## 3.	How to Contribute a Patch.
+
+The Working Group uses pull requests to track changes. To submit a change to the specification:
+
+**3.1	Fork the Repo, modify the Specification to Address the Issue.**
+
+**3.2.	Submit a Pull Request.**
+
+## 4.	Pull Request Workflow.
+
+The next section contains more information on the workflow followed for Pull Requests.
+
+**4.1.	Pull Request Creation.**
+
+o	We welcome pull requests that are currently in progress. They are a great way to keep track of important work that is in-flight, but useful for others to see. If a pull request is a work in progress, it should be prefaced with "WIP: [title]". You should also add the wip label Once the pull request is ready for review, remove "WIP" from the title and label.
+
+o	It is preferred, but not required, to have a pull request tied to a specific issue. There can be circumstances where if it is a quick fix then an issue might be overkill. The details provided in the pull request description would suffice in this case.
+
+**4.2.	Triage**
+
+o	The Editor in charge of triaging will apply the proper labels for the issue. This should include at least a size label, a milestone, and awaiting review once all labels are applied. 
+
+**4.3.	Reviewing/Discussion.**
+
+o	All reviews will be completed using the review tool.
+
+o	A "Comment" review should be used when there are questions about the spec that should be answered, but that don't involve spec changes. This type of review does not count as approval.
+
+o	A "Changes Requested" review indicates that changes to the spec need to be made before they will be merged.
+
+o	Reviewers should update labels as needed (such as needs rebase).
+
+o	When a review is approved, the reviewer should add LGTM as a comment.
+
+o	Final approval is required by a designated Editor. Merging is blocked without this final approval. Editors will factor reviews from all other reviewers into their approval process.
+
+**4.4.	Responsive.** Pull request owner should try to be responsive to comments by answering questions or changing text. Once all comments have been addressed, the pull request is ready to be merged.
+
+**4.5.	Merge or Close.**
+
+o	A pull request should stay open until a Maintainer has marked the pull request as approved.
+
+o	Pull requests can be closed by the author without merging.
+
+o	Pull requests may be closed by a Maintainer if the decision is made that it is not going to be merged.