This is ridiculous. So you want to exclude wget or chromium also, because it permits downloading nonfree code?

On the contrary, these packages (cpan, cpanm, any ruby or php or python or go package manager, npm) give you the freedom to override packagers decisions.
You don't want to go down this rabitt hole.

Yes, freedoms are ridiculous, depending on point of view.

No, we do not intend to exclude wget or chromium for their ability to download code.

Yes, freedoms from one POV is restrictions from another POV.

ah, sorry - forgot to address your last remark:

Yes, in fact the exact rabbithole we want to go down is this one: http://www.gnu.org/distros/free-system-distribution-guidelines.html

...as documented at the summary page for the tag applied to this issue: https://tracker.pureos.net/tag/freedom-harm_downloads_potentially_nonfree_code/

"A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so. The system should have no repositories for nonfree software and no specific recipes for installation of particular nonfree programs. Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow. Programs in the system should not suggest installing nonfree plugins, documentation, and so on"

I was not aware of any nonfree cpan module - nonfree in this case bring published at ACM, which brings in the restriction of usage for non financial gain. There's no steering, loopholes or anything. There might be few old modules with unclear licenses.

As user I do appreciate the effort to avoid those rabbit holes. But at least you should raise those issues with upstream. Patches are trivial for a license check before downloading. And upstream would be every major packager. You just cannot pick the weakest, cpanm. Easiest would be to start with the strongest ones, npm, pypy and go.
cpanm would be the very end.

I don't understand all details of what you write, so will comment only on the parts I understand.

Yes, CPAN contains nonfree code. Or possibly more accurately follow a different definition of "free" than Debian and FSF.

I disagree that I should report issues in a certain order.

Yes, it makes good sense to report issues upstream - but only sometimes not always, and not as a prerequisite for filing issues here (if that is what you mean by "at least").

So why are wanting to ban cpanm, and not the official client cpan out of the blue? You are acting completely irresponsible.

The issue is the threat of a blank ban on all native package managers.

For the perl side: If you want to add an option to a client you'd need to start with cpan, which then goes down to cpanm. It's a trivial process.
The client have no idea what and how this process should be handled. Who defines the nonfree'ness of a license, where is the list, how it is managed?
On the cpan database and clients this is handled with the toolchain-gang.
On the python pypi database with a pypi ticket. For javascript as a npm ticket. For go as a go ticket. ruby, haskell, ml, ocaml, tex, R, ... and so on down the rabbit hall. Regarding your interpretation all native package managers needs to be forbidden.

Regarding cpan: If I would be on that team I would not trust you to handle such a list all, e.g. There needs to be responsibility handling license issues and censoring parts of the internet.

Uhm, it seems you are reading something between the lines here that I did not write.

This issue is about the package cpanm potentially downloading nonfree code.

This issue is not about the package cpan. you are quite welcome to file a separate issue about the package cpan. Or npm. Or any other package you suspect there is an issue with in PureOS.

Quite likely your guess is right that I will find that all native package managers potentially downloads nonfree code. But this issue is not about "all native package managers" and I will not discuss that here - feel free to file a separate issue about "all native package managers" if you find our treatment about those as a whole to be an issue worth attention.

I agree with you that (to the best of my knowledge) cpanm has no way of knowing the licensing of a CPAN module, and therefore cannot be instructed (by default or patched specifically for PureOS) to consider only modules that fits the licensing regime imposed on PureOS. This is the reason I see no other solution than to avoid cpanm in PureOS.

Please note that it is not sufficient for cpanm to inspect the META hint about licensing of a module, since that hint evidently reflects only the _perl_ part of a module, not other parts shipped together with the perl code. A concrete example is https://metacpan.org/release/XML-Compile-WSDL11 which contains parts found to be nonfree by Debian regime: https://tracker.debian.org/media/packages/libx/libxml-compile-wsdl11-perl/copyright-3.06-2.

I guess you are not able to read.
Every single native packager for any single scripting language or other package system does allow installation of nonfree packages according to your terms, and would be thus as such banned from PureOS. Many of them already agreed to add a license meta field to their databases. So they are not hostile. You are the one who started the hostility against them.

cpanm is the smallest fish, npm would be the biggest, followed by pypi, cpan, tex, emacs and so on. cpan is the very same as cpanm. It installs cpan packages, which are potentially nonfree.
npm does the same, so does pip, and any other python installer, php installers, go, ...

So if you start with your interpretation (which is wrong according to my understanding of GNU nonfree'ness, and what you cited), you need to come up with a proposal to fix such issues. You cannot just come up with a straight ban of the smallest fish. BTW I'm in now way related to cpanm. I didn't see any attempt to contact the maintainers of CPAN (for the maintenance and interpretation of such a license field) or cpanm (for the addition of such a filter according to your terms, or maybe a broader terms those people might agree upon).
You are acting irresponsible.

And the simple fact that a debian nonfree package exists has nothing to do with the license filter you want to apply to those external databases. debian only has a very limited view into these databases, maybe 10%.

You continue to discuss matters I have explicitly told you is outside the scope of this issue.

I will now take a break from spending time on your contributions to this issue, in the hope that your writing style might change.

Again I see that you are not able to read.

Of course cpanm has the ability to implement such a trivial filter, technically. 1hr work. CPAN, the database, has such LICENSE fields already, and cpanm just queries this database. Same for npm, pip, and so on.

The problem is the maintenance. Who would decide that a certain license is nonfree and as such should be filtered from PureOS?
Best would be to let the pureos maintainer decide that, and the packagers clients such add a no-license=regex or list of nonfree licenses
option to their config file.
But to decide such new policies you need to start with the biggest fish, npm, and not cpanm.

I add a npm ticket for your convenience:
https://github.com/npm/npm/issues/19453
and also a pip issue here: https://github.com/pypa/pip/issues/4941
Those are the biggest, and with them it will be the easiest to get to an agreement of your problem.

pip already came up with a decision. see the link above.