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?"
They shall all drown in lakes of blood. Now they will know why they are afraid of the dark. Now they will learn why they fear the night.
the sco trial is over man. you just had a bad dream, that's all.
summarizing the work you did, and identifying you as the original author of the code.
This isn't hard. Yahoo career advice stuff.
will not help with changing what already happened, but for the future put your work on github or some other similar service, keep the project private, then you can use that to prove precedence.
That sounds like a shitty situation, my condolences :(
I suspect the lawyer route is probably a bad idea, but I'd be really curious what a lawyer would have to say on the subject (at least here in Canada we have "moral" rights that dictate among other things an authors ownership of his work (even when it's "work for hire").
...and inform them of the unethical behavior of the new developer, the situation it put you in and how shocked you were to find that they had deprived you of the opportunity to take credit for your work. Somebody at that company hired you and knows what truly happened. Hopefully that person is in a position to put the situation right and give you the credit you are due.
That said, relying on your code being still accessible after you have left it for a while is not a situation you want to be in. Your former clients can take that code down and replace it any time they want, with anything they want. You should have checked to see the status of that code yourself shortly before you tried to present it as an example of your work.
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...
Get a referral from the company.
If the copyright message is pointing to the maintainer rather than the company, you may want to point it out to the company since the new developer may be trying to claim ownership of the code (or may simply be naive).
Most of the people here don't give a rats about intellectual property unless they are ranting about how Hollywood and proprietary software's model is broken. When it's one of our own though, it's pitchforks and torches.
Have you considered that the people who argue the former aren't always the people who are upset by things such as this?
Smart move. Because that doesn't look like an admission of guilt at all.
Seriously, how difficult is it to prove that you were there before him?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Inform them of what's happened. Get them to send you a written & signed confirmation that you are the original author.
The code you developed for your client was most likely never yours to begin with. Despite well-meaning suggestions made here, you really have no right to go back to the client and demand anything. Present the code as your own to prospective clients, explain the situation, and leave it at that.
We all have fantasies of getting back at assholes like the one you described, but in the real world, you just need to take the high road and let it go. From the description you gave, it sounds like you're new to the game. Focus your creative energies on your work, not on vengeance. Your integrity and professionalism will remain intact, which is much more important than striking back at some perceived slight.
Yeah, because when I download a movie, I replace all of the credits with my name and try to pass off to potential employers that I was wholly responsible for the film. Unless it's an Abrams film... he can keep those.
I cannot remember anyone claiming that artist should not be credited. There have been arguments that you should be allowed to copy their stuff for free, but I've never ever seen anyone claiming that you should be allowed to claim you had written that stuff if you haven't.
Or in short: There's a difference between copying and plagiarism.
What the submitter complains about is plagiarism, not copying. From his submission, there's no indication about how he thinks about copying.
The Tao of math: The numbers you can count are not the real numbers.
you have commit dates, if the change copyright on your file is newer, there is your proof
you also have the commit history, better proof than anything, unless they suspect you faked hundreds of commits and bug fixes
That would work, but it would be unethical for a developer to commit his code to a publicly-accessible server without client permission to do so.
You spelled "Uwe Boll" wrong...
Information, when copied at one's own cost, does not take that information away from the original owner. Credit, when taken, is taken away from the original owner. Your notion of intellectual property falls on its ass when you try to to equate it to material goods. Credit, however, maintains the same basic rules as physical property: Claiming it for yourself, even at your own cost, does take it away from the original owner.
Mind the frickin' laser...
In the context of an interview the fact that the source was presented could be a perfect opportunity to demonstrate your knowledge of the code by offering to explain its operation and the design decisions that came about during development. Your skills are better proven in how you articulate your knowledge and ideas rather than just pointing to a name on a comment banner. A major lesson learned would be to expect this and to keep cool and not look flustered when someone tries to call you out on it. If you had an amicable relationship with this former employer you might even touch base with them ahead of time to ask if you can list them as a reference so they can corroborate your authorship.
Account -> Discussions -> Disable Sigs
The server itself is still public and it isn't your code to commit. You are being paid, generally, to create code for someone else; thus it is their code. This means that you are putting the code on an outside host of unknown security, and is still wrong.
When you work for someone else as a contractor, you can't just do this. You should spell it out in your contract or whatever before you work for them that you will be archiving your work for reference material for the purposes of demonstrating it to future clients.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Agree: this is more about credit than about copyright.
If you had built a bridge for your city, you should be able to list that as one of your accomplishments. It does not mean that you can walk off with the bridge. At the same time, you'd be perfectly justified in getting pissed off if someone else said that it was they, not you, who had built it.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Even then: there is a difference between "ownership" or "intellectual property" (what many here dismiss) and getting credit where it is due (this case).
It's like in science: scientists (many /. posters among them btw) don't care about who copies their work, as long as their name is in the history books. Most free/open source software: the same story.
wtf is this? fair use? we're not talking a copyright of a book, we're talking somebody's property. do I have fair-use rights to use your house for educational purposes?
The submitter probably doesn't have access to their version control.
However, if they can show their work remotely, they could easily find an archive.org link to an older version. I believe javascript files are archived just like everything else. This could possibly be useful if the submitter decides to take legal action -- I think they have some grounds to do so.
Charisma is the measure of someone's ability to lie with a straight face.
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.
Much more useful than seeing code with someone's name on it is hearing that person describe the code. If someone calls you on it, offer to explain the design of the code, the decisions and tradeoffs made along the way, and what you'd improve next, or how you left the code in a state to be more easily maintained (by you or others) in the future. That would feel *much* more useful than seeing your name on it, and would take you a fraction of the time invested to get it done.
Basically he's like the architect and builder of a beautiful building, and was bragging about it to a prospective employer, to suddenly find out some asshat that got hired to do maintenance after he left changed the dedication plaque and blueprints to have his name instead.