Update from and add to type of hasConcludedLicense and hasDeclaredLicense

[bact]

Per 14 Oct 2025 Tech call, reviewing a proposal in issue #1114:

• Update entry description of hasConcludedLicense and hasDeclaredLicense to explicitly state the type of to. Make it AnyLicenseInfo.
• from type updated to Artifact to support hardware
• Minor format/style update of "for example" in the hasDeclaredLicense description to make it consistent with another "for example" instance (in invokedBy entry)
• Update compliance point relevant content in Licensing profile

Current hasConcludedLicense and hasDeclaredLicense descriptions:

• hasConcludedLicense: The from SoftwareArtifact is concluded by the SPDX data creator to be governed by each to license.
• hasDeclaredLicense: The from SoftwareArtifact was discovered to actually contain each to license, for example as detected by use of automated tooling.

graph LR;
  A(SoftwareArtifact) -->|hasConcludedLicense| C(Type unspecified)
  A(SoftwareArtifact) -->|hasDeclaredLicense| B(Type unspecified)

Loading

Proposed in this PR:

• hasConcludedLicense: The from Artifact is concluded by the SPDX data creator to be governed by each to AnyLicenseInfo. If the to of an Artifact's hasConcludedLicense is not the same as the to of its hasDeclaredLicense, a written explanation should be provided in the comment field of the hasConcludedLicense relationship.
• hasDeclaredLicense: The from Artifact was discovered to actually contain each to AnyLicenseInfo (for example, as detected by automated tooling).

graph LR;
  A(Artifact) -->|hasConcludedLicense| C(AnyLicenseInfo)
  A(Artifact) -->|hasDeclaredLicense| B(AnyLicenseInfo)

Loading

[bact]

Should the "license" --> AnyLicenseInfo update be in 3.0 too? @kestewart @goneall @zvr

If it should, I will create another PR targets support/3.0 that only update the "license" --> AnyLicenseInfo.

[zvr]

No need to back-port this to 3.0.

But I am a little skeptical of the wording that says stuff about "each to".
Why "each"? Can there be more than one?
I am pretty sure in the case of hasConcludedLicense we should have only one -- if there a multiple licenses, there should be a single expression combining them.

I need some more time to think about whether hasDeclaredLicense should be the same.

@swinslow what do you think?

[bact]

In case there will be a change in "each to", and the change is not in 3.0, will the change (in post-3.0) be considered a breaking change?

[stevenc-stb]

am pretty sure in the case of hasConcludedLicense we should have only one -- if there a multiple licenses, there should be a single expression combining them.

There made be times that there will more that one hasConcludedLicense relationship per element like when they have different CreationInfo.

[bact]

Note that the description of hasDeclaredLicense and hasConcludedLicense may need further clarification too, see @JPEWdev comments and my comments in #1022

Update: I have added another sentence to hasConcludedLicense description, copy-edited from the Licensing profile page, on the case that hasConcludedLicense disagrees with hasDeclaredLicense. It may slightly addressed part of the concerns in #1022.

[bact]

But I am a little skeptical of the wording that says stuff about "each to". Why "each"? Can there be more than one? I am pretty sure in the case of hasConcludedLicense we should have only one -- if there a multiple licenses, there should be a single expression combining them.

I need some more time to think about whether hasDeclaredLicense should be the same.

Note that the Licensing profile has such a constraint for hasConcludedLicense:

spdx-3-model/model/Licensing/Licensing.md

Lines 115 to 123 in 9e7c359

	## Profile conformance
	For an element collection to be conformant with this profile,
	the following has to hold:
	1. for every `/Software/SoftwareArtifact` there shall exist exactly one
	`/Core/Relationship` of type `hasConcludedLicense` having that element as
	its `from` property and a `/SimpleLicensing/AnyLicenseInfo` as its `to`
	property.

[stevenc-stb]

There are three problems:

1. Inconsistent Definition (Description vs Profile conformance )
2. All the SupplyChain will need a Licenses. What would be the License for a TransportAction? Licenses will not apply to the SupplyChain.
3. SupplyChain will merge graphs when making things. What if two different SPDX data creators want to accept the same or different AnyLicenseInfo info for an Artifact?

