[consulting] copyright policies

Bill Fitzgerald bill at funnymonkey.com
Thu Jan 24 19:49:12 UTC 2008


Some thoughts below --

Kevin Amerson wrote:
> Yes that's a good point Boris, saying that something is GPL and 
> available for the public is quite different than actually following 
> that and making it publicly available.  I hope that the latter is the 
> case here.
What does this mean? Why go through the difficult conversation with a 
client about the benefits of Open Source/GPL'ed code without the follow 
through to actually release it? I think I'm missing something here.
>
> Kevin
>
> On Jan 24, 2008 12:35 PM, Boris Mann <boris at bryght.com 
> <mailto:boris at bryght.com>> wrote:
>
>
>     On 24-Jan-08, at 9:00 AM, Kevin Amerson wrote:
>
>>     Does the non-compete cover this scenario?
>>
>>     Client A pays you for a solution to problem A that directly ties
>>     to their business.  You retain the ability to reuse the code as
>>     you stated.
>>
>>     Client B is a direct competitor to Client A and comes to you for
>>     a solution to the same problem.
>>
>>     You gladly hand them the same code tailored to them.
>
>     Or rather, after Client A, you submit it to Drupal.org
>     <http://Drupal.org> with sponsorship from Client A.
>
>     Client B wants extra functionality. You add it, and Client A gets
>     it "for free".
>
Exactly.
>
>
>>
>>     Who is competing with who?  In essence, Client A just paid to
>>     help out their competitor, Client B.
>
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
503.897.7160



More information about the consulting mailing list