[Incubator] GDAL graduation

[Cameron Shorter]

Frank, I'm happy with your wrappup below. I suggest that it should be 
copied into your providence review, or similar.

Frank Warmerdam wrote:
> Cameron Shorter wrote:
>> Paul, Frank,
>> Great to see GDAL reaching graduation, it sounds like GDAL is in good 
>> shape.
>> However, before graduating I think we need further closure on the 
>> Providence Review Issues. I suspect that you should be able to close 
>> many of them by either:
>> 1. Receiving clarifications already requested.
>> 2. There was a legal opinion stated by Eric Raymond during the 
>> formation of OSGeo that Contributions to a project will automatically 
>> assume the license of the project. You might want to apply this to 
>> contributions you cannot get a response for.
>> 3. If you don't resolve the license issue, there should be a work off 
>> plan describing how it will be resolved. Is the code going to be 
>> rewritten? Is it going to be moved into a separate download?
>>
>> If there are any outstanding license issues, then there should be an 
>> informative web page explaining the issues to potential users so they 
>> understand the risks associated with using the code. A reference to 
>> the Provenance Review should suffice.
>
> Cameron,
>
> In the interest of directness, I'll list the issues marked TO_RESOLVE:
>
> In gdal/data we have several coordinate system dictionary files derived
> in one fashion or another from other source (via translation scripts):
>
> * cubewerx_extra.wkt: derived from definitions distributed by 
> Cubewerx, rights unclear. '''TO_RESOLVE''' (emailed Edric)
> * ecw_cs.dat: Derived via much processing from ERMapper GDT 
> definitions, rights unclear. '''TO_RESOLVE'''
> * esri_extra.wkt: Derived with some processing from projections 
> definitions in ArcGIS, rights unclear. '''TO_RESOLVE'''
>
> Also two data files - one a seed (template) used when creating DGN files,
> and one a list of Canadian mapsheet names:
>
> * seed_2d.dgn, seed_3d.dgn: Exact source of these files is unclear. 
> '''TO_RESOLVE'''
> * NTS-50kindex.csv: Provided by Matt Wilkie, derived from NRCan 
> dataset, rights unclear.  '''TO_RESOLVE'''
>
> Also, I discovered that the gdal_merge.py script is accidentally 
> distributed
> under LGPL instead of MIT/X license:
>
> * gdal_merge.py: copyright held by Atlantis, under LGPL.  
> '''TO_RESOLVE'''
>
> I noted some concern about the license terms of libgeotiff:
>
> * Contains copy of libgeotiff, license terms not made clear.  
> '''TO_RESOLVE''' (Emailed Niles about using MIT/X license for his 
> libgeotiff code).
>
> This specific file from libgeotiff is somewhat unclear:
>
> * geoextra.c: Derived by public domain contribution to libgeotiff from 
> PCI but the terms are not clear.  (this also affects libgeotiff) 
> '''TO_RESOLVE''' Email send to Dave Stanley to allow relicensing under 
> MIT/X license.
>
> The only C/C++ source marked TO_RESOLVE is the libgeotiff related 
> stuff.  I
> am very comfortable with the origin of this code and feel the issue to 
> resolve
> is just ensuring provenance and licensing are more clearly documented.
>
> The gdal_merge.py script is under a legitimate open source license, and
> the fact that it is LGPL does not affect any other parts of the library
> so I'm not overly concerned.  I'd just like it cleared up so there aren't
> any peculiar licenses in GDAL.
>
> The coordinate system data files are slightly more confusing.  Some
> capabilities of the library will not work without them.  I don't believe
> there is any problem with any of them but it is a little unclear.   I
> would like to get clarification on them but it can be challenging to get
> a legal release from large corporations when they have no particular
> incentive to apply their legal resources to the question.
>
> In short, I believe the code is clean.  I am concerned about some of the
> supporting coordinate system dictionaries.  One possible fallback might
> be to somehow segregate the questionable dictionaries from the standard
> install but this would substantially reduce the ability to process files
> with ERMapper coordinate systems, and reduce ESRI compatability.
>
> (cc:ing gdal-dev too as these provenance issues affect the GDAL 
> community)
>
> Best regards,


-- 
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html