kaboutlicense api extension ::spdxId()?

[Harald Sitter]

On Tue, Jul 11, 2017 at 2:17 PM, Sebastian Kügler <sebas at kde.org> wrote:
> It does parse "and later", it's indicated by the + sign, but it's not
> reflected in the enum, GPLv2+ would be mapped to GPLv2, so you're right, our
> current system is lacking in that regard (but could be extended, although I
> don't know what would break then.

Well, yes, no, I don't know.

Currently it "handles" a trailing plus being present. So yeah, we
could actually build something. What we could do on the code side of
things is add a property `bool andLater` which would be fully
backwards compatible as querying the property is opt-in. That would
allow us to represent the and later on the code side and consequently
carry it into the spdx notation.

That said, after a bit of musing I am kinda thinking the enum should
go away (in KF6). From an API-use POV it serves no purpose to have the
licenses serialized as an enum, or at least I can't think of one. And
even internally I don't quite appreciate the way it is used.

Right now we get a stringy license key, we convert that into a License
object. And internally the type is then used to run excessively long
switch cases to translate the type into what is essentially a
displayName for displaying to the user and a full text representation
of the license. Simply put it looks to me the reason we have an enum
is so we can convert undefined input strings into well-defined output
strings. A crutch really.

With well-defined input strings (spdx license keys) we would have no
use for the enum and could write infinitely smarter code which would
be a fraction of what we have now.

In `byKeyword` one would parse proper spdx.
Once the spdx expression has been torn apart you can run the spdx key
against a hash to map it to a `name` and for the `text` you simply
`File("licensedir/$KEY.txt").open` which will also work reliably
because the key is well known. If spdx grows more options we'll not
have to care that way. If we have no fancy name we can simply fallback
to the spdx key as name, if we have no full license that's tough luck.
If we later decide that this is not good enough we can integrate spdx'
own license data https://github.com/spdx/license-list-data

In the end a plasma applet author could then define "MPL-2.0" as a
license and our UIs will know what that means without having to invent
a bunch of stringy representations to parse for, expand an enum and
write switch-case code around that in a number of methods.

(Only useful thing we'd lose is kAboutData.addLicense(enum) which does
add compiler safety, but if desired we could replace it with
kAboutData.addLicense(KAboutLicense::staticGPLv2InstanceThing); I
supose)

Something to think about maybe.

HS