in reply to Re^3: Debugging PAR packaged programs
in thread Debugging PAR packaged programs

No, you can't, Grandfather. For example, code contamination rules.

Replies are listed 'Best First'.
Re^5: Debugging PAR packaged programs
by Tanktalus (Canon) on Dec 10, 2008 at 04:57 UTC

    That's basically covered under scenario #3, "Manager support". Seriously. Start by talking to your manager about the situation. There are two types of "contamination" that I can imagine your employer being worried about: copying of unauthorised code, and licensing issues. The first one is pretty easy to manage. Point out that you will not be copying unauthorised code. You won't be taking the CPAN code and putting it into your code. You'll just install it, and use it, just as you would Boost's C++ library, your C compiler's C library (such as MSVC*.DLL), or any module that comes with Perl.

    The licensing issue is a bit more painful, but ask if your corporate lawyer wouldn't mind looking at the license that the module is released under (almost always the Artistic license). Explain how you're going to use the module. And how that lines up with what the Artistic license allows you to do.

    This all sounds like a bunch of work. And, honestly, it is. But, from experience, it's far less work than trying to reinvent the solution yourself. And once you get down that road once or twice, it should get progressively easier for each subsequent request, making it more and more worth it each time.

    In the spirit of full disclosure, I'll point out that I got a virtual slap on the wrist from my employer's IP lawyer for not following each step (which is why I recommend following each step), though he still approved the use of the code. And this is a multi-billion-dollar publicly-traded corporation (deep-pockets theory of law applies). CYA seems to be the first thing we're taught when we join, and it seems to get repeated for those drafted into managerial roles. And still, the IP lawyer accepted the use of the module in question based on the artistic license. (I'm now in the process of trying to convince the law department to start issuing blanket approvals based on licenses, such as the artistic license, just to make things easier/faster.) It's still worth it to use a module instead of rewriting it every time. And that goes a thousand-fold for XML modules.

Re^5: Debugging PAR packaged programs
by GrandFather (Saint) on Dec 09, 2008 at 21:10 UTC

    I don't know anything about 'code contamination rules', I guess they don't apply in my environment. Does the concept extend to 'thought contamination rules'? Are you allowed to read a piece of 'contaminated' code (off site presumably) then apply what you learned to 'clean room' code that you write on site? Are you even allowed to visit places where contaminated code may reside (like PerlMonks)?

    Most rules taken to the extreme are silly. You don't have to take "Not Invented Here" rules very far at all to see how silly they really are however.


    Perl's payment curve coincides with its learning curve.
      There is a set of guidelines that determine whether a site is appropriate or not. I do adhere to it because I like my job, even if the rules are strict. And you're right, if taken to the extreme, it is a bit silly.