13

Perhaps the most obvious way of protecting a company's intellectual property from its own developers seems to be an NDA - Non Disclosure Agreement. Effectiveness of this approach may vary, depending on many factors, and sometimes or somewhere it may not work as expected.

What other approaches, apart from this purely legal one, exist for protecting software code from the people who develop it? Do they exist at all? Does it make sense in practice?

Maybe, for example, Team Edition of Visual Studio already contains some features related to this problem (for example, levels of access to parts of code, depending of role inside a development team or something like that)?

Reference on the topic:

As statistics says, on average, programmers tend to change their job every three - four years.

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
rem
  • 16,745
  • 37
  • 112
  • 180
  • 3
    From a purely curious standpoint why would this be necessary? I immediately think the environment would be chaotic or have a high turn over to have fear over developers stealing code and going somewhere else making "good use" of it. Anything at an ultra high level should probably apply for a software patent. – Mech Feb 09 '10 at 20:20
  • 6
    should be community wiki – SilentGhost Feb 09 '10 at 20:20
  • 7
    Heh, takes balls to ask this on a developer site :) – Pekka Feb 09 '10 at 20:34
  • 5
    This is an awful idea. You will undoubtedly create an environment conducive to failure. – JP Richardson Feb 09 '10 at 20:35
  • 2
    @Mech Software, the fact that you can patent software at all is kind of frightening. – mmcdole Feb 09 '10 at 20:49
  • @Simucal: As a US citizen, I agree with you about software patents. – David Thornley Feb 09 '10 at 21:16
  • @Simucal: I agree as well. I disagree with patents however based on this question it sounds like there might be some critical software piece that should only be allowed to a small group of developers. Is this the KFC Secret recipe by chance? :) – Mech Feb 09 '10 at 21:29
  • Mech Software: The word "patent" *means* "make public". The KFC Secret recipe is almost certainly a trade secret, which is almost exactly the *opposite* of a patent. Its value is largely in that it's not known to the general public. – Ken May 21 '10 at 20:41
  • If you can't trust your coders to behave professionally then why trust them to write your code? – TheMathemagician Sep 19 '12 at 14:15
  • Duplicate of https://stackoverflow.com/questions/173875, https://stackoverflow.com/questions/1382538/how-do-you-prevent-hired-developers-from-stealing-code?noredirect=1&lq=1 – tkruse Jan 10 '18 at 00:57

12 Answers12

34

Try to build a team you can trust.

cherouvim
  • 31,725
  • 15
  • 104
  • 153
  • I agree. Probably the best job I ever had was in a company where half of the developers were working there for about a decade, some even longer. Good policies made people stay and that in turn made for very good code. ("I have been maintaining this baby for more than ten years and it's in such a good shape because I never allowed such code in there. I demand this to be cleaned up!") – sbi Mar 16 '10 at 18:26
34

The first approach is to force programmers to only know interfaces of other components, so that each one can only steal a small part of the whole software. This approach can be borrowed from footwear production. One transnational corporation, to prevent stealing by employees, arranged its factories so that each factory produced only left or only right shoes. You could do the same with your code: some programmers only write lines with odd numbers, and the others--those with even numbers; provided that they can't see the work of each other! That's sometimes referred to as "pair programming".

Some organizations force employees to sign a non-compete agreement. That's the kind of agreement that prevents programmers to work for competitors. This technique is best combined with job postings like "Looking for senior programmer with 5 years of experience in the similar field".

To prevent your programmers from stealing, you can do harm to them as soon as they finish the software. The method proved itself as the most efficient, and has been used for centuries. For example, Russian Tzar Ivan The Terrible burned eyes of the architect that designed a beautiful church at the Red Square, so the one designed remains the most beautiful ever. You can do something like this to your architect. I heard, latest Visual Studio contains some features...

Nowadays, however, it's more humanistic to hire already blind and already dumb people that lost their hands, so that they can't look at your code to memorize it, can't tell anyone about your code and can't type it again. The advantage is that this will help you dealing with labor agency in your country, which watches for balance that your employees are not discriminated.

And yes, this post is a sarcastic joke, which criticizes the idea of any code-stealing-prevention measures. Sorry, couldn't help posting it.

P Shved
  • 96,026
  • 17
  • 121
  • 165
  • 1
    It should be mentioned that loosing the hands is absolutely essential, otherwise you could read the code with braille displays. And it should be noted that maybe talented individuals will be able to read braille with their toes, so maybe you need to cut these, too ;) – Stefan Steiger Aug 14 '13 at 05:54
17

How do you protect a power plant from sabotage by an employee? How do you prevent a boxer from throwing the fight? How do you prevent a brothel from distributing the clap?

Your concern, while valid, is one that can only be properly addressed by personal responsibility and accountability within your team. Any options you employ to secure the code against theft is likely do more harm than good. If you feel a team member is not trustworthy, get rid of them.

Chris
  • 27,596
  • 25
  • 124
  • 225
6

If really necessary you can split the application in subapplications. Each team works in a single application and sees all others as "black boxes". Maybe SOA helps here.

