2016-07-26 10:58 GMT+02:00 Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx>: > On Tue 26 Jul 2016 10:44:24 AM CEST Haïkel wrote: >> 2016-07-26 3:38 GMT+02:00 Dennis Gilmore <dennis@xxxxxxxx>: >>> >>> A way to deal with it could be to enance rpmdev-bumpspec that we use in mass >>> rebuilds. or one of the other mass rebuild script, or for that matter if we >>> had a script that could do the conversion we could integare it into the mass >>> rebuild process. I am willing to make the changes needed to make it happen as >>> part of the next mass rebuild. It would require someone to script the >>> conversion from what we have to SPDX. it would still take time to propagate >>> everywhere. We would probably want to extend rpmlint and the review scripts >>> to throw a warning on it. >>> >>> Dennis >> >> I can volunteer for that, it's even a better plan than the one I suggested. >> I already wrote code to do the reverse conversion (from SPDX to Fedora >> short license tags) >> >> But that seems one of the easiest point to solve here. > > So here's a question: > SPDX is *very* clear that when you say MIT you mean this one: > https://spdx.org/licenses/MIT > > On the other hand when you see "MIT" in License tag in spec file it can > be any of these: > https://fedoraproject.org/wiki/Licensing/MIT > > So we can easily "pretend" we are matching SPDX license tags. But the > right thing would be to add all kinds of license variant identifiers - > one for each license text. > As far as we speak of MIT, SPDX has listed 7 variants while we have 5 short identifiers: No 1:1 mapping * MIT -> either MIT, MIT-CMU or MIT-enna or MIT-feh http://spdx.org/licenses/MIT.html http://spdx.org/licenses/MIT-enna.html http://spdx.org/licenses/MIT-CMU.html http://spdx.org/licenses/MIT-feh.html Most of these are functionally the same, but SPDX has attributed different short identifiers. I think this is mostly because of SPDX having stricter matching guidelines. http://spdx.org/spdx-license-list/matching-guidelines In most cases, we can fix fedora-review checks to choose the proper identifier, in others, display a warning. Not in SPDX: * DMIT (Docbook MIT) -> actually non-free license so not applicable in our use-case https://fedoraproject.org/wiki/Licensing/DMIT 1:1 mapping with SPDX * MIT with advertisement -> 1:1 mapping http://spdx.org/licenses/MIT-advertising.html * MITNFA (MIT +no-false-attribs license ) -> 1:1 mapping http://spdx.org/licenses/MITNFA.html * AML (Apple MIT) -> 1:1 mapping http://spdx.org/licenses/AML.html I prefer our own classification, but I think that the first step would be uniformizing short identifiers even if it means relaxing SPDX guidelines for existing packages. New packages should follow the strict classification unless we manage to get SPDX standards changed, but I feel that this is nitpicking and should not be too hard on packagers for this particular case. > Otherwise we'll have packages with license text that does *not* exist in > SPDX but we're going to be pretending that's the text. Right now our > wiki is at least obviously ambiguous - it can be any of the variants. > Well, our classification has the edge of being understandable by tech people, but SPDX provides common lingua franca with other distro, and since recent releases a meta-language to build identifiers for corner-case (exception, multi-licensing) that is less ambiguous. J. > -- > Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> > Business System Analyst, PnT DevOps - Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com _______________________________________________ legal mailing list legal@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/legal@xxxxxxxxxxxxxxxxxxxxxxx
