<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi<div class=""><br class=""></div><div class="">I think this is easily resolved: </div><div class=""><br class=""></div><div class="">1) Add a guideline on the plugin page that we **prefer** plugins to be shipped without binary blobs, but if they are required they should still adhere to our licensing requirements and other criteria as referenced by Matthias below.</div><div class="">2) Evaluate plugins with binary blobs on a case by case basis and simply accept them if they author appears bona fide.</div><div class=""><br class=""></div><div class="">I would have also liked to have the following:</div><div class=""><br class=""></div><div class="">3) Have a tag in the metadata that indicates that the plugin contains binary blobs so that the user can make up their own mind as to whether they wish to install blobs or not. But this is not a blocker for me. For double points use an icon like this <font color="rgba(0, 0, 0, 0.870588)" face="arial, sans-serif" size="3" class=""><span style="cursor: pointer; line-height: 26px; white-space: nowrap;" class=""><a href="https://goo.gl/images/NYt3uE" class="">https://goo.gl/images/NYt3uE</a></span></font> so you can see at a glance which plugins are blobbified.</div><div class=""><br class=""></div><div class="">I think guidelines and rules are great, but that we also should not become so caught up in our rules that we lose sight of common sense - people spend a lot of time and effort building their plugins and it is a shame to turn them away if they had to blobbify their plugins for good technical reasons...</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Tim</div><div class=""> <br class=""><div><blockquote type="cite" class=""><div class="">On 22 Dec 2016, at 11:36 AM, Matthias Kuhn <<a href="mailto:matthias@opengis.ch" class="">matthias@opengis.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Anita,<br class=""><br class="">On 12/21/2016 09:16 AM, Anita Graser wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><a href="http://anitagraser.com" class="">http://anitagraser.com</a><br class=""><br class="">On Dec 21, 2016 7:07 AM, "Paolo Cavallini" <cavallini@faunalia.it<br class=""><mailto:cavallini@faunalia.it>> wrote:<br class=""><br class=""> Hi all,<br class=""> should we take a decision on this?<br class=""><br class=""><br class="">Could you summarize the issue. I haven't been reading along all the time.<br class=""></blockquote><br class="">The question is, if it should be possible to deploy binaries (normally<br class="">additional libraries) through our plugin servers as part of a plugin.<br class="">Everyone agrees that if it should be allowed, only under the condition<br class="">that the source code is present as well and properly licensed.<br class=""><br class="">Contra:<br class=""><br class=""> - We cannot verify if binary matches source<br class=""> - Hosting binaries feels wrong<br class=""><br class="">Pro:<br class=""><br class=""> - Plugin dev's life is easier (because sometimes using libs cannot be<br class=""> avoided)<br class=""> - We have a higher chance of keeping track of the plugins and closer<br class=""> contact to the developers<br class=""> - Less risk of having multiple plugin repositories out there<br class=""> - There is no additional protection for the user by not allowing this<br class=""><br class="">Possible solutions are listed here:<br class=""><a href="https://lists.osgeo.org/pipermail/qgis-developer/2016-December/046247.html" class="">https://lists.osgeo.org/pipermail/qgis-developer/2016-December/046247.html</a><br class=""><br class="">Best wishes<br class="">Matthias<br class="">_______________________________________________<br class="">Qgis-psc mailing list<br class="">Qgis-psc@lists.osgeo.org<br class="">http://lists.osgeo.org/mailman/listinfo/qgis-psc</div></div></blockquote></div><br class=""><div class="">
<span><img height="65" width="59" apple-inline="yes" id="F6984D63-5EBE-4803-8235-1DF1CEF3AFFD" apple-width="yes" apple-height="yes" src="cid:879A6E78-CA46-47B2-AA0E-1810BD833229" class=""></span><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; line-height: normal; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="font-weight: normal;" class=""><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">---</div><div style="font-weight: normal;" class=""><br class=""></div><div class=""><b class="">Tim Sutton</b></div><div style="font-weight: normal;" class="">QGIS Project Steering Committee Chair</div><div style="font-weight: normal;" class=""><a href="mailto:tim@qgis.org" class="">tim@qgis.org</a></div><div style="font-weight: normal;" class=""><br class=""></div></div><br class="Apple-interchange-newline" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; line-height: normal;"><br class="Apple-interchange-newline" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
</div>
<br class=""></div></body></html>