On Thursday, 13 February 2020, OpenChain was featured in an article in the CIO Review India. The primary focus of the article was related to welcoming Lyra Infosystems are an official partner.
“We are excited and delighted to be part of the OpenChain Ecosystem to offer OpenChain conformance services, Open Source Policy, Process, Compliance consultation, Legal Remediation, and Audit services to organizations around the globe. Lyra Infosystems is an Open Source promoter, user, provider and a services organization with more than 280+ customers across geographies, domains, industries and technology verticals,” says Naba Magrabi, Open Source Senior Consultant for Lyra Infosystems.
Fukuchi San from Sony has provided us with a draft outlining where the various sections of the OpenChain Specification fit into company process workflows. This is building on a document that was previously available for OpenChain Specification 1.2. The goal is to provide a quick framing of our industry standard for organizations considering adoption, considering conformance, or managing these activities.
We would like to collect feedback on this document as it is likely to disseminate widely throughout our community in various languages over time. Email our General Manager (scoughlan@linuxfoundation.org) or any of our mailing lists to provide comments and suggestions.
The 10th OpenChain Project interview is live! Meet Alex, who makes sure our collection of international activities are recorded and fit together, and who brought previous interviews to publication.
Stefan from Fiducia & GAD IT announced yesterday that work is well advanced on a German translation of our Supplier Education Leaflet. Originally created by a sub-group of the OpenChain Japan Work Group, the supplier education leaflet is available in Japanese, English, Simplified and Traditional Chinese, as well as in Vietnamese as a draft.
Stefan’s full announcement and call for support
As discussed yesterday in Nuremberg during our kick-off meeting of the German OpenChain Working Group, I would like to reach out for support regarding finalisation of a translation of the Open Chain Supplier Leaflet into German.
The layout is not yet as complete as in the original – I would like to finalise the design after having sorted out the final German text. Thus, in a first round, quality checking of the text would be a good point to start 🙂
The video minutes for the first meeting of the OpenChain Germany Work Group are now available. This meeting was kindly hosted by Siemens in Nuremberg and featured 38 people from 29 companies. A big thank you to everyone who made it happen.
New from EACG: OpenChain Cheat Sheet – Conformance Requirements in One Page. This is a handy way to contextualize the whole industry standard for open source compliance in a single, easy-to-read handout.
Our partners over at PwC Germany have just released a video outlining their Third Part Certification for OpenChain Project. This is another example of the growing user community and support community around our industry standard for open source compliance.
The OpenChain Reference Tooling Work Group held a series of meetings adjacent to the FOSDEM conference in Brussels. Here are the outcomes and minutes as provided by Oliver Fendt.
Big Picture
It would be good to have information about “who is using which open source tool to do OSS compliance work” to create an overview that might help during internal discussions about appropriate tooling. We did not find an exact solution for this but there was consensus to work on enhancing a planned TODO Group survey with concrete questions about OSS based compliance tool usage. The survey is scheduled to be launched in June 2020.
It would help if we could create a detailed description of the functional building blocks (e.g. license & copyright scanner) available and which tool(s) implement the desired functionality or part thereof. A similar concept is also an outcome of the “requirements” session, see below.
Glue Code
To produce practical glue code a concrete use case is necessary. If you have a concrete use case and the tools intended to address this use case it is easy to identify the glue code required for implementation. This also provides the possibility to address whether the APIs of the tools support the implementation of the use case. When a tool does not support the needed API it is then practical and possible to file a targeted issue for that specific tool.
We intend to create a place where one can share information about different integration scenarios or proof of concepts different person are currently working on, in order to avoid duplicated efforts and to be able to connect to others addressing the same concerns. Two examples: Martin is willing to share the information about his company’s Yocto proof-of-concept and Arun will share information about work in his company.
* Oliver Fendt has taken an action item to create a place (directory) in our Github repo that this and other information can be shared and coordinated.
There is also the possibility that existing tools have integration scenarios with on their roadmap and that for these scenarios glue code is unnecessary. Coordination is key.
Requirements
There was consensus that documentation is needed to describe the progress from user stories (what do I want/need to do) to capabilities of the functional building blocks that make up the big picture (e.g. License & copyright scanner). It is important to provide concrete instances of tools which implement the necessary capabilities. This will also be a good base to identify needed glue code and/or APIs to be implemented in the concrete tools.
If you want to contribute to realize our targeted results you are highly welcome. Jump in and comment on the issues we will create based on these outcomes.