Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

license issues

by szabgab (Priest)
on Sep 11, 2005 at 08:45 UTC ( #491037=perlquestion: print w/replies, xml ) Need Help??

szabgab has asked for the wisdom of the Perl Monks concerning the following question:

While working on a commercial software I face the question on what is the best way to make sure we comply with the licences of the various CPAN modules.

Is there some automatic way that based on the prerequisites in Makefile.PL or Build.PL will give me a list of the licenses of all the modules we are using ?

Replies are listed 'Best First'.
Re: license issues
by eyepopslikeamosquito (Bishop) on Sep 11, 2005 at 12:46 UTC

    I don't have a good answer here. As discussed in What if it were you instead of Linus?, it might be safest to email the module's author directly, asking for clarification and seeking permission.

    It starts to get murky if a module author accepts a patch from someone and that patch turns out to be legally suspect. Come to think of it, that seems to be more or less what happened to the Perl core in Professional Employees and Works for Hire. (I think it's happened to Linux also).

Re: licensing issue
by fraktalisman (Hermit) on Sep 11, 2005 at 16:39 UTC

    This is a very good question indeed. Personally, I happen to be working with the "standard" modules and I rely on the versions being installed by web providers on webservers, so this didn't seem to be an issue. Are there any known problems to the core modules? I guess the only correct and proper way to be really sure is to copy the license text of all modules you are supposed to use, and send it to your company's lawyer or law expert.

    In Germany, the law only allows for legally qualified people, like lawyers and judges, to give advice on such issues. As a programmer without official qualifications in law, I have to state that my advice is nothing but my personal point of view. So, it's up to the lawyers again, if there should be any doubt about licensing.

Re: license issues
by scmason (Monk) on Sep 11, 2005 at 19:30 UTC
    I don't really care for lawyers very much, but I'll tell you what my companies lawyer who is in charge of this type of thing says of open type licenses:

    Use only those modules released under the SAME license as Perl itself and declare themselves as such. If you find a SINGLE variation statement, dont use it.

    "Never take yourself too seriously, because everyone knows that fat birds dont fly" -FLC
      Use only those modules released under the SAME license as Perl itself and declare themselves as such. If you find a SINGLE variation statement, dont use it.

      Which is a great way for the lawyer to avoid work :-)

      At the least he could have made a list of the OSS approved licences that your company would accept.

      Did the lawyer say why? Maybe to avoid possible contradictions between different license types?

Re: license issues
by xdg (Monsignor) on Sep 11, 2005 at 21:21 UTC

    The META.yml spec defines a "license" field. Module::Build will fill it in automatically if a license is defined in the Build.PL. E.g.:

    name: Object-LocalVars version: 0.14 author: - David A Golden <> abstract: |- Outside-in objects with local aliasing of $self and object variables license: perl [snip]


    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re: license issues (yours, or the customers?)
by shenme (Priest) on Sep 12, 2005 at 01:26 UTC
    It may be I'm confused by your situation. If you are writing some software which you are going to sell, and your software uses some modules from CPAN, it seems to me this is not a problem - unless you want to package the CPAN software within your own release.

    I seem to remember other discussions where people realized that if your _customer_ is installing CPAN modules to satisfy prerequisites stated in your products README, and then your software is installed, then they (the customer) is simply using CPAN correctly, to upgrade their Perl installation. You aren't involved at all in that transaction.

    Now if you want to check over the individual module licenses yourself, so that you can tell the customer that there are no restrictions on _their_ use of the modules, that seems a nice thing to do. But, all, please tell me if there are any modules out there that say you (the customer) can't install them if their company name starts with 'M', are incorporated in Papua New Guinea, or are just too tall.

      Even for simple usage there might be CPAN modules that restrict the usage based on seemingly arbitrary qualification. AFAIK The Rules of CPAN do not say anything about what kind of licenses can be used for things uploaded.

      If we write an app that us using CPAN modules we only have to take care of this. But actually we might distribute these modules by ourself (e.g. packaged by PAR or zipped together with a full Perl installation) to make it easier to deploy the application.

      In such situation - I belive - one has to make sure he has the right to redistribute the original module in this packaged form.

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://491037]
Approved by wfsp
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (5)
As of 2020-09-25 10:25 GMT
Find Nodes?
    Voting Booth?
    If at first I donít succeed, I Ö

    Results (137 votes). Check out past polls.