Skip to content

Conversation

@jkowalleck
Copy link
Member

@jkowalleck jkowalleck commented Feb 20, 2025

As discussed via #549, this PR adds new structures to allow documenting the licensing and "properties" of SPDX expressions
As discussed via #554, this PR adds new structures to allow documenting the license texts for SPDX expressions' individual parts.


TODO

  • agree on data models & finalize examples
  • write the schemata
  • write the spec
  • write a proper summary for this PR

@jkowalleck jkowalleck changed the base branch from master to 1.7-dev February 20, 2025 13:01
- tests: examples for licenses with text
- tests: draft for expressiosn with text

Signed-off-by: Jan Kowalleck <[email protected]>
@jkowalleck jkowalleck force-pushed the feat/license-expression-text-attachment branch from dac5995 to 39524a2 Compare February 20, 2025 13:09
@jkowalleck
Copy link
Member Author

@Joerki , I've tried to incorporate your remarks and suggestions.
Also tried to make a schema for them, which lead to the current state.
Please give them a quick review.

This PR will probably sit here for some weeks, as It requires rework in case #582 is moved forward.

@Joerki
Copy link

Joerki commented Feb 25, 2025

@Joerki , I've tried to incorporate your remarks and suggestions. Also tried to make a schema for them, which lead to the current state. Please give them a quick review.

This PR will probably sit here for some weeks, as It requires rework in case #582 is moved forward.

Hi @jkowalleck ,
I had a look both at the JSON and (first time) XML definition.
The JSON schema definition looks fine!
A "LicenseRef-custom-license" example would be a meaningful.
I noticed a difference in the naming JSON: expressionDetails, XML: expressionDetailedType (-> expression-detailed in XML)

I stumbled over the explanation of "content" of the text:
"The attachment data. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text."
Honestly, I do not understand what is meant here. Shouldn't it simply be: The license text?

@jkowalleck
Copy link
Member Author

A "LicenseRef-custom-license" example would be a meaningful.

added via c16b24a

@jkowalleck
Copy link
Member Author

I noticed a difference in the naming [...]

this is not a difference in naming, but in structure.

in JSON, we have this one object that contains the property "expression", and additional properties.
in XML we dont have objects, we need to have named elements. there was none that could "expression" and arbitrary repeated/nested details - so i've created one - called "expressionDetailedType". See my discussionhere: #599 (comment) ff

Hope this helps to understand.

XSD and JSON-schema and ProtoBuf-schema are just implementations of the CycloneDX spec.
The thing is: XML and JSON have different capabilities, and therefore some structures are not the same.

Signed-off-by: Jan Kowalleck <[email protected]>
@jkowalleck
Copy link
Member Author

jkowalleck commented Feb 26, 2025

I stumbled over the explanation of "content" of the text:
"The attachment data. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text."
Honestly, I do not understand what is meant here. Shouldn't it simply be: The license text?

I've copied this over from the existing spec somewhere. Feel free to open an issue/pullrequest to improve this in the spec 👍

In addition, I've revisited the docs and and changed them - hopefully to the better: 7c49125

Signed-off-by: Jan Kowalleck <[email protected]>
</xs:complexType>
</xs:element>
<xs:element name="expression" type="bom:licenseExpressionType" minOccurs="0" maxOccurs="1" />
<xs:element name="expression-detailed" type="bom:licenseExpressionDetailedType" minOccurs="0" maxOccurs="1" />
Copy link
Member Author

@jkowalleck jkowalleck Feb 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after #582 got merged

  • make expression-detailed's maxOccurs="unbounded", too.
  • add an example where a declared expression is transferred to a concluded expression. we have an example for this where the ... OR ... expression become a concrete one.

this change would not affect the spec or scope of this feature, and will not interrupt the standardization process.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why this is called expression-detailed and the JSON is called expressionDetails. Not too worried about the hyphen, rather detailed vs details.

Copy link
Member Author

@jkowalleck jkowalleck Mar 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • details - these are the details
  • detailed - that is the thing that contains the details.

@jkowalleck jkowalleck marked this pull request as ready for review February 27, 2025 15:44
@jkowalleck jkowalleck requested a review from a team as a code owner February 27, 2025 15:44
@jkowalleck jkowalleck changed the title [WIP] feat: license expression text attachment feat: license expression text attachment Feb 27, 2025
@jkowalleck
Copy link
Member Author

I think all needed tasks on this PR were touched. it is ready for review.
Thank you, @Joerki , for your persistence and patience during the draft process.

