Jeff&#39;s suggestion is probably the easiest way down this path. In general, your work is a work for hire, and the deliverables are owned by the client.<div><div><br></div><div>There are, however, some circumstances of being involved in Open Source you may wish to consider. It&#39;s unlikely Drupal would be of the quality it is today without the support of companies sponsoring development of contributed modules on <a href="http://drupal.org">drupal.org</a>, and thus transferring the ownership of these modules. Your client is leveraging Drupal, and thus &quot;standing on the shoulders of giants,&quot; so to speak. If the client demands that *all* code remain under their explicit ownership, the long-term upkeep and richness of the code is starved of the benefits of being released to the Drupal community for new feature ideas, contributions, bug fixes, etc. </div>
<div><br></div><div>Suppose some of the code you were developing was available on <a href="http://drupal.org">drupal.org</a>; would your client be interested in using it? Likely so. What if the module had a bug or could use a new feature? Would you patch the module, fostering collaboration and new ideas and enthusiasm from others? Perhaps. </div>
<div><br></div><div>So, you might address the entire issue by considering what deliverables are best served by being property of the client (design, graphics, branding, custom APIs), and which are best served by being property of you, the developer (possible contrib). Something to consider. </div>
<div><br></div><div>In the end, you may find no headway with this, and will have to abide the client&#39;s demands. Then again, the whole point may be moot since not every scrap of Drupal code is appropriate or useful for release. But having some leverage at the forefront will give you some flexibility throughout the relationship.</div>
<meta charset="utf-8"><div><br></div><div><br></div><div class="gmail_quote">On Wed, Mar 23, 2011 at 9:55 AM,  <span dir="ltr">&lt;<a href="mailto:jeff@ayendesigns.com">jeff@ayendesigns.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


  
    
  
  <div style="direction:ltr" bgcolor="#ffffff" text="#000000">
    <p style="margin-bottom:0cm;margin-top:0pt">I have three clauses
      in my standard contract that address this. One is to define the
      licensing of elements (graphics, code, etc.).  The second, below,
      intellectual property...you would add to that list. The third is
      about confidential information and the protection of it.</p>
    <p style="margin-bottom:0cm;margin-top:0pt"><br>
    </p>
    <p style="margin-bottom:0cm;margin-top:0pt">Each party shall
      retain ownership of the Intellectual Property that they possess
      upon the signing of this contract. In the case of PROVIDER, this
      includes, but is not limited to, functions, methods, libraries,
      techniques, standards and general know-how with regards to
      software development, subject matter, and web site development.</p><div><div></div><div class="h5">
    <p style="margin-bottom:0cm;margin-top:0pt"><br>
    </p>
    <p style="margin-bottom:0cm;margin-top:0pt"><br>
    </p>
    <p style="margin-bottom:0cm;margin-top:0pt">On 03/23/2011 11:51
      AM, Joe Murray wrote:<br>
    </p>
    <blockquote type="cite">You might try a non-competiton clause, where the focus
      is not on working with named competitors. You have to watch for
      GPL violations in the terms of your contract. It is theoretically
      possible to avoid GPL violations by doing code that only writes to
      APIs rather than modifies other code that is integral to the
      project, or by using data (ie configurations in the database). Of
      course, this is not legal advice, and you should consult a lawyer.<br>
      <br clear="all">
      Joe Murray, PhD<br>
      President, JMA Consulting<br>
      <a href="mailto:joe.murray@jmaconsulting.biz" target="_blank">joe.murray@jmaconsulting.biz</a><br>
      skype JosephPMurray twitter JoeMurray<br>
      <a href="tel:416.466.1281" target="_blank">416.466.1281</a><br>
      <br>
      Message: 4<br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
          Date: Wed, 23 Mar 2011 08:44:23 -0700<br>
          From: Bob Morse &lt;<a href="mailto:bob@morsemedia.net" target="_blank">bob@morsemedia.net</a>&gt;<br>
          Subject: [consulting] Contract protection clause<br>
          To: <a href="mailto:consulting@drupal.org" target="_blank">consulting@drupal.org</a><br>
          Message-ID: &lt;<a href="mailto:33DA2428-972C-4A75-AE33-97BACA672CB9@morsemedia.net" target="_blank">33DA2428-972C-4A75-AE33-97BACA672CB9@morsemedia.net</a>&gt;<br>
          Content-Type: text/plain; charset=us-ascii<br>
          <br>
          We have a client who is concerned with protecting his new
          Drupal website we will be developing. He is asking for a
          clause in the contract that somehow states we will not turn
          around and sell his site with a new design slapped on top to a
          competitor. I&#39;m not sure how to separate out, ahead of time,
          what would be very common elements and what would be unique
          based on the internal processes of a competing business.<br>
          <br>
          How might I write something that assures the client we won&#39;t
          resell the unique aspects of his web application without also
          writing something that prevents us from making a website for
          another company that uses many of the same elements but with
          the details being unique to that company&#39;s internal process
          and interactions with clients?<br>
          <br>
          <br>
          <br>
          ------------------------------<br>
          <br>
          _______________________________________________<br>
          consulting mailing list<br>
          <a href="mailto:consulting@drupal.org" target="_blank">consulting@drupal.org</a><br>
          <a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
          <br>
          <br>
          End of consulting Digest, Vol 62, Issue 16<br>
          ******************************************<br>
        </blockquote>
      </div>
      <br>
      <pre><fieldset></fieldset>
_______________________________________________
consulting mailing list
<a href="mailto:consulting@drupal.org" target="_blank">consulting@drupal.org</a>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a>
</pre>
    </blockquote>
  </div></div></div>

<br>_______________________________________________<br>
consulting mailing list<br>
<a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
<br></blockquote></div><br></div>