Lifecycle & Provenance

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:
  • 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 <alasdair@babilim.co.uk> (@aallan), Chris Adams <chris@productscience.co.uk> – @mchrisadams, Adrian McEwen <adrianm@mcqn.com> @amcewen, Dries De Roeck <dries@studiodott.be> @driesderoeck, Matthew Macdonald-Wallace <matt@mockingbirdconsulting.co.uk> @mbconsultinguk, Joanna Montgomery <joanna@littleriot.com>  @joannasaurusrex

Advertisements