Signed-off-by: Jan Kowalleck <[email protected]>
@jkowalleck jkowalleck changed the title feat: license expression text attachment feat: license expression details and properties - text attachment, licensing, etc Feb 27, 2025
@jkowalleck jkowalleck linked an issue Feb 27, 2025 that may be closed by this pull request
Signed-off-by: Jan Kowalleck <[email protected]>
@jkowalleck jkowalleck force-pushed the feat/license-expression-text-attachment branch from 49bded2 to 5b12e67 Compare February 27, 2025 16:36
@jkowalleck
Copy link
Member Author

RFC notice sent.

Public RFC period ends April 8, 2025

@jkowalleck jkowalleck added request for comment ready for review draft RFC notice sent A public RFC notice was distributed to the CycloneDX mailing list for consideration and removed prototype labels Mar 11, 2025
@jkowalleck jkowalleck added promote to tc54 Promote to Ecma Technical Committee 54 RFC vote accepted labels Apr 14, 2025
@jkowalleck jkowalleck added the tc54 accepted Ecma TC54 has accepted the feature candidate label Jun 5, 2025
@jkowalleck
Copy link
Member Author

This feature was just approved by Ecma TC54 👍

@jkowalleck jkowalleck mentioned this pull request Jun 5, 2025
@jkowalleck jkowalleck merged commit 6425bd8 into 1.7-dev Jun 5, 2025
9 checks passed
@jkowalleck jkowalleck deleted the feat/license-expression-text-attachment branch June 5, 2025 15:45
stevespringett added a commit that referenced this pull request Oct 21, 2025
## Fixed

* XML schema: add type for `ComponentData` sub-elements ([#600] via
[#601])
* JSON schema: added the correct `deprecated` mark for already
deprecated structures (via [a973a6b])

## Deprecated

* Deprecated various fields and structures related to _cryptographic
transparency_ - _CBOM_ . (via [#657])
Use the newly added structures and fields for detailing the information
instead.

## Changed

* Extended the scope of _formulations_. (via [#647])
From now on, _formulations_ may be used to describe how any referencable
object within the BOM came together, including components, services,
metadata, declarations, or the BOM itself.
  Before, it was restricted to components and services.

## Added

* Support for _external components_ with _version-ranges_ ([#321] via
[#586])
* Support for _multiple_ SPDX License Expressions alongside with other
licenses ([#454] via [#582])
* Support for _Streebog hashing algorithm_ ([#485] via [#525])
* Support for license expression _details and properties_ ([#549],
[#554] via [#599])
* Support for expressing BOM distribution constraints with the _Traffic
Light Protocol_ (TLP) in metadata ([#595] via [#604], [#653])
* Support for representing _patent information_ ([#596] via [#597])
* Support for _properties_ on external-references ([#608] via [#610])
* Support for _citations_ ([#630] via [#629])
* Support for detailing _cryptographic transparency_ information -
_CBOM_ ([#569] via [#657])

## Documentation

* Elaborated component classification "platform", explicitly expressed
that it includes just-in-time compilers and interpreters ([#233] via
[#647])
* Removed the term "optional" from the schema where the definition was
already unambiguous ([#616], [#649] via [#680])

## Test data

* Add test data for CycloneDX 1.7 implementations in XML, JSON, Protobuf


[#233]: #233
[#321]: #321
[#454]: #454
[#485]: #485
[#525]: #525
[#549]: #549
[#554]: #554
[#569]: #569
[#582]: #582
[#586]: #586
[#595]: #595
[#596]: #596
[#597]: #597
[#599]: #599
[#600]: #600
[#601]: #601
[#604]: #604
[#608]: #608
[#610]: #610
[#616]: #616
[#629]: #629
[#630]: #630
[#647]: #647
[#649]: #649
[#653]: #653
[#657]: #657
[#680]: #680
[a973a6b]:
a973a6b

----

- fixes #233
- fixes #321
- fixes #454
- fixes #485
- fixes #549
- fixes #554
- fixes #595
- fixes #596
- fixes #600
- fixes #608
- fixes #629
- fixes #616 
- fixes #649
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

draft promote to tc54 Promote to Ecma Technical Committee 54 proposed core enhancement ready for review request for comment RFC notice sent A public RFC notice was distributed to the CycloneDX mailing list for consideration RFC vote accepted tc54 accepted Ecma TC54 has accepted the feature candidate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat: (multiple) attachments for license texts of type "expression" [FEATURE]: "properties" on an SPDX-expression license

4 participants