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.
