[gdal-dev] New JPEG 2000 Driver

Greg Troxel gdt at lexort.com
Mon Mar 1 09:39:21 PST 2021


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210301/cd087956/attachment.sig>


More information about the gdal-dev mailing list