<br><br><div class="gmail_quote">On Mon, Jul 13, 2009 at 8:42 AM, David Metzler <span dir="ltr"><<a href="mailto:metzlerd@metzlerd.com">metzlerd@metzlerd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Given all that, continue to point all this out, every time you get an opportunity. Sometimes it takes a while to sell, and the proprietary module could be released into the community at any time. No rush.<br></blockquote>
</div><br>To me, "proprietary" is the key. It's important for the contract to make clear that code will be licensed legally. Otherwise, the developer could be put into a difficult position of distributing proprietary code. It's the one distributing GPL code who is accountable.<br>
<br>It's best to express contracts in terms of what functions will be provided and/or hours required to get there, not specifically what new code might be required. Then, as you are augmenting an existing code base and using the appropriate license for new work, the engagement stays focused on the collective result, not the component pieces.<br>
<br>In the end, it's never a good idea to redistribute an entire replica of any collective result. Sharing new functions back to the community places important functions into an overall support infrastructure and can be done discretely, without detracting from anyone's solution or market advantage.<br>