Fresh Perl programmers often ask 'How do I hide my source?'. First of all do a perldoc -q 'hide the source' if You haven't read about it in the FAQs.

Question: Why is it bad to hide the source?

In short:
- doesn't work
- pointless
- waste of time

Doesn't work because the Perl interpreter must read it and You can't snatch it at that point. Obfuscation of the code isn't a solution, You can use B::Deparse to see what is does, or You can use the Perl debugger.

Anyway reverse-engineering a software is legal in some countries (e. g. in Finland), if it is required for e. g. assuring interoperability between systems.

- "I don't want to give away my knowledge"

Nobody owns knowledge in fact. Programmers' real knowledge is the ability to construct non-trivial programs. It isn't in knowing some specific tricks or even knowing some specific algorithms. If people are buying customized applications, they typically expect to get full rights to the resulting code, anyway: source code, documentation everything.

- "I live by programming. If I give away the source I can't ask money for e. g. bugfixing?"

Charging for bugfixes is in fact illegal due to most countries sales laws. If You sell something for a price, they may demand it works. If your program is too buggy, they can require You to fix it or give their money back.

If You are a good programmer, write good code, You are cooperative and professional enough, customers will certainly use You for more than one project. On the other hand if You behave like a moron, encrypt your code, make sure code won't be reusable, act as if You don't trust the customer at all, etc, You certainly won't get even the first project. They can't ask the first best guy from the street to debug pro-level Perl code. If they had the time/ability to write the program they want, they wouldn't have hired You.

Hmm! The only way to address this issue is to go ahead and post the code w/ the real password and the IP address of the server. HHOS! Storring any kind of uber sensitive data, like root's password, in a script is not only generally bad form, but a *H*U*G*E* security issue as well.

If one feels a necessity to do this, don't. There's usually a better way, like running it as a cron job or daemon or interactively. Ask the monks; read the holy texts. Some monk likely addressed such an issue in the past and devised an elegant yet functional solution ( like encasing the server in concrete and sinking it in the Atlantic ). Worst case, it will provide the Monastary an interesting query.

UPDATE: oh, yeah ... it is likely legally sticky to store privilliged info in your code ... due dilligence and all that ...

HTH
--
idnopheq
Apply yourself to new problems without preparation, develop confidence in your ability to to meet situations as they arrise.

I agree that obfuscating your code solely for the basis of continued employment is unprofessional. This is also unethical and if the client finds out, and has any brains they will get you out of there ASAP. I think your point here is very sound.

I disagree with the statement that there are no valid reasons for hiding your source.

If you're supplying a client with software, under a support agreement and Jo{e|an} Admin decides to use their newly acquired perl skills to "improve things" and horribly munges the software, then you may have to fix their mistakes at your expense. Sometimes you can charge but sometimes you can't.

Hiding your code when you don't trust the client not to break it, is valid, so long as the client can have access to your well documented/structured code after the support agreement lapses. This tends to discourage casual hacks.

Hiding your code is not pointless, yes you can reverse engineer from the debugger or b::deparse, but this is not exactly simple. Recreating the program structure is complex and requires someone with a good knowledge and lots of time. E.g. C debuggers have existed for a long time but few people have the expertise to recreate the C source from a running program.

Charging for bug fixing is legal, depending on your support agreement. Developing perfect software costs a lot of money, the client can pay the cost up front in terms of expensive development, or they can pay the cost later in terms of support costs. If they don't pay it, and you support them for free, you will be out of pocket.

I agree however that you should always provide your client with a mechanism to get access to the source, should you no longer be available to resolve their problems. Escrow agreements where the source is held by a trusted 3rd parties are good alternatives to revealing your source.

"Nobody owns knowledge in fact. ".

I may be misreading your point here: I'm interpreting this as 'knowledge cannot and should not be owned, and thus should never be charged for'. I strongly disagree with this.

I consider that I own the personal information (aka knowledge) about myself. You have no right to this.

I consider that any investment I make in developing a complex product, that involves a lot of domain specific knowledge, can and should be protected. If it cannot be protected why should I make the investment? Why should drug companies develop new medicines if their knowledge cannot be patented and protected?

My perspective here is a little different as I'm approaching this from the perspective of developing specific software projects under contract for a potentially large pool of clients, not as a private contractor/gun for hire. (Not that I'm actually doing this now but I would like to keep the option :-)

"The future will be better tomorrow."
... from the collected wisdom of George W Bush.

