How to "Open Source" Custom, Contract Software?

customWorks asks: "I've been approached to write a piece of custom software for a small business owner with the promise of autonomy in its design and implementation. I do not intend to stick around for incremental development after I've delivered it, and so I feel strongly that open sourcing the software would be prudent for the both myself and prospective client. That said, I still expect to be paid for the developing the software. The issue of course is over convincing the client of the benefit of giving away the source to something they've just paid to have developed. I'd like to know if any of you who've done similar contract work have had experience (success?) in presenting an argument for open sourcing the end product? What were the major concerns/misperceptions that you had to overcome in making the case for open source?"

Comments

Just make sure you own the IP

[rfreynol]

In any contract work I have ever done, I have made sure that I own the copyright, and give the client a perpetual license for the resulting programs.

If the customer insists on owning the IP, then there is a great reason to raise your rates.

Re:Actually

[NutscrapeSucks]

I've been doing this for a while and in something like 90% of the cases the client proactively demands ownership of the code. And it's Work For Hire, so that makes sense.

This can get tricky because you might want to use some of it for in house code libraries and the like, and in some cases they have objected to using any pre-existing code and/or using any of "their" code for future projects. Yes, this affects the price, and yes you should get a contract signed that covers all of this.

Furthermore, there's the matter of good business sense. Even if you do own copyright, giving away what you just sold to your clients competitors doesn't sound like a good idea. It causes ill feelings when a developer is selling a app they were paid to write -- much worse if they just posted it on their website.

Recap of some of the above

[Jay Carlson]

I know I'm tempting moderator retribution but let me summarize some of what I see above:

• The contractor owns everything; customer gets license to a binary
• The contractor owns everything; customer gets license to binaries and the source code under some circumstances (such as contractor unavailability)
• The contractor owns everything; customer gets license to use and modify binary or source for any internal purpose
• The contractor owns everything; customer gets an unlimited but non-exclusive rights to binary or source.
• The contractor owns everything, but agrees on limitations on reuse or redistribution; customer gets some license from above
• The contractor owns nothing; it's a work for hire, since the customer contracted for the work rather than a service
• The contractor owns nothing, but the customer grants certain rights to the contractor, such as limited reuse of modules.
• Ownership is mixed, with some parts retained by either sides.

It sounds like what you need to do is agree with your customer what their expectation is on licensing, and get that in the contract. For example, if you own the work but agree not to disclose certain modules dealing with business process, it's clear to both sides what you can and can not disclose later. That may mean reuse on other contracts, provision to their competitors, or release to the general public.

In general, the more restrictive the customer rights to work performed, the higher the rates.