On 11-01-31 12:28 PM, Ray Gardener wrote:
I think Mr. Butler makes a good point.
Maybe just have folders in the source tree called "frmts/reciprocal" and
"frmts/proprietary" and the same for any libs. That way it's in people's face
all the time and impossible not to be conscious of what is licenced how. And
easy to exclude such drivers, just skip building that folder's makefile. If I
want total certainty, I can even delete those folders. And if someone makes a
classification mistake, it'll be more obvious too ("hey, driver XXX shouldn't
be in that folder").
Ray,
That would be adequate for those who are building things from source and
wanting to distribute the resulting binaries under a single consistent
licensing policy. However it does not help me for the OSGeo4W need.
OSGeo4W is a unified installer that can install a wide variety of OSGeo
project binaries for windows into one unified tree. So, for instance if
you install QGIS, MapServer and GRASS which all use GDAL they will end up
using a common copy of GDAL. Users also often want proprietary format
drivers for formats like MrSID and there is an optional package offered
for this.
In this situation MapServer and GDAL are under a non-reciprocal open
source licenses and there is no problem using them with proprietary drivers.
However, QGIS and GRASS are GPL and it is improper to distribute them with
proprietary drivers. I am *hoping* to be able to deliver a solution that
lets users have proprietary drivers easily with MapServer or GDAL
commandline, while not letting them use these drivers with QGIS or GRASS
unless they make a deliberate decision to do so even though it abridges
the freedoms they would normally have with GPLed software.
In the RFC I have also tried to offer a way for proprietary software
to avoid loading GPLed drivers accidentally. But as you note most
proprietary software distributors will just take care to avoid building
in any GPLed dependencies at compile time. However, I do like to imagine
a time in which even proprietary software distributors might be able to
take advantage of common "system level" installations of GDAL in which
case greater care about licenses might be appropriate.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev