[gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions

[Even Rouault]

> 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.