Copyright vs Exclusive License?
cdanzig asks: "My company recently hired a development house to do some contract work for us. They did great work, but they are claiming that they now own the copyright on the code and are issuing us a permanent and exclusive license. My bosses are concerned that this will hamper our ability to make changes to the code or prevent us form being able to claim the software as a company asset. What is expected protocol between a client and a development house? What is the long-term difference between owning a copyright and owning an exclusive license? If we paid for the development of the code, is it fair for us to demand ownership?"
You didn't specify the terms of the license agreement. It's great that it's permanent and exclusive, but if you want the copyright transferred to your company, be prepared to pay for that privilege. This is a fairly common practice.
In increasing order of expected value:
1. Temporary, non-exclusive right
2. Permanent, non-exclusive right or temporary, exclusive right
3. Permanent, exclusive right
4. Copyright transfer
The author has the right to expect greater compensation for greater value delivered. Perhaps you should try to negotiate a transfer agreement before you get too up in arms about this matter.
When I've done contract software development in the past, I've brought a common library of foundation code that gets me started very quickly. I wrote this library after completing projects for two clients and realizing that I started each project with the same two months worth of work. So in the next downtime, I wrote a more flexible/reusable version based on lessons learned.
I'm perfectly happy to license this code to my clients and allow them to maintain it themselves once I'm out of the picture, but I don't want to lose the ability to use that library for the benefit of my next client.
IMHO, the best option is to negotiate the licensing terms of all of the parts of the project up front and in good faith. This means being clear that the contractor is bringing code written elsewhere to the project and wants to retain ownership of that code. This means being clear that code written specifically for this client (embodying confidential and domain-specific knowledge) will not be owned or re-used by the contractor. This also means being crystal clean about billing of time spent maintaining the outside library (*). There are a few ways to clearly differentiate between the three kinds of time. I find that a "domain-specific" test is generally enough to leave both parties satisfied that their interests will be protected.
* If we expect significant expansion of the non-domain-specific code I've brought, I'll ask for a lower rate when working on that part of the system. Otherwise, if the maintenance take more than an hour in a week, I'll eat the time, less than an hour in a week and I'll bill the time. This has usually been acceptable to my clients and acknowledges that we both benefit from that time.
Playing games just means a lot of hard feelings, a lost reference, no assistance maintaining the project, and nobody is happy at the end of the day. Be clear, be honest, and negotiate from shared goals instead of trying to screw every penny or minute of time from the other.
Ross