[gdal-dev] Re: [Incubator] GDAL graduation
warmerdam at pobox.com
Tue Jan 8 10:19:32 EST 2008
Cameron Shorter wrote:
> Paul, Frank,
> Great to see GDAL reaching graduation, it sounds like GDAL is in good
> 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.
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
* 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.
* NTS-50kindex.csv: Provided by Matt Wilkie, derived from NRCan dataset, rights
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)
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
More information about the gdal-dev