From: Matthias A. <mat...@gm...> - 2008-05-06 11:00:34
|
Jelmer Vernooij schrieb am 2008-04-30: > Hi Matthias, > > To quickly introduce myself: I'm one of the OpenChange developers and am > mentoring Yangyan for the Summer of Code. > > Am Freitag, den 18.04.2008, 09:51 +0200 schrieb matthias.andreea: > > The final issue I'd like to raise for this mail is that of licensing, > > any third-party libraries should be GPLv2-compatible and > > GPLv3-compatible and also AGPL-(Affero GPL) compatible so that I can > > keep your parts should I rewrite major other parts of fetchmail and > > maybe put them under the AGPL later on. > > > > Hope that helps as an early starting point. > OpenChange is licensed under GPLv3 or later; in other words, > incompatible with GPLv2-only licensed code but compatible with "GPLv2 or > later" licensed code. Is this a problem? > > If it is, would it be acceptable if Yangyan's contributions were under > these three licenses but not OpenChange? I imagine the support for MAPI > would be a compile-time option anyway. Changing the OpenChange license > is not really an option since it relies on Samba, which is GPLv3 or > later as well. Hi Jelmer, Yangyan, *, I have contacted Carl Harris Jr (the popclient author, popclient is fetchmail's predecessor, some lines of code remain in fetchmail) and Eric S. Raymond (who extended and maintained fetchmail for a long time) yesterday. Carl considers GPLv3 compatible with his original distribution terms. Eric lets me choose what suits the project best from "any version of GPL", "GPL v2 or later", and "GPL v2 only", so I guess I'll turn it into a "GPL v2, or, at your option, any later version of the GPL" for the nonce, and later review if fetchmail as a whole should move on to GPL v3 or perhaps AGPL v3 - that would require a new license review. I'll have to check if any code pieces remain that are GPLv2 only or otherwise incompatible, or require consent of the authors to change to "any later version" or similar; however, as I expect these to be minor, I'm ready to drop or rewrite them if need be. I expect the MAPI support to become part of a later fetchmail version I'll dub 6.4 or 7.0 depending on the extent of other changes, so we have the opportunity for a bigger cleanup anyways, and we should take it (for instance, drop POP2 support). WRT the MAPI code itself, I'd very much appreciate if it could be kept in separate .c/.h/... files with as little changes to other files as possible (for instance, don't hack too much on sink.c, but add a sink-mapi.c file and just add the hooks to sink.c you need while testing, and we'll in a team effort then split sink.c into sink.c, sink-smtp.c (perhaps sink-lmtp.c), and sink-mda.c, and add your sink-mapi.c. HTH, -- Matthias Andree |