Make License field a multi-select

[Warr1024]

• Remove the separate code/media license fields and combine them: licensing may be split across any boundary or specific to any component, not necessarily one particular boundary.
• Make the "license" field a multi-select, where authors can select all that apply, i.e. covers any portion of the package.

Users should assume that they must comply with all selected license requirements if they want to use the entire package; if they want to use only a portion, then they are responsible for figuring out which license applies to the relevant specific parts.

[Warr1024]

From the package approval thread for Texture Generator (https://content.minetest.net/threads/2765/#reply-7145)

CDB does not allow publishing of works licensed under "Other (Free/Open)", and probably should continue to disallow it: if a license exists that actually IS Free/Open, then it is worth adding as an explicit option.

The fundamental problem is that CDB currently does not allow publishing of works that have any more complex licensing needs than "one license for code, one for media". Workarounds thus far have centered around licensing the code as a bundle, and media as a bundle, under terms that are compatible with all components, but there was never any guarantee that that solution would continue to work in all cases.

A way to fix this was floated as a discussion topic, and IIRC some attempts at a proof of concept implementation had even been made ... but now I am escalating this to a formal proposal

[S-S-X]

Users should assume that they must comply with all selected license requirements

This should be made very clear in UI. Most of time multiple licenses in single package means that copyright owner allows you to use package with any of those licenses by your choice so it has to be clear for users and for package maintainers.

[Warr1024]

Most of time multiple licenses in single package means that copyright owner allows you to use package with any of those licenses by your choice...

CDB doesn't really support user-choice dual-licensing (i.e. "OR" licensing) and it would get complicated when combined with "AND" licensing, which CDB needs to support because most Minetest packages are licensed this way, e.g. "to use this package you must comply with GPL to use the code AND comply with CC-BY-SA for the media." I would hate to see us try to cram a whole boolean expression tree in the license field.

The simplest option is probably just to have the package authors choose one single set of license terms for the package metadata as published in CDB (probably should be the most restrictive ones), and if they wish to grant the user additional permissions, such as to use the package under alternative license terms, they should include it in their license file and README/long-description.

CDB editors will verify that there are no restrictions/requirements imposed by the package license that aren't reflected in the metadata, and there are no grants of permission implied by the metadata that don't match the actual project license. Editors should not however block a package from being published for mismatches the other way around, i.e. permissions granted in the license not reflected in the metadata, or restrictions implied by the metadata that can be worked around according to the license.

[S-S-X]

CDB doesn't really support user-choice dual-licensing (i.e. "OR" licensing

Yes and this reinforces my point which you left out from quote, saying it out loud because reply seems to be addressing only completely irrelevant portion of my comment and concern.

Basically: This should be made very clear in UI / it has to be clear for users and for package maintainers. Which means that it should be written out how multi select licenses should be interpreted and message should be clear enough.

(this is for user's point of view, not for admin or CDB editor perspective)

[fgaz]

I would hate to see us try to cram a whole boolean expression tree in the license field.

Why? There's even a standard for that: https://spdx.dev/ids/

[Desour]

I'd also like to specify my licenses via an spdx expression. Having to specify the same license for every code / media file is a weird restriction. https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/

Ideally it would also be neat if contentdb detected when a project is using REUSE and extracted the license information automatically.

[rubenwardy]

@fgaz @Desour how would you suggest representing that syntax or a boolean expression in a relational database

ContentDB needs to 1) know whether a package contains any non-free licenses 2) filter by specific license

[fgaz]

I would store the canonicalized/formatted expression in a text column. CDB mostly needs to display the whole expression on package pages anyway. At a glance the only other operation on licenses that I see is filtering on FOSS licenses, but there's already a field for that

[fgaz]

Oh, I just saw the edit. Where is the filtering used? I can't find any related feature in the website/api

[Desour]

@fgaz @Desour how would you suggest representing that syntax or a boolean expression in a relational database

ContentDB needs to 1) know whether a package contains any non-free licenses 2) filter by specific license

I'm probably the wrong person to be asked this, due to my limited experience with databases. But the question is interesting, so I'll answer anyways.

For (1), you probably want to filter out non-free packages, right? I'd just store in a separate db column whether the package can be redistributed under a set containing free licenses only. This bool can be either set by a human, or computed by replacing all the non-free licenses with false, and all the free ones with true, and then evaluating the resulting boolean expression.

What do you mean with (2)? Filter by whether the package can be redistributed with this license, or filter by whether this license is used by the package at all? Either way, it's a binary relation between a license expression and a license id.

To conclude, I'd do it like this:

• Package table:
  • other fields, like package name ...
  • license expression foreign key (e.g. the expression as string, or a sha265 hash of the expression string, or just an id)
• License expression table:
  • the key
  • the expression (e.g. as string) (not needed if the key is the expression)
  • can be free (bool) (to satisfy (1))
• License expression uses license-id table:
  • license expression foreign key
  • license id

Storing the license expression via relations would probably be too complicated.