Note: lists.spdx.org will be down for maintenance on Monday, September 26th, starting at 9AM Pacific Time (4PM Monday September 26, 2022 UTC), for approximately one hour.
SPDX as description for binary deliverables containing OSS artifacts
Mario Tokarz <mario@...>
this is a spin off of a discussion I was having with Peter and Garry
on the tech mailing list. I am considering how SPDX could form the
basis for the following example use case:
Customer A ordering a software with company B. B's software is closed
source but contains one file under 3-clause BSD. When A gets the
executable he may still have 'open source obligations' (like
e.g. non-endorsement) from the software even though not actually
receiving code. In fact in the scenario outlined here A might not even
be entitled to ever see/receive that sourcecode.
Still A of course needs to know about the licenses in play (besides
those agreed on between A and B upfront) and he might also want to
know about possible copyright holders.
So, I think what I am describing here can be clearly achieved with a
subset of SPDX, as your work has been really diligent. So I would like
to discuss with you
* whether the usecase makes sense, needs amendment or whether there
are similar use cases that I did not address here which could be
relevant as well
* how such a subset could look like. A subset would necessarily imply
changed cardinalities in the SPDX Spec and this would need to be part
of SPDX tooling in the long run. This is why I think one could also
describe this as an "SPDX Profile".
I may still need some time for this, but I can offer to come up with a
draft for requirement and then also a subset if this is something you
feel SPDX could support.
BMW Car IT GmbH