[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