Andrew C Aitchison <[email protected]> writes: > On Mon, 1 Mar 2021, Greg Troxel wrote: > >> 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. > > I take it you are aware of > doc/source/development/rfc/rfc34_license_policy.rst > https://gdal.org/development/rfc/rfc34_license_policy.html
No, I was not aware of that; thanks for pointing it out. What I did was look at the top-level docs and for the INSTALL file that is typically present, to try to understand the prereqs and rules. Even looking at that page there is a bunch of text that doesn't read like it's a done deal. But, I'm worried about something different. As a packager, I'd like to know that unless I take the affirmative step of passing --enable-foo, for any GPLish or proprietary foo, I won't end up with a gdal build linked with foo just because it happened to be present in my build environment. I don't think this set of build defaults is controlled by RFC34.
signature.asc
Description: PGP signature
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
