Obligations, Risks, Restrictions part of the software delivery in B2B case

[mcjaeger]

(sorry for reposting, searched the issue space, went into some, but was not finding this issue)

For some use cases, the following three items shall be part of a B2B delivery of software:

• Obligations (ie. written offer, etc)
• Risks (ie. binary files in OSS where no analysis was done)
• Restrictions (ie. not for commercial use)

and, as I would like to motivate it, also part of the SPDX document, because assuming the following (IMHO very popular) case:

• A company A delivers software (including OSS) for some integrating company B for integration, i.e. controller in some machinery.
• From perspective of company A, complying with licenses is one thing (providing disclosure documents or other elements of a "FOSS compliance bundle"), when delivering from A to B.
• but in order to help the integrating company B, machine readable listings of what the party needs to fulfill when bringing the product to market maybe helpful / required.
• In the supply chain, the party bringing the shipping-product to the end customer needs to process all the information about obligations, risks, restriction resulting from all included OSS from all suppliers in the chain.

Now the question arises if such information could be also standardised machine readable for processing - in the ideal case per SPDX.

[goneall]

There is a related effort from FINOs the Open Source Compliance Handbook which provides a machine readable set of license terms (see the blog post). They use the same license ID's as SPDX so this information can be easily integrated to provide some of what you are looking for.

[kestewart]

May want to work with license team - obligations, restrictions.

[kestewart]

This gets into scope of SPDX and is going to need wider discussion.

[swinslow]

I'm inclined to say that this is (and should be) outside SPDX's scope. From the SPDX spec:

1.5 What is not covered in the specification? . . . 1.5.4 Legal interpretation of the licenses or any compliance actions that have been or may need to be taken.

Instead, SPDX aims to focus on "just the facts" about what's present in a software distribution.

I think it's fantastic that Fossology produces these kinds of recommendations to users about license obligations. But I'm not sure that incorporating that into an SPDX document is in sync with SPDX's intended use.

[jlovejoy]

+1 to the above comments: determining the obligations and restrictions of licenses involve legal interpretations, which is outside the scope of the SPDX specification. It also requires determining the use case for the given software - a key step that many "license summaries" omit. I can ensure you that trying to break down open source license obligations and use cases in a way that software tooling can understand it only works to a limited extent (for the easy obligations, I would say) You still need a human interpretation (preferably the human is a lawyer) for some.

But all FOSSology can do is great - the more we can reduce and automate the redundant work, make things clearer and so forth, then the time spent on the harder questions or interpretations is not so bad.

[goneall]

Moving to 3.1

[swinslow]

I'm going to go ahead and mark this one as closed / wontfix. I think SPDX has consistently taken the position that it will enable tracking which license applies, and the corresponding text; but that SPDX will not include fields to interpret particular licensing requirements, categorizations of licenses or any one entity's views of a license's supposed "riskiness."