http://qs321.pair.com?node_id=108445


in reply to Why is it bad to hide the source?

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.

Replies are listed 'Best First'.
Re: Re: Why is it bad to hide the source?
by dragonchild (Archbishop) on Aug 28, 2001 at 18:17 UTC
    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!

Re: Re: Why is it bad to hide the source?
by coreolyn (Parson) on Aug 29, 2001 at 01:56 UTC

    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.
Re^2: Why is it bad to hide the source?
by JavaFan (Canon) on Oct 27, 2010 at 09:12 UTC
    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.