How to protect my code from getting stolen by employees?

[Paul Conrad]

You could always have the programmer sign a non-disclosure/non-compete agreement.

"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak

[Amarnath S]

Two steps on top of my mind: 1. Keeping core algorithms and code to yourself, with others just getting a dll to link to. 2. Making sure that the licensing algorithm and code is with you alone. You alone should hold the license generator.

[raddevus]

1. You could make them partners in your company. Then they'd be stealing from themselves. 2. Give them profit sharing so that the more money the code makes the more money they make then they have no reason to steal it. 3. Pay them so handomely it would be more work to steal the code than to sit back and rake in the money you are paying them. :cool:

[ekesa]

THE ONLY BEST WAY IS TO FIND SOMEONE OR A PROGRAMMER YOU REALLY TRUST OR MAKE HIM OR HER A SHAREHOLDER IN YOUR BUSINESS.

[CHill60]

Just a gentle reminder that all-capitals is considered to be "shouting" on the internet, and rude. Best to use sentence-case when posting.

[s smith93]

Is everything okay with your code and your employees now? I am about to do the same thing, I am not really good at these things. I proposed a term in the contract to prevent him from copying the code. Is this enough? Could you share what you have done? Thanks in advance :)

[Sid pathan]

There are plenty of software's that can help you keep your data secured. Google them !

[DCE Security Ltd]

In computer science, method of maintaining proof of authorship (PoA) in code is done in the style of one of two approaches. The chosen approach is either A) a tangible, or B) an un-tangible. Tangible PoA methods are usually either literally simple like writing your name, username, ID number, into the code. This does work to some extent but can be removed, even if the thief doesnt remove the string, you must be able to show PoA of this string. So, make sure the string you use is verifiable to you as the string has to be able to show by verifification that you have PoA of the string (tag/ID number/email address etc.). Using this method, you could include a ciphertext string in the code if the plaintext had been encrypted using your public key. If the plaintext consisted of 'mr.xx wrote this code and owns all including intellectual rights to this code' for example, before insertion of the ciphertext string into the code, remember that the encryption key for this string must be one which your private key can decrypt. This therefore stamps the code with an easily provable PoA element, so if the code pops up somewhere else, you could demonstrate your explicit and exclusive PoA of the code. Another useful tangible approach method is adding 'red herrings' into the codebase. A red herring in this context is anything in the code that is nonsensical and usually syntactically invalid. If you added a few letters at random to the end of randomly-selected and randomly-ordered code lines it could be used an PoA as only you could explain it (showing your valid PoA); nowadays you could even include an encrypted statement of ownership and timestamp ciphertext that can only be decrypted by using your private key, then build a pseudorandom ciphertext-bit distribution process. The reverse of the distribution algorithm will collect and reconstruct the original ciphertext. You could then decrypt this ciphertext and show those who are concerned that you have PoA over the code. Whereas an intangible method would likely be computerised; one example is, the use of compartmentalisation to keep code secret from those who didnt code it. This can be done by writing chunks of code in various containers, such as; a written in javascript in a HTML setting. or a Python script batch that is called upon by the C++ applicationcodebase or even just host the secured script on sister server and code the applications interaction with the code via APIs like you would in most applications. Hope this helps

[User 13495102]

There are several actions you can take to protect yourself and your business. 1. Establish a code of conduct. 2. Set up organizational checks and balances. 3. Institute policies and procedures. Thank me later at Oakton Tow Truck!

[Matt Comb]

This is a tricky one and it depends on the size of the code base you are trying to protect. Here are a couple of things you can try. 1. If the code represents a platform, and if the team is large enough you can segment the codebase into multiple repositories and then segment access to them e.g. repositories for the presentation tier (gui interfaces) and repos for services so no one in the team has access to the full set of code. 2. You can achieve similar things to the above by having "core" code e.g base and common classes which are compiled and provided as compiled assemblies to the rest of the team. This way they never work with the deep internals of the system. 3. If you are working with applications you can look into locking them down with code signing certificates. This not prevent the source code but it will prevent the team from taking the code and repackaging it for sale as they won't have the certificates. 4. If you are really paranoid, consider getting all developers to remote into a terminal services environment (or similar) for development, this prevents the ability for the developer to copy large number of coding files off the development environment. Hope this helps a little.