By Richard Rost 43 days ago
I received this email from one of my developer students, and I wanted to share it as well as my reply because I've been asked this many times before. I'll keep him anonymous, for obvious reasons.
Q: I need advice from you. I am the owner of a database I created at work. You know how protective we get towards our databases. What would you do if a new employee is hired and she wants to learn what I do, and she wants to get a copy of my project. If my manager tells me I have to teach her about my database, do I look bad if I say that it bothers me? I do not really want to mix someone else's database in with mine. Please help me.
A: I'll start out by saying that I'm not a lawyer, and you should speak with one before making any decisions, but this is my understanding of how the law works.
If this is a database that you built at home on your own time, then its your property, and you can do whatever you want with it. If that's the case, you can sell or license it to your employer however you want, and if you don't want anyone else in the design (source code) then you don't have to. Of course, your boss can also terminate your employment at any time and for any reason or no reason at all, as you live in an "at will" state.
If, on the other hand, this is software that you built on company time, on company premesis, or using company computers, then your employer can argue that the software belongs to them. You have no say in whatever is done with it. They can demand you give them copies of the source code and/or teach anyone else how to use it. You of course, can choose to quit and not provide training, but the software belongs to them.
Now, that's my understanding of the legal ramifications of software development at work. In the real world, however, things are often a bit more complex than that. What I would do is explain to your employer, "look, I built this software from the ground up. I know it inside and out. I really don't want someone else tinkering around with it. I don't want them introducing bugs that I have to then fix. I'm happy to teach them about it (on company time, of course) but I really don't want to let anyone else mess with it."
If your employer is smart, they'll understand. I get it. I've been in that situation as an outside developer. I had a very strict policy with databases that I used to build for my clients. If I install it as a locked ACCDE and nobody has access to make modifications, then I will warranty the software. If any bugs are discovered, I will fix them on my own dime. If you want me to give you the source code (ACCDB file) then I will, but if any changes are made, it voids your warranty. If you want me to troubleshoot problems that someone else created, it's double-time.
In addition to not wanting someone else messing with your code, I understand your reluctance to give up the program. It's job security for you. That software makes you indespensible. But, just be aware that if you built that database at work, your employer technically owns it.
I also understand why your employer wants you to teach someone else about how the database is built. They don't want you to be the only person that knows what's going on with it. It's probably not that they're trying to get rid of you, but put yourself in their shoes. What happens if you get hit by a bus tomorrow? Who's going to maintain their business-critical software? The more they rely on your database to run their business, the more important a backup developer becomes.
Ultimately, I can't really tell you what to do. Every situation is unique. However, I hope this gives you something to think about.