copyright policies and contracting in an open source world

really interesting thread on the Drupal consultants mailing list

especially of note:

http://lists.drupal.org/pipermail/consulting/2008-January/002324.html

We work primarily with educational entities and non-profits; in our line of work the fear of competition comes up infrequently, but it still comes up –

WRT Alan’s question re posting our dev agreement — we spent a fair amount of time and money working through this with our lawyers — the resulting document is tied pretty closely to our business model and our work with educators and non-profits.

At the core, though, the section in question — and this is the section that has been very useful to us — makes the following distinctions — and IANAL so these distinctions are a layperson’s distinctions, and should not be confused with the writings of a person who actually knows anything about the topic :-)

Client pre-existing IP: specialized information/knowledge that the client has developed
Developer pre-existing IP: specialized information/knowledge that we have developed
Project IP: work that results from Client and Developer coming together to solve the client’s specific needs. For us, this is often a blurry line, as we are frequently approached by clients to help them articulate, and then solve, the specific issues within their organization.
Custom Code: Any code we write belongs to the client as work for hire
License Back: the client agrees to grant us a perpetual, royalty free license, as governed by a non-compete clause (ie, we don’t copy the client’s business plan — for us, this isn’t generally an issue, as we work with non-profits and schools)
GPL: Custom code is licensed under the GPL, and will be released back to the community under terms negotiated b/w Client and Developer

The key elements are the different types of IP, and how the code is owned and licensed. By clearly stating that we develop GPL code, we have the conversation up front, which allows us to avoid any misunderstandings re licensing.

The one exception we make is themes/graphic identity. The branding always remains the property of the client.

I was a consultant for over 4 years and never under any circumstances would we be allowed to reuse a solution built for one client for another client. We were expensive, however, the client kept everything always.

This is possible in theory, but, IMO, more difficult in practice — once you know how to do something, you can’t un-know it. As a recent example, we worked out some publishing workflows on a community writing site we developed this summer. The process was unique to the client, as it met their specific internal needs. On a site we brought live this fall, we used some of the same principles to support an online grant application and review process. To somebody looking strictly at the technical solution, it would look amazingly similar, despite the complete differences in context. Part of the reason we have the license-back clause in our contract is to protect us against any misunderstanding here — the fact that we have experience is a good thing. Again, I think I’m missing something wrt the original comment.

Cheers,

Bill

– Bill Fitzgerald http://www.funnymonkey.com Tools for Teachers