[stevenc-stb]

Suggested change

	`/Core/Relationship` of type `hasConcludedLicense` having that element as
	`/Core/Relationship` with value /CreationInfo/createdBy being the same, of type `hasConcludedLicense` having that element as

[bact]

@stevenc-stb I forgot the rationale for this. I think you already mentioned that during the AI team meeting but it is probably not get recorded. Do you mind to put it here again please? Thank you.

[bact]

@stevenc-stb So the general suggestion is to keep the Licensing profile conformance separated from the type constraints as describe in the relationship type description - right?

i.e. hasConcludedLicense / hasDeclaredLicense can take from of any Artifact, but the Licensing profile conformance requirement will only applied to SoftwareArtifact -- am I understand your suggestion correctly? (if so, I agreed with that and will revert related changes).

[stevenc-stb]

@stevenc-stb So the general suggestion is to keep the Licensing profile conformance separated from the type constraints as describe in the relationship type description - right?

i.e. hasConcludedLicense / hasDeclaredLicense can take from of any Artifact, but the Licensing profile conformance requirement will only applied to SoftwareArtifact -- am I understand your suggestion correctly? (if so, I agreed with that and will revert related changes).

Exactly, that's what I was getting at. Keeping the licensing profile conformance separate from type constraints. We might want to open it up allow even more that one hasConcludedLicense : see the RelationshipType.md hasConcludedLicense: "hasConcludedLicense: The from Artifact is concluded by the SPDX data creator to be governed by each to AnyLicenseInfo." by that define we might be able to have ONE per SPDX data creator.

[zvr]

There is a mix-up of two different cardinalities in these comments.

I am firmly of the opinion that a hasConcludedLicense relationship should never have more than one to licenses. Therefore we should never talk about "each of the to", since there will be only one.

Whether there are more than one hasConcludedLicense relationships with the same from Element (be it an Artifact or a SoftwareArtifact) is a completely different question, which would never be addressed in the RelationshipType description (since this talks about a single relationship).

[stevenc-stb]

I am firmly of the opinion that a hasConcludedLicense relationship should never have more than one to licenses. Therefore we should never talk about "each of the to", since there will be only one.

Yes to that. I was unclear before.

Whether there are more than one hasConcludedLicense relationships with the same from Element (be it an Artifact or a SoftwareArtifact) is a completely different question,

This is what i meant by the last reply.

[stevenc-stb]

What about for this Profile conformance?

1. for every /Software/SoftwareArtifact there is a /Core/Relationship of type hasConcludedLicense having that element as its from property and there shall exist exactly one /SimpleLicensing/AnyLicenseInfo as its to property.

[bact]

What about for this Profile conformance?

1. for every /Software/SoftwareArtifact there is a /Core/Relationship of type hasConcludedLicense having that element as its from property and there shall exist exactly one /SimpleLicensing/AnyLicenseInfo as its to property.

The change in Profile conformance section is now reverted to its original text, which is:

1. for every /Software/SoftwareArtifact there shall exist exactly one
   /Core/Relationship of type hasConcludedLicense having that element as
   its from property and a /SimpleLicensing/AnyLicenseInfo as its to
   property.

Apart from few language differences, I believe the text you proposed and the original text are similar in meaning. Do you think it is ok to keep the original? @stevenc-stb

[stevenc-stb]

it's ok to keep the original. We can revisit it later.

[swinslow]

@zvr wrote:

There is a mix-up of two different cardinalities in these comments.

I am firmly of the opinion that a hasConcludedLicense relationship should never have more than one to licenses. Therefore we should never talk about "each of the to", since there will be only one.

Whether there are more than one hasConcludedLicense relationships with the same from Element (be it an Artifact or a SoftwareArtifact) is a completely different question, which would never be addressed in the RelationshipType description (since this talks about a single relationship).

I agree with this. There should not be a situation where a single hasConcludedLicense relationship has multiple to licenses.

In terms of "are multiple different hasConcludedLicense relationships specified, I agree that that's an entirely separate question. Presumably multiple SPDX data creators could specify different conclusions as to the same from Element.

