Only one small additional idea: Cause of this reason, we could add a extra "license filter", which goes throw all installed plugins and check there licenses (so every symfony project could be license validated).
Therefore you have to define a plugin_license_only: MIT in your settings.yml or whatever. However this filter has to be cachable, because it would be too much overhead, when every time these licenses would be checked. - Frank > > Perhaps we can just add a warning with the license name... or perhaps we > can ALWAYS print the license name after a successful installation and > the URL where the full license text is available. > > All this can only be done fairly easily if the user install the plugin > via a PEAR channel. If he just installs with a downloaded archived or a > URL, we won't be able to do this without extra work (and only if it is a > valid PEAR package). > > Fabien > > Bjorn Wijers wrote: >> I agree with Fabien. Not hosting plugins with licenses you don't want to >> endorse seems a fair and good compromis. >> >> I'm not so sure on making it harder to install plugins with licenses >> other than the endorsed ones, though. If I understand correctly these >> will not be part of the symfony plugin site anyway and therefor the >> developer in need for these plugins already has to add another channel. >> This would seem sufficient to me as this already requires an extra step, >> which I presume implies that the developer knows what he/she is doing. >> Therefor adding another command-line option seems not necessary to me. >> >> All the best, >> >> grtz >> BjornW >> >> >> >> >> Matthias Nothhaft wrote: >>> Fabien POTENCIER schrieb: >>>> Hi all, >>>> >>>> Here is my thoughts. >>> Thank you. This finally pushes this "flame war" into the right >>> direction. I was a bit tired of it already.. ;-) >>> >>>> I (as in the symfony project sponsor) only want to host (package files >>>> and subversion repositories) plugins released under a MIT/BSD/LGPL/... >>>> license on the symfony-project.com website. >>>> >>>> People can release plugins under other licenses (GPL or whatever) if >>>> they want but I don't want to host them. >>>> >>>> So, +1 for creating a new wiki page for "non compliant" plugins where >>>> we >>>> allow people add links to external websites where they host their >>>> plugins. >>>> >>>> We can also create an option to the plugin:install task to be able to >>>> install a non "MIT like" licensed plugin (will only be possible for >>>> symfony >= 1.1): >>>> >>>> ./symfony plugin:install --allow-gpl-plugins sfGPLPlugin >>>> >>>> Without the option, symfony gives an error and explain how to install >>>> it. >>>> >>>> Of course, we need a better name than "--allow-gpl-plugins". Ideas? >>> what about --allow-non-compliant ? >>> >>> >>>> This discussion comes at the right time as I will release a new >>>> version >>>> of the plugin system for symfony 1.1. In this new version, we will be >>>> able to check licenses and people will be able to register other >>>> plugin >>>> repositories: >>>> >>>> ./symfony plugin:add-channel >>>> my-symfony-plugin-pear-channel.foobar.com >>>> >>>> Then, if the alias PEAR channel alias is foobar, you can install a >>>> plugin with: >>>> >>>> ./symfony plugin:install foobar/myCoolMITPlugin >>>> >>>> Fabien >>> This is what we need. Great ideas! >>> >>> Regards, >>> Matthias >>> >>> >>> >> >> > >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
