[Incubator] Acceptable commercial involvement in OSGeo Projects

Peter Baumann p.baumann at jacobs-university.de
Thu Mar 7 23:47:06 PST 2013


Bruce-

I was hoping and believing that we just had a misunderstanding, as it turns out now.

Of course I (and everybody engaged in rasdaman I know of) share the firm opinion 
that all contributions are to be considered and are welcome. Otherwise indeed we 
would shoot in our own legs.

Glad that we could sort it out. Your opinion is very much respected, as your 
mentoring has brought the project forward significantly, and has helped a lot to 
stabilize and mature processes.

-Peter


On 03/08/2013 07:04 AM, Bruce Bannerman wrote:
> Peter,
>
> I just picked up this comment in re-reading your email today:
>
> "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?"
>
> In re-reading your initial response, I noted a similar sentiment. Sorry, this 
> slipped by me before now.
>
>
> This was not the intent of my initial email to the Rasdaman list.
>
> My intent was to ensure that we have an open development process that is not 
> constrained by artificial constraints.
>
> 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.
>
> If we go down that path IMHO, Rasdaman will not have a viable future as an 
> open source project.
>
> Bruce
>
>
>
>
>
> On Fri, Mar 8, 2013 at 10:37 AM, Peter Baumann <p.baumann at jacobs-university.de 
> <mailto:p.baumann at jacobs-university.de>> wrote:
>
>     Hi all,
>
>     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!
>
>     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.
>
>     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.
>
>     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.
>
>     -Peter
>
>
>
>
>     On 03/07/2013 11:52 PM, Jody Garnett wrote:
>>     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".
>>
>>     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).
>>
>>     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.
>>
>>     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).
>>
>>     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.
>>
>>     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.
>>     -- 
>>     Jody Garnett
>>
>>     On Thursday, 7 March 2013 at 4:54 PM, Bruce Bannerman wrote:
>>
>>>     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.
>>>
>>>
>>>     I would appreciate some guidance on what we consider acceptable
>>>     commercial involvement within an OSGeo project.
>>>
>>>     To start this discussion off, I will propose a set of scenarios to help
>>>     start and guide the conversation.
>>>
>>>     These are but four scenarios. There are of course a continuum of
>>>     variations to these.
>>>
>>>
>>>     *****
>>>     Does OSGeo provide clear guidance as to what is acceptable commercial
>>>     involvement within an OSGeo project?
>>>     *****
>>>
>>>     Where do we draw the line on what is considered acceptable involvement?
>>>
>>>     Bruce
>>>
>>>
>>>     =================
>>>     Scenario 1
>>>
>>>     Organisation X is interested in furthering the development of project A.
>>>     The involvement is:
>>>
>>>     * X allows staff to work on project A
>>>     * staff contribute work to project
>>>     * staff are assigned commit access
>>>     * staff work within project processes and Project Steering Committee
>>>     (PSC) to
>>>       ensure that contributed work is assigned a priority release date
>>>     * staff integrate work with rest of project code, provide automated
>>>     tests etc
>>>
>>>
>>>
>>>     ==================
>>>     Scenario 2
>>>
>>>     Organisation Y offers commercial services based on project B.
>>>
>>>     * Y contracts staff to develop functionality on behalf of a client G
>>>     * contract requires G to contribute software back to project B
>>>     * Y staff integrate work with rest of project code, provide automated
>>>     tests etc
>>>     * Y has both commit rights and staff on PSC and ensure that work is
>>>       prioritised for an early release.
>>>
>>>
>>>
>>>     ==================
>>>     Scenario 3
>>>
>>>     Same organisation Y offers commercial services based on same project B.
>>>
>>>     * Y contracts staff to develop functionality on behalf of a client H
>>>     * contract does not allow Y to contribute software back to project B
>>>     * Y staff delivers software to client H as a standalone branch of B
>>>     * Y will only integrate above work to project B if paid a fee.
>>>
>>>
>>>     ==================
>>>     Scenario 4
>>>
>>>     Organisation Z releases their previously proprietary software as an Open
>>>     Source project under a GPL Licence. This becomes Project C.
>>>
>>>     * Z also releases the software under dual licensing, with a commercial
>>>       closed source version containing more advanced functionality than
>>>       the open source version
>>>     * Project C attracts a number of developers
>>>     * Z retains control of PSC and discourages developers from adding the
>>>       functionality found in the closed source version to the open source
>>>     version
>>>     * if a developer does submit such functionality, it is ranked by the PSC
>>>        as low priority and is never released within the open source version.
>>>
>>>     ==================
>>>     _______________________________________________
>>>     Incubator mailing list
>>>     Incubator at lists.osgeo.org <mailto:Incubator at lists.osgeo.org>
>>>     http://lists.osgeo.org/mailman/listinfo/incubator
>>
>>
>>
>>     _______________________________________________
>>     Incubator mailing list
>>     Incubator at lists.osgeo.org  <mailto:Incubator at lists.osgeo.org>
>>     http://lists.osgeo.org/mailman/listinfo/incubator
>
>     -- 
>     Dr. Peter Baumann
>       - Professor of Computer Science, Jacobs University Bremen
>         www.faculty.jacobs-university.de/pbaumann  <http://www.faculty.jacobs-university.de/pbaumann>
>         mail:p.baumann at jacobs-university.de  <mailto:p.baumann at jacobs-university.de>
>         tel:+49-421-200-3178  <tel:%2B49-421-200-3178>, fax:+49-421-200-493178  <tel:%2B49-421-200-493178>
>       - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>         www.rasdaman.com  <http://www.rasdaman.com>, mail:baumann at rasdaman.com  <mailto:baumann at rasdaman.com>
>         tel: 0800-rasdaman, fax: 0800-rasdafax, mobile:+49-173-5837882  <tel:%2B49-173-5837882>
>     "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)
>
>
>
>
>
> _______________________________________________
> Incubator mailing list
> Incubator at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/incubator

-- 
Dr. Peter Baumann
  - Professor of Computer Science, Jacobs University Bremen
    www.faculty.jacobs-university.de/pbaumann
    mail: p.baumann at jacobs-university.de
    tel: +49-421-200-3178, fax: +49-421-200-493178
  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
    www.rasdaman.com, mail: baumann at rasdaman.com
    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"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)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20130308/47e5720c/attachment-0001.html>


More information about the Incubator mailing list