How to count number of licensing profiles?

[bact]

(spin-off from #1226)

We have some inconsistencies between the spec and the model, and within the model, on how to count the number of licensing profiles.

In the model structure, we have 3 licensing profiles:

1. Licensing
2. SimpleLicensing
3. ExpandedLicensing

In the model, in ProfileIdentifierType vocab, we have 2 licensing profiles:

1. "simpleLicensing"
2. "expandedLicensing"

(no "licensing" entry)

In the spec, in the Conformance chapter, we have 1 licensing profile:

1. Licensing profile

The spec treats all *Licensing profiles as one.

---

Questions:

1. Should we add the "licensing" entry to ProfileIdentifierType?
2. When saying SPDX has "N" profiles, that N includes 1 licensing profile or 3 licensing profiles?

---

Note that "Licensing" profile is different from almost all other profiles. It contains only profile information and contains no model part (there are no classes/properties/vocabularies in Licensing profile) -- all classes and properties used in Licensing profile conformance are from Core, Software, and SimpleLicensing profiles.

Another profile that also contains no model part is the Lite profile.

[AlexanderDenkBMW]

Hi,

maybe a general thought on that topic - even if the issue may not be resolvable on short notice.

Profile is an overloaded term in SPDX. On the one hand it is used for the data model itself, on the other hand it is used to specify the compliance of the usage of a model for a certain use case.

In my eyes this introduces serious limitations as well as a lot of ambiguity in discussions about SPDX 3.0 - esp. when people have little background knowledge about SPDX 3.

I'd consider to sperate this topics and associated terms.

What else is an issue in my eyes: it's not extensible.
We have for example use cases which require a similar set of conformance rules like the "lite" profile provides, e.g. to satisfy minimum regulatory requirements for the U.S. rule ICTS or for cybersecurity requirements. All of them are using existing models (Core, Security, SimpleLicensing, ...) and some (ICTS) specify some extension fields. However, for cybersecurity the security-profile conformance does not require anything that is actually required - it's just stating that the vocabulary is used. For the practical value the "how" the vocabulary must be used to match the use cases minimum constraints would be far more important.

[bact]

Agree that the Lite profile is more about compliance to some regulatory requirements.

While other profile is more about conformance to the SPDX spec itself (which is also important. for example, in the case of Security profile, it "facilitates interchange of the security information produced by tools supporting SPDX").

They are two layers that compliment to each other. But, yes, terms used currently can be confusing.

[AlexanderDenkBMW]

I would generalize it and just say lite and licensing are use cases.
And there I see the problem, that we have two complementing layers - one defines the syntax and general semantics, the other layer defines the appliance and specific semantic constraints.
In the language itself it's merged in a single layer "profileConformance". This makes it hard to handle...

[goneall]

I agree with the comments that we are overloading the use of the term "profile" in SPDX.

This came up late in the development of the SPDX Version 3 release.

We partially resolved this by including a property profileConformance which (at least attempted to) document it is used to specifically describe conformance to restrictions and not anything to do with namespaces. I recall discussions where some of the participants wanted to use the property for both purposes, but that was rejected for the reasons described in this issue. It was also pointed out that if you want to know what namespaces are used within a collection, you can just look at the terms / properties / classes in use.

The fact we are using the term profile to mean both a conformance mechanism and a namespace within other SPDX documentation and discussion does, however, create confusion.

BTW - We also use the term profile to describe how we organize working teams.

Perhaps we can restrict the term Profile to just conformance and use other terms like namespace and workgroups to refer to the other uses. I'm not sure this would help or be even more confusing since we have the same names in the namespace and conformance enumerations.

[zvr]

Some of all this we have tried to explain before in the Glossary documentation of this repo.

[AlexanderDenkBMW]

Yes, I've read the section a few times. However, I'm not really happy with the topic because it's somehow mixing up two different things or at least lacking clarity (same for this Understanding Profiles).

• In the description the concepts are clearly described and separated, the namespaces/ontology are seen as as closely related tool to realize the profiles. That's fine for me.
• lite is in my eyes a real profile as it's implementing the minimum requirements to fulfil an actual use-case. That'a also fine for me and kind of was I'd expect.
• Problem 1: I'm not seeing good extension points - ProfileIdentifierType is a closed enumeration. For the most common use cases this is also fine, as they are usually industry-wide baselines (lite). However, for some domains there are specific use-cases which would require more specific profiles, that may also not be defined on the level of the foundation, but maybe on the level of an industry-related organization (e.g. Catena-X e.V., Auto-ISAC, OpenChain, whatever...)
• Problem 2: ProfileIdentifierType does not link to the profile specifics. As the enumeration correlates with the documentations Model this is fine. But, it's getting a bit fuzzy in the details:
  • lite: Lite is named as Profile and specifies the basic requirements, however, the actual full set of requirements are compiled in the Annex D. This is somehow redundant and not straight forward.
  • core: Core says in the description it's a namespace, not a profile: "The Core namespace defines foundational concepts serving as the basis for all SPDX-3.0 profiles.". All other entries see themself as actual profiles.
  • ai: AI's profile conformance section is focused on licensing topics. Beside that it's just the definition of the language elements. That's in my eyes a pretty small difference between the requirements of the ontology and the profile. Same for Dataset.
  • build: Build has no profile conformance section at all. The whole profile is basically only an ontology but not really sufficient minimum requirements for a use case. That's allowing maximum flexibility of usage, but is not enabling any practical use case.
  • expandedLicensing and simpleLicensing: no profile conformance section at all, the description of SimpleLicensing suggests it's just an ontology "profile provides classes and properties to express licenses".
  • software: Software specifies itself as namespace, not as profile: "The Software namespace defines concepts related to software artifacts.". No profile conformance section.
  • secutity: Security on the other hand describes itself as profile "The Security Profile captures security related information.", however there is no profile conformance section, nor is it sufficient for security use cases without additional constraints.

So practically I miss a clear separation between the specification of the namespaces/ontology and the actual application of them to fulfil practical use cases by conforming with profiles.
Also the somehow inconsistent usage of the related wordings leads to confusion and makes the documentation somehow hard to understand.

I hope the examples above help a bit to get my point.

Edit: Extension

• extension: Extension is listed as profile, but in my eyes this does not make sense to see it as profile. It's a namespace as said in it's own description.

Edit: Conformance Page
https://spdx.github.io/spdx-spec/v3.1-RC1/conformance/ makes also some statements in the direction of profile conformance. However, the texts for the specific are pretty generic and also for me it's not really actionable. The summary describes the role of the namespaces/ontology and less the role of profiles as described here.

Edit: SPDX 3.1

• hardware: Hardware says namespace
• supplyChain, service and operations: SupplyChain, Service and Operations say profile. However it seems to be more the plain description of the ontology and not focusing on the application for actual use cases. This may also be beyond the extend what's feasible, as these use cases may be pretty different for users of the ontology.
• functionalSafety: FunctionalSafety is the best of both worlds: "FunctionalSafety profile's namespace". From the description it's a pure namespace, regardless of the usage of the word "profile".
• ProfileIdentiferType has no entries for functionalSafety, operations, supplyChain and service, but for hardware and supplyChain.

[bact]

Small notes on AI and Dataset profiles' conformance sections are now removed, since 3.1-RC1. https://spdx.github.io/spdx-spec/v3.1-dev/model/AI/AI/

• Agreed on the Lite conformance information redundancy in two locations.

[goneall]

The profile descriptions alone is not sufficient to describe conformance restrictions.

Each profile can add additional restrictions on classes and properties - for example, it can change the cardinality of a property within a class defined in the core profile. These are defined in the individual markdown files within the profile. They can also include constraints on the classes and properties they define uniquely within those profiles. Stating a profileConformance indicates that all constraints defined in that profile should be adhered to.

What gets confusing (at least to me) is when you only have constraints for the classes and properties defined within a given namespace, it is essentially the same as just using the namespace. As soon as you add an additional restriction on a core or software class / property then having the profileConformance property is useful.

[goneall]

For the description consistency, I would suggest we just use the word profile, since we have other documentation which describes what a profile is.

[goneall]

ProfileIdentiferType has no entries for functionalSafety, operations, supplyChain and service, but for hardware and supplyChain.

It looks like this is fixed for RC2 already. See https://github.com/spdx/spdx-3-model/blob/develop/model/Core/Vocabularies/ProfileIdentifierType.md