I was about to create a similar issue, the license field currently does not allow distinguishing AGPL-3.0-only and AGPL-3.0-or-later which is quite a problem.

@bigcat88 What do you think about moving to SPDX identifiers only and keeping the old values for compatibility? I don't think there is a way to really deprecate an enum value, but it should be removed eventually.
I can create a PR for this, if this is the way to go.

SPDX Identifiers is definitely the way to go, imho.

To make the transition simple, we can:

1. just add a new field to info.xml which we'll call for example - and if it exists, take SPDX Identifiers from there. And for some time there will be two fields in parallel.

or

2. Since SPDX Identifiers will start with "SPDX-License-Identifier" - can we add support for them directly to the app store in the current field?
   We'll have to rewrite it a bit and move away from enum as I understand it in this case - but it seems possible.

2. Since SPDX Identifiers will start with "SPDX-License-Identifier"

I think there is confusion about this: SPDX-License-Identifier is from REUSE while I think @provokateurin and @jorsn want to use SPDX license identifiers within the license field.
So just some standardized identifiers for licenses, as currently agpl could mean anything, it does not have any license version information.

(BTW I would also love to see SPDX identifiers for license 😅 )

Exactly, this is about the appinfo.xml <license> element

Two more questions:

1. Do we still want to limit the list of allowed licenses to those already specified by the shorthand values?
   If so, we can just add the SPDX identifiers as enum values and go from there.
   If not, the easiest solution would be to allow any string value (containing only [0-9A-Za-z\.-]) rather than limit ourselves to specific enum values, and then try to detect the license depending on whether an SPDX identifier or shorthand value is given.

2. Does anyone know if the agpl and gpl3 values were meant to be interpreted as -only or -or-later by default?

2. Does anyone know if the agpl and gpl3 values were meant to be interpreted as -only or -or-later by default?

IMHO, this means "AGPL-3.0 or later" because when Andy added the SPDX headers to AppAPI, he specified an AGPL-3.0 or later license.

Do we still want to limit the list of allowed licenses to those already specified by the shorthand values?

The old values should still be allowed, but a warning should be show or something like that. Best way is probably to also limit the allowed values in the xsd and hope that the info.xml linter will catch it in all repos.

Given that currently only a limited set of licenses is allowed we should continue this path for now and just replace them with the proper SPDX identifiers.

Does anyone know if the agpl and gpl3 values were meant to be interpreted as -only or -or-later by default?

This is exactly the problem, we don't know.

IMHO, this means "AGPL-3.0 or later" because when Andy added the SPDX headers to AppAPI, he specified an AGPL-3.0 or later license.

I think for software developed by employees we can safely assume this because everyone works under this license.
For anyone else can't make a decision.

CC @AndyScherzinger

1. Do we still want to limit the list of allowed licenses to those already specified by the shorthand values?
   If so, we can just add the SPDX identifiers as enum values and go from there.
   If not, the easiest solution would be to allow any string value (containing only [0-9A-Za-z\.-]) rather than limit ourselves to specific enum values, and then try to detect the license depending on whether an SPDX identifier or shorthand value is given.

My opinion:

I would still do it through an enum of all possible SPDX license identifiers, since we are already switching to REUSE and SPDX.

For old types of licenses, we just need to decide what to change them to when an application with an old license is uploaded(or when licence type is displayed), and think about how to tell everyone that they must update the license field within a year or two, for example.

The ability to specify anything in the license field seems unnecessary to me.

I would still do it through an enum of all possible SPDX license identifiers, since we are already switching to REUSE and SPDX.

I'm not sure what the original intention of limiting the allowed licenses was. I don't think we really want to allow most licenses. Probably only everything that is compatible with AGPL-3.0. Again @AndyScherzinger your input would be very helpful on this topic.

In the app store dev database, I see that agpl has a name value of AGPLv3+, which is clear enough but should probably be changed to the full name of GNU Affero General Public License v3.0 or later instead, I think. For gpl3, it's still less clear as it's only given the name GPLv3.

I see that agpl has a name value of AGPLv3+

Note that this is not always true. There are code based of apps that are agpl3 only (eg everything from OC time)

I'm not sure what the original intention of limiting the allowed licenses was. I don't think we really want to allow most licenses. Probably only everything that is compatible with AGPL-3.0. Again @AndyScherzinger your input would be very helpful on this topic.

Happy to comment while not going to deep into the rabbit whole since SPDX license identifiers can also be combined with AND and OR... But let's not go down that road. So with

    <xs:simpleType name="licence">
        <xs:restriction base="xs:string">
            <xs:enumeration value="agpl"/>
            <xs:enumeration value="mit"/>
            <xs:enumeration value="mpl"/>
            <xs:enumeration value="apache"/>
            <xs:enumeration value="gpl3"/>
        </xs:restriction>
    </xs:simpleType>

I agree with @provokateurin statement to extend the list by adding further items (SPDX license identifiers) for compatibility reasons. I would also agree to not add all identifiers out there (the list is very long...). So I would add the ones that reflect the original list in the -only and -or-later variants where applicable (AGPL, GPL) and would also "just" add (A)GPL-3.0 not 2.0 or older.

IMHO, this means "AGPL-3.0 or later" because when Andy added the SPDX headers to AppAPI, he specified an AGPL-3.0 or later license.

I think for software developed by employees we can safely assume this because everyone works under this license.
For anyone else can't make a decision.

On the repos where I added the SPDX header I checked this explicitly. As mentioned by other above already. Nextcloud when founded in 2016 decided to go with AGPL3+, also on existing repositories from the oC times where in most cases AGPL3 (ONLY) has been used. In the later case the overall license is locked on AGPL3-ONLY. So yes, I did and could choose AGPL3+ for AppAPI because it was built by Nextcloud with no history "before the fork" hence not AGPL-3-only.

In general:
When unsure about which license it is or shall be, just ask me or Björn :)

beware that the server also ships an XSD for this... so that one needs to be updated as well. I can't say if that causes issues, maybe check back with @nickvergessen . I think he mentioned something some time ago with respect to the schema file and changing enums... So it might cause compatibility issues (in cases where old servers with old XSDs validate the info xml)

Since we can likely not just drop the current/old enum values, what is the best way to tell everyone that they should use the new ones?
We could have a debug log in the server when such an app is enabled, or script creating issues in all nextcloud org repos that contain such an app, or we make the appstore reject new app release uploads that use one of the old values.
Are there any other viable options?

We could have a debug log in the server when such an app is enabled

Please don't there are too many debugs no one can do anything about already ...

or we make the appstore reject new app release uploads that use one of the old values.

Please don't as it will just fail the release action and have many people with no clue ask questions what to do, and no one can give them a legally binding answer.

beware that the server also ships an XSD for this... so that one needs to be updated as well.

Should be done, yeah. the only difference is that the server one allows the default_enabled element iirc.

See my comments in #1560 minVersion>=31 shall be used since we cannot guarantee older, existing server versions to ship the updated XSD, hence their validation fails, so only app-versions with an info.xml with minVersion>=31 shall use the new identifiers.

Also this can only be merged after the same PR has been merged on server v31, to ensure v31.0.0 (and later) won't break.