Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE]: "properties" on an SPDX-expression license #549

Open
mcombuechen opened this issue Dec 6, 2024 · 2 comments
Open

[FEATURE]: "properties" on an SPDX-expression license #549

mcombuechen opened this issue Dec 6, 2024 · 2 comments

Comments

@mcombuechen
Copy link

Describe the feature

When defining a component's licenses, one has three options to choose from:

  1. A license with SPDX identifier
  2. A named license
  3. An SPDX license expression

While options 1 & 2 afford the possibility of a "properties" attribute (key-value store), this is not available on option 3, the SPDX expression. See https://cyclonedx.org/docs/1.6/json/#tab-pane_components_items_licenses_oneOf_i1.

Would it make sense to also add "properties" to an SPDX-expression license?

Possible solutions

Add "properties" as an optional attribute to SPDX-expression licenses.

Alternatives

n.a.

Additional context

We are looking to store custom data plus an SPDX expression on a license definition.

@stevespringett
Copy link
Member

Thanks for the suggestion. What is the use case? Do you want to annotate licenses? If so, the annotations feature can provide this functionality today. See https://cyclonedx.org/docs/1.6/json/#annotations

If you’re looking to store data, what kind of data is it?

@mcombuechen
Copy link
Author

We are in the process of adopting CycloneDX as an internal DTO; there are a few edge cases where we would like to stuff prioprietary data into the documents. For the sake of illustration, let's say we'd like to attach a createdAt value to a license. It would be great if there could be something like:

{
  "expression": "MIT",
  "properties": {
    "snyk:createdAt": "2001-01-01T12:00:00.000+00:00"
  }
}

For any consuming application of this document it would be easy to look this information up. Looking in other parts of the document would increase complexity ever so slightly.

I understand that this is a "it's not you, it's me" problem: if we have certain feature requests because we'd like to use them internally, we should not force that onto the specification. However, since other license definition option afford the "properties" feature, maybe an SPDX license expression could, too?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants