Optionally include license text in the License element about specification

[stevespringett]

Included in CycloneDX 1.1

[stevespringett]

This is specially important for licenses that require it's to be include in any derivative work.

Agreed

[juanjoDiaz]

Hi @stevespringett,

What would be the next step to move this forward?
My organization has some people ready to get this in and implement the necessary changes in the node module and possibly others.

[stevespringett]

@juanjoDiaz Glad to know your org finds CycloneDX useful and am always happy to have contributions. CycloneDX is a versioned schema. There are a number of improvements coming in schema v1.1. They're documented here: https://github.com/CycloneDX/specification/milestone/1. Most are done or may have minor changes left. SPDX expressions is currently in progress and will likely be complete in the next day or two.

The plan is to release 1.1-DRAFT-2 this week followed and a third and final draft the week after. Assuming all tests pass and the community doesn't have any objections, 1.1 will be released on March 1. At that point, all official CycloneDX implementations will need to be updated to support both 1.0 and 1.1 of the specification.

For the <text> element, I think it would be good to support optional content-type and encoding. For example:

Defaults to: content-type: text/plain with no encoding

<text>text goes here</text>

Overriding the default with the specified content-type

<text content-type="text/markdown">text goes here</text>

Overriding the default with the specified content-type and encoding

<text content-type="text/xml" encoding="base64">PGxpY2Vuc2U+dGV4dCBnb2VzIGhlcmU8L2xpY2Vuc2U+</text>

[juanjoDiaz]

That sounds good.

What about the <url> element?
I think that's also fairly common that the license is not just plain text but a URL.

[RaineInto]

Regarding the encoding attribute, detecting the exact encoding from the license file with 100% accuracy is challenging, and if failed, it could cause confusion (e.g., UTF-8 versus ISO-8859-1). In my opinion, the encoding is not relevant here. However, we could consider converting longer license texts to base64 in order to keep the look of the XML file elegant.

The <url> element in NPM is only available in deprecated style, which is not supported by the current version of CycloneDX Node.js module. Therefore, it must be modified to support the deprecated style or just omit the <url> elements.

@stevespringett Any thoughts on these?

[stevespringett]

@RaineInto I agree with your position on encoding and feel like we should omit that from the specification. I don't want to overburden the various CycloneDX implementations to figure out the exact encoding.

The plan is to update all official CycloneDX implementations (npm, nuget, maven, etc) to be able to produce boms compatible with schema 1.0 and 1.1. If a user selects to output v1.1 format, then <url> would be part of the bom, so yes, the npm module will need to be updated to include this if it's specified in the package info.

Going forward, schema versions will be less of an issue as 1.1 can now include any element in a bom or component which is not defined by the specification as long as that element defines an external namespace. So i envision 'extensions' to CycloneDX 1.1 in the future without a real need to modify the spec.

[stevespringett]

@RaineInto For clarification, encoding (according to the spec) is optional and may only contain a value of "base64" if present. Encoding in this context doesn't mean specifying UTF-8, ISO-8859-1, etc.

So the spec supports "data encoding" not "character encoding".

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.