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, [email protected] 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 [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
