[gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions
Baker (US), Anthony W
Anthony.W.Baker at boeing.com
Tue Jan 18 05:18:24 PST 2022
unsubscribe
-----Original Message-----
From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of Greg Troxel
Sent: Tuesday, January 18, 2022 8:14 AM
To: Even Rouault <even.rouault at spatialys.com>
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions
If that is meant to apply mainly to drivers with proprietary SDKs, it
looks fine. It's a little hard to tell which things apply to drivers
that don't have proprietary dependencies.
For example:
Drivers require a designated responsible contact.
seems perhaps a bit much, perhaps not, for something that is actually Free Software.
Besides proprietary SDKs being a problem because the users can't read them and fix bugs, they are also non-portable.
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 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.
More information about the gdal-dev
mailing list