Hi Jeremiah, Glad to see a growing interest in HyperLegder. At Wind River we have been exploring how a Hyperledger based project could facilitate in the sharing of compliance artifacts among our customers for the past several months. Our current thinking has been motivated by recent customers request to assist them with sharing source code they receive from us with others in the supply chain. We started thinking about how a *ComplianceLedger* could be built using a Hyperledger base platform. Although somewhat similar to how you positioned HyperLedger below, I don’t see it so much of an SPDX 2017 road map item, but instead more of a separate larger ComplianceLedger initiative that is complementary with SPDX (and OpenChain). A key concept of a ComplianceLedger is that each supply chain participant, for a given software offering, creates a collection of compliance artifacts that are bundled in what we are currently referring to as a *compliance envelope* (think of .zip archive for simplicity). For example, typical artifacts include source code, attribution notice files, SPDX data, cryptography data (for export compliance) and so forth. Essentially a compliance envelope represents the output of an OpenChain conforming program. It would be the compliance envelope that each member in the supply chain would sign off on. First and foremost, the main objective of a ComplianceLedger would be to manage the accountability and traceability of *source code* and *notice files*. And yes SPDX data too (when it exists). We view the idea of a ComplianceLedger (accountability and tractability) independent yet very complementary to both SPDX and OpenChain. The output of an OpenChain conforming program would be a trusted compliance envelope that is traceable and accountable by a ComplianceLedger as it travels across the supply chain. When a product reaches its final distribution end point the compliance envelop should contain all the required source (notices, …) for all the open source components used to construct the product. In the event some source would be missing then it could be traced back to the responsible supplier.
My experiences with SPDX have taught me that new technologies have a better chance of adoption when developed to serve individual vertical industries as opposed to horizontally (across many different industries). For example, Hyperledger technologies are currently being explored to assist with providence within the diamond and pharmaceutical supply chains. I don’t think the evolution of a ComplianceLedger should be driven by the particular adoption needs of a technology such as SPDX, but from specific well defined vertical industries where a *must have* need for compliance envelop providence exists. We are seeing several industrial IoT verticals starting to bubble up but we are not prepared to declare any one worth pursuing (yet). Another challenge is that the Hyperledger technologies are still in the proof of concept stage. All in all, even in the absence of mature technologies and a clear vertical industry, it probably still makes sense to start the ComplianceLedger discussion. That is, provided we manage expectations by considering it more of an exploratory initiative. We have submitted a talk to the upcoming Linux Foundation’s Open Source Leadership conference in where we will describe the compliance envelop and ComplianceLedger concepts, and discuss the highly complementary relation with SPDX and OpenChain. Because of the Linux Foundation’s support for SPDX, OpenChain, HyperLedger and open source compliance in general, the summit would provide an ideal venue to begin this discussion. - Mark Mark Gisi | Wind River | Director, Open Source & Software Assurance Tel (510) 749-2016 | Fax (510) 749-4552 From: [email protected] [mailto:[email protected]] On Behalf Of Jeremiah Foster Sent: Friday, December 02, 2016 1:02 PM To: Kate Stewart Cc: [email protected] Subject: Re: SPDX Roadmap Ideas for 2017? Hi, What about using Hyperledger on SPDX output as a way to validate the supply chain? My vision is that each member in the supply chain would sign the resulting SPDX document in a Hyperledger thereby creating an immutable record of a large, complex software project as it moves through the supply chain to delivery. These seems to be one of Hyperledger's use cases: "The blockchain platform must provide a means to allow every participant on a supply chain network to input and track sourcing of raw materials, record parts manufacturing telemetry, track provenance of goods through shipping, and maintain immutable records of all aspects of the production and storage of a finished good through to sale and afterwards. In addition to employing both the Business contracts and Asset depository patterns described previously, this case emphasizes the need to provide deep searchability, backwards in time through many transaction layers. This requirement is at the core of establishing provenance for any manufactured good that is built from other component goods." This would improve the integrity of the SPDX data and the usefulness of SPDX in general. Hyperledger is a project at the Linux Foundation like SPDX. Regards, Jeremiah On Wed, Nov 30, 2016 at 4:08 PM, Kate Stewart <[email protected]<mailto:[email protected]>> wrote: Hi, If you've got ideas for tools to help people use and adopt SPDX, please feel free to send them out on this email list, or join the general meeting tomorrow (see attached). We've got some ideas, but would like to make sure we're going to be focusing on what will be most useful for the communities to encourage them to use SPDX. Thanks, Kate ---------- Forwarded message ---------- From: Phil Odence <[email protected]<mailto:[email protected]>> Date: Tue, Nov 29, 2016 at 5:00 PM Subject: Thursday SPDX General Meeting To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Special Discussion, 2017 Goals- Please bring your thoughts about goals for next year. After each update, team leads will facilitate some brainstorming on this subject. The Core Team will finalize and announce formal goal at the January 5 General Meeting. GENERAL MEETING Meeting Time: Thurs, Dec 1, 8am PDT / 10 am CDT / 11am EDT / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html Conf call dial-in: Join the call: https://www.uberconference.com/katestewart Optional dial in number: 877-297-7470<tel:877-297-7470> Alternate number: 512-910-4433<tel:512-910-4433> No PIN needed Administrative Agenda Attendance Minutes Approval http://wiki.spdx.org/view/General_Meeting/Minutes/2016-11-03 Technical Team Report – Kate/Gary Legal Team Report – Jilayne/Paul Business Team Report – Jack Cross Functional Issues – Phil _______________________________________________ Spdx mailing list [email protected]<mailto:[email protected]> https://lists.spdx.org/mailman/listinfo/spdx -- Kate Stewart Sr. Director of Strategic Programs, The Linux Foundation Mobile: +1.512.657.3669<tel:%2B1.512.657.3669> Email / Google Talk: [email protected]<mailto:[email protected]> _______________________________________________ Spdx-tech mailing list [email protected]<mailto:[email protected]> https://lists.spdx.org/mailman/listinfo/spdx-tech -- Jeremiah C. Foster GENIVI COMMUNITY MANAGER Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden M: +1.860.772.9242 [email protected]<mailto:[email protected]> [cid:[email protected]]
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