[swinslow]

Regarding the change from Artifact to SoftwareArtifact:

Can you help me understand what other Artifacts, other than SoftwareArtifact, would be relevant to be from values for hasConcludedLicense / hasDeclaredLicense?

[bact]

@swinslow

There's a case of Hardware, which is also Artifact and it could have a license.

But also please see @stevenc-stb 's comment, particularly the (2):

There are three problems:

1. Inconsistent Definition (Description vs Profile conformance )
2. All the SupplyChain will need a Licenses. What would be the License for a TransportAction? Licenses will not apply to the SupplyChain.
3. SupplyChain will merge graphs when making things. What if two different SPDX data creators want to accept the same or different AnyLicenseInfo info for an Artifact?

TransportAction is a subclass of ModifyAction, Action, Artifact

https://github.com/spdx/spdx-3-model/blob/develop/model%2FCore%2FClasses%2FAction.md

So maybe we can't have either "only Artifact" or "only SoftwareArtifact", but "Artifact without Action".

But this also brings me to a question if we want to have Action as an Artifact.

(An action is certainly a noun, at least in English, something that is human made, but I don't think it is an object. Being an object should be a qualification of an artifact)

[bact]

Btw, since the "each to" is also in 3.0 relationship type descriptions for both hasConcludedLicense and hasDeclaredLicense, we may want to update there as well

https://github.com/spdx/spdx-3-model/blob/support%2F3.0/model%2FCore%2FVocabularies%2FRelationshipType.md

[swinslow]

@bact Thanks for the responses.

I don't understand what this means: "All the SupplyChain will need a Licenses. What would be the License for a TransportAction?"

Let's all please keep in mind that SPDX is talking about licenses specifically in the context of the distribution of software (and software-like content) in a supply chain. An "action" is not a licensable thing. You can't apply the MIT license to the act of making "an actual change to a product's location."

For Hardware, similarly, if you are talking about a physical hardware device, then the structure of SPDX-style licenses is not at all aligned with the idea of selling a physical device. SPDX licenses could apply to something like "open source hardware designs" -- but in that case, you're presumably referring to the underlying design files themselves, and we're back to software again.

I would strongly encourage that if there is a desire for expanding the licensing-related fields beyond software artifacts, then it would be appropriate to have a broader conversation about this that includes participants from the legal team (perhaps a joint tech/legal call should be scheduled). I really would not recommend enabling the licensing fields to apply to other things which are fundamentally different from software (and software-like content such as documentation, etc). I suspect that doing so will lead to a LOT of confusion when users try to implement this.

[bact]

I think that line ("All the SupplyChain will need a Licenses. What would be the License for a TransportAction?") is a question, a devil's advocate, a counter example.

That if the "from" has to change from SoftwareArtifact to Artifact to accommodate the case of Hardware, there's a huge question to be answered for the SupplyChain profile.

I agreed that we need more discussion between Tech and Legal teams.
This PR is basically reflecting the discussion in the 14 Oct 2025 Tech call.

And in any case, we need to specify a type for the "to".
That is left missing/unspecified since 3.0.

[stevenc-stb]

I don't understand what this means: "All the SupplyChain will need a Licenses. What would be the License for a TransportAction?"

This was back in commit (d50e486) the The Licensing profile Profile conformance of was changed to Core/Artifact from Software/SoftwareArtifact. This lead to need to have a action need a License. you pointed "action" is not a licensable thing. Profile conformance back to changed back to Software/SoftwareArtifact and this point does not apply now.

think that line ("All the SupplyChain will need a Licenses. What would be the License for a TransportAction?") is a question, a devil's advocate, a counter example.

Yes.

[bact]

As this PR is keep developing through the discussion.
Please see the latest proposed text in the "Files changed" tab https://github.com/spdx/spdx-3-model/pull/1122/files

--

To have a smaller and agreeable portion moving forward, I opened PR #1174 to essentially specify the type/range of the "to".

The rest of the discussion (each "to", Artifact/SoftwareArtifact for "from", etc) can continue here.