There was a little discussion on the webmasters mailing list, with a suggestion that nedjo was going to make a case on dev list about 3rd party, GPL, jquery plugins in contrib.
Quoting karthik:
Thus far, to the best of my knowledge, 3rd party GPL code has not been
allowed in the repository.. We have also turned down applications
based on this guideline. However, I've noticed that the jquery
_module_ [1] and the jstools [2] modules both include (or apparently
plan to, in the case of the former) 3rd party plug-ins.Please advise ...
There were some follow up comments, and an indication that nedjo was going to begin a discussion on the dev list. For my part I just want to discuss plugin management, based on said policy.
Scenario
Say I'm using a third-party plugin. The plugin developer has a v1.1 and a version v1.2. However the jquery.js version in Drupal was released somewhere between these 2 versions of the plugin, and the plugin happens to be incompatible with Drupal's jquery.js. It's also fair to assume that the developer doesn't think about Drupal in their day-to-day jquery bliss, but they have agreed to GPL and mirroring, being good open-source netizens.
So, it seems like the options are to:
- Provide instructions for both downloading and modifying the plugin so that it works in my module, or,
- Host a modified version of the plugin somewhere else.
What would people do in this situation?
Comments
Solved by Committing Backwards Compatibility Plugin to Core?
Thanks for bringing this up since I'm running into similar dilemma.
I can understand how it makes sense to not have non-GPL code in the repository due to any potential licensing conflicts, but I don't understand the logic of a blanket ban on any and all 3rd party GPL code.
Getting it work with Drupal seems to be of prime concern here, especially when the Core js files may be a version or two behind in development.
But I think this question is merely a symptom of another decision that gets to the core "disease" of this issue. The underlying issue is the decision to not patch Drupal js files in future Drupal 5.x releases to make them compatible with jQuery upgrades.
Two threads of debate on this can be found with Dries offhanded comment that a patch to textarea.js "Needs to go in Drupal 5." & again here.
I think there may be a workable solution to this backwards compatibility concern:
* Demonstrate that the jQuery1.0 compatibility plugin appropriately reinstates the deprecated jQuery 1.0 functions. More on this from Josh here.
* Demonstrate to Drupal core developers that this compatibility plug-in -- if committed to Drupal 5.x core -- would in fact solve the outstanding issues as expressed by Steven here: "Drupal 5 will never be distributed with jQuery 1.1. Because of the lack of backwards compatibility, manually upgrading the jQuery library is a bad idea. It might break modules you downloaded. Or, you'll probably start using jQuery 1.1 features in your own modules, which cause them to break for other users. Keeping Drupal 5 broken under jQuery 1.1. When we included jQuery, this was the policy that was set down. Unless we actually switch over Drupal 5 to jQuery 1.1, none of these 1.1 patches are relevant for Drupal 5."
* Develop working patches to Drupal 5 that make textarea.js & collapse.js compatible with both jQuery 1.0 and 1.1.x -- (currently Steven is saying that the collapse.js patch doesn't work as advertised.)
* Have this javascript-centric group of users help track down & fix other potential conflicts.
I understand the fears around making Drupal 5.x core js files only compatible with jQuery 1.0 -- especially if future jQuery releases horribly break all of the Drupal-specific js functions.
But from my perspective, I think it would be worth the effort to make the Drupal js files as compatible with all of the jQuery releases as possible so we wouldn't have to fork and maintain separate Drupal-specific versions -- which is the unfortunate path that we currently find ourselves on.
The benefit of having 3rd party development is that they can take care of maintaining it, fixing bugs, etc.
It seems to me that you lose this benefit by not solving the root cause and solution mentioned above.
Unless I'm missing something here, why not put the effort in to demonstrate this plug-in addresses the compatibilty concerns and then have a collective outcry for making Drupal 5.x javascript files compatible with both jQuery 1.0 and 1.1.1 (and beyond?)
Any thoughts?
I trust Steven's judgment
I trust Steven's judgment about no 1.1.1 in D5 core. And I also, I think it's a good policy not to let third-party stuff in contrib. I'd love things to be different but I'm deferring to the decisions of more experienced Drupallers.
Of course these are all fair points you raise, and I hope that a good compromise can be reached. However, I am learning with open-source that you need to need to walk and talk at the same time. Hence, I'm looking for constructive ways to work with the current situation.
On hold for
On hold for this:
http://drupal.org/node/124978