feat: support multi license mix #582
Conversation
jkowalleck
changed the title
jkowalleck
force-pushed
the
feat/licenses-multi-mix-all
branch
2 times, most recently
from
fb297fa to
9374fbe
Compare
There was a problem hiding this comment.
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.
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.
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.
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.
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]>
jkowalleck
force-pushed
the
feat/licenses-multi-mix-all
branch
from
9374fbe to
9f5b308
Compare
Signed-off-by: Jan Kowalleck <[email protected]>
jkowalleck
force-pushed
the
feat/licenses-multi-mix-all
branch
from
c2dcce9 to
4abbe2f
Compare
There was a problem hiding this comment.
this case is now passing - as expected
There was a problem hiding this comment.
this case is now passing - as expected
There was a problem hiding this comment.
this case is now passing - as expected
|
@stevespringett this one is ready for review |
stevespringett
added
the
RFC notice sent
|
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 |
jkowalleck
removed
the
RFC notice sent
jkowalleck
added
request for comment
RFC notice sent
| @@ -1454,32 +1454,22 @@ | |||
| }, | |||
| "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.
@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.
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.
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