<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

<br>

<br>

Larry Garfield wrote:<br>

<blockquote cite="mid:1ac189024d4dd5a8a7fd78b2d3b99e63@localhost"

 type="cite">

  <pre wrap=""><!---->

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

  </pre>

</blockquote>

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.<br>

<br>

Therefore a module *is* derivative work.<br>

<br>

The same argument applies to a module that interfaces with third party

non-GPL-compatible software in the same fashion (a so called bridge).<br>

<br>

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.<br>

<br>

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.<br>

</body>

</html>