What about if you have a client that requests that the code stays secure so that competitors can not use or adapt it? Especially if the code inlcudes the use of unique business algorithms?

For example, say a small web design firm has spent the last 4 years building a web marketing business, and has developed systems to track customers, projects, sales, sales leads, etc. They now want to turn this paper system into a Intranet using Perl. But they either don't want their competitors getting the code, or want to sell the code? Wouldn't you want to protect the code source some how?

Two easy answers (though I'm sure there are many more that are better).

If the client wants specific routines protected, write then in C, compile that, and distribute that lib with your Perl. That gains your the "protection" that compilation affords to protect your proprietary stuff with the development benefits of Perl

If the client wants the whole thing protected, then they should develop in Perl, port to something else (like C), compile that, and distribute that. Perl isn't meant to be distributed in a proprietary fashion.

Of course, the second point brings up an interesting discussion that's been touched on a few times ... business models. Red Hat, Caldera, and the other Linux distros ... their business model is to charge for standardization and support. They don't charge for software at all. This is directly opposed to Microsoft's business model, which is to charge for standardization and algorithms and pretend to support you.

Perl directly supports the first model and directly does not support the second. Build a sufficiently complex Perl application. Give it away. Make is something everyone wants to use. Then, charge the users for support and updates. (Sorta like a drug pusher, but nicer.) Give the user rebates for bug reports. Give them a bigger rebate for a patch. Some users will make money on you, but most will not. Some users, you will make money on, most you will not.

This is the argument that drives me bonkers about wanting to 'hide your source'. You as the code developer know the code. You know the strengths and limitations, and having developed it are already hard at work at developing the next generation and have the reputation of being the leader. As the old addage goes 'Imitation is the most sincere form of flattery'. Additionally if your competitor is following you, then you have the strategic advantage and the competitor is doomed to follow. Let them eat your cake!.

What about if you have a client that requests that the code stays secure so that competitors can not use or adapt it?

Then tell your customer to pick good passwords for their system.

For example, say a small web design firm has spent the last 4 years building a web marketing business, and has developed systems to track customers, projects, sales, sales leads, etc. They now want to turn this paper system into a Intranet using Perl. But they either don't want their competitors getting the code, or want to sell the code? Wouldn't you want to protect the code source some how?

Yeah, but not by "hiding" the source. You do this by securing the systems the program is run on. In the same way the company keeps secret documents locked up, instead of printing them out rot13 encrypted, and leaving them in the lobby of the building.

Yes! The value in a good program is really the value of the programmer. Giving the source to one program is giving just that, but the real value is the ability of the programmer to design and write other good programs.

I think spending time answering why it may or may not be bad to hide the source is a distraction from the real problem, thinking that it's to one's advantage to hide the source even if one could. Code that's already written in an infinite good. It is much more profitable to use it to sell scarce goods.

For those that are focused on hiding the source, this would represent a change in their business model. That can be hard, but that's what it takes to compete.

> "I live by programming. .. ask money for e. g. bugfixing?"
>
> Charging for bugfixes is in fact illegal due to most countries sales laws.

Okay, but there are *other* reasons besides bugfixing, like attempting to limit distribution of code, which is pretty difficult if the source is open. You cleverly ignore the rest of the discussion by framing the question and answer.

And I *know* that any such hiding or copy protection scheme can be hacked by a talented and motivated hacker, and yet I still lock the door to my house, and I bet you do as well, even though locks can be picked.

Really what this comes down to is that some people don't believe in obfuscating source for ethical reasons (i.e., the Open Source movement) and so they push for others to not attempt to hide their source for practical reasons (i.e., the superhacker argument). We do not live in a society of superhackers. And even if one superhacker finds a way to hack your code and distribute it does not mean that everyone in the world will start using it for free (unless we're talking about music ;-)

It seems to me that this is clear:

There are very strong ethical considerations for whether your source code should be hidden or not. It might be worth reading some of the arguments for both sides, you may find yourself an open source convert.

And if not, then you'll have to be wary of all the converts trying to give you technical advice with an ethical slant behind it.

There *are* "solutions" for packaging your perl code, all with different tradeoffs and costs. If you are looking for something free that works with plenty of simple scripts, then consider:

Went to join the gridlock to see it
Held an eclipse party
Watched a live feed
I cn"t see tge kwubosd to amswr thus
I tried to see it, but 8000 miles of rock got in the way
What eclipse?
Wanted to see it, but they wouldn't reschedule it
Read the book instead