On Thu, Feb 22, 2001 at 12:00:37PM -0500, Jon Smirl wrote: >... > Apache and MPL are both open source, non-viral, royalty free, commercially > redistributable licenses. I find it disappointing that a large piece of > excellently code (NSPR and XPCOM) could be ignored because of religion over > which open source license is the best.
Don't be argumentative ... nobody said it would be ignored. We said there are problems to work out. Big difference. That said: Apache *already* uses and includes MPL code in its releases. For nearly two years now. A subset of Expat is included in Apache 1.3 since 1.3.9 and is also included in every Apache 2.0 release. Expat is licensed under the MPL 1.1 (we weren't going near it while it was under 1.0). James Clark made the 1.1 release, partly at our prompting for a switch to MPL 1.1, and partly to release some pending bug fixes. MPL only comes into play if people want to modify the Expat that we redistribute. I believe some people have forgotten that it resides in our tree and have (recently) been surprised by it. Mostly, it is about concern that Apache redistributors know of its existence and its different license. Much of this will go away in the next couple weeks, as we toss the old Expat and upgrade to the latest (which is under an MIT/X license which is a *total* subset of Apache's license and is, therefore, totally cool). Back to the XPCOM issue. I'd totally love to see XPCOM in Apache. I'm quite familiar with it, being a Technical Advisor for ActiveState (who happen to be doing the Perl and Python bindings for XPCOM). It isn't going to replace the hook stuff for 2.0, but it is definitely an option for the future. And to the heart of the matter: APR and NSPR. Personally, I believe the path is pretty simple: 1) assuming the NSPR developers don't want to continue maintenance... 2) assume that the APR developers *do* (true right now) 3) build the NSPR API on *top* of the APR API 4) extend APR's API, where needed, to enable the complete NSPR API The end result being a backwards compatible API for developers, a shift of the maintenance load from NSPR to APR, and a loosening of the license (that is, switching to Apache) due to the rewrite on top of APR. [ since the NSPR is needed within GPL'd projects, before such projects could use NSPR/APR, we would need to fix the small gotcha in the Apache license. we've already decided to do that, and are just cranking the wheels now ] I believe the above should suit everybody: NSPR and APR users. Note that it is also possible to simply build *portions* of NSPR on top of APR, and leave the non-APR-able portions alone. That would, at least, reduce some of the code size and complexity of NSPR itself. Finally... assuming the above is agreeable, then the question is whether it is doable :-). Ryan mentioned memory handling concepts. There may be other semantics which would be hard to piece together: threads, I/O, signals, processes, etc. Each piece could be rebuilt bit by bit on top of APR. APR could be extended bit by bit to support the NSPR API. How does that sound? Cheers, -g p.s. and yes: I'm omitting the biggest question: "is there anybody motivated enough to sit down and actually do the coding?" All is moot if nobody wants to spend the time. -- Greg Stein, http://www.lyra.org/
