Having ranted earlier about the use of AGPL3 to sell proprietary licenses, I'd like to say that I'm glad to hear the new library is "righteous AGPL3" instead of "subversive AGPL3".
I also was unclear on the optional driver situation. Certainly if drivers can link with proprietary libraries, there is absolutely no reason to object to a driver because it links so an AGPL3 library. I believe that drivers with non-MIT licenses shouldn't be built by default even if the prerequisite libraries are available in the build environment. Partly this bias is from pkgsrc, as packaging systems typically try to control the build to get a repeatable outcome, and partly because having a proprietary library installed is different from a decision to make gdal use it and thus end up with possible distribrution problems. I found https://gdal.org/download.html#development-source https://gdal.org/drivers/vector/index.html#vector-drivers https://gdal.org/drivers/raster/index.html#raster-drivers but didn't from that understand if one needs to pass --enable, or if the library being found is enough. Consulting configure.ac, it seems some drivers are built if the library is found, and others are only built if the driver is requested and also the library is found. For pkgsrc this is not a big issue as our build process hides libraries that have not been declared as an explicit dependency. But I wonder if it would be best to document that libraries that are other than MIT (really, not MIT-ish) will not be searched for and used without an explicit --enable-foo, and adjust.
signature.asc
Description: PGP signature
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
