Earlier today I released Push Up The Web for Drupal. Like many other modules, it requires download of an external library (in this case pushup.jquery). I did not copy the library to the cvs repository because it is MIT licensed. I fully understand and support the reasons for keeping contributed projects licensed under GPL.
Since I already require users to manually download and install the script, I plan to add a method to check and verify the script is installed. If it's not installed can I then prompt a user to install the script which will then use file_get_contents() (or another similar script) to download and save the required files? I feel that the notification is sufficient (ubuntu does this with proprietary drivers) if it clearly shows that the scripts are not licensed under GPL; however, I do not want to run afoul with Drupal.org webmasters ;).
Thanks for the clarification.
Comments
Comment #1
dave reidThere shouldn't be any problem with this. Many modules do this same thing with drush commands, including the drush 'module' itself.
Comment #2
dman commentedI've done this myself (to install a the required 'tidy' binary for htmltidy) (the binary!), plus some js libraries sometimes. And I think it's quite fine. For dev sites.
Working around unintentionally awkward licensing issues is (IMO) fine. But there's another reason why we get install instructions instead of install scripts for third-party downloads.
The biggest reason not to do this is because it involves opening up write-access on the server for executable files. Generally a no-no unless you also happen to know exactly what you are doing.
As the folk that need this extra installation step softened up for them are the ones that don't know what they are doing with regards to security - and why allowing a webserver to alter its own code is a bad thing - then it's a bit of a Catch-22.
See also drush 'make'. This is a ratified way of making that happen.
Although I like using
/sites/all/libraries- as you are doing - for JUST a js library you can probably just put it in a special place in your files dir and call it from there if using the auto-installer. That would avoid (most) code security issues.If you know what you are doing, put it in the proper place. If you want the webserver to do it for you, put it in an adequate-but-not-perfect-place and avoid bad security karma.
Comment #3
dman commentedx-post didn't mean to switch status.
But the security aspect if trying to bootstrap the module from the web UI stands as an issue. Unrelated to the licensing one. This approach is fine for drush because the uid is secure (normally)
Basically, a new module application that tried to do this would be swatted hard by the security team, so it's an issue.
Comment #4
Crell commentedWriting JS code to the files directory is as much a security issue as writing PHP code there. It won't break the server, but it could be an attack vector against a user's browser.
Comment #5
dman commentedoff-topic, but it makes me wonder whether the XSS vulnerabilities in css : IE dynamic css code evaluation or
url('javascript:alert("bad stuff")')warnings are real.I'm not an expert, just read enough to be paranoid.
And if so, is that an issue with using css aggregation in a web-writable dir.
Not something I'm losing sleep over, but if the risk is real, then writable css is as bad as writable js
Comment #7
avpaderno