Larry Garfield wrote:
How exactly is a Drupal module not a plugin? (Not a troll, a genuine question.) I don't know of a legal definition of plugin, but from a technical standpoint they fit my understanding of what a plugin is, despite the name. In the generic sense "module" would mean "somewhat discrete component of a system", while "plugin" would mean "swappable and optional component of a system". (Again, not legal definitions.)
--Larry Garfield
Refering to the references I mentioned in my previous email the conclusion I draw is that a Drupal module that utlizes hooks cannot be considered a plugin since Drupal does not provide a defined interface. By defined interface I mean a discrete set of public routines that can be called by an application the same way Drupal uses GD to manipulate bitmap data. A Drupal module uses and can use not only hooks but a wide range of internal functions to Drupal (as well as of other modules) since it has not access to a limited scope but to all the internals of Drupal. The question here is not what a module does but what it is allowed to do. Since Drupal fails to provide a defined interface a Drupal module cannot be considered a plugin. Which may also be of relevance is that that a module is perceptually and behaviorally (from the user's POV) a part of Drupal. Therefore a module *is* derivative work. The same argument applies to a module that interfaces with third party non-GPL-compatible software in the same fashion (a so called bridge). Now this is old news. Jeff started this discussion quoting the FSF's experts reaching the same conclusion as I have. What we need to focus on is the issues that were raised - that is how do we allow Drupal modules to interface with software available under non-GPL-compatible licenses without violating the GPL. So far many good ideas have been posted and there are others with much more knowledge than I have who I know for certain can provide a viable strategy to bring every contributor's code safely back into the GPL fold.