|
Explaining source code ownership to clients
I'm curious if anyone has some great metaphors for explaining to consulting clients the issues around source code ownership. All my projects involve translating generalized small biz needs into both design and implementation which means I own the source code, unless specifically handed over via contract.
I've used the analogy of someone who buys a painting not being able to then make copies of that painting without the artist's permission but could use a better metaphor than that.
Joe Hendricks
Friday, March 26, 2004
Why not say "book" instead of painting: perhaps people are more familiar with copyrighting books, and copying text, than paintings.
Christopher Wells
Friday, March 26, 2004
"Why not say "book" instead of painting"
Are books ever commissioned by businesses ? Forgive my ignorance of the publishing biz but I thought book publishers usually locked up all reprint rights, leaving the author with a set fee ? Or do authors usually get a royalty ?
Joe Hendricks
Friday, March 26, 2004
Architecture plans? I.E., you could design a house for someone, and if they don't buy the rights from you, you could design the same house for a neighbour down the street.
Somewhat limited, but generally similar anyways.
Nigel
Friday, March 26, 2004
So your clients need an analogy to understand copyright? I'm starting to think there are people who wouldn't understand *anything* without an analogy, which means there must be a One True Analogy at the root of it all.
Philo
Philo
Friday, March 26, 2004
We've never had a problem with this with clients before. Just quote them two rates, one with source code, one w/o if they want full ownership.
When I was doing consulting, i gave them that option for the custom code. Quite often the custom code would be based on a large library of reusable code that I had built up over the years.
In that case, they also had a third option of paying for a software escrow service which would give up my reusable library in the event of my company going under.
asdf
Friday, March 26, 2004
> Are books ever commissioned by businesses ?
I wrote software manuals for IBM (their copyright). Businesses do generate other kinds of text (advertising, reports, ...): is there anyone who doesn't know what "copyright" means?
> Forgive my ignorance of the publishing biz but I thought book publishers usually locked up all reprint rights, leaving the author with a set fee ? Or do authors usually get a royalty ?
Either. Authors may also sell or give a non-exclusive copyright to their work: for example, sometimes journalists write articles that are published in more than one newspaper, or in more than one country ... in depends on the contract that the author negotiates with the publisher.
Christopher Wells
Friday, March 26, 2004
If they pay you to develop software, this is not like a book or a painting. It is like house painting. Do you get to keep the house?
Most companies of any size are not going to allow you you own then code, they paid you to write it. In fact, several I work with have you sign that you are not using code from another customer, to protect them from infringement.
If you want to own the code, the simplest statement is this: If the client owns the code, my service costs $X, if I own it, the cost of my service is $X-$Y. Short of that, you are in a "work for hire" situation.
Perhaps they understand, they just do not want to do it.
MSHack
Friday, March 26, 2004
MSHack, what country are you in ? <g>
Joe Hendricks
Friday, March 26, 2004
Here's how I do it:
1. Every client signs a contract
2. Every contract explicitly states that I *own* the software and they *licence* it.
The analogy I use: MS Office.
You don't buy the 'source' you buy the 'licence'.
Canuck
Friday, March 26, 2004
For those new to USA "work for hire" laws on custom software, here's a nice summary link:
http://www.smrfirm.com/complaw/ciht-new.htm
and here's a great book:
"Software Development A Legal Guide" by Fishmann
Joe Hendricks
Friday, March 26, 2004
Joe - I am in the US and the opinion expressed in the link varies with a number of cases. While IANAL, it is unlikely that _no_ contract will exist. As such, most include a provision that fall under the work for hire statute such that "when an employee is specifically directed to produce a software product as a condition of employment, ownership rights including copyright rest with the employer."
Regardless, unless you plan to take a client to court, it is something that should be agreed upon in advance. In the absence of an agreement, you may wish to claim ownership, but they can probably make an equally compelling case that this was a "directed" engagement.
In the end, it works against you, because it violates one of the consult tenets of survival - when you are in a legal battle with a client, you lose, even when you win.
MSHack
Friday, March 26, 2004
MSHack, I agree wholeheartedly with you that it should be 'agreed in advance', but find that small biz owners don't 'hear' you until later unless a very good metaphor is used. I never use contracts, just handshakes. So my original post was how to 'agree in advance' using a non-tech metaphor.
I'd hate to mislead beginning consultants in this thread, so thanks for your clarification.
Joe Hendricks
Friday, March 26, 2004
"I never use contracts, just handshakes."
Wow. That sounds like a really, um, interesting approach to business. One that leaves the door open to a LOT of misunderstandings and complications.
curious
Friday, March 26, 2004
Curious, yeah I know <g> But have you ever worked with small biz CEO's ? I give a no-questions-asked money back guarantee on any 2 weeks work, which they definitely prefer over any contract...
Joe Hendricks
Friday, March 26, 2004
MS Hack, where developers are employed on a casual basis, that is as contractors, they own the copyright to their work and the right to withhold the source code.
Only when the employer commits to all the additional benefits of providing full time employment and a career does the employer also gain the copyright in your work.
Joe Hendricks, just tell them straight out that the source code is valuable and you can't give it away. I wouldn't waste time with analogies, which always have exceptions.
Explain that your source code includes many years of experience that they have not paid for, and that's why you keep it.
JM
Friday, March 26, 2004
==> ... the source code is valuable and you can't give it away
Honestly, that's the biggest crock of horse hockey I've ever heard (and I've been hearing it for quite some time) . I've been in the contracting/consulting world for 10 years now, 6 as an independent. I've known, worked with, and hung out with ... maybe a hundred or so like myself over the years. You know how many of us have actually made money through the resale of code developed for others? None. Zero. Zilch.
Especially with the smaller clients. You're developing something very specific to their business. Not much else you can do with code customized for their business process.
I hear it so much from developers -- that it's valuable and worth money, and you shouldn't give it up freely. It's not. None of these folks that insist it's worth something have ever made a nickel off the code droppings from a previous project. Not one.
It's a load of hogwash -- "Hey! I'm *valuable*. I created something I could *sell* ..." Yeah. Tell me again when the check's cleared from the millions you're gonna make on some podunk mom&pop shop's automation of sending out their Christmas cards every year. In theory it sounds great -- have the first client pay for it and keep selling it over and over again. It just doesn't work that way in the world I live in.
That all being said, we've all got our scraps of code for generic utility functionality, snippets here and there, a script here, an object there. Some of us have even organized them into a rather extensive code library.
The problem with this stuff is that it's so generic and so pervasive that you can't sell it. Period. Even the guys who write generic functionality and sell libraries have a hard time making a living. The real money's in the custom stuff and that, by definition, limits your market. It's custom to that first client, the one you originally developed it for, it fits their business model/process and only theirs - there is no market for the custom stuff like that.
Get off your high horse. The code you write for a client is worth nothing in the marketplace (other than to the client who contracted (oops, hand-shaked (hand-shook ?)) it) . If you think otherwise, then show me da money. I want to see bank statements. If the checks aren't rolling in (and I doubt they are) you just dreaming.
Here's the way we do it: The generic stuff we pull from a well used, well tested library of doo-dads that we've been using since the dark ages. The client is given a binary of that, no source. It's ours. We developed it prior to the first engagement with the client. The custom code developed for them -- it's theirs. No questions asked. In fact, we've won quite a few bids over the years because we weren't petty enough to argue over something that is completely worthless to us in the marketplace anyway.
Sorry for the rant. I've never understood this mentality and I've seen people walk away from good money over disputes on who owns the source. It's a piss-poor way to do business -- lose potential clients over something that won't make you a dime. It's usually the folks who have no business sense about them (handshake != contract : handshake != GoodBusinessPractice) who perpetuate the myth that their code is somehow "special", and has substantial resale value. It doesn't. Get over it.
Sgt. Sausage
Friday, March 26, 2004
Sgt Sausage, maybe the answer is in the fact that you have been contracting for a long time and you hand over the source code.
You've never thought to create a useful product or solution, and it's not easy.
Perhaps you don't modularise and enhance your code, but hack and hack till it works. There are plenty of coders like that.
Thing is, there are plenty of software firms who build common solutions and are able to maintain them for multiple clients, and make money from them, and hire people to build even better products.
JM
Saturday, March 27, 2004
==> Sgt Sausage, maybe the answer is in the fact that you have been contracting for a long time and you hand over the source code.
Maybe so ...
==>You've never thought to create a useful product or solution, and it's not easy.
You're talking about a different world than the world I (and I believe the OP) live in.
We live in the world of building solutions *for the client*.
If I were going to create a useful product or solution, I'd do it under a model not unlike our beloved Joel's. I'd find a nice "useful product or solution" and run with it. No client involved. My code. My sales. No client involved who paid me to write the original code.
Unfortunately, that's not the business model I work in. The client contacts me for a specific solution to their specific business problem.
It's basically the custom software -vs- shrinkwrap argument. Vertical -vs- horizontal. Joel chose to go more the shrinkwrap, I chose to go the custom route.
I still stand by my original post. Software -- code specifically -- custom developed for a particular clients business model is rarely (more likely never) worth a thing as far as resale value to someone other than the original client.
==>Perhaps you don't modularise and enhance your code, but hack and hack till it works. There are plenty of coders like that.
And I'm not one of them. My code's clean, efficient, and easily maintained.
Still doesn't matter didley squat when it's *specific* to the client's business model.
==>Thing is, there are plenty of software firms who build common solutions
We're talking apples and oranges. Look at the term you used "common solutions". I'm starting out with the premise that I'm not writing a "common" code base -- I'm writing code specific to the client's business model and processes.
Here -- tell ya what. Do a survey. Talk to your peers who consult/contract. Find out how many are concerned about ownership of the code (all of 'em). Then ask them the big question. How many of them have actually made any $$$ from the rights they've retained to the code they wrote (none of 'em).
I've got a local developer's group meeting on Monday. There's usually about 40 of us -- independent developers doing custom code for clients. I doubt 40 of us will make a good representative sample of the universe of developers out there, but I'm willing to bet that 1, maybe 2 have ever resold a single line of code, and of those two, if you add them together you get chump change.
I'll report back here on Tuesday after the Monday night meeting.
You do same. Tell me what you come up with.
Sgt. Sausage
Saturday, March 27, 2004
OOPS! Just re-read the OP and it appears that I'm including him in my discussion when I shouldn't be:
Here's my mistake: "translating generalized small biz "
Note the "generalized" part. Given that, yes, you should be concerned about retaining the rights to your code.
Apologies.
NOTE: That still doesn't change my opinion on custom, specialized, oriented to a single client's business needs. In this case, worrying about rights to the code is a waste of time. This is the world I live in.
We now return you to your regularly scheduled entertainment ...
Sgt. Sausage
Saturday, March 27, 2004
Do you see the source of your problem? You're talking about what your contractor friends do. The ones working like you do. Ask all 40 of them.
Meantime there are plenty of companies who work at a different level. They have built a product based on the requirements at one or two sites, and then they sell that into other sites, each time building on it. Each client gets the benefit of a whole lot of work for much less than they would pay to develop the whole thing from scratch.
There is commonality in almost all development contracts, unless you're doing web pages.
JM
Saturday, March 27, 2004
Yes I do re-use code from one client to another, sometimes wheels really are round and have hubs, spokes and brakes that are compatible.
And yes I keep all rights unless they're negotiated away, but I also provide an unlimited and non-distributive licence to the source.
Simon Lucy
Saturday, March 27, 2004
Im with Sgt Sausage.
We have clients and we have products of our own. I tell clients that any work we do they get the source for it and can use it however they want (including taking it elsewhere for further work if they wish).
I also tell them that I get to reuse any part of the source that I want in other projects if I wish.
With the obvious stipulation that I wont resell the entire source to their competitors...although that opportunity has never arisen anyway.
<shrug> it works fine...mostly clients stick with us, if they want to leave theres nothing tying them here (I dont believe in locking in a client except by amazing them with our brilliance)
My clients are happy because they have security...come what may between us their project will move forward.
Im happy because I have clients, and I can reuse code from earlier work where I want, so my company is gradually building up a lovely set of reusable classes, proven algorithms and sexy UI code.
FullNameRequired
Saturday, March 27, 2004
 Recent Topics
Fog Creek Home
| 
