This working group is dedicated to editing the lifecycle section of the certification mark and as of June 16th on draft 0.1 reads as follows.
NB: The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are used as described in RFC 2119.
Understanding the Lifecycle
- Company MUST maintain a bill of materials, but doesn’t necessarily have to be shared publicly. Has to be maintained so that it can be shown when audited for compliance.
- Company SHOULD demonstrate they are:
- Sourcing components in the spirit of the OECD Due Diligence Guidance for Responsible Supply Chains of Minerals
- Not using vendors breaching global minimum working conditions (hours and wages)
- Company SHOULD be able to list the countries involved in their supply chain comprising their product.
Openness of the Product
- Company MUST make clear about how open the product is — whether the software is open source for instance.
- If it is open source the company MUST point to a public code repository that reflects the current up to date version of the firmware or server software from which the code can be downloaded in uncompiled form.
- If it is open hardware the company MUST comply with https://www.oshwa.org/definition/.
- Company MUST give expectation of what can be maintained by the user — iFixit style repair documentation to show how to maintain the device.
- Company SHOULD publish instructions on repair and maintenance in an easily understandable format and in a publicly accessible space on their website
- Company is RECOMMENDED to provide spare parts
Expectation of Purchase
- At point of sale, company MUST clearly communicate:
- Minimum lifetime of any necessary cloud/backend service
- Minimum guaranteed period of software/service updates
- What is intended to happen in the event of a transfer of ownership (eg. company is acquired or sold).
- Company SHOULD make sure a potential purchaser of the company takes on the overheads of supporting the platform until the end of the agreed time as part of the conties for take-back and reuse
- There SHOULD be a clear expectation for the end-of-life procedure for all involved stakeholders. Eg. consider an escrow model to provide extended support after company goes bankrupt or stops production.
- If the company terminates the product and/or service, or goes bankrupt, the software and service infrastructure — backend server software — SHOULD be made open source.
- The fate of the data (sold as an asset, destroyed) if the company terminates MUST be explicitly declared.
Authors : Alasdair Allan <email@example.com> (@aallan), Chris Adams <firstname.lastname@example.org> – @mchrisadams, Adrian McEwen <email@example.com> @amcewen, Dries De Roeck <firstname.lastname@example.org> @driesderoeck, Matthew Macdonald-Wallace <email@example.com> @mbconsultinguk, Joanna Montgomery <firstname.lastname@example.org> @joannasaurusrex