There are a few different approaches to this. You're correct that there are legitimate concerns on both sides. The hit-by-a-bus is probably the most legitimate from the client's perspective. In such cases, my intellectual property attorney recommends an escrow agreement, where you agree to contract with another developer (or more) to hold the credentials in escrow, to be used only in the event of your death or other incapacitation.
As far as a routine of giving up the full access, it's not so clear, because there are legitimate intellectual property concerns from your standpoint as the developer. What if he takes your work and decides to resell it? Are you protected against derivative works? Who owns the final product (as a matter of contract)? What did you agree to (in writing)?
I disagree that it's automatically "the right of the client to take the file to someone else if they're unhappy with my work". That would only be the case if it's part of the contract. If it's a work-for-hire contract, it's probably true. But not all contracts work that way (most of mine don't). (If they're unhappy with your work, why would they want to take it to someone else, necessarily?) Most of the time, I retain ownership of all the code, even when it's a custom build. That way, I can turn it into a commercial product for resale later, or I can use portions of it in other builds, saving future clients time and money. Work-for-hire contracts tend to get dicey if clients insist on owning the source code, because you end up with nasty questions about who owns what programming method you used. (There have been other threads that discuss such situations, and they're best avoided.)
Another legitimate issue you have, as a developer, is the quality of the final product. You do all the development, you do all the testing, you deliver the solution. Three months from now, the client calls up, irate that something isn't working right, and claiming your software has caused some form of havoc or damage to his business. You arrive, only to discover they've messed with the code. So who's responsible? I'd love to be a fly on the wall during discoveries for that lawsuit.
So no, I do not routinely give up the full access credentials when I do builds for clients. The only circumstances under which I even consider doing it are where the client signs a waiver of liability for any quality issues that may arise. It's the only reasonable thing to do, since I can't control the code once it leaves my hands.
You will likely get a lot of other opinions on the matter. That's fine. But I recommend you contact an IP attorney and get yourself some (at least) boilerplate licensing agreements in hand. And listen to what he tells you, because this is a lot bigger than just being nice to a worried client.
Mike, You have given me a lot to think about. Now you've got me thinking along the lines of IP while being an in-house developer. I'll contact an IP lawyer and ask them this question as well as how it works as an in-house guy.
You'll probably want to check with your in-house legal or HR department WRT your rights / responsibilities when working in-house. In most cases I've seen, employees are bound by an employee agreement that says anything they do for the company belongs to the company (it's essentially the same as a work-for-hire contract). But your situation may be different, so check with the appropriate folks at your company.
Unfortuantely my company right now has no policy in this.Since I sort of stumbled into this job by creating the need and supplying the technical work, it has been my work that has made it what it is.
And there is nothing in any hanbook that talks about the work that is created under the job description.
Working in this school system as a teacher, they've asked for lesson plans from all teachers be posted in a dropbox. I've refused because the lesson plans are my hard work.
I am developing their system under their filemaker license, and at least partly on a school computer.
I hate to ask for clarification on the policy at this point however
Think of it this way: A contract does two things (and really only two things). It defines the expectations up front (because most disagreements come from disappointed or misunderstood expectations, in business or, really, in relationships in general). By doing so, it fosters a good relationship between provider and client.
The second thing a contract does is provide you the legal basis for a lawsuit. That's a place you really don't want to go unless absolutely, positively, excruciatingly (and I mean that literally) necessary. They almost never end well, and they never end the way you want them to.
It sounds like your employer is ignoring point 1. Kind of a shame, really; if the expectation were defined more clearly, nobody would be fuzzy or have a basis for hurt feelings later.
Australian law gives the IP rights to the developer except in the in-house situation.
Evenso... you as an in-house developer can't unlearn what you know so you take that additional skill with you... Just not the databases.
We can only license to a client and only THAT instance of code because FMI only licenses to us. In turn there is code they license from others.
If I start with a DB they have constructed to begin with... they get the Full access un/pw. If I start with my own code I don't. I am more likely to restrict things to stock-standard code and leave out the clever stuff if I build in someone else's system. I have never been asked for the full access account ... But it would come at a huge cost and with contracts that restrict the use in any other circumstances or from distribution. The thing is, though.... you would never know.
With PHP it is a different story. If you don't host it yourself there is no way To restrict what they do with the pages...
I know of one job which has been passed to many developers who have not been paid the last chunk of their money before a new developer has been bought in. The owner has got tens of thousands of dollars of free development. The reality is probably that he has paid much more for his system because each new developer has to get up to speed before they can take over. These scumbags do exist. Protect yourself...!
I have my master password in the hands of my accountant along with some other developers names. My clients can have it if the bus strikes me... and I don't recover.
Sent from my iPad
11th Hour Group Pty Ltd
I think a court would rule that it is the schools property. You were employed at the time of its creation and did it as part of the job. Unless you brought it with you when you were employed.
Sent from my iPad
11th Hour Group Pty Ltd
You're probably right, and I'm not too concerned about my work. As you've said in your subsequent post, it is the skills that I learned. I wager I could rebuild a system for a school much more efficiently based on what I've learned.
There are a few custom functions that I would want to keep, but other than that, the system is there's. I have no intention of taking it with me. It is just a digital file. And I was getting paid to create it
My biggest concern is with contract jobs that I take on.
I think you have hit the nail on the head...
Every time you do something you learn and would probably attack it slightly differently next time.
A new client is like a new relationship. I like to be up-front with that fact. Clients can never be led to think there is some short service you are providing but rather a two-sided investment in the success of their business system. It is better to get good steady long term work on building upon the basics than to constantly be finding new clients.
The reality is that there is a huge task in trying to build something generic in applying to a different workspace. Someone who can figure out a complex system could probably have built it themselves and is not really a threat. Someone trying to pass off work of others as their own soon gets found out.
Giving away the full access account details is not as big a threat as it seems unless there is some nastiness involved. If clients trust you to do the right thing by them, they will be loyal.
My advise is to find the right clients and don't undervalue your services. You have to eat and you need to make sure you are not just taking on every job but rather those which interest you and where you get on well with the client and where they don't hesitate to accept rates you set. Most don't want to become developers themselves and understand that your professional history gives you the skills to make it work and what you are providing is a licensed database that does what they want and they own the data they input.... and you own the intellectual property. This is just like the dentist....they don't let you play with their tools or x-ray machine. CCA don't give away their recipe for Coke.
That's what your contracts should say.
Have a good search in this forum. There are some good discussions and some have posted sample contracts.
Sent from my iPad
11th Hour Group Pty Ltd
I’m going to agree … and disagree.
I am absolutely in agreement that it’s all about the relationship. The client should feel that your concern is the success of his business. (And honestly, it should be.) You’ll build a better product and, as you say, it’s far easier to keep a client than to find new ones.
The flip side, though, is the client who “thinks he knows”. Those are the ones who, because of the ease of FileMaker, want the full access credentials so they can “help” or “make improvements” to what you’ve built. They frighten me. (I have one like that, but our relationship is limited to consultation.) Dentists don’t let you play with their tools, but then again, the number of people who think they can drill their own teeth is vanishingly small.