[Zope3-dev] lxml / elementtre inclusion

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:
> 
>> Jim Fulton wrote:
> 
>> Well, libxml2/libxslt cannot be relicensed by me, so the MIT
>> license will stay.
> 
> Of course.  I don't think we should include those libraries in the
> release. I suggest we simply make those prerequisites of Zope 3.
> 
> Most 'nix platforms seem to have it already.  (I hope lxml doesn't 
> depend on particular recent versions.)

It's likely not going to work in a significant set of cases, as Unix 
platforms sometimes have rather old versions of libxml2 floating around. 
Debian unstable is okay for now (it wasn't though until some update a 
few months ago), and Mac OX Tiger (10.4) seems to be okay for now too, 
but Panther (10.3) is too old (people have got it going by using a 
differently installed libxml2 though). A Solaris box I checked a few 
years ago had a then-already-ancient version of libxml2 (don't know 
where from, whether this came with the OS or not). I also have no idea 
what the status is for non-Debian/non-Ubuntu Linux distributions.

By working on lxml, I found bugs in libxml2 that got fixed in more 
recent versions. Eventually I'd obviously like to start relying on those 
fixes. Right now libxml2 works with 2.2.16 and newer, which goes back to 
november last year. The current release of libxml2 is 2.6.19 from april 
this year, and this does contain bugfixes I'd like to start relying on 
at some point.

So, in summary, making libxml2/libxslt prerequisities of Zope 3 will 
make installation of Zope 3 unfortunately a bit harder initially due to 
the new binary requirement. I got reports of lxml working on Mac OS X 
and Windows besides the Linux I develop on, so it's all possible, but 
it'll increase the installation burden somewhat. The libxml2 libraries 
do offer a huge featureset though, which may weigh against the drawbacks.

>> If it helps to also license lxml under the ZPL besides the
> 
>> existing BSD license, that shouldn't be an issue, though I myself
>> do not comprehend why adversiting-clause-less BSD should be an
>> issue; as far as I understood it could be safely combined with
>> absolutely anything.
> 
> This issue is that users of Zope should have as few different
> licenses to deal with as possible.  Some people care about IP issues
> and fewer different licenses is a significant advantage.

It also means an extra hurdle whenever an external library is used in 
Zope 3. For incompatible libraries such as GPL this cannot be avoided. 
As someone who just spent a lot of time updating copyright headers in 
the Five source code as I merged a new version into Zope 2.8, I'm not 
particularly looking forward to doing something similar with lxml as 
well.. Perhaps with lxml it is as simple as adding a note to the license 
information that this thing is dual-licensed, though.

If someone that is not interested in Zope 3 in the first place wrote a 
Python library we'd like to include, the relicensing hurdle will be 
larger, though. What's to be done with Twisted integration, for instance?

Relying on new external libraries with the core of Zope 3 will always be 
a big step. Then again, I also think that this way large amount of new 
features can be made available to Zope 3 without us having to reinvent 
wheels. It makes Zope 3 a more open platform. Perhaps the procedure for 
adopting externally written code should be spelled out. There are quite 
a few shapes this could take (external library, included in Zope 3 
tree), and right now it seems nobody but Jim knows what is required, or 
whether such inclusion is allowable at all in the first place.

Regards,

Martijn