Slashdot Mirror
Ask Slashdot: What To Do When Another Dev Steals Your Work and Adds Their Name?
An anonymous reader writes "I have had an interesting situation arise where I built some web apps for a client about 2 years ago. I have no longer been working with the client and a new developer has taken over purely for maintenance work. Currently I have been looking for new work and have used the said apps as part of my portfolio. During one interview I was informed that I not telling the truth about building the apps and I was then shown the source of a few JS files. It seems the new developer had put a copyright header on them, removed my name as the author and put his own. Now this is grey territory as it the client who owns the source, not the contracting developer. It put me on my back foot and I had to start explaining to interviewers that the developer stole the work and branded it. I feel it makes me look like a fool, having to defend my position in an interview with a possible client and I feel I had lost the chance of directing the outcome of the interview. I have cut the apps from my portfolio, however they are some of my best work and a real testament to my skills. I decided to cut my loss and move on, I am not looking for a fight or any unnecessary heartache. So what you do in my situation?"
If the original client won't cooperate, perhaps you could send a DMCA takedown notice asserting your ownership of the copyright for the original digital content.
Sometimes the "writing on the wall" is blood spatter...
In cases of works made for hire, the employer or commissioning party is considered to be the author
Really depends on your contract. My standard contract clearly states that I retain all copyright to my code. If the client is paying for source code and not a finished product then I assign them a perpetual non transferrable right to use and modify the code provided that they attribute my original copyright.
Do what thou wilt shall be the whole of the Law - Aleister Crowley
Interviewer - "We checked the source code cited, and your name isn't on it?"
You - "Thanks for checking the source code, that was work for hire, so it's owned by the company I wrote it for, so while I'm disappointed my name was removed from the source, they own it so they decide, I can cover some of the features if that would help?'
The above shows that you clearly understand work for hire is owned by the entity that hired you. You expressed your personal opinion while remaining professional about what happened, and providing a reasonable way to prove you at least understand the code.
If they go so far as to say you lied, then do you honestly, really, want to work for them? Do you want to be dealing with them when you submit your bill?
If they approached this more professionally and said something like 'Oh we could see how that could happen, maybe you can describe the challenges in that software and the solution' then you should be able to convince any reasonable person that you at least grok the problem, and explain your solution.
They can then follow up with another question, and you've avoided the pain.
We've all had interviews where the interviewer was just an incredible jack-ass. They may be intimidated by you, they may be just an incredibly insecure person or having a terrible day and acting poorly. The best way to act if at all possible is always to be professional. Give your answers, they can take them or leave them.
Remember this part if you remember anything. You are interviewing them just as much as they are interviewing you. Yes you have to pay your bills, and feed yourself (and possibly your family), but don't go into this from a position of weakness. You are a valuable commodity, and it's their job to convince you to decide to spend the finite allotment of time we have during your lifetime working for them just as much as you may want the job.
Many technology professions and engineers are uncomfortable with negotiating. Don't be. If everyone in IT could learn that one lesson, that being hired whether it's contract or full-time is a negotiation goes a long way.
If you are dealing with a less tech-savy more 'business' orientated person you will win points (even if grudging) that "Damn this technology person can actually negotiate and isn't a nerd who would work for star-trek lunchtime showings"
If you are dealing with a more tech-savy person they probably won't be focused at all on the business side of things and you can discuss shop talk - discuss honestly some 'pain' (without dissing any company or individual) and often you can throw in a small amount of humor. When interviewing for a technology position it's a big plus to meet a candidate who can admit things that were tried that were disasters that they worked through.
If the interviewer has any scar-tissue at all they will understand you have been in the trenches and had things go wrong, and you can explain how you worked around it. The solution may not have been pretty or elegant but it got you and the company you were working with through the problem.
Someone who can think of their feet, evaluate what's going on, make a decision and adapt to save the ship is worth a ton. There are so many people in technology who search for silver bullets and are so enamored with X, whether it's hardware or software architecture that showing this helps hugely.
This is defined in your contract with the client. It is common for the developer to retain ownership of the code, but to grant an unlimited license to the client. This is common practice, since it prevents a client from suing you when you use similar code or techniques in a future project (perhaps on of their competitors). If a potential client wants me to actually hand over ownership, then they get a different price.