-
-
Notifications
You must be signed in to change notification settings - Fork 74
feat: support multi license mix #582
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
Conversation
fb297fa to
9374fbe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this example is new
the examples are taken from the use-cases of #454
All licence posture in here is for show-case ony.
This is not a real law-case!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this example is new.
the examples are taken from the use-cases of #454
All licence posture in here is for show-case ony.
This is not a real law-case!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this example is new
the examples are taken from the use-cases of #454
All licence posture in here is for show-case ony.
This is not a real law-case!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a backport of a newly added valid example for CDX 1.7.
in CDX 1.6, it is invalid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a backport of a newly added valid example for CDX 1.7.
in CDX 1.6, it is invalid.
… named/spdx licenses Signed-off-by: Jan Kowalleck <[email protected]>
9374fbe to
9f5b308
Compare
Signed-off-by: Jan Kowalleck <[email protected]>
c2dcce9 to
4abbe2f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this case is now passing - as expected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this case is now passing - as expected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this case is now passing - as expected
|
@stevespringett this one is ready for review |
|
RFC notice sent. Public RFC period ends March 6, 2025 |
Period ended today, change was promoted to TC54. In today's TC54 meeting, some members rejected the feature as it is today, and rejected the original promoted feature. Reason: they expressed, that allowing multiple licenses was a bad idea. The discussion about that shall be continued in the original ticket: #454 |
| "licenseChoice": { | ||
| "title": "License Choice", | ||
| "description": "EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)", | ||
| "description": "A list of SPDX licenses and/or named licenses and/or SPDX License Expression.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pombredanne proposed to go with
EITHER (list of SPDX licenses and/or named licenses) OR (list of SPDX License Expressions)
but with the addons from #619
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i dont see how this proposal is a user-friendly solution.
if my intake is a list of declared SPDX licenses, and i am planning to add a single SPDX Expression for the concluded license, then I would have to migrate all the existing structures from SPDX licenses to SPDX license expressions.
INTAKE
<licenses>
<license acknowledgement="declared"><id>Apache-2.0<id><license>
<license acknowledgement="declared"><id>MIT<id><license>
<license acknowledgement="declared"><name>My Custom Foo<name><license>
<licenses>OUTPUT as proposed - causing migration
<licenses>
<expression acknowledgement="declared">Apache-2.0</expression>
<expression acknowledgement="declared">MIT</expression>
<expression acknowledgement="declared">LicenseRef-My-Custom-Foo</expression>
<expression acknowledgement="concluded">Apache-2.0 and MIT and LicenseRef-My-Custom-Foo</expression>
<licenses>instead, i would prefer to not migrate any structures and still be able to add new data.
this is especially important when evidence collection happens - i want to be free with the types i record, i dont want ot be forces to use only one or the other.
Signed-off-by: Jan Kowalleck <[email protected]>
Signed-off-by: Jan Kowalleck <[email protected]>
|
Incorporated the latest development of 1.7-dev into the examples. |
pombredanne
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good for me... we can always refine it later!
Sorry to have taken so much time to review and come to an agreement.
no worries, @pombredanne, |
## 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
As discussed in ticket #454, this PR adds the following abilities:
Please read the original ticket and see the provided example data for use-cases.
fixes #454
TODO/DONE