chore: adopt Community Specification License 1.0

.0_CS_Contributor_License_Agreement.md

@@ -0,0 +1,17 @@
+# 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) [LF Europe Code of Conduct](https://linuxfoundation.eu/policies/code-of-conduct)
+
+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.

.github/config/wordlist.txt

@@ -2,8 +2,8 @@ APIs
 BACKEND
 Backend
 Backends
-CNCF
 CLI
+CNCF
 CTF
 Canonicalization
 CycloneDX
@@ -17,20 +17,25 @@ GOOS
 GitOps
 Golang
 HTTPS
+Bräutigam
+Gergely
+Implementer's
+Möller
 JSON
 Kubernetes
 Lifecycle
 LocalBlob
-NeoNephos
+MERCHANTABILITY
 NIST
 NPM
+NeoNephos
 NodeJS
 NormalisationAlgorithm
-ORAS
 OCI
 OCIArtifact
 OCIRegistry
 OCM
+ORAS
 PEM
 PKCS
 RDF
@@ -66,8 +71,8 @@ componentNameMapping
 config
 conformant
 deployer
-deserialization
 descriptor's
+deserialization
 digester
 digesters
 directoryTree
@@ -98,6 +103,7 @@ localblob
 mariadb
 md
 mediatype
+merchantability
 multiarch
 namespace
 namespaced
@@ -122,12 +128,14 @@ schemas
 semantical
 sha
 structs
+sublicensable
 subtree
 templated
 tgz
 toolset
-untyped
+transferee
 untrusted
+untyped
 updatable
 uploader
 url
@@ -136,3 +144,13 @@ wget
 whitespace
 whitespaces
 yaml
+SIG
+SIGs
+TSC
+ANSI's
+Pre
+LF
+enablement
+stichting
+collegial
+Hyperledger

2._Scope.md

@@ -0,0 +1,28 @@
+# Scope
+
+The Open Component Model (OCM) standard provides a technology-agnostic, machine-readable framework for software bills of delivery (SBOD), along with a globally unique identification scheme to reference and document software artifacts throughout the software lifecycle.
+
+The OCM standard defines a “software artifact” as any discrete, uniquely addressable piece of content associated with the software delivery process. This encompasses container images, package archives, executable binaries, file system content, and multiple descriptor formats, including software bills of materials.
+
+## In Scope
+
+This group is focused specifically on establishing and promoting activities focused on:
+
+1. A **component model** that defines the structure and semantics for describing versioned sets of software artifacts, including versioned descriptions of it's content, artifacts, and references.
+2. **Model element fundamentals** that define identifiers, access specifications, labels and signatures that ensure semantic correlation across multiple storage mediums while maintaining integrity.
+3. **Processing operations** that define procedures for referencing, signing, verification, and normalization of software artifacts based on a serialization into a machine-readable format.
+4. An **abstract persistence layer** that defines model operations and mappings to storage backends to allow the processing operations listed above.
+5. An **extension framework** that defines extension points for software artifact types, access methodology, and algorithms to extend the processing operations listed above.
+6. **Guidelines and conventions** for transporting component versions and references across storage backends.
+
+## Out of Scope
+
+The group's activities do not include:
+
+1. The building, compilation, or deployment of software artifacts. Such activities are the responsibility of tooling that operates on top of the model defined herein.
+2. The definition of tool-specific metadata formats. Tool-specific metadata, such as deployment descriptions, may be represented as typed artifacts within the model but their internal semantics are not governed by this specification.
+3. The definition of internal formats or structures for individual artifact types where established standards exist and are incorporated by reference (e.g., OCI Image Layout Specification, Helm chart format).
+
+## Scope Changes
+
+Any changes to this scope apply prospectively and are not retroactive.

3._Notices.md

@@ -0,0 +1,55 @@
+# Notices
+
+## Code of Conduct
+
+Contact for Code of Conduct issues or inquiries: Gergely Bräutigam, Jacob Möller
+
+## 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.
+
+---------------------------------------------------------------------------------

4._License.md

@@ -0,0 +1,11 @@
+# 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 Apache License, Version 2.0 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.

5._Governance.md

@@ -0,0 +1,62 @@
+# OCM Community Governance Policy
+
+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 must adhere to the requirements in this document. Each Working Group is part of the Open Component Model project, which has been established as a project of Linux Foundation Europe. The policies of Linux Foundation Europe, available at [www.linuxfoundation.eu/policies](https://linuxfoundation.eu/en/policies) apply to participation in each Working Group.
+
+For governance specific to the Technical Steering Committee (TSC), see [TSC Governance](https://github.com/open-component-model/open-component-model/blob/main/docs/steering/GOVERNANCE.md).
+
+## 1. Roles
+
+Roles are defined in the following documents:
+
+- **TSC roles** (Chair, Voting Members, Code Owners, Contributors): [Project Charter, Section 2](https://github.com/open-component-model/open-component-model/blob/main/docs/steering/CHARTER.md)
+- **SIG roles** (Chair, Tech Lead, Voting Members, Maintainers, Contributors): [SIG Handbook](https://github.com/open-component-model/open-component-model/blob/main/docs/community/SIGs/SIG-Handbook.md)
+- **SIG Runtime roles**: [SIG Runtime Charter - Roles](https://github.com/open-component-model/open-component-model/blob/main/docs/community/SIGs/Runtime/SIG-Runtime-CHARTER.md#roles)
+- **Participants**: "Participants" are those that have made Contributions to the Working Group subject to the Community Specification License.
+
+Each Working Group may adopt additional roles so long as they are documented publicly.
+
+## 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 Maintainers will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and the nature of support and objections. The Maintainers will document evidence of consensus in accordance with these requirements.
+
+**2.2. Appeal Process.** Decisions may be appealed via a pull request or an issue, and that appeal will be considered by the Maintainers in good faith, who will respond in writing within a reasonable time. If the appeal cannot be resolved within the Working Group, it may be escalated to the TSC.
+
+## 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), OCM Working Groups must adhere to consensus-based due process requirements. Due process means that any person 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.
+
+**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.
+
+**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 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, it 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. The publication of an Approved Specification in a publicly accessible manner must include the terms under which it is being made available.
+
+**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 Maintainers will coordinate the submission. Working Group Participants that developed that 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.
+
+## 6. Code of Conduct
+
+All participants are subject to the [LF Europe Code of Conduct](https://linuxfoundation.eu/policies/code-of-conduct).
+
+## 7. Amendments
+
+This governance document may be amended by a two-thirds vote of the TSC and is subject to approval by LF Europe.