On Aug 31, 2007, at 2:56 PM, David Strauss wrote:
Jeff Eaton wrote:
This is very true. It's also important to keep in mind that the FSF gets annoyed when people distribute code that "Is GPL Compliant, Wink Wink Nudge Nudge" but doesn't actually do anything until you put it in the presence of non-GPL code.
The no-distribution loophole seems to contradict what was quoted earlier, but if true that's very reassuring. Thanks. The not- permitted- even-if-not-distributed thing was what sounded so alarming. It's a darned shame though that a GPL module that enhances a free- standing GPL system (e.g., a module that bridges Drupal with an outside system) is lumped together with a "GPL" widget that is wholly dependent upon a proprietary system. The former is what I would consider a powerful enhancement of another existing GPL system, while the latter is clearly a licensing gimmick to get away with something. And yet legally they should be considered the same? Ouch! Hypothetical: Could one argue that the GPL bridging module that bridges, say, Drupal and ASP.NET does not depend upon the proprietary system in order to be there and available for Drupal? I mean, if I can, for example, see the module active and available in the Drupal admin area, even if the ASP site is not connected, would not that module be considered as not requiring a proprietary system to run?
To avoid this sort of GPL Hell, we have very specific terms on which we work with clients:
(1) The client owns the work we do specifically for them.
(2) The client licenses .module files and their dependencies back to us under the GPL, version 2, and all future versions as published by the FSF.
The terms of (2) mean their internal staff can contribute to the project, but the final working modules are licensed back to us in a GPL-clean way that allows us to return the work to the community.
That's a very interesting contractual approach. Thanks for sharing that! Laura