XML-RPC interface to mailman
I've created a patch to Mailman to add XML-RPC based remote procedure calls to mailman. This is just a first cut to show that it can be done and to do a few basic operations I need to plug it into a kind of hosting framework so it can be controlled from a separate web server. I plan to add functionality to it to fully meet my needs, but I thought I'd throw it out there so that I can get some feedback. It's made against a pristine 2.1.6 tarball.
In order to reuse code, I had to refactor quite a few files. Most notably some of the Cgi interfaces that do real work were tied very closely to the idea that you want to output HTML. You don't with XML-RPC, so I split out the work from the formatting and replaced said formatting with some exception handling. I welcome comments on this part of the patch. I'd like to know how to make this better.
You can see that I handle authentication in each XML-RPC call that needs it, so it shouldn't be any less secure than the appropriate Cgi call.
Finally, I'd like some discussion of licensing. I think that the xmlrpc.py file itself should be LGPL just so that there is no ambiguity whatsoever about using XML-RPC calls from a non-GPL application. However part of me thinks that this is unnecessary because there is no import required to use XML-RPC, and therefore, calling these functions would not be considered "linking" in any technical sense of the word, and therefore would not require making the calling application GPL. Thoughts?
-- Joseph Tate Personal e-mail: jtate AT dragonstrider DOT com Web: http://www.dragonstrider.com
"Joseph" == Joseph Tate <dragonstrider@gmail.com> writes:
Joseph> Finally, I'd like some discussion of licensing. I think
Joseph> that the xmlrpc.py file itself should be LGPL just so that
Joseph> there is no ambiguity whatsoever about using XML-RPC calls
Joseph> from a non-GPL application.You can't, since it calls Mailman functions. Mailman is licensed under the GPL, so all derivative works must be licensed under the GPL when distributed.
Joseph> However part of me thinks that this is unnecessary because
Joseph> there is no import required to use XML-RPC, and therefore,
Joseph> calling these functions would not be considered "linking"
Joseph> in any technical sense of the word,Unfortunately, linking is not a necessary condition for a program to be a derivative work, merely a sufficient one. I would suspect that Richard Stallman and Eben Moglen will tell you that anything with "RPC" in its name should be presumed to create derivative works until proven otherwise. After all, the whole point of any "remote procedure call" protocol to allow the moral equivalent of linking without actually sharing memory cells.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
On Fri, 2005-07-22 at 02:08, Stephen J. Turnbull wrote:
Unfortunately, linking is not a necessary condition for a program to be a derivative work, merely a sufficient one. I would suspect that Richard Stallman and Eben Moglen will tell you that anything with "RPC" in its name should be presumed to create derivative works until proven otherwise. After all, the whole point of any "remote procedure call" protocol to allow the moral equivalent of linking without actually sharing memory cells.
Isn't this a gray area that the GPL 3 is trying to clarify? I agree that the patch probably needs to be licensed under the GPL (and unfortunately assigned to the FSF) to be integrated into Mailman, but to provide XMLRPC services to a Mailman server probably does not require the client to be GPL'd.
I wouldn't call it "linking" any more than trying to require GPL web browsers to connect to a GPL web server via the "linking" rule. That my own opinion, and I don't know what the FSF would say.
Joseph, the best thing to do is to post your patches on SourceForge. It's way to easy for them to get lost in the archives (or <shudder>, my inbox).
-Barry
"BAW" == Barry Warsaw <barry@python.org> writes:
BAW> On Fri, 2005-07-22 at 02:08, Stephen J. Turnbull wrote:
>> Unfortunately, linking is not a necessary condition for a
>> program to be a derivative work, merely a sufficient one. I
>> would suspect that Richard Stallman and Eben Moglen will tell
>> you that anything with "RPC" in its name should be presumed to
>> create derivative works until proven otherwise. After all, the
>> whole point of any "remote procedure call" protocol to allow
>> the moral equivalent of linking without actually sharing memory
>> cells.
BAW> Isn't this a gray area that the GPL 3 is trying to clarify?Last I heard, yes. However, all GPL 3 can do is provide an exemption (similar to the one that LGPL provides for what we normally think of as linking). It is the law (including existing and future court decisions) that decides what is and is not a derivative. The license can only exempt some derivatives from its restrictions; it cannot define what a derivative is. That exemption doesn't exist in GPL 2.
It's not really a problem for Mailman. But I think that people who implement clients of the XML-RPC interface should be warned that there is a plausible theory that such clients are derivatives of Mailman, just as much as if they imported the functions instead of wrapping them in a thin layer of XML and sending the XML over the net. And therefore distribution of such clients may be subject to the GPL.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
On Fri, 2005-07-22 at 14:15, Stephen J. Turnbull wrote:
It's not really a problem for Mailman. But I think that people who implement clients of the XML-RPC interface should be warned that there is a plausible theory that such clients are derivatives of Mailman, just as much as if they imported the functions instead of wrapping them in a thin layer of XML and sending the XML over the net. And therefore distribution of such clients may be subject to the GPL.
That's a valid point, and given that it's the FSF that owns Mailman 2.1, it's really up to them to press the case, should they ever decide to. I definitely think that if we distribute client side code for the XML-RPC interface, that code ought to be LGPL'd. OTOH, you don't really need any client code, since Python (or whatever language you'd want to use) probably has everything you need.
It's worth a (non-scary sounding) warning in the docs.
-Barry
participants (3)
-
Barry Warsaw -
Joseph Tate -
Stephen J. Turnbull