timelsass
commented
5 years ago For the remaining items you cited: husky script: https://github.com/WPTRT/theme-sniffer/pull/139/commits/37a4f8c1228af58b13e4157c2c42332d10ac513d This just changes husky to just run the npm script instead of adding it to husky where we can't access it, so the best of both worlds :smile: .
Set up license data repo, pull in as dep: https://github.com/WPTRT/theme-sniffer/pull/139/commits/c3fc0fa95c87b860384b13443ad442e8c59f0633 Created the initial repository/readme/etc and updated theme sniffer's build process. This will let theme sniffer use/update versions as needed for it's releases.
dingo-d
This does a basic readme.txt sweep. Once info is parsed the following is checked:
License
SPDX/FSF ID Matches
Checks if supplied text for license field is a FSF or SPDX ID. SPDX is preferred, and warning for FSF usage are given with the correct SPDX ID provided in those instances if it could be determined.
SPDX/FSF name matches.
Will check if a valid SPDX or FSF name match is found. This is not case insensitive, just as the one above is not either. They all require users to use exact license matches. This ensures they are submitting properly licensed themes in the repository where the license identification is universal and recognized.
So using GPL-2.0-or-later as an example, these are acceptable in the License field: GNU General Public License v2.0 or later GNU General Public License (GPL) version 2
This would not be: GPLv2
Non-standard Identifiers
Some of the FSF lingo is more non-standard, and doesn't correlate 1 to 1 to a SPDX counterpart. In the above section, the example shows GPLv2 is not a standardized license identifier, and could mean GPL-2.0-or-later, GPL-2.0-only, or their deprecated counterparts GPL-2.0+, and GPL-2.0. In those situations, it should warn and not error. They have a few license terms which sometimes refer to multiple, but it's not very common (aside from the example of GPL :laughing: ).
Deprecated License Identifiers
Deprecated License identifiers are accounted for, so if a user does try something like GPL-2.0+, then it will error letting them know it's deprecated.
I have not added anything in to notify them of the appropriate replacement identifier in those cases though.
GPL compatibility
Standard checks on the license field, once a valid license identifier is found - then a gpl compatibility check is done - and throws errors if the supplied license is not GPL-2.0-or-later compatible.
License URI
License URIs are checked against valid license's supplied. Errors are thrown, and proper long life URI's are provided, so the author can easily change to an approved license URI. All licenses have multiple URIs - some as little as 2, others more. Take for example:
Imlib2, which is the SPDX identifier for Imlib2 License - it has these URIs available: http://trac.enlightenment.org/e/browser/trunk/imlib2/COPYING https://git.enlightenment.org/legacy/imlib2.git/tree/COPYING http://spdx.org/licenses/Imlib2.json https://www.gnu.org/licenses/license-list.html#imlib http://directory.fsf.org/wiki/License:Imlib2
Listing any of those for the License URI will allow theme-sniffer to pass license validation for a theme claiming Imlib2 license.
Contributors
Will check against .org user profile for each contributor listed. Will error when the user doesn't exist as a required field if they choose to add contributors && warn for call failures. It might be worth add a short lived cache per each for people who run multiple times, but I didn't implement anything for that.