Skip to content
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

Open
samcv opened this issue Apr 21, 2017 · 4 comments
Open

Modules which have no license field or non-standard values for "license" #324

samcv opened this issue Apr 21, 2017 · 4 comments

Comments

@samcv
Copy link
Contributor

@samcv samcv commented Apr 21, 2017

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.

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

  • Terminal::ANSIColor (R*)
  • Template::Mojo (R*)
  • Linenoise (R*)
  • PSGI (R*)
  • MIME::Base64 (R*)
  • Pod::To::HTML (R*)
  • rakudo-debugger (R*)
  • File::Find (R*)
  • Inline::Scheme::Guile
  • CompUnit::DynamicLib
  • Digest::SHA1::Native
  • EventSource::Server
  • RPi::Device::PiGlow
  • Acme::Insult::Lala
  • Archive::SimpleZip
  • RPi::Device::SMBus
  • Algorithm::Tarjan
  • Audio::Liquidsoap
  • Getopt::ForClass
  • CompUnit::Search
  • Audio::PortAudio
  • Crypt::TweetNacl
  • Hash::MultiValue
  • Printer::ESCPOS
  • App::ModuleSnap
  • Audio::PortMIDI
  • Monitor::Monit
  • Music::Helpers
  • IO::Path::Mode
  • Perl6::Parser
  • Unicode::GCB
  • Doublephone
  • Task::Noise
  • Pg::Notify
  • Log::Async
  • Lumberjack
  • XML::Class
  • Test::META
  • Manifesto
  • DOM::Tiny
  • Clifford
  • GraphQL
  • ANTLR4
  • META6

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

@samcv samcv changed the title Modules which use non-standard values for "license" Modules which have no license field or non-standard values for "license" Apr 24, 2017
@AlexDaniel AlexDaniel mentioned this issue Jul 17, 2019
4 of 47 tasks complete
@JJ
Copy link
Contributor

@JJ JJ commented Jul 12, 2020

Some of these distributions are now under the aegis of raku-community-modules. Maybe we should take a look at it.
And while we're at it, some still use META.info and/or panda. Also we should take a look at it...

@JJ
Copy link
Contributor

@JJ JJ commented Oct 3, 2020

With respect to the rest, we should take a decision with respect to them, including de-listing them from the ecosystem.

@jonathanstowe
Copy link
Contributor

@jonathanstowe jonathanstowe commented Oct 3, 2020

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.

@JJ
Copy link
Contributor

@JJ JJ commented Oct 3, 2020

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.

@JJ JJ mentioned this issue Nov 25, 2020
2 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants