I agree all the comments done Our first way to distribute the plugin was a custom repo
https://raw.githubusercontent.com/QTrafficmodel/QTrafficPluginRepository/master/emsure.xml and publishing in the official repo was a way to reach more users (not used to configure custom repos) other solution would be to download the .exe after local installation (but need more but simple code... and wasn't planned because was planned to have code and license available) btw... I'll remove and I hope publishing it temporarily was a good way to raise the problem. thank you for your patient cheers Luigi Pirelli On 2 December 2015 at 11:01, Denis Rouzaud <denis.rouz...@gmail.com> wrote: > I think we already have this kind of discussion once. > Victor's proposition arise and the point was that it only makes sense if the > plugin doest not fully rely on the external binaries. If it's totally > depending on it, then I believe the 3rd party repo is the most appropriate > way. > > my 2 cents too > > > > On 12/02/2015 10:51 AM, Victor Olaya wrote: >> >> Maybe another option is to publish the plugin without the binaries, and >> leave the user the task of installing and configuring that separately. >> So all the code of the plugin itself is available, but then it relies on >> a 3rd party application that is not open, but that we are not shipping. >> >> my 2 cents >> >> 2015-12-02 10:38 GMT+01:00 Tim Sutton <t...@qgis.org >> <mailto:t...@qgis.org>>: >> >> Hi Luigi >> >> >>> On 02 Dec 2015, at 05:43, Luigi Pirelli <lui...@gmail.com >>> <mailto:lui...@gmail.com>> wrote: >>> >>> Hi qgis devs >>> >>> I just published the QTraffic plugin... It's a plugin developed for >>> the Coimbra university (Portugal) that I finished some months ago. >>> >>> I had ethical problem publishing it, because it contain a windows >>> executable (the algorithm developed by the University team) that >>> I'not >>> able to verify directly. >>> I worked to convince to publish the code since the beginning of the >>> project, but because it's a research project they are still in >>> experimental phase testing and calibrating it. So they don't want to >>> have a "official" release of the code before to have it deeply >>> tested. >>> Deep testing depends of accessibility of the plugin, so I >>> published it. >>> During Gran Canaria hackfest I asked to some core developer if it was >>> correct to publish it, and all give me the ok. >>> I'm still not sure of this decision, and at least I want to be >>> transparent about this. >>> >>> I'm sincerely confident that the executable code (Fortran code) will >>> be sooner or later published, what I don't know is when and in what >>> form and with what license... but I'm confident that it will be a >>> open >>> license. >>> >>> please ask more info or do pressure to the official code >>> maintainer(s): qtraffic_supp...@uc.pt <mailto:qtraffic_supp...@uc.pt> >>> >> >> For my part I have concerns both from licensing and from exposing >> our users to potential harm point of view. >> >> * In the first case (which is probably not as well defined) I don’t >> think it is good to ship code from the official repo where the >> licensing is indeterminate, and which potentially conflicts with >> QGIS licensing itself. >> * In the second case, shipping a binary from the official repo gives >> us no opportunity to inspect the code to ensure that it is not doing >> something potentially harmful to the users computer. >> >> My suggestion would be to publish it under a third party repo and >> encourage users to test it from there. >> >> Regards >> >> Tim >> >> >> >>> Regards >>> >>> Luigi Pirelli >>> >>> >>> ************************************************************************************************** >>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT >>> com >>> * LinkedIn: https://www.linkedin.com/in/luigipirelli >>> * Stackexchange: >>> http://gis.stackexchange.com/users/19667/luigi-pirelli >>> * GitHub: https://github.com/luipir >>> * Mastering QGIS: >>> https://www.packtpub.com/application-development/mastering-qgis >>> >>> ************************************************************************************************** >>> _______________________________________________ >>> Qgis-developer mailing list >>> Qgis-developer@lists.osgeo.org >>> <mailto:Qgis-developer@lists.osgeo.org> >>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> >> >> >> >> Tim Sutton >> QGIS Project Steering Committee Member >> t...@qgis.org <mailto:t...@qgis.org> >> >> >> >> >> >> _______________________________________________ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org> >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> >> >> >> _______________________________________________ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
