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.
Martijn _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com