spdx@lists.spdx.org | Help converting Fedora license IDs to SPDX format

Home Messages Hashtags Subgroups

Date Date 1 - 5 of 5

Help converting Fedora license IDs to SPDX format

Richard Hughes #900 Hi all, I hope I'm asking in the right place, if not please disregard this message. When writing AppStream metadata I'm required to convert the existing Fedora license tag to an SPDX-compatible string so it can be made into a hyperlink and be clickable. Most license IDs are either the same, or map between one and the other with a small fudge factor, but I'm having problems finding SPDX licences for a few Fedora IDs. The fedora license ID's that probably should map to something (ideas welcome!): * Afmparse * AGPLv3 with exceptions * AGPLv3+ with exceptions * libtiff * mecab-ipadic * Mup * OpenPBS * softSurfer * Teeworlds * TORQUEv1.1 * UCD * Vim * XSkat * Baekmuk * Bitstream Vera * Crystal Stacker * Liberation * MgOpen * mplus There are a few things that don't make sense, e.g. * Public Domain * Copyright only * Freely redistributable without restriction * Redistributable, no modification permitted If anyone knows of any existing SPDX IDs suitable for any of the above, I'd be very grateful. Thanks. Richard
More All Messages By This Member
Philip Odence #903 Richard, I¹m moving you from the general SPDX list to the legal team. We are actually in the middle of marching through the Fedora licenses and are happy to work with you on this. You should be hearing shortly from someone on our legal team. Best, Phil Odence SPDX Chair toggle quoted message Show quoted text On 5/2/14, 7:53 AM, "Richard Hughes" <hughsient@...> wrote: Hi all, I hope I'm asking in the right place, if not please disregard this message. When writing AppStream metadata I'm required to convert the existing Fedora license tag to an SPDX-compatible string so it can be made into a hyperlink and be clickable. Most license IDs are either the same, or map between one and the other with a small fudge factor, but I'm having problems finding SPDX licences for a few Fedora IDs. The fedora license ID's that probably should map to something (ideas welcome!): * Afmparse * AGPLv3 with exceptions * AGPLv3+ with exceptions * libtiff * mecab-ipadic * Mup * OpenPBS * softSurfer * Teeworlds * TORQUEv1.1 * UCD * Vim * XSkat * Baekmuk * Bitstream Vera * Crystal Stacker * Liberation * MgOpen * mplus There are a few things that don't make sense, e.g. * Public Domain * Copyright only * Freely redistributable without restriction * Redistributable, no modification permitted If anyone knows of any existing SPDX IDs suitable for any of the above, I'd be very grateful. Thanks. Richard _______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx
More All Messages By This Member
Richard Fontana #901 On Fri, May 02, 2014 at 12:53:30PM +0100, Richard Hughes wrote: Hi all, I hope I'm asking in the right place, if not please disregard this message. When writing AppStream metadata I'm required to convert the existing Fedora license tag to an SPDX-compatible string so it can be made into a hyperlink and be clickable. Most license IDs are either the same, or map between one and the other with a small fudge factor, but I'm having problems finding SPDX licences for a few Fedora IDs. The fedora license ID's that probably should map to something (ideas welcome!): * Afmparse * AGPLv3 with exceptions * AGPLv3+ with exceptions * libtiff * mecab-ipadic * Mup * OpenPBS * softSurfer * Teeworlds * TORQUEv1.1 * UCD * Vim * XSkat * Baekmuk * Bitstream Vera * Crystal Stacker * Liberation * MgOpen * mplus There are a few things that don't make sense, e.g. * Public Domain * Copyright only * Freely redistributable without restriction * Redistributable, no modification permitted If anyone knows of any existing SPDX IDs suitable for any of the above, I'd be very grateful. Thanks. I think the problem is that you are dealing with three different notions of license identifiers, two of which are superficially the same in that AppStream has decided to use SPDX identifiers for its own purposes, if I understand correctly. Also (based on what little documentation on AppStream that I looked at) it is unclear what the purposes are in the case of AppStream. 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. 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. 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. 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. (By contrast there are some GPLv2 and GPLv3 SPDX license identifiers that include some commonly-found permissive exceptions.) So when you say "I'm required to convert the existing Fedora license tag to an SPDX-compatible string so it can be made into a hyperlink and be clickable", this is only meaningful if what you mean by "Most license IDs are either the same, or map between one and the other with a small fudge factor" is understood with my point about, e.g. the significant distinction between SPDX "MIT" and Fedora "MIT" in mind. And what would "MIT" hyperlink to -- the OSI version of the MIT license? This is what Fedora "MIT" means some of the time but not all of the time. - Richard
More All Messages By This Member
Richard Hughes #902 On 2 May 2014 14:41, Richard Fontana <rfontana@...> 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
More All Messages By This Member
J Lovejoy #904 Hi Richard (x2)! Richard H - great to hear you are using the SPDX License List for identifying licenses in AppStream for a number of reasons. Your responses below are all correct in terms of understanding the SPDX License List, so I’ll only add a bit more info in regards to the issues you have come across. As Phil mentioned in his response, the SPDX legal team is currently working through the Fedora Good License list (https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses) in order to identify where the SPDX License List is missing a license that is on the Fedora list. The inclination is to add any such licenses and try to align the SPDX short identifier with whatever Fedora had been using. However, for the reasons you and Richard F identified (e.g. I’ll call it the “MIT bucket,” identifying that Fedora uses to describe similar licenses) not all the short identifiers will align. I suspect we will end up with a “equivalency” document as part of the SPDX License List reference materials, for convenience. In any case, the next release of the SPDX License List is currently schedule to coincide with the release of 2.0 of the spec, so at that point you will see many additions to this end. In regards to the exceptions, this is also something we are currently working on. As of 2.0, license exceptions will be treated as a modifier to the base license to better enable capturing the various exceptions that exist in the wild. An explanation of this change, as well as the bigger picture in regards to creating a better way to express complex licensing info for files was recently summarized here: http://article.gmane.org/gmane.comp.licenses.spdx.legal/855/match=expression If you are not on the legal mailing list, please join!! (http://lists.spdx.org/mailman/listinfo/spdx-legal) <<I have responded to both the general and legal mailing lists here, but subsequent discussion should move to the legal list only, where it will get more direct responses/discussion :) Thanks! Jilayne SPDX Legal Team co-lead opensource@... toggle quoted message Show quoted text On May 2, 2014, at 8:03 AM, Richard Hughes <hughsient@...> wrote: On 2 May 2014 14:41, Richard Fontana <rfontana@...> 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 Spdx@... https://lists.spdx.org/mailman/listinfo/spdx
More All Messages By This Member

1 - 5 of 5

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms