Sage 100

What's the answer when a client's employee demands a password to a development db? The employee has been taking computer classes/programming classes. The db is a prototype for an interface to collect labor transactions for later import to Work Order. The db isn't setup for multiple programmers and I'm not comfortable with him seeing the property strings for pass through queries, nor having him mess up the work to date.

I think you just answered your own question: ""I wish I could give you access to the database right now, but it's still a prototype, it isn't set up for multiple developers, and there is some information in the code that could compromise security if too many people got hold of it.

Explain your concerns to the client and let them make the call regarding property property strings etc. Regarding the ability to mess up your work, make a copy of the db with a different PW. Tough situation to be in. Is any of the code proprietary?

Thank you both, great suggestions. Is any of the code proprietary? Well @JeffSchwenk I guess some of its, since I wrote it myself, especially the special ways to display the drawings from bill of materials and images from inventory, not that someone else couldn't figure out a way to do that too. The primary contact at the client suggested I make a copy, change the password on the copy, then pass it over, but that seems a bit decietful. Yes, backups on hand.

If it is proprietary - Increase your price 100 fold. If they don't understand that then tell them to think about buying Microsoft Office versus buy a licence to the Microsoft Office source. $$$$

I like your thinking @DanBurleson!

Go with Dan's response. However, you may want to change your engagement letter to reflect that the code is proprietary to head this off at the pass.

@MoiraGoggin, for us, the first question to ask is; ""Is this employee authorized by management to have access to the data / programs being requested?"". The second is: ""Does management understand the security risk / exposure that comes with disclosing the requested information?"". The third question (as previously stated): ""Is any of the code proprietary to you as the developer and is it covered in any documentation, disclaimers, terms sheet, or agreement that you have in place with your client?"" This is something you should always have in place if you don't intend to provide source code to the client. If the client understands what is being shared, still wants you to share it, and you haven't covered yourself regarding proprietary ownership of the code, you are obligated to give the information since the client purchased the tool from you. My two cents. Sorry, no sugar to go with it. It can be a bitter pill sometimes.

@JeffSchwenk - the engagement will cover this in the future, a very good suggestion, I'd just never run into this before and hadn't thought that part through. The purpose of the prototype was to create the screens and programming flow so that it could be passed off to a C developer who'd write it up with an ASP front end and provide the source code with the final program, and I did find someone to write it up and provide the source, hope they're still available...

@ShawnSlavin - yes, it is a hard one to swollow, but you're absolutely right.

What does your contract say about access to the source?

It's pre-contract prototype, it was for a proof of concept, I proved the concept then got the rest of the job (a nice 50 user deal). The prototype then was used to spec for a C programmer, but it was never meant for production only testing. The employee in question took credit for my prototype btw, claiming it as his own, and is now in hot water since he lied and management expected him to produce a final product rather than have an outside programmer write it and provide source. He doesn't have a clue (believe me, I had to explain what ODBC is to him) , so I suspect that by demanding the password, he thinks I'll just shrug my shoulders and let him have it. (ugly huh) So, there wasn't any agreement about source other than verbal that it's my prototype for testing and spec work only. I'm kicking myself for not having something in writing for a prototype, too darn trusting I guess. I was paid well for the prototype with a promise to credit back a portion once the prototype was re-written in C. Never would have thought someone would take credit for my work like that.

Sage licenses their program but not the source code (without additional fees). Live and learn and use your judgement but on future projects add in a single line clause that you retain all rights to source/development code unless agreed to in a separate written clause.

Very good advice @WayneSchulz - I generally do linked db after contract, this was a first to do it before hand, now I know to have an engagement for prototypes with that line, retaining all rights to source/development code. Thank you.

Careful! You didn't say in what system your prototype source exits. Many are easily broken into with programs freely available via the Web.

It's good old VB & Access and someone could easily crack it and perhaps they have but then got to the secondary password and it blocked them. But then again, the pseudo-programmer employee doesn't get ODBC so, its not likely.

@MoiraGoggin, what deliverables were defined within your agreement? Was it the prototype or a design document to be used for the development of the later program? I may use a number of tools to build a bird house but in the end, the customer gets the bird house, not the tools I used to build it with. Certainly MS Access is a tool. However, if you built your own tool or jig to create the end product, that doesn't mean they get the tool or jig, just the end product. (Sorry about the 'jig' reference. Too much 'New Yankee Workshop' on PBS.) If the end product was the prototype, then you are still in a box. Good luck with this. Let us know how you work it out and if you come up with something to add to your engagement letters or terms and conditions documents in the future, I would love to see a copy. Plagiarism is alive and well!

Thanks to everyone for your ideas, suggestions, support, words of wisdom, and plain talk of hard lessons to learn. Rather than get involved in a power struggle via email, last night I decided to handle this with a phone call directly to the employee that originated the demand. Turns out he'd rather I deal with the db to get it past the last beta test and then pass it off to an outside programmer. So, he never asked again for the password just asked what he could do to help out with data, ideas, and testing. He confessed that he'd written the email in anger having just been chewed out by his boss and apologized! Now that I have breathing room, I'm sending out a specific engagement for this beta. I'll post the details @ShawnSlavin for your future plagiarism, and anyone else too. Thank you all again, this group is truly the greatest.