[horde] phpGroupWare + Horde

[Anil Madhavapeddy]

Quoting Dan Kuykendall <dan at kuykendall.org>:

> For the end user it doesnt matter. But for developers and some admins
> that are a bit extreme in their support of the "Free Software Movement"
> will not accept this.

Well, I don't think we want to worry about zealous developers in deciding
whether or not continue support for PHP3.  The clear technical advantages
of PHP4, and the fact that all new development is occuring on that platform
is enough for me.

Since the recent decision to merge PHPLIB and PEAR, sticking with PHP3 looks
like a harder and harder solution.  You would do well to look at PEAR as an
'easy' route to helping Horde and phpGroupWare interact - whether this has
more value to you than PHP3 compatibility is a decision you must take.

PEAR is the direction that Horde has been going - this way, anyone can interact
with us, via that project, and we will happily use any useful code that someone
adds to it.

> Me neither. I do wish they would have kept the basic PHP able to run in
> a fully GPL form, and then have the performance improvement code (zend
> parts) as an optional part. As it is now they are too tightly
> inter-twined.

Zend isn't 'performance improvement code'.  

> I personally like the LGPL the best. The BSD license leaves me feeling
> less secure because any commercial company can take my code and use it
> to create a closed source solution and never return any of their
> improvements back to me.

The various BSD OS's have done pretty well from the license.  If you GPL
your code, you scare away a lot of companies;  with BSD code, there is at 
least a chance that they contribute it back.  The GPL has often been described
as a virus; I don't blame those companies!

> Dont under-estimate the FSF. They have duplicated plenty of closed
> source applications, and since most of PHP4 is open, they would really
> only need to replace the Zend parts with LGPL'd replacements.

Don't over-estimate the FSF either.  Their rabid desire to use ONLY other
GNU tools has led to some horrible code - autoconf, automake, and libtool's
decision to use m4 over perl is a great example of this.  The first time I
tried to debug a configure script problem when the package doesn't include the
configure.in left me on a ten-coffee-a-day recovery program for weeks :)

Don't even get me started on libtool!

-- 
Anil Madhavapeddy, <anil at recoil.org>