PPM ERROR: 401 Authorization Required

Posted by n6532l on 2013-03-19 10:37
Forums: PPM | OS: Windows XP Pro

The PERL Package gives me a error. Here is an example:

Synchronizing Database ... DONE
C-Analyzer marked for install
Preparing install to site area of:
Downloading C-Analyzer-0.02 ... redirect
Downloading C-Analyzer-0.02 ... status 401

ERROR: 401 Authorization Required

ActiveState Staff
Wed, 2013-03-20 14:58

You need Business Edition.

n6532l | Mon, 2013-03-25 10:55

I have never had any problem before. Here is what I am running:

This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 33 registered patches, see perl -V for more detail)

Copyright 1987-2006, Larry Wall

Binary build 819 [267479] provided by ActiveState http://www.ActiveState.com
Built Aug 29 2006 12:42:41

ActiveState Staff
Mon, 2013-03-25 12:06

Community Edition Build 819 was withdrawn from the list of products covered by free support August 01, 2007. It has been part of the Business Edition portfolio since Business Edition was launched in February, 2010.

There is an FAQ posted on PPM Access to Repositories which are only usable by Perls that are under Business Edition.


Details on Business Edition are available on our site here:

bravehurts | Fri, 2013-05-03 01:29

Funny thing. I wondered about this error and saw at forum that I've got to update to install modules. I wanted to save my modules "ppm install PPM-Profile". Okay right no Modules for your old version (5.12) .. loop loop

I'm using activestate perl for years. Now I installed strawberry perl.

jkirk | Tue, 2013-05-07 12:27

That makes at least two of us.

I tried to load HTML::TableParser via ppm, got the "authorization required" error message, Googled it, wound up here, read this thread, uninstalled ActivePerl "community edition", Googled for alternatives, found Strawberry Perl, installed Strawberry Perl.

ActivePerl de-installation and Strawberry Perl installation proceeded flawlessly. I was back up and running in minutes.

Took me five minutes (Thanks, Google!) to figure out how to load modules into Strawberry. Loaded up HTML::TableParser. No demands for money or any snotty messages from "support" personnel about how they already told me this.

The best I can dope it out, ActiveState is only giving free access to Perl modules that are actively supported by the developer community? Once the original authors and user community quit supporting / extending a module, ActiveState is requiring purchase of ActivePerl Business Edition to even have access to those modules?

Assuming I've got this straight, I wonder: Is ActiveState actually continuing to maintain and develop those modules? If so, assuming they violate no open source licensing requirements in doing this, it still smacks to me of something other than the open source spirit.

I think they should at least let users continue to load the "unsupported" modules -- so long as they still reside on CPAN -- via ppm. If they're worried about their own liability they can present a "use at your own risk" click-through in ppm.

Strawberry Perl loads up HTML::TableParser without demanding a toll.

The upshot of this, for me: I'm done with ActiveState, which I've used for several years, and am switching to Strawberry Perl.

BTW -- Larry Wall has declared Strawberry Perl his preferred Perl implementation in the Windoze environment.

ActiveState Staff
Thu, 2013-05-16 09:45

Strawberry Perl has it's own role in the community, and is a good solution for people like Larry who don't need support, upgrade in synch with the Perl release schedules, know about compilers, and have no concerns about the terms of GPL licensing. Increased adoption of Strawberry is an indicator of growing sophistication and maturity in the Perl community, and that's not a bad thing.

It looks like there are some things about PPM that I can clarify:

- ActivePerl does not lock you into PPM. It has always fully supported using the same "CPAN" tools that Strawberry Perl uses. PPM even makes a version of dmake and MinGW available for download with newer Perls, but we have never felt that forcing a non-Perl component like a compiler, by bundling it in the installer, was fit for our model.

- We apply one filter to CPAN: modules labeled Developer or Beta are never attempted, but we don't make any calls on deprecation. CPAN itself already monitors content for deprecation of modules, and they take a very long term stand on that. There are many modules in CPAN which have been untouched in years. Are they supported by their authors or not? That's usually a grey area. We can offer opinions, but not judgements.

- Availability in PPM does not mean support is provided by ActiveState, or that we have forked the code. PPM is just a build service so that end users can run Perl without needing a compiler. The Perl code used as the primary input for modules comes directly from CPAN. The CPAN maintainer is still responsible for that Perl code. If we find a problem when building, we report it to the maintainer so it gets fixed in the official source. That model works better for us than forking, and better for the community at large.

- What about the items which are reported as local patches by perl -V or modules that report a -r revision number? Items reported by Perl -V are in the installer, not PPM, and those are things we do maintain. We may apply a local patch to address issues unique to ActivePerl, or support a feature not in general Perl. Modules with -r revisions typically get that patch to fix an issue unique to ActivePerl, fix a problem when used with tools from the Perl Dev Kit, or include an important fix that the module maintainer has produced but has yet to release.

- Similarly to the case with modules, we don't make the call on deprecation of Perl versions. That happens automatically when a new major revision of Perl is released. Yes, we do restrict access for PPM, but it's access to binaries that are only usable with versions of Perl that the community has stopped working on. The modules themselves are very likely to continue to be attempted by PPM, just against a supported Perl.

- Why do we restrict access now? As a service, PPM needs to be a net benefit. Once a Perl build gets old enough to be an increasing problem to the user, does it really do the user a favor if we continue to enable it's use? We used to do that, and now we don't. One of the reasons for Business Edition is to get users to pay more attention to the downside of using old versions of open source software. More of the reasons behind Business Edition are discussed in this blog post: