-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modules which have no license field or non-standard values for "license" #324
Comments
Some of these distributions are now under the aegis of raku-community-modules. Maybe we should take a look at it. |
With respect to the rest, we should take a decision with respect to them, including de-listing them from the ecosystem. |
Probably need to revisit the above list, I'll knock something up a bit later to see what the current state is if someone doesn't get there first. But personally I'd not be in favour of something quite so draconian as de-listing, I'd probably be more in favour of using a form of words like "We are unable to determine the licence for this module, the details may be available in some other form in the source code, if the licensing is of concern to you please contact the author" maybe with some additional disclaimer. |
Well, not in the case of not having a license, of course. But the ecosystem is in need of a bit of curation... If we look hard enough, I'm sure we'll find quite a few META.info. |
I have automated most of the pull requests below, to ones where it is indisputable what the License of the project was, either due there only being one LICENSE and it matching copies of those licenses almost exactly, or the metadata for
license
key was set to something such as "The Artistic License 2.0" or the URL of the Artistic License or something ambiguous and able to be automated.I am posting this here since I have finished the automated stage and going forward most of the rest will probably have to be checked manually to check what license they actually are (for those that have a LICENSE type file), or for those which don't opening an issue for the project.
Artistic-2.0
Dual Licensing
Though it is not yet in S22, the way to denote a dual license using the SPDX spec is as below:
A license which allows you to use subsequent later versions if you choose
Common with GPL licenses. Example:
GPL-3.0+
. You can use a+
after the license name to denote this. The+
syntax is universal, and can technically be applied to any license, though in practice an "or later" clause is most often found in GPL (though please note GPL-3.0 means ONLY GPL-3.0, GPL-3.0 does not imply that you may use any later version).Example using the licensing of the Perl 5 project, which is dual licensed under Artistic 1.0 as sourced from the Perl site and the GPL-1.0 (or greater):
Artistic-1.0-Perl OR GPL-1.0+
Detailed information about the ones which do not yet have Pull Requests can be seen in this JSON here:
https://gist.github.com/samcv/9177c43f2a78049248fcb954c63d28e5
Note: jonathanstowe has stated he would not like any PR regarding metadata to his projects
This list contains all non-standard identifiers, and a very small number which have no license at all (added manually and not computer generated like the non-standard identifier ones were).
No PR or Issue
Outstanding Issue
Outstanding PR
Rejected
Note repeated from above: jonathanstowe has stated he would not like any PR regarding metadata to his projects
Merged or Fixed
The text was updated successfully, but these errors were encountered: