apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Mixing Apache and Mozilla
Date Fri, 23 Feb 2001 05:51:51 GMT
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/

Mime
View raw message