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

Reply via email to