On Tue, Jul 11, 2017 at 2:17 PM, Sebastian Kügler <se...@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