<div dir="ltr">This is a generic question that may help us develop a consistent policy to be applied towards projects that we are currently working with and those that we may potentially work with in the future.<br><div><br>
<br>I would appreciate some guidance on what we consider acceptable commercial involvement within an OSGeo project.<br><br></div><div>To start this discussion off, I will propose a set of scenarios to help start and guide the conversation.<br>
<br></div><div>These are but four scenarios. There are of course a continuum of variations to these.<br><br><br>*****<br></div><div>Does OSGeo provide clear guidance as to what is acceptable commercial involvement within an OSGeo project?<br>
</div><div>*****<br><br></div><div>Where do we draw the line on what is considered acceptable involvement?<br><br></div><div>Bruce<br></div><div><br><br>=================</div><div>Scenario 1<br><br></div><div>Organisation X is interested in furthering the development of project A. The involvement is:<br>
<br></div><div>* X allows staff to work on project A<br></div><div>* staff contribute work to project<br></div><div>* staff are assigned commit access<br></div><div>* staff work within project processes and Project Steering Committee (PSC) to <br>
  ensure that contributed work is assigned a priority release date<br></div><div>* staff integrate work with rest of project code, provide automated tests etc<br><br><br><br>==================<br></div><div>Scenario 2<br>
<br></div><div>Organisation Y offers commercial services based on project B.<br><br></div><div>* Y contracts staff to develop functionality on behalf of a client G<br></div><div>* contract requires G to contribute software back to project B<br>
* Y staff integrate work with rest of project code, provide automated tests etc<br></div><div>* Y has both commit rights and staff on PSC and ensure that work is <br>  prioritised for an early release.<br><br><br><br>==================<br>
</div><div>Scenario 3<br><br><div>Same organisation Y offers commercial services based on same project B.<br><br></div><div>* Y contracts staff to develop functionality on behalf of a client H<br></div>* contract does not allow Y to contribute software back to project B<br>
* Y staff delivers software to client H as a standalone branch of B<br></div><div>* Y will only integrate above work to project B if paid a fee.<br><br><br>==================<br></div><div>Scenario 4<br><br></div><div>Organisation Z releases their previously proprietary software as an Open Source project under a GPL Licence. This becomes Project C.<br>
<br></div><div>* Z also releases the software under dual licensing, with a commercial <br>  closed source version containing more advanced functionality than <br>  the open source version<br></div><div>* Project C attracts a number of developers<br>
</div><div>* Z retains control of PSC and discourages developers from adding the <br>  functionality found in the closed source version to the open source version<br></div><div>* if a developer does submit such functionality, it is ranked by the PSC <br>
   as low priority and is never released within the open source version.<br><br></div><div>==================<br></div></div>