Protecting SourceCode

[zooropa66]

I've been working on a large project for my employer for a year now (but software development isn't part of my normal day to day duties). Most of the work (around 70%) has been done in my own time at home. The company were going to buy a system that would be customized by developers at a cost of around $60,000. I've developed a solution that is probably better than what they would have got. At my last appraisal my boss said that it had been discussed that i would be rewarded if i delivered it. I reckon i'm about 2 weeks away from completing the project. However, I'd rather get nothing for my work than a pittance.

My question is:

Is it possible to password protect access to the source code? I'm working with Access 2003 just now. I know I can create a .mde file to prevent access to the source code but that would make further development difficult. Any suggestions would be very welcome.

 

[bob fitz]

I know I can create a .mde file to prevent access to the source code but that would make further development difficult.

Not if you split the db and keep the mdb file at home.

 

[Lightwave]

Yep you keep the mdb file and only give them mde files.

Experiment with it but it's kind of good practice only to give users mde's anyway as they have smaller footprints tend to run quicker and they can't go in and break things. (although sometimes its nice to give talented employees the opportunity to discover things / learn for themselves )

 

[MarkK]

Look, if you are directly employed by a company and you deliver a database system, they own it. Maybe you worked on your own time, but so what? Unless you have a contractual agreement outside of that employment relationship for delivery of specific products or services, I don't see how you avoid this reality. You could only have written that system as a result of knowledge you gained as an employee. And if, in that capacity, you deliver a system with the intent to solve a problem--even an mde--then I don't see why they don't retain the right to update that solution.

I think you have to be very careful about how much work you do for whom and under what circumstances. You are putting yourself in a really vulnerable position trading a million hours work on your own time for the suggestion of some unknown future "reward," and that has nothing to do with whether you deliver an .mdb or .mde.

Think how hurt you might get if they screw you around. You are making it very easy for them to screw you around, again, not a function of .mdb or .mde.

I only deliver mdb files. I sell services not products. My product is so customized that it would need to be almost completely reworked to solve a different problem, and that reworking is the service I provide.

Best of luck
Mark

 

[Lightwave]

Lagbolt raises a good point. I wish people would dig around back code more but they simply don't.

Pity they might start asking better questions.

 

[zooropa66]

Actually, most of the domain knowledge i've used has been gathered over 20 years working for various companies. It's mainly the VBA part i've learned at my current employer. Your point is a good one though.

 

[NigelShaw]

Look, if you are directly employed by a company and you deliver a database system, they own it. Maybe you worked on your own time, but so what? Unless you have a contractual agreement outside of that employment relationship for delivery of specific products or services, I don't see how you avoid this reality. You could only have written that system as a result of knowledge you gained as an employee. And if, in that capacity, you deliver a system with the intent to solve a problem--even an mde--then I don't see why they don't retain the right to update that solution.

I think you have to be very careful about how much work you do for whom and under what circumstances. You are putting yourself in a really vulnerable position trading a million hours work on your own time for the suggestion of some unknown future "reward," and that has nothing to do with whether you deliver an .mdb or .mde.

Think how hurt you might get if they screw you around. You are making it very easy for them to screw you around, again, not a function of .mdb or .mde.

I only deliver mdb files. I sell services not products. My product is so customized that it would need to be almost completely reworked to solve a different problem, and that reworking is the service I provide.

Best of luck
Mark

I dont know though... If the Company specifically asked the OP to develop the database, then they do own it even if the OP developed this mostly at home. If the OP suggested that it could be done 'out of hours' in personal time and made it clear, they i wouldnt think that the Company would own it. The problem is that it has been developed without any confirmed agreement. The downside is that 30% has been developed inside work hours so technically, the company owns it unless a specific agreement was made to isolate that.

I would attempt to confirm what the 'reward'would be and probably state the time spent from your personal time and more importantly, not to highlight that 70% was done at home because that exposes the 30% from work. Not that im telling you to be untruthful to them, im just suggesting to limit the information you provide for development time.

You should have really tried to set this in stone from the start though to secure a fee.

Nidge

 

[gemma-the-husky]

lagbolt is right

rather than doing any more work, you would be better discussing this with your firm at this point, and trying to negotaite a sensible compromise.

in legal terms, you are probably in difficulties though. your firm is no doubt much bigger and stronger than you, and are probably legally in the right anyway. things you do inyour employment belong to your employer. working at home is just paid (or unpaid) overtime. you won't be wanting to fight them on this, and you ought to think very carefully before oyu decide to "lose" the software.

 

[MarkK]

To be clear though, I'm not saying don't deliver the system, just understand the reality of the situation and set your expectations accordingly.

I think you do, potentially, have a lot to gain by becoming the go-to guy for data management in an organization, but consider that data is very sensitive in a company. If you control collection and processing of data you become quite powerful, and you need to understand how that will impact the feelings of others in the workplace, particularly bosses who might already feel threatened.

You actually need to be quite delicate. Change in a workplace makes people very nervous, and a lot of people already feel vulnerable about their lack of computer experience and knowledge. And you want everybody to trust you, and like you, and see the value of your vision.

Sell people on your ideas and get your work out there for sure, but understand it's not so much the specifics of your system or your code that's valuable, it's you and your good attitude, and your good relationships in the company, and the confidence you generate in your capability to continue to deliver that value going forward.

All the best,
Mark