I don't see anything wrong with it. To some extent, it may depend on who is claiming the copyright. If you, personally, are taking the copyright and making it open source, and your $WORK is licensing it to use it, then release it under your author ID. If $WORK is keeping the copyright, then maybe release it under a $work ID to help make that distinct from any other work you release on your own.

I'd think about adding your personal ID as a 'co-maintainer'. And you'd want to make sure that the XXXX at cpan.org email forwarding goes somewhere that won't disappear if you leave the company.

Thanks a lot. That's roughly the lines I was thinking along. I'm an employee, so the "default" situation is copyright assigned to $WORK, I would just be CPANing it on their behalf. I think I'll go ahead with creating an account for work, upload using that, and co-maint myself.

I'm an employee, so the "default" situation is copyright assigned to $WORK,

I'd just like to point out that "I'm an employee, so copyright is assigned to $WORK" isn't universal, and will depend on national laws.

But regardless of the country you work in, it won't hurt to talk your legal department. You also may want to consider to have your company write a document that gives you permission to release the code - and to write down anything they expect you to do (or not to do).

To some extent, it may depend on who is claiming the copyright.

Copyright ownership is irrelevant. What matters is if the person is licensed to distribute the module. For modules under the Perl Artistic License or the GPL, that would be everyone.

I acquired one of those organizational CPAN accounts, WHITEPAGE. The idea of an organizational CPAN account isn't entirely uncontroversial with the CPAN maintainers. I think it was only on even odds that I acquired it. The default idea is that individuals do the work so that's who the CPAN account should belong to.

The default idea is that individuals do the work so that's who the CPAN account should belong to.

Funny. Individuals (plural) do the work, so that's who the CPAN account (singular) should belong to.

Seems like a pretty good definition of an organizational CPAN account to me! ;-)

Having said that, there are some difficulties. If I were to work at $ORG which releases a package $PACK on CPAN, using account $NAME (be it a personal or a organizational account), with $NAME comes password $PASS. Now I stop working for $ORG. I probably shouldn't have write access to $PACK anymore. But that would require changing $PASS, and distributing passwords. It's even worse if $PACK was distributed on my personal CPAN account. Then maintainership of $PACK would need to be passed, and if me parting with the company was not on friendly terms, I might not want to cooperate.

Thanks for your input. I got the organizational account I was after approved, and I'm going to trial publishing under that, but if there's any big deal I can just transfer the module to my own name.

Sidebar: good for you and good for them. All else being equal-ish I'd choose to work at a place that does that over one that doesn't.

Just make sure that the CPAN email address reaches somebody who maintains the packages.

There's quite a checklist to go through to get anything published through that account though.

/J

I would publish under an individual's name, and have reference to their workplace.

I would think the copyright notice is the authoritative part here, not the account. The cpan account just holds the stuff. It's the docs of the distro that say who's what.- aha.. corrected- thank you ikegami, makes total sense, everyone, anyone, is authorized to distribute.

I can go copy PDF::API2 code right now, call it Agent::Orange, and distribute it- provided I state what the code is based on.. etc. This is the whole point of releasing under the perl license and using open source/gnu what have you- that code cannot be held hostage!

It's kinda like a capitalist free market science information model. If I release X and you start maintaining a version in better shape than my X, then more people will download, use it. That's what gives you 'authority' - or close enough.