PracticalWeb Ltd

Websites that work for you.

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

Comments