[OpenLayers-Dev] GeoExt proposal

Tim Schaub tschaub at opengeo.org
Tue Mar 31 12:39:57 EDT 2009


Hey-

Paul Spencer wrote:
> I feel this is covered by
> 
>> "The OpenLayers PSC will ask the GeoExt PSC to provide evidence that 
>> code contributions are free from encumbrances.  Further, the 
>> OpenLayers PSC will provide guidance to the GeoExt PSC if it appears 
>> that GeoExt is in violation of any other criteria of an OSGeo member 
>> project."
> 
> I *think* you are suggesting that this be done before accepting ...  I'm 
> +1 on accepting the proposal as is, OpenLayers PSC is not accepting the 
> copyright, just accepting a role in ensuring that the project is run in 
> a way that is acceptable to OSGeo.
> 
> When a project enters incubation, it doesn't have to have complete 
> processes before starting.  You are proposing that we impose more 
> rigorous rules on a project that isn't even trying to enter incubation.
> 

Exactly.  Nobody is asking OpenLayers to do what OSGeo does during the 
incubation process.

I really want to limit what we are asking the OpenLayers PSC to take on. 
  Again, nothing is required (legally or otherwise) to assign copyright 
to OSGeo.  This is simply a courtesy.

I'd like to take up the subject separately with OSGeo - requesting that 
they provide a set of guidelines that projects follow before assigning 
copyright.

Tim

> Paul
> 
> On 30-Mar-09, at 9:56 PM, Cameron Shorter wrote:
> 
>> I'm answering to this email from an "Incubation Committee" member more
>> than as an "Open Layers PSC" member.
>>
>> I applaud GeoExt's embracement of OSGeo principles and assigning of
>> their license to the OSGeo. This will increase adoption and mitigate the
>> risk of future legals battles if done right.
>>
>> However, there is more to be done than just assigning copyright of the
>> project. You also need to protect the code base from being polluted
>> intentionally or accidentally with incompatibly licensed code.
>>
>> OSGeo projects protect themselves by setting up processes for their
>> committers to follow and sign up to, which include rules for accepting
>> new code and new members.
>>
>> I suggest that this proposal is extended to include some of these
>> processes. (You might be able to cut and paste the Open Layers
>> processes, or use them outright).
>>
>> I'll vote positively after this has been addressed.
>>
>> Tim Schaub wrote:
>>> Hey-
>>>
>>> So, I'm picking up the GeoExt governance proposal again.
>>>
>>> Please see the links below for a history of the issue [1], [2].
>>>
>>> The executive summary follows: GeoExt is a new project that brings
>>> OpenLayers functionality to Ext JS widgets and data utilities.  The
>>> GeoExt PSC would like to assign copyright for the code to OSGeo.  OSGeo
>>> suggested that out of courtesy, the GeoExt PSC make a proposal to an
>>> OSGeo member project asking the member project to accept a role in the
>>> governance of the new project.
>>>
>>> The responsibilities of this role (for the OpenLayers PSC and for the
>>> GeoExt PSC) are described here:
>>>
>>> http://www.geoext.org/trac/geoext/wiki/governance
>>>
>>> What does this mean for the OpenLayers PSC?
>>> -------------------------------------------
>>> The OpenLayers PSC will ask the GeoExt PSC to provide evidence that code
>>> contributions are free from encumbrances.  Further, the OpenLayers PSC
>>> will provide guidance to the GeoExt PSC if it appears that GeoExt is in
>>> violation of any other criteria of an OSGeo member project.
>>>
>>> What does this means for the GeoExt PSC?
>>> ----------------------------------------
>>> The GeoExt PSC will gather signed license agreements from code
>>> contributors.  It will provide a report (periodically or generated on
>>> demand) all contributors and status of their CLA.  In addition, the
>>> GeoExt PSC will continue to govern the project in a way that conforms
>>> with the guidelines for OSGeo member projects.
>>>
>>> What does this *not* mean?
>>> --------------------------
>>> The OpenLayers PSC will *not* be responsible for examining the commit
>>> logs, tracking down code contributors, asking individuals to sign the
>>> CLA, or any duties that have to do with technical aspects of managing
>>> the GeoExt project.  The OpenLayers PSC will also *not* vote on issues
>>> before the GeoExt PSC.
>>>
>>> Why is this happening?
>>> ----------------------
>>> See the links below for a little history.  Basically, anyone can assign
>>> copyright to OSGeo.  Frank Warmerdam suggested that the OSGeo would
>>> probably be happier about having copyright assigned if a current member
>>> project accepted some role in the governance of the new project (the one
>>> assigning copyright).  OSGeo doesn't have any real responsibility for
>>> the non-member projects that assign it copyright.  By extension,
>>> OpenLayers does not assume any real liability under this agreement (its
>>> status as a member project is not jeopardized if the terms of the
>>> agreement are not met).  This is largely a courtesy to the OSGeo.
>>>
>>>
>>> So, as a member of the OpenLayers PSC, I'd like to propose that we
>>> accept this role in the governance of the GeoExt PSC.  I'm happy to
>>> answer any more specific questions about what this means.
>>>
>>> Thanks for the vote and/or questions.
>>>
>>> Tim
>>>
>>> [1] http://n2.nabble.com/copyright-question-td2088465.html
>>> [2] http://n2.nabble.com/proposal-for-GeoExt-governance-td2477185.html
>>>
>>>
>>>
>>
>>
>> -- 
>> Cameron Shorter
>> Geospatial Systems Architect
>> Tel: +61 (0)2 8570 5050
>> Mob: +61 (0)419 142 254
>>
>> Think Globally, Fix Locally
>> Geospatial Solutions enhanced with Open Standards and Open Source
>> http://www.lisasoft.com
>>
>> _______________________________________________
>> Dev mailing list
>> Dev at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
> 
> 
> __________________________________________
> 
>    Paul Spencer
>    Chief Technology Officer
>    DM Solutions Group Inc
>    http://research.dmsolutions.ca/
> 


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.



More information about the Dev mailing list