On 2 May 2014 14:41, Richard Fontana <[email protected]> wrote: > Also (based on what little documentation on AppStream that I looked at) it is > unclear what the purposes are in the case of AppStream.
So, for AppStream the idea is to explain the licenses in the user-facing software center, e.g. gnome-software or apper for KDE. This would mean you could click on a link that says "GPLv3+" and get sent to http://spdx.org/licenses/GPL-3.0+ rather than just having a license string to look at and perhaps Google. > My knowledge of SPDX itself is limited, but if you look at: > http://spdx.org/spdx-license-list/matching-guidelines you will see > that SPDX is using license identifiers in an entirely different way > from how Fedora uses RPM metadata license identifiers. Right. The idea is that you can define "upstream" what licenses your software is using, rather than relying on the packager to work it out and apply broad classification during the packaging step. I'm really only doing this for applications not explicitly specifying what SPDX licences they are using. > A good example, though not on your list probably because you assume it > is not problematic, is "MIT". For SPDX, this means > http://spdx.org/licenses/MIT#licenseText subject to the points made in > the SPDX matching guidelines. Right. > For Fedora, however, "MIT" is supposed > to mean a wide range of different license texts (which SPDX would > surely treat as distinct, non-matching licenses) that were determined > by the Fedora Project to be what I myself might verbosely call "X > Window Project-descended license family licenses, particularly as > distinguished from BSD-family licenses" if I had to call it anything. Yes, this is the fudge-factor I was talking about. Ideally we would have all these MIT-variants as separate SPDX license IDs. > So for the ones you list, first of all for most of these there isn't > any SPDX license identifier anyway even if you ignore the issue I just > talked about, since the SPDX list is, at least at present, not meant > to be a comprehensive list of all licenses ever encountered in, say, a > conventional Linux distribution, but rather those that are "commonly > found". In your list, none of those are "commonly found" in that sense > except that the AGPLv3 part of "AGPLv3 with exceptions" is *likely* to > correspond to SPDX AGPL-3.0, but not the "with exceptions" part which > has no SPDX license identifier counterpart. Right. > (By contrast there are > some GPLv2 and GPLv3 SPDX license identifiers that include some > commonly-found permissive exceptions.) Agreed, I didn't know whether the "with exceptions" AGPL thing could/should be broken down any further for SPDX. > This is what Fedora "MIT" means some of the time but not all > of the time. Yes, it's not ideal at all, but the data I'm presenting is more of an interesting titbit of information about the application rather than a comprehensive legal explanation. Apps are still free to specify a special license ID of "libtiff with extensions" but it just won't be hyperlinked in the front end tool. Richard _______________________________________________ Spdx mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx
