Shane Coughlan

The Software Engineering Maintenance and Evolution Research Unit (SEMERU) lab at William and Mary is running a new survey relating to third-party software license compliance. The target audience is “people with a background in law, preferably with a law degree and some amount of experience in practice.”

Research Goal and Procedure

The purpose of this study is to investigate issues, needs, and opportunities related to open source software licensing. In particular, this study aims to investigate how legal practitioners address concerns related to software licensing and identifying pain points and unmet needs.

If you decide to participate, you will take a brief survey via the Qualtrics platform. The study will last about 15 minutes during which time you will be asked questions regarding your familiarity and experience with several topics related to open source software licensing that pertain to your work.

With your permission, we may contact you by email and invite you to participate in a follow-up interview.

Access the Survey

• https://wmsas.qualtrics.com/jfe/form/SV_emy0Tqan7qRWAlw

About the College of William & Mary

The College of William & Mary is a public research university in Williamsburg, Virginia. Founded in 1693 by a royal charter issued by King William III and Queen Mary II, it is the second-oldest institution of higher education in the United States and the ninth-oldest in the English-speaking world.

The OpenChain Japan Work Group held its 28th meeting (3rd hybrid) on the 11th of July. This meeting contained an exceptional roster of speakers and topics covered. OpenSSF, SPDX 3.0, OSPO leadership, education material and addressing common licensing misunderstandings. You name it, we covered it. Check out the recording below in Japanese for details:

Be part of this:

Everyone is invited to be part of the OpenChain Japan Work Group and contribute to (or simply participate in) future activities.

https://lists.openchainproject.org/g/japan-wg

During July we had two excellent calls covering the next generations of our license compliance and security assurance specifications.

The first call took place on the 11th of July and allowed North American and European contributors to gather:

The second call took place on the 18th of July and allowed North American and Asian contributors to gather:

Two GitHub issues were central to the discussion:

Align “Terms and Definitions” in Section 2 with Licensing Spec 3.0

• https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/30
  [ISSUE NOW CLOSED]

Adjust SBOM definition to align with Licensing Spec 3.0

• https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/31
  [ISSUE NOW CLOSED]

Initially scoped to focus on the Security Assurance specification, the conversations lead to improved material for the License Compliance specification as well.

The discussion then proceeded on a related topic:

What is a quality or complete SBOM for licensing or security use cases?

• https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/32

This issue is actively soliciting comments. It is significantly influenced by the forthcoming Telco Spec:

• https://github.com/OpenChain-Project/Telco-WG/blob/main/OpenChain%20Telco%20SBOM%20Specification.md

Next Steps

There is a next step to review what the SPDX Lite proposal from the OpenChain Japan community covers:

• https://github.com/OpenChain-Project/OpenChain-JWG/blob/master/subgroups/sbom-sg/meetings/spdx-asia-telco/SPDX-Asia-Telco-20230711.pptx

(See slide 25 and 26)

They have already submitted SPDX Lite for the forthcoming SPDX 3.0 specification via this pull request at the SPDX Project:

• https://github.com/spdx/spdx-3-model/pull/350

Open Issues

Of course, both the next generation License Compliance specification and the next generation Security Assurance specification also have pre-existing open issues for review:

Licensing:

• https://github.com/OpenChain-Project/License-Compliance-Specification/issues

Security:

• https://github.com/OpenChain-Project/Security-Assurance-Specification/issues

Join a Complimentary Live Webinar Hosted by The Linux Foundation on August 9, 2023 | 08:00 AM PDT (UTC-7)

A formal specification for an IT project allows implementers to understand what is required to build an implementation (or create a process) that conforms to that specification, and it allows a conformance test suite (or checklist) to be developed that can be used to check an implementation’s conformance. Users of tools that (partly or fully) conform to that specification can use the specification to learn the potential impact of moving source code, data, or processes between different implementations.

This presentation outlines a number of considerations involved when creating a formal IT specification, in general, and for software, in particular, such as a programming language or library.1

[Note: this will NOT be specific to making an ISO standard; that will be the subject of another webinar.]

Register on the official website:

• https://www.linuxfoundation.org/webinars/writing-a-formal-it-specification?hsLang=en

On a recent InnerSource Commons Community Call there was some informal discussion about outbound processes, and the conversation briefly touched on the Open Source outbound process of SAP.

Here are the public references around SAP’s Outbound Open Source Process:

• Blog Post – February 2020 – SAP’s Open Source Outbound Process – From scattered and tedious to streamlined and automated | SAP Blogs
• Podcast – November 2020 – Outbound Process Made Easy – SAP’s Process and Tooling – The Open Source Way (opensap.info)
• Blog Post – January 2021 – SAP Open Source Year in Review | SAP Blogs – just a paragraph

It is also worth noting that a member of the SAP team is active in TODO Group, so adjacent material like A Guide to Outbound Open Source Software may also be of interest.

On the related topic of compliance tooling, a team at SAP is working on the Open Component Model (https://ocm.software/docs/overview/context/), an open source standard for defining extendable machine-readable Software Component descriptors that could be used in compliance automation. This fits neatly into the type of topic covered by the OpenChain Automation Work Group.

Huge thanks to Guilherme Dellagustin for preparing and sharing these links.

This is from one of our board members, Helio at CARIAD, and is a worthy read on the topic. As per the abstract:

The current software compliance landscape relies strongly on de-facto SBOM standards as the correct relevant documents to attest to all the end needs. One consistent issue in the generation of these documents is the data gathering among multiple sources of information, as none of the tools provide everything, the so-called magic silver bullet.

As a solution, a central placement of unique data shared by all tooling would be ideal, but achieving this with multiple tools that do not communicate with each other is highly unlikely an easily solvable task.

The idea of abstracting the SST ( Single Source of Truth ) is to provide a stable contractual interface where the data connection between tooling and storage could be decoupled and used with the discretion of developers and companies’ choice, preventing polarization and hurdles on the platform engineering architecture.

Read The Article

• https://heliocastro.info/draft/sst.html

The OpenChain Telco Work Group is completing their work on a reference Telco SBOM specification.

This specification outlines certain requirements related to how an entity creates, delivers, and consumes Software Bill of Materials (SBOM), so that entities that produce and/or consume SBOMs that conform to this specification can ensure repeatability and streamlining of tools and processes for generating and consuming SBOMs.

Check out the current draft here:

https://github.com/OpenChain-Project/Telco-WG/blob/main/OpenChain%20Telco%20SBOM%20Specification.md

Check out the Japanese translation here:

https://github.com/OpenChain-Project/Telco-WG/blob/main/OpenChain%20Telco%20SBOM%20Specification_JP.md

(Thank you Masahiro Daikoku from KDDI!)

Watch one of the meetings to finalize the specification below:

Be part of this:

https://lists.openchainproject.org/g/telco