Getting confused about tri licensed package

[xnox]

Generated json and yet it fails conformance checker.

Unrecognized license reference: GPL-2.0+. license_expression must only use IDs from the license list or extracted licensing info, but is: GPL-2.0+ OR EPL-1.0+ OR LGPL-2.1+ Unrecognized license reference: EPL-1.0+. license_expression must only use IDs from the license list or extracted licensing info, but is: GPL-2.0+ OR EPL-1.0+ OR LGPL-2.1+ Unrecognized license reference: LGPL-2.1+. license_expression must only use IDs from the license list or extracted licensing info, but is: GPL-2.0+ OR EPL-1.0+ OR LGPL-2.1+

Software in question is https://github.com/jruby/jruby-openssl/blob/master/LICENSE.txt

JRuby-OpenSSL is distributed under the same license as JRuby a tri EPL/GPL/LGPL
license. You can use it, redistribute it and/or modify it under the terms of the:

  Eclipse Public License version 1.0
  GNU General Public License version 2.0
  GNU Lesser General Public License version 2.1

Not sure how to square this. Is this a bug in my declaration or that source package? or this checker tool?

[jspeed-meyers]

Thank you for the bug report, @xnox!

Not sure how to square this. Is this a bug in my declaration or that source package? or this checker tool?

I'm not sure either. I'll investigate. If anyone else figures it out in the meantime, feel free to chime in.

[jspeed-meyers]

@xnox, can you please post here the SBOM you scanned with ntia-conformance-checker?

[xnox]

@jspeed-meyers

ruby3.2-jruby-openssl-0.14.2-r0.spdx.json

And any changes to it do not make it pass.... for example changing "AND" to "OR" or changing "-and-later" to "+" or having fixed licenses etc. Is it like a bug in tri-license calculation? or are these three somehow incompatible with each other?

[jspeed-meyers]

@xnox, I doubt this is a bug in ntia-conformance-checker directly. But it might be a bug in spdx-tools, the Python library underpinning ntia-conformance-checker.

I doubt that there is an "incompatibility" issue. Let me investigate a bit this afternoon.

cc @maxhbr @goneall too

[jspeed-meyers]

@xnox -- I investigated.

I can't replicate your exact output, but I get similar. Could you please provide the exact commands you ran too?

In the meantime...

I run (using version 1.1.0 of ntia-conformance-checker:

ntia-checker --file ~/Desktop/ruby3.2-jruby-openssl-0.14.2-r0.spdx.json

I get:

Is this SBOM NTIA minimum element conformant? False

Individual elements                            | Status
-------------------------------------------------------
All component names provided?                  | True
All component versions provided?               | True
All component identifiers provided?            | True
All component suppliers provided?              | True
SBOM author name provided?                     | True
SBOM creation timestamp provided?              | True
Dependency relationships provided?             | True

The provided document is not valid according to the SPDX specification. The following errors were found:

Unrecognized license reference: EPL-1.0-or-later. license_expression must only use IDs from the license list or extracted licensing info, but is: GPL-2.0-or-later AND EPL-1.0-or-later AND LGPL-2.1-or-later

The output is saying that EPL-1.0-or-later is an unrecognized SPDX license. I checked the SPDX license list and there is indeed no EPL-1.0-or-later license. But there is EPL-1.0 and EPL-2.0.

Looking at the jruby license you referenced, the appropriate license looks like EPL-1.0,

So if I change the SBOM you provide to have this license, GPL-2.0-or-later AND EPL-1.0 AND LGPL-2.1-or-later, the SBOM is deemed conformant.

It looks like there was a change just made in wolfi 's ruby3.2-jruby-openssl.yaml. I predict that the new version of the SBOM won't have an issue given this change.

In short, there's no bug here, I don't think. spdx-tools is strict about what licenses can be used. It only allows licenses on the SPDX license list. EPL-1.0-or-later was not on the SPDX license list.

[xnox]

Agreed, close it.