[gdal-dev] New JPEG 2000 Driver

Greg Troxel gdt at lexort.com
Wed Mar 3 12:14:35 PST 2021


Andrew C Aitchison <andrew at aitchison.me.uk> 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.

-------------- 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/20210303/3247ac6e/attachment.sig>


More information about the gdal-dev mailing list