[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