<div dir="ltr"><div><div><div><div><div><div>Peter,<br><br></div>I just picked up this comment in re-reading your email today:<br><br>"Actually, in the concrete case at hand the question was different
      even from scenario #4, aka: Should OSGeo actively encourage
      contributors in dual-license projects to clone commercial
      functionality?"<br><br></div>In re-reading your initial response, I noted a similar sentiment. Sorry, this slipped by me before now.<br><br><br></div>This was not the intent of my initial email to the Rasdaman list.<br>
<br></div>My intent was to ensure that we have an open development process that is not constrained by artificial constraints.<br><br></div>I would not like to see Rasdaman become a project where developers do not feel free to contribute functionality for fear of offending someone or some entity.<br>
<br></div><div>If we go down that path IMHO, Rasdaman will not have a viable future as an open source project.<br></div><div><br></div>Bruce<br><div><div><div><div><br><br><br></div></div></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 10:37 AM, Peter Baumann <span dir="ltr"><<a href="mailto:p.baumann@jacobs-university.de" target="_blank">p.baumann@jacobs-university.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Hi all,<br>
      <br>
      allow me to chime in. First, thanks to Bruce for abstracting from
      the case by fleshing out these variations, and to all for your
      thoughts!<br>
      <br>
      I'm pretty much in line that #4 is not very desirable, although
      I'm not sure OSGeo should influence - I understand OSGeo more as a
      project quality check, but not as project hypervisor. Usually
      community is quite aware and the situation probably would
      self-regulate. <br>
      <br>
      Actually, in the concrete case at hand the question was different
      even from scenario #4, aka: Should OSGeo actively encourage
      contributors in dual-license projects to clone commercial
      functionality? On a side note, in the case on hand the commercial
      player is a key contributor to the open-source version, as the
      commit logs convey; this may or may not be relevant.<br>
      <br>
      Of course this situation was not planned, it just surfaced the
      potential issue by coincidence. Consequently, I see no particular
      severity in it, just a useful discussion. My personal preference?
      Coexistence.<br>
      <br>
      -Peter<div><div class="h5"><br>
      <br>
      <br>
      <br>
      On 03/07/2013 11:52 PM, Jody Garnett wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      
      <div> OSGeo does not tend to have policies with respect to our
        projects - the organisation is driven by its goals and does its
        best be "hands off". </div>
      <div><br>
      </div>
      <div>The only exception to this is during incubation (when we have
        a mentor available to answer questions) and some specific checks
        to perform (check the IP, check that the license is open, check
        that the development process is open to outsiders).</div>
      <div><br>
      </div>
      <div>In this respect we are trying to do all the research that an
        "contributor" would require before participating in a project …
        and ensure each OSGeo project is in position to handle new
        contributors. </div>
      <div><br>
      </div>
      <div>We have never been involved in the business model supporting
        the project, and any related commercial considerations. If the
        project does not have a useful model for commercial involvement
        I would expect it to suffer, if it does not have a useful model
        for community engagement (say the original JUMP) I would expect
        it to fail (or be forked).</div>
      <div><br>
      </div>
      <div>During incubation we ask that the community be handled with
        "open source" and that contributors be handled with "open
        development". Beyond that (rather low) bar the specifics of how
         a project intends to stay viable and manage its commercial
        relationships is outside of our scope. </div>
      <div><br>
      </div>
      <div>I had hoped that the OSGeo Foundation could be part of the
        solution (a reason GeoTools joined the foundation was to pursue
        funding for thankless tasks such as documentation and
        marketing). The recent board decisions take this goal off the
        table.</div>
      <div>-- </div>
      <div>
        <div>Jody Garnett<br>
        </div>
        <div><br>
        </div>
      </div>
      <p style="color:#a0a0a8">On Thursday, 7 March 2013 at 4:54 PM,
        Bruce Bannerman wrote:</p>
      <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
        <span>
          <div>
            <div>
              <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>
            </div>
            <div>
              <div>_______________________________________________</div>
              <div>Incubator mailing list</div>
              <div><a href="mailto:Incubator@lists.osgeo.org" target="_blank">Incubator@lists.osgeo.org</a></div>
              <div><a href="http://lists.osgeo.org/mailman/listinfo/incubator" target="_blank">http://lists.osgeo.org/mailman/listinfo/incubator</a></div>
            </div>
          </div>
        </span> </blockquote>
      <div> <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Incubator mailing list
<a href="mailto:Incubator@lists.osgeo.org" target="_blank">Incubator@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/incubator" target="_blank">http://lists.osgeo.org/mailman/listinfo/incubator</a>
</pre>
    </blockquote>
    <br>
    </div></div><span class="HOEnZb"><font color="#888888"><pre cols="80">-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   <a href="http://www.faculty.jacobs-university.de/pbaumann" target="_blank">www.faculty.jacobs-university.de/pbaumann</a>
   mail: <a href="mailto:p.baumann@jacobs-university.de" target="_blank">p.baumann@jacobs-university.de</a>
   tel: <a href="tel:%2B49-421-200-3178" value="+494212003178" target="_blank">+49-421-200-3178</a>, fax: <a href="tel:%2B49-421-200-493178" value="+49421200493178" target="_blank">+49-421-200-493178</a>
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   <a href="http://www.rasdaman.com" target="_blank">www.rasdaman.com</a>, mail: <a href="mailto:baumann@rasdaman.com" target="_blank">baumann@rasdaman.com</a>
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: <a href="tel:%2B49-173-5837882" value="+491735837882" target="_blank">+49-173-5837882</a>
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)


</pre>
  </font></span></div>

</blockquote></div><br></div>