Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Why is it bad to hide the source?

by z0d (Hermit)
on Aug 28, 2001 at 00:27 UTC ( [id://108254]=perlmeditation: print w/replies, xml ) Need Help??

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.

-- <-- z0d -->

Replies are listed 'Best First'.
Re: Why is it bad to hide the source?
by idnopheq (Chaplain) on Aug 28, 2001 at 13:57 UTC
    Allow me to add one ...

    - "But my code contains ( my | a privilliged | root's ) password!"

    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.

Re: Why is it bad to hide the source?
by Mungbeans (Pilgrim) on Aug 28, 2001 at 14:45 UTC
    I agree with the spirit but disagree with the letter.

    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.

Re: Why is it bad to hide the source?
by belize (Deacon) on Aug 28, 2001 at 18:08 UTC
    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?

    Just an example of why to protect the source, customer needs.

      Two easy answers (though I'm sure there are many more that are better).
      1. 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
      2. 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.

      ------
      /me wants to be the brightest bulb in the chandelier!

      Vote paco for President!

      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!.

      coreolyn -- It's the talent that has value NOT the code.
      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.
Re: Why is it bad to hide the source?
by echo (Pilgrim) on Aug 28, 2001 at 14:09 UTC
    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.
Re: Why is it bad to hide the source?
by JavaFan (Canon) on Oct 27, 2010 at 09:19 UTC
    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.
    Reverse engineering != retrieve source code.

    Reverse engineering is finding out what a program does. It does not require to find out how it does it (which is what the source code reveals).

Re: Why is it bad to hide the source?
by ikegami (Patriarch) on Mar 02, 2011 at 18:52 UTC

    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.

Re: Why is it bad to hide the source?
by daveola (Sexton) on Oct 26, 2010 at 20:06 UTC
    This post is very one-sided. For example:

    > "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:

    http://MarginalHacks.com/Hacks/perlc/

    (Written because I needed exactly such a solution myself, even though most of my perl code is completely available as source!)

        See my reply. I know there are ways to extract the source. There always will be. You can "extract source" from a C program as well. And you have to know what you are doing.

        Not to mention that the author:

        A) Didn't fully understand the tool

        B) Didn't give an example on how to actually extract the source.

        Regardless, I know it's possible.

        I know that someone can give me an exact example of how to do it if I search hard enough.

        Great.

        But that doesn't mean that the tool isn't useful.

        Do you lock your house doors? Because I have lock picks and know how to use them. And I can show you how. But I'll bet you'll still lock your door.

          A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://108254]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2024-03-19 08:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found