<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">Folks,</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">When Andrew first mentioned RFC 34 I skimmed it and was a bit surprised it existed though perhaps it seemed a wee bit familiar.  Now that Even mentions it was not ever implemented I see that *I* proposed it and presumably did not actually follow up on implementing it or getting it adopted.   It still seems like a vaguely good idea, but also apparently one without a compelling need since it has not been followed up on.  </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">However, it does not solve the build-time problem posed by Greg.  I think the approach that inclusion of reciprocally licensed or proprietary drivers requiring explicit inclusion at configure time is a reasonable approach to avoid accidental license violations by packagers.</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">Best regards,</div><div class="gmail_default" style="font-family:arial,sans-serif">Frank</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 3, 2021 at 3:31 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
> <a href="https://gdal.org/development/rfc/rfc34_license_policy.html" rel="noreferrer" target="_blank">https://gdal.org/development/rfc/rfc34_license_policy.html</a><br>
<br>
As indicated in the top of the RFC, its status is "development" (draft), <br>
which here means stalled/non-adopted given that it was proposed long <br>
time ago. So there's no runtime mechanism to control license compatibility.<br>
<br>
<br>
> But, I'm worried about something different.  As a packager, I'd like to<br>
> know that unless I take the affirmative step of passing --enable-foo,<br>
> for any GPLish or proprietary foo, I won't end up with a gdal build<br>
> linked with foo just because it happened to be present in my build<br>
> environment.<br>
<br>
This should normally be the case. One of the few GPL dependencies is <br>
Poppler and must be explicitly enabled with --with-poppler . Similarly <br>
with MySQL. All proprietary dependencies need also to be explicitly <br>
enabled AFAIK (you actually need to point to their SDK).<br>
<br>
GEOS (LGPL) is enabled by default is found.<br>
<br>
Even<br>
<br>
-- <br>
<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="monospace">---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | +1 650-701-7823<br>and watch the world go round - Rush    | Geospatial Software Developer</font></div></div></div></div></div>