2015-07-09 14:08 GMT+02:00 Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx>: > > Can you elaborate on how you envision this working? SPDX appears to > work best when upstream projects integrate it and maintain it > themselves. Doing that downstream is possible, but it sounds both > time consuming and easy to get wrong or stale. > > josh To give some context, I'm currently discussing with other RPM distribution to push OpenStack packaging upstream. One of the topic raised was using common licensing classification, and the Linux Foundation has been working to standardize this. Some of our fellow distributions have standardized to SPDX or considering it: * Suse: standardized to SPDX * Debian: considering it https://wiki.debian.org/SPDX * Ubuntu: same (Canonical is also part of the SPDX WG) Though, I was skeptic at first, I must admit that there is some gain to standardize our licensing nomenclature. And maybe reuse all the licensing compliance checking tools from SPDX. If we agree and Legal approves it, the plan would be: * Updating guidelines to reflect this * Fix fedora-review, rpmlint -there's already a fix from Suse- and all package compliance checking tools * Then require, all new packages should follow the SPDX format for license tag * provenpackagers massively fix all the specs (could be automated) Benefits: * share a common standard with other distributions (including the other leading RPM one) and ease communication. * reuse SPDX tooling for license compliance checking (slides from FOSDEM 2015 talks: https://spdx.org/sites/spdx/files/FOSDEM_2015-v2-static.pdf) * doesn't change anything in our licensing policies (ie: what we accept or not) Inconvenients: * requires changing our guidelines, and tooling => low to medium impact * mass changing all specs => could be automated I know this would raise a lot of questions, so I want to have your feedback before thinking submitting a F24 changes. Regards, H. _______________________________________________ legal mailing list legal@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/legal
