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.

Open Source Policies

[Bouncings]

I've done only very limited contract work and at that, it wasn't Open Source. I think it really depends on the client, as the people I was working with hired me specifically because they were a Windows firm and didn't want to bother themselves with some Unix stuff that came their way from an existing client. For them, of course, it would have been impossible. But I can speak in regard to how some companies would react in general.

If you're working with a firm that's more familiar with the a community or is part of a larger scientific community, it's another matter. Some firms view releasing open source software as almost a promotional effort and you might egg them to develop an "open source policy" to satify their concerns.

Board of director types have bazaar stigmas and FUD like "won't we have to support it," "won't it give away our business model," and so on. You can address those questions by suggested an OSS policy. The policy basically comes down to how and when they'll open source software. For example, they won't open source software that would be directly useful to their compeditors. When they do, putting the employee email addresses won't be allowed, as it will burden them with emails. Open Source projects shall be included on another website, etc etc etc.

But they will be more warm to a policy than simply deciding to open source things adhoc -- so if you give them a policy to address their concerns, you might have better luck.

And of course if your Philip Greenspun good, you can TELL them it'll be Open Source. :)

2 cents.

Re:Emphasize the benefits

[stubear]

I'm not sure how software code works but as a graphic designer I most certainly own the copyright to my work unless otherwise stated in the contract. Contract does not mean work for hire. If it did then the company would be responsible for paying me benefits as top of my fee.

If I design a logo for a company I state up front in the contract what they can do with the logo. For instance if they were going to just use the logo on a web site I would charge accordingly. However, if this logo is to become the company's entire identity system I charge a dfferent, more lucrative (for me) fee. I can't turn around and sell this logo to another company but as I own the copyrights to the logo, I can include it in my portfolio without the company's approval.

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.