Another comment is about "complicated registration process". I
sympathize but I don't really understand that. So it might be good to
say what's acceptable, which could be one of:
The SDK must be downloadable by a URL with no user interaction
It's ok to have a form which requires a name and an email address, and
which does not opt the user in to spamming, to download.
It's ok to have a form which requires a name and an email address (and
opting in to spamming is ok) to download.
Something else
I'll keep the vague formulation.
I also think it probably went without saying that drivers that depend on
proprietary SDKs will be default off, even if the build system finds the
SDK, so that people who build GDAL will not accidentally create
proprietary software.
Sorry , but no. If people have put proprietary SDKs in default findable
locations (which generally requires efforts since they generally have
non standard layouts), they will be used by default, at least in the new
CMake build. That makes things much more consistent. People can still
disable them (see
https://gdal.org/build_hints.html#cmake-package-dependent-options and
https://gdal.org/build_hints.html#selection-of-drivers). People who
build GDAL should look at the licensing of all dependencies. It might be
well possible to create a GDAL build with only free components with
incompatible licenses, who knows. Or maybe people want a build that is
globally permissive licensed, and thus they must be careful of not
including copyleft components. There was a RFC attempt at addressing
this, but this was abandoned as being a too complex issue.
Anyway people who want to create a build that is going to be used by
other peoples should do that in a dedicated controlled environment, not
just the random state of their desktop day-to-day env.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev