With perl right now, licensing issues just aren't. You don't have to worry about the licenses on the modules your code uses if you don't actually ship them with your program, so most people don't even think about the ramifications of the licenses of the modules they use.
Once you start doing all-in-one packages, especially if you're shipping what's essentially a single binary, those license terms become far more important. A not insignificant number of perl modules are pure GPL, which can be an issue both if you don't want to release the source for your program and if you use other modules that use GPL-incompatible licenses. This isn't a problem with the current setup, as the restrictions are on distribution and not use, but once you start distributing...
Not a new issue in general, just one that perl's not had to deal with for the most part up until now. | [reply] |
| [reply] |
So the difference is that now you ship just your main program and the user has to look up all the modules on CPAN himself, and the licence allows for whoever downloads it directly from CPAN to use it, but doesn't allow you to redistribute the module as part of a larger system?
Yes, or at least it may apply a license to your program that you wouldn't otherwise want applied to it. License conflicts generally get you something that's not distributable.
Perhaps the licence issue needs to be addressed as part of CPAN for Perl 6. Perhaps a standard package variable can be proposed so a compiler/bundler/linker can check this.
No. Licensing issues are social and legal things, and not generally amenable to a technical solution.
| [reply] |