On PAUSE, when you go to register your namespace, in the field for what license you choose, there is:

restricted_distribution is for code that limits distribution somehow,

Which I take as explicitly allowing commercial modules.

Afaik such a distribution should not be on CPAN at all. Please let us know what module it is that you mean, and also advise the module list, Andreas Koenig and Jarkko Hietaniemi of the situation. Such a module could cause serious problems for the CPAN network (for lack of a better term.)

The license if full of the usual only if you pay for it, do not modify, do not redistribute, you may not copy any of this code language common to commercial products.

Ignoring whether commercial applications with restrictive licences should be on CPAN, it sounds like its incompatable anyway. Considering the mirror structure of CPAN a "do not redistribute" clause does not make sense.

Update: If the OP is talking about Astro::SLA they need to take another look at the licence. The Perl module is distributed under the same terms as Perl. It can talk to a C and Fortran version of the underlying library code. Neither the C or Fortran code is distributed with the Perl module. The Fortran library is GPL. The C one is proprietary.

If it isn't Astro::SLA I would like to know what it is :-)

Abigail

It's not to Perlmonks to decide what belongs on CPAN or not

I don't know why I bother but:

1. Jarkko isn't CPAN. Jarkko does not have control of what CPAN is. CPAN is a central storage location for code authored by thousands. If Jarkko or anybody else started outside of an acceptable area, all that makes up www.cpan.org would move to a suitable alternative.
2. Nobody here said that the decision whether or not to allow commercial modules on CPAN would be made in this thread. Nobody ever claimed that the side with most posts for it here would win.
3. Open discussion of such issues is good. This is what this thread is - a discussion. A chance for people to provide different viewpoints on an issue in an attempt to weigh all possible variables and come up with the best solution. Privately emailing Jarkko does not have the same effect.

So since my method of discussing the issues, weighing the advantages and disadvantages and coming up with a best guess solution doesn't appeal to you, I'll try your strategy. Please read the following statement over around 100 times. I'll even add in a second point with a happy face so you'll acquire a positive association.

• Open discussion is good.
• :-)

Perhaps I should get a bell.

An interesting and relevant essay on this is A Group Is Its Own Worst Enemy (which I saw thanks to dws).

That said, Jarkko maintains CPAN. He lead the 5.8.0 release of Perl. It is clear that he is a member of the "core group" involved with Perl and general Perl infrastructure. It is true that if he (and other members of the core group) took Perl in directions that the users don't want to go, users would go elsewhere. But it is equally true that until users get upset enough about affairs to either join the core group, or to fork Perl, the core group fundamentally does what it thinks is right and everyone else can argue about that as long as they want to. Conversely if a group of users does get upset enough to take decisive action and succeeds, then they will wind up re-creating the same basic core/general division all over again because it is a natural dynamic for human groups as they scale.

So, given this reality, what should we conclude? Well first of all, any conversation here does not mean much unless Jarkko hears about it somehow. Second, it is quite possible that there already is a policy about this kind of thing that Jarkko already works by. Third, the single most effective feedback is direct feedback to Jarkko or (if he functions that way - and if a lot of issues do come up he hopefully does) to the relevant list of people whose discussions he pays attention to. Which probably isn't PerlMonks.

Finally, why would it be good for Jarkko (I don't meant to pick on him, what I am saying applies to anyone with a position of influence in an online community) to decide things in an open manner? Here are some of the top reasons that I see:

1. Anything he decides gets sanity checked. A lot of obvious problems are caught immediately.
2. The open forum provides many people who might otherwise be motivated to cause problems an opportunity to participate instead.
3. Other list members, and archived discussions from the list take the load of responding to people about policy decisions from Jarkko's shoulders.
4. The forum provides a way for good possible maintainers to identify themselves to Jarkko for when he wants to pass the baton on.
You will note that conspicuous by its absence is any notion of making the process more democratic. Well-run open source projects are meritocracies, not democracies. Wanting a say doesn't give you one. Decisions are made in the end by convincing the right key people, not by voting.

Does this module belong on CPAN? If you own the vendors product, then you should know to look to their site to get it.

I feel that they are using CPAN to place an unpaid ad for their product. How do others feel about this?

On the one hand, yes it does seem a little bit like free product advertising (very little, as I highly doubt that the advertising benefit is all that great). On the other hand, the only license restriction that I see for CPAN is this:

Does CPAN allow contributions of shareware or code that requests a fee of any kind?

No. Everything on CPAN is free of charge. The reason for this is that CPAN is the product of hundreds of people donating their time and resources for the common good of the Perl community. There are places on the net where one can offer shareware without treading on the generosity of others and this is not that place.

Also, there are alot of interfaces to commercial products on CPAN. DBD::Oracle, DBD::Informix, and DBD::Sybase, just to name some of the DBD modules. DBD::Informix was written by an Informix person and is currently (but not originally) supported by Informix (now IBM), which is seen as a good thing by the users of DBD::Informix. DBD::Oracle users are not so lucky. Last time I had a problem (a segfault on certain types of sql statements which brought down the database server, but was not reproducable in SQL*Plus), I had to be careful not to mention perl, and write a test case in 'C' before I could get any help from the Oracle people.

Finally, if I had their product, needed a perl interface to it, and their site was down, I'd be glad to be able to get it from CPAN. Maybe they should distribute the perl module with their product, but then the same could be said for getting updates.