copyleftness of CC-SA-NC (and CC-SA-ND) style licenses

[pepper-jk]

When I compared our (HELLA's) license classification with yours, I noticed that I moved all CC-SA style licenses to be coypleft-strong, while you have it as either copyleft-file-level or source-available. The case copyleft-file-level I find less interesting here, as this is not to big a difference. I'm probably just wrong on that one.

When I inspected the source-available & SA licenses I noticed, all of them were CC-SA-NC. It makes sense to me that ND licenses would be source-available, but why NC? Is it because the users of your config require commercial use? Or just because scancode classified the licenses like that? [1]

Even if the CC-SA-NC licenses are source-available shouldn't they also be copyleft due to the SA clause? I'm curious to hear your opinion.

https://github.com/doubleopen-project/policy-configuration/blob/a1252101dbd1422272aece807a3ed3bf693f9c02/license-classifications.yml#L84-L88

https://github.com/doubleopen-project/policy-configuration/blob/a1252101dbd1422272aece807a3ed3bf693f9c02/license-classifications.yml#L1644-L1654

https://github.com/doubleopen-project/policy-configuration/blob/a1252101dbd1422272aece807a3ed3bf693f9c02/license-classifications.yml#L3302-L3321

[1] scancode/cc-by-nc-sa-4.0

[willebra]

Just a heads-up, we're collecting different views offline. I agree these need modification.

[willebra]

We have considered these and related changes to the Double Open license categorization and propose the following updates:

• The category and property descriptions will be cleaned up of references to software, and be written to describe the actual licenses and less the licensed content.
• CC licenses with SA will be categorized as copyleft-strong, even if some have been earlier categorized as copyleft-file-level. This difference has stemmed from analyzing CC licenses as if software code would not be licensed with them. As this is not true in all cases, copyleft-strong is a better classification, and more describes the language of the license and is agnostic towards the licensed content.
• All CC-licenses will be added with a property:creativecommons to help distinguish this group as it mostly applies to non-software content. This will give users of the classification an option to separately handle CC-licenses, e.g. to have a modified how to fix or in some cases accept such licenses without violation if e.g. some other critieria e.g. regarding the type of the file where the license hit was found, is fulfilled.
• CC licenses with ND or NC will be changed to the category free-restricted. Earlier Scancode seems to use both source-available and free-restricted. While analyzing this we determined the category free-restricted is closer to the meaning of these licenses.
• We will introcude a new property:no-modifications applied to e.g. certain CC-licenses. This allows the user to e.g. have ORT alert or give advisory on files where the license prohibits modifications. Initially this new property will be added to some licenses only, so please note that there may remain other licenses in the categorization which de-facto have this property while it is not yet reviewed.

As a related change, we will

• Add a property:specification-license to help distinguish licenses that are typically applied to specification files. It signifies an open source style license, with some imporant limitations. Therefore mostly these licenses will be in the free-restricted catergory. The adding of this property means that the licensed content is often a specification file and that the all important limitations of the license are described with properties. This gives users an option to evaluate whether specification licenses could be automatically accepted even if free-restricted otherwise creates rule violations, if the user is willing to take that risk, as these licenses in practice seem to be encountered almost exclusively in the specification files.
• Consider adding a property:mark-modifications. This property would be added to licenses that require special actions when modifiying the work. The Artistic license (https://spdx.org/licenses/preview/Artistic-2.0.html), as well as Ubuntu font-license (https://scancode-licensedb.aboutcode.org/ubuntu-font-1.0.html) have this type of requirements. This would give users the option to review the fulfilment of such requirements separately.

Happy to hear eventual comments or ideas. Thanks.

[willebra]

This is solved by pull request #43

[pepper-jk]

Hello @willebra,

sorry for not reviewing this earlier. But I finally got around to it.

I like the addition of the property:no-modifications. Now we can mark both NC and ND license accordingly without it effecting the main classification (NC with property:non-commercial and ND with the new property of course).

So you would agree that a CC-N*-SA license should be copyleft-strong? Being that copyleft is the stronger obligation than the other properties.

The other new properties, are good additions as well. We actually have something similar to property:mark-modifications, so I'm happy to incorporate those changes. Might be able to recontribute something for that later.

However, I noticed two remaining problems regarding CC licenses in the current main branch, details below. I opened a PR https://github.com/doubleopen-project/policy-configuration/pull/49 for this.

1. CC-BY-NC-SA-2.5 and CC-BY-NC-SA-4.0 are still missing the property:creativecommons. Therefore they have not been updated at all and remain source-available. https://github.com/doubleopen-project/policy-configuration/blob/7a3850dce54333b01e6b59574deac16cd918ee01/license-classifications.yml#L1675-L1685 Same goes for CC-BY-NC-ND-4.0: https://github.com/doubleopen-project/policy-configuration/blob/7a3850dce54333b01e6b59574deac16cd918ee01/license-classifications.yml#L1451-L1455 Here we have two more CC license just missing the property without being classified incorrectly: https://github.com/doubleopen-project/policy-configuration/blob/7a3850dce54333b01e6b59574deac16cd918ee01/license-classifications.yml#L1438-L1441 https://github.com/doubleopen-project/policy-configuration/blob/7a3850dce54333b01e6b59574deac16cd918ee01/license-classifications.yml#L1486-L1489

2. The other CC-NC-SA licenses are still not classified as copyleft-strong despite being SA. https://github.com/doubleopen-project/policy-configuration/blob/7a3850dce54333b01e6b59574deac16cd918ee01/license-classifications.yml#L3358-L3380 Only CC-SA only licenses appear to be copyleft-strong: https://github.com/doubleopen-project/policy-configuration/blob/7a3850dce54333b01e6b59574deac16cd918ee01/license-classifications.yml#L1871-L1881