It looks like it's caused only by the sort_unstable call.

The underlying bug is the splitting on OR, which is fundamentally wrong since SPDX licence strings can contain parens. So a SPDX string must either be taken verbatim, or parsed properly.

Why is that required?

I presume that this is an attempt to normalise the licence string. If the SPDX strings are normalised, they can be deduplicated, so that a minimum number of different licences are reported.

But, if normalisation is desirable, the right way to implement it would be to properly parse the SPDX string. This is nontrivial (and would come with its own subtleties).

IMO this normalisation ought not to have been attempted with this fundamentally incorrect algorithm. But simply abolishing it would probably be too disruptive.

In the meantime I suggest the following bodge: if the string contains any ( or ), completely skip the normalisation (including the splitting and the sort_unstable). That would fix this particular case by outputting the original string, without mangling it.

(Also, sort_unstable ought to be sort. sort_unstable isn't appropriate here, because we want the output to remain the same across different builds of cargo license.)

FTAOD my proposed bodge leaves the algorithm correct (in the sense that it would never corrupt a licence string); it's just not optimal and rather unprincipled. Currently the algorithm is broken.,

Just chiming in that I saw this exact issue. I was putting together a NOTICE file for a project and did cargo license to get all the dependencies. My editor showed the mismatched parentheses for libm in red which made me notice there was something wrong.

I checked #79.

I think using spdx instead of the ad-hoc normalization logic is a correct way, but spdx::Expression::canonicalize doesn't sort license order.
Sorting seems to be necessary to normalize licenses with different order like MIT OR APACHE-2.0 and APACHE-2.0 OR MIT.

If this PR is merged as is, the output changes significantly.
So I think it is better to keep the current logic for simple, sortable case, and add spdx canonicalize for complex case like including (), as the same as @ijackson 's idea.

It would also be possible to use spdx::Expression::parse after calling canonicalize and then sort the parsed expression. This would stay close to the current behavior while fixing the bad cases.