I've found where I picked up this idea from.

On the Perl Foundation pages there is a copy of Artistic License 2.0 together 
with notes.

I interpret Section 8 of Artistic 2.0 as meaning you can't do
'mypacked.exe anyoldscript.pl'

But its all moot anyway as we are talking perl5 and Artistic 1.0.

Once again - sorry for FUD!!

Mark

Mark Dootson wrote:
> Hi,
> 
> I stand corrected then.
> I always thought 'mypacked.exe anyoldscript.pl' would NOT be OK.
> 
> Sorry for creating FUD!!
> 
> Mark
> 
> Steffen Mueller wrote:
>> Mark Dootson schrieb:
>>> Duncan Murdoch wrote:
>>>
>>>> 2.  Can you run a script that's not in the .par file, but look in
>>>> there for any modules it depends on?  For example, I'd like to do
>>>> something like the line above even though subdir/baz.pl was not in
>>>> foo.par.
>>> It is probably possible but it is a generally accepted interpretation
>>> of the Perl License that you may not create executables with a
>>> packager (PAR, PerlApp etc) that can run arbitrary external perl
>>> scripts on systems without a Perl installed.
>> I think what Duncan was intending to do was something like
>>
>> perl foo.pl
>>
>> with foo.pl loading modules from some.par.
>>
>>> So, having an executable mypacked.exe
>>>
>>> that can do
>>>
>>> mypacked.exe anyoldscript.pl
>>>
>>> on a system without Perl installed, is at the very least in a grey
>>> area as far as the Perl License is concerned.
>>>
>>> I only post this to flag up a potential issue that you may not have
>>> considered. I may be completely wrong and "mypacked.exe
>>> anyoldscript.pl" might be fine. I just always understood that you
>>> could not do this and should distribute Perl instead.
>> I am not aware that this (i.e. your scenario, not the one I point to
>> above!) is violating perl's license. In fact, I am somewhat confident
>> that it's fine. I suppose only Larry, the perl5-porters or lawyers can
>> answer this question definitely, though.
>>
>> Steffen
> 
> 


Reply via email to