cherouvim
  • 31,725
  • 15
  • 104
  • 153
6

It's highly unlikely that your code is the real intellectual property - that is your company's business knowledge and process.

  • Agree: only a small number of companies invest *that* much in R&D unreleased source code actually give some real competitive advantage – ZJR Feb 10 '10 at 11:17
  • Still I heard of managers using *Company A* workpower for the benifit of *Company B* making them implement features the *Company B* customers requested and then bootlegging them, but it's obvious **this kind of people isn't really bothered by legal roadblocks**. – ZJR Feb 10 '10 at 11:25
5

SVN has the ability to limit different users to different folders, so you could split your code up into seperate libraries, and allow only certain people Read / Write access.

The file for this is under conf\authz Here is a sample

[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average

[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe

[/
# [/foo/bar]
# harry = rw
# &joe = r
# * =

# [repository:/baz/fuz]
# @harry_and_sally = rw
# * = r

Some documentation can be found here

Under 'Per-directory access control'

PostMan
  • 6,899
  • 1
  • 43
  • 51
4

Either build a team of developers that you can trust, or entirely lock their system down so they can't access the USB ports, the CD drive, or web mail clients. The only thing they could do is work on the code and possibly browse the web. Also only give them access to the code that they are in charge of.

But with all these security measures chances are your developers will hate working with you and quit their job

Matt S.
  • 13,305
  • 15
  • 73
  • 129
  • 2
    I know of a guy who stole code from an environment like that by taking over 200 photos of the screen with his mobile phone... – CesarGon Feb 09 '10 at 20:45
  • If they can browse the web, there's always pastebin and the like. – doppelfish Feb 09 '10 at 20:51
  • 1
    screw it, take their phones away too!!! Or you can just be open – Matt S. Feb 09 '10 at 20:51
  • @dopplefish, web can be browsed via remote-desktop clients with copy-paste forbidden. Remote-desktop is a security measure, not code prevention, so it may even be not too hard to implement. – P Shved Feb 10 '10 at 11:43
2

There's no straightforward way to do this if your code is within the same project (i.e. you want to allow access to some parts of the code and not others). However, if you have seperate projects that require different security levels, it's possible to allow developers to only have code access to certain projects, and then pull builds from a common build server.

Keep in mind that decompiling of frameworks that work against IL like .NET is relatively straightforward, so preventing access to the code files is not necessarily a silver bullet to protect IP.

Ryan Brunner
  • 14,723
  • 1
  • 36
  • 52
1

I know you said aside from the purely legal one, but I'd just like to add that in addition to the legal one you mentioned, there is also the Non-Compete. Basically says that once you leave your job, you won't be able to compete in any way against your former employer. Stealing code is not as appealing if you won't be able to put it to use for a year or two.

Brandon
  • 68,708
  • 30
  • 194
  • 223
  • At least in the UK, non-compete clauses in an employment contracts are of of dubious utility - the courts tend to favour the employee's right to work. –  Feb 09 '10 at 20:30
  • Even here in the States, non-competes are largely for show and someone who takes the moral high-ground will attempt to abide by what they signed; "stealing code," however, is ALWAYS illegal and should be punished. – Austin Salonen Feb 09 '10 at 20:34
  • 2
    Non-compete agreements don't prevent someone from selling the stolen code to a competitor behind the scenes. – doppelfish Feb 09 '10 at 20:53
  • Non-compete agreements aren't valid in all US states, and if they are binding they'll discourage competent people from working for you. – David Thornley Feb 09 '10 at 21:16
1

You could make them develop a module that would be seperate from the rest of the application. If you had a plugin/module type system going this would suit well. You could release APIs for the developers to develop against and have them integrate with your DLLs and not the source code.

People seem to be very critical of this but there are legitimate reasons for doing this i.e. partnering with a potential competitor if you gave them all your source you would be shooting yourself in the foot.

Burt
  • 7,680
  • 18
  • 71
  • 127
1

It might be worthwhile to spend some brain cell activity on the business model you want to follow. If the core value is embodied in the code, the core value can be stolen by stealing the code. If, however, the core value of your business is embodied in a group of employees, some of them engineers, others sales people, yet others customer support people, and when the software is only the net that keeps these peoples business going, then there's no easy way of stealing the value of your business. And if the software does get stolen, the thieves won't be able to make much use of it.

So, in addition to what cherouvim said, build a team that you can not just trust, but a team that is the core value of your business.

doppelfish
  • 963
  • 7
  • 18
1

Develop your software in modules.

Have one common module that contains objects that pass back and forth, and utility classes that act on those objects.

Have each group build modules on top of that, without much need to know about other modules.

Have one trusted team of developers do the planning of what goes in each module, and have that team also do the integration of all of the modules into the whole.

Also have a lot of trust in whoever runs your version control server. While it's stable, no one developer can do all that much harm; they can't delete everything, for example, and you'll know exactly what they did and when if that ever becomes an issue.

Dean J
  • 39,360
  • 16
  • 67
  • 93