Add four licenses, see individual commits

[willebra]

No description provided.

[willebra]

I anticipate there to be discussion regarding some choices I made. E.g. the "...WITH LicenseRef-scancode-openssl-exception-lgpl-3.0plus" comes in another variant "LicenseRef-scancode-openssl-exception-lgpl-3.0-plus", but in this instance our scandcode version gives the first variant so it needed to be added.

Also is it appropriate to squash the two last commits into one?

[sschuberth]

This is probably getting a bit nit-picky, but I'm really interested in your view: Strictly, the license text says "You cannot delete this copyright notice" (emphasis mine). It does not say to include a copy of the notice in the distribution of the app using the dependency.

By just using a Bahyph-licensed dependency, we're not deleting its notice (but we're also not including it explicitly in our distribution). So, isn't it too strict to say the license would demand to "add the relevant copyright notices and the license text into the project/product notice file" (which is the description of the include-in-notice-file category)?

[willebra]

Perhaps I'm too much on the side of caution here. The license says: You cannot delete this copyright notice. If you change this software, you must include comments explaining who, when and why.

My thinking is that the latter obligation might become completely hidden, if the notice is not distributed. So the authors possibly inteded for the notice to be distributed in documentation. And the notice obligation is very light.

While it is usual that sw would normally not be be changed without access to source code, in this case this is about a dictionary, so the chance is perhaps not totally unexistent. On balance, the notice obligation is so light, and the purpose of marking modifications could disappear without reproducing the notice, so I added it.

Anyhow, I may be wrong on the technical side regarding modifications, and I'm clearly making an interpretation on the sidelines of the text. As it is erring on the side of caution, it is not a problem. But as it is also not clearly existing there, I'm happy to remove the notice obligation too.

[sschuberth]

So the authors possibly inteded for the notice to be distributed in documentation.

I agree that's what they probably intended, but they do not say that.

As it is erring on the side of caution, it is not a problem. But as it is also not clearly existing there, I'm happy to remove the notice obligation too.

I'm fine with keeping it. I just was curious about whether we'd agree on our interpretation to be on the side of caution, and not to be strictly clear.

As a general remark, exactly the written-out thinking from your post above should actually go to the commit message for future reference outside of this PR discussion.

[sschuberth]

Also is it appropriate to squash the two last commits into one?

No. The proper fix would be to edit the commit that adds "Bahyph", and move it to the correct position in the first place.

That said, I believe we should sort licenses case-insensitively (also see oss-review-toolkit/ort#3289). But let's do that as a follow-up PR.

[sschuberth]

E.g. the "...WITH LicenseRef-scancode-openssl-exception-lgpl-3.0plus" comes in another variant "LicenseRef-scancode-openssl-exception-lgpl-3.0-plus", but in this instance our scandcode version gives the first variant so it needed to be added.

To me, this clearly should be "LicenseRef-scancode-openssl-exception-lgpl-3.0-plus" to match https://scancode-licensedb.aboutcode.org/openssl-exception-lgpl-3.0-plus.html. Let's discuss in the daily about this.

[willebra]

E.g. the "...WITH LicenseRef-scancode-openssl-exception-lgpl-3.0plus" comes in another variant "LicenseRef-scancode-openssl-exception-lgpl-3.0-plus", but in this instance our scandcode version gives the first variant so it needed to be added.

To me, this clearly should be "LicenseRef-scancode-openssl-exception-lgpl-3.0-plus" to match https://scancode-licensedb.aboutcode.org/openssl-exception-lgpl-3.0-plus.html. Let's discuss in the daily about this.

So I'll just make a license conclusion for this?

[sschuberth]

So I'll just make a license conclusion for this?

Not necessarily. I wanted to discuss this in the daily, but you jumped off too early 😬 Anyway, the point is that I first would like to understand where "...3.0plus" (without the dash) comes from, because ScanCode's source code does not seem to contain that string anywhere... I'll try to investigate a bit.

[sschuberth]

I first would like to understand where "...3.0plus" (without the dash) comes from

It comes from here, so the less correct "LicenseRef-scancode-openssl-exception-lgpl3.0plus" is used as the primary spdx_license_key, and the correct "LicenseRef-scancode-openssl-exception-lgpl-3.0-plus" is just one of other_spdx_license_keys. I need to think about the best way forward.

[sschuberth]

So I'll just make a license conclusion for this?

Not necessarily.

I've made up my mind about this: Yes, let's do a license conclusion and then only use the proper name in this PR. That's the quickest way forward for us.

[sschuberth]

Additionally, I did aboutcode-org/scancode-toolkit#4807.

[willebra]

Let me change the commits accordingly, and remove the oddly id'd exception.

[sschuberth]

While we don't enforce strict rules on the commit messages in this repo, I'd appreciate if you still could:

• Make commit message titles no longer than 75 chars (and use no punctuation marks there); if you have more to write, that should go to the body of the commit message. But also lines in the body should ideally be hard-wrapped at 75 chars.
• Fix the typos in your commit messages.
• Add rationales / your thoughts that led to the concluded code as mentioned here.

[willebra]

What typos do you see? Did you consider the rationale too lightly explained with respect to Bahyph so it should both be extended and moved to commit body?

[sschuberth]

What typos do you see?

I saw a typo in "mofidication". Maybe there's more.

Did you consider the rationale too lightly explained with respect to Bahyph so it should both be extended and moved to commit body?

Yes. Just compare the amount of text you wrote here to your commit message here. There's too big of a discrepancy for me.

And the other commits deserve similar sophisticated commit messages. For any reader of the Git commit history (not this PR discussion) it should be totally transparent and comprehensible how you came to the conclusions you made WRT the categorization.

[willebra]

I made a longer commit message for the Bahyph license. Anyhow, I don't think we should move to a practice where these are all justified in this detail. But here I justified all the choices consistently to show what it would look like. It took me roughly 30 mins, so perhaps a total of 45 mins with classifying the license, if we don't count any of the git adminstration, mostly due to me not being proficient with the tool.

[sschuberth]

It took me roughly 30 mins, so perhaps a total of 45 mins with classifying the license, if we don't count any of the git adminstration, mostly due to me not being proficient with the tool.

So we probably need an ORT Server UI for that 😉