On Friday, March 8, 2002, at 02:30 PM, Neal Richter wrote:
> This would mean that calling libhtdig would be problematic from PHP > code. This is further complicated by the interpretive nature of > PHP... a > 'function call' in a PHP page is not a function call per-se. It > becomes a > function call during the interpretation of the page, after the page (or > the php.ini) loads the needed module (xxx.so). I hate legal issues. I was tempted to be flippant and write that it's up to the user to decide how to use ht://Dig and PHP. But of course if you're writing PHP wrappers for libhtdig, there's a rather implicit use for them. > With the branching of mifluz and libhtdig an LGPL license seems > more appropriate. Using the LGPL license would encourage the use of > libhtdig & the mifluz library by the widest possible set of developers, > hopefully enhancing the project's quality and feature set. I'm not sure that mifluz will be relicensed under the LGPL. Keep in mind that it's now "GNU mifluz." For the moment, I'm going to ignore the question of contacting all copyright holders in ht://Dig and asking them about a dual license. I'm quite certain in terms of # of lines of code outside of the Berkeley DB, that Andrew and Loic are probably the largest contributors. So in order to get a new license for ht://Dig as a whole, I think you'd need to see a few things happen first: a) mifluz dual licensed. b) Andrew agree to allow an LGPL for his code in ht://Dig. This is, of course, ignoring the question of other contributors, which are many. > Idea: Form an official steering committee consisting of the > developers that have CVS commit access. This committee would become the > representatives of the contributing developers as a whole. The > committee > would then have the power to make re-licensing decisions for the > "The ht://Dig Group" as listed in each source code file. So far, the "steering" has been via open mailing list on htdig-dev. Such decisions usually involve pushing towards various releases, whether certain changes should be implemented in a "frozen" tree before a release and the merits of certain approaches. I'm not a lawyer, nor do I want to be one. I would suggest that a scheme more in line with previous practice would be at a minimum that the htdig-dev list should vote on such a steering committee. This may, in fact, be little more than a "rubber stamp," but I would also think major decisions such as relicensing should require more general votes as well. (I look towards Debian, for example.) > any. If HtDig wanted to become an official entity (non-profit etc.) > there > would be costs, if not it may be as simple as posting the notice on the > web-site. I don't think most of us would know the benefits/drawbacks of being an official non-profit. I am aware that this would probably entail some paperwork overhead in terms of tax purposes in the U.S. Also keep in mind that many contributors are not in the U.S. and as such may not wish to be bound to various U.S. regulations. I understand some of the motivations for such moves, but personally before there's much talk about licenses, I'd want to know that a license change would even be possible. If mifluz is completely GPL'ed, period, then there's not much a steering committee for ht://Dig could do. -Geoff _______________________________________________ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
