Proprietary system documentation 'leaks' and how to stop them?

Question

The ability to use BitKeeper free of charge had been withdrawn by the copyright holder Larry McVoy after he claimed Andrew Tridgell had reverse engineered the BitKeeper protocols in violation of the BitKeeper license. At Linux.Conf.Au 2005, Tridgell demonstrated during his keynote that the reverse engineering process he had used was simply to telnet to the appropriate port of a BitKeeper server and type "help".

-- Wikipedia on Git

Sometimes it's not always a matter of someone leaking your documentation or source code, so much as a matter of someone not remembering to delete a utility function or two. What sort of processes and procedures do you have in place to stop these sorts of 'leaks' getting through?

Answer 1

Not creating them in the first place.

Answer 2

Being extremely careful about them, and making sure only the right people get the right documentation (this includes making sure management does not get a hold of the proprietary documentation).

I was working on customizing some proprietary software my company wrote (which relied on security through obscurity) for a client. I made sure to create two versions of document, a complete technical design document of my customization, and another one with the "security" bits removed to be shared with the client. I made the mistake of making this available to management, who shared it with the client.

Fortunately, the client did not say anything about it (they asked some questions, but did not make a big deal about it, I guess they are used to the quality of my company's software ;)).

Answer 3

I don't think you can simply avoid proprietary documentation, but I think you should clearly mark it as such.

Any code you write for internal purposes should be part of a separate project and also clearly identified.

Answer 4

Not trying to prevent third party technologies from being compatible with yours.

Seriously, if you lack the confidence to let third parties make replacements that are compatible, then think about whether that many people will find your product that valuable in the first place.

Answer 5

This touches on a related subject where you comment out things "temporarily".

It is important to have a process while coding that protects you from this.

• When making "temporary" changes, make sure that you annotate them so that you'll find them. Unit Tests are excellent here.
• Make sure the infrastructure is intelligent enough so that you can have different types of builds. You don't want to always remember to disable certain things for a certain type of build. Remove any possibility for human error as soon as you know you're creating them. (At least create a ticket for it.)