You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by rb...@covalent.net on 2001/02/21 23:09:03 UTC
Re: Mixing Apache and Mozilla
On Thu, 22 Feb 2001, Jon Smirl wrote:
> XPCOM is a very interesting technology that allow the mixing of modules
> written in C, Java, Javascript and Python across all of the Mozilla
> target platforms (Windows, Linux, BEOS, Max, Unix, etc). XPCOM is a
> portable version of Microsoft's COM.
>
> http://www.mozilla.org/projects/xpcom/
>
> XPCOM could be used to replace Apache's module system. XPCOM is cross
> platform and language neutral. I especially like the ability to call
> Java in-process. XPCOM is built on top of NSPR, Mozilla's portable
> run-time base. My desire to efficiently use XPCOM with Apache is one
> reason I'd like to see Apache use NSPR and merge memory management
> schemes.
>
> http://www.mozilla.org/projects/nspr/reference/html/index.html
>
> I've built a test module that uses Apache for the front-end and
> Mozilla's XPCOM for the back. I'm pleased with the features and
> performance. I can continue to use XPCOM from a module without changing
> Apache but I'd like to see this technology become more mainstream.
>
> What's everybody's opinion on this? Let's ignore the license issues for
> now, if there is technical agreement then I'm sure the license issues
> can be worked out. After all these are both freely available, open
> source projects.
There is a problem with ignoring the license issues, the license issues
are a real issue for a lot of people on this list.
There is also the problem that neither project can really just pick up and
start over with their API's. I would be interested in bringing the two
projects closer together, and trying to merge things where possible. NSPR
has some very interesting APIs that would be cool to merge with APR.
However, the memory management functions is not one of those areas IMHO.
The pools implementation that APR uses is very closely tied to Apache and
APR. If we ported Apache to NSPR, all we would do, is put the pools over
NSPR's PR_malloc calls, as Dean did originally.
I do not believe either team is interested in dropping support for their
current projects. Both APR and NSPR would like to continue to move
forward, at least for now. At least that is my impression. What I
wonder is, is there anything that we can do to move the two projects
closer together, so that at some point in the future, the two projects may
be able to merge?
If and when the projects merge, that would mean figuring out a way to be
able to wrap the resulting API with macros that are backwards compatible
for ecah project. That is a problem to solve later. The problem to solve
now, is to determine if the APR and NSPR developers are at all interested
in trying to move the two projects closer together. If not, we can end
this now. If so, and this is what I am hoping for, let's stop talking
about ending either project (that isn't going to happen immediately),
let's instead talk about how we can move the two closer. Would NSPR be
interested in any code from APR, would APR be interested in code from
NSPR? Does it make sense to merge the two mailing lists (BTW, this
message should be copied to the NSPR list, and all resulting messages
should go to both as well)? Does it make sense to design future work
together?
We also need to tackle the license issues. First let's answer the
questions in the previous paragraph. Then we need to look at licenses.
If we can resolve all of those issues, then we can begin to actually work
together.
This is not going to be a fast process. Nobody should think that if we
start this today, the two code bases are going to be merged by year's end.
I don't believe it will go that fast, and it could be stalled and/or
stopped at just about any time.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Mixing Apache and Mozilla
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 23, 2001 at 01:05:17PM -0500, Jon Smirl wrote:
>...
> If Apache will come on to the NSPR bandwagon my next target will be
> Xerces/Xalan. They're building yet another portable run-time.
Dirk,
I'm concerned about this one. What are Xerces/Xalan building? Does it truly
overlap the APR effort?
Or is it a bunch of Java code to deal with differences in OSes on the "other
side" of the JVM?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Mixing Apache and Mozilla
Posted by "B. W. Fitzpatrick" <fi...@apple.com>.
On Friday, February 23, 2001, at 12:05 PM, Jon Smirl wrote:
> <snip>
> What are the advantages to maintaining two libraries doing the same thing
> with slightly different APIs? Portable run-times are a lot of work, NSPR
> is
> 68KB times the number of platforms it works on. Supporting a portable
> run-times is a permanent time sink, every time a new OS version is released
> the PR has to be tweaked. I'm sure a new round of tweaking will be needed
> for Windows XP.
> Are there technical objections to NSPR from the Apache side?
> If Apache will come on to the NSPR bandwagon my next target will be
> Xerces/Xalan. They're building yet another portable run-time.
I think that the main reasons for the resistance you are seeing are:
- apr is well along the development path
- switching Apache 2.0 from apr to NSPR would set Apache back at least 6
months, and it's already behind schedule. (As Greg pointed out).
I think that those 2 reasons far outweigh any technical objections that
people might have.
-Fitz
Re: Mixing Apache and Mozilla
Posted by Jon Smirl <jo...@mediaone.net>.
The last thing I want to create is yet another library mapping between the
two APIs. That is the worst of the possible choices. I'll work towards a
merger but I won't create another library. There is also no point in doing
the engineering work for a merger if the merger has no chance of being
accepted by either side.
Besides, I'm just a poor Apache user whose app is using components
implementing six different portable run-times. I've given up on trying to
track down memory leaks and interactions so now I just reboot once a week.
I guess I need to give up on components and go back to the model of
monolithic apps using sockets to communicate.
Jon Smirl
jonsmirl@mediaone.net
Re: Mixing Apache and Mozilla
Posted by Brian Behlendorf <br...@collab.net>.
On Fri, 23 Feb 2001, Jon Smirl wrote:
> > > The other goal is the introduction of XPCOM into Apache.
> >
> > This doesn't require NSPR, does it?
>
> XPCOM is dependent on NSPR.
As a technology/API, I'd hope it isn't.
> What are the advantages to maintaining two libraries doing the same thing
> with slightly different APIs?
That doesn't sound to me like the NSPR/APR situation here.
Look, clearly you're motivated to see this happen. No one thinks that
such a thing is a bad idea, but *someone* has to step up to do more
serious work on this - *either* implementing the NSPR API on top of APR,
or the other way around, since clearly neither camp is going to give up
their API's. Another solution might be to port a significant NSPR-based
app, such as Mozilla, to use APR's current API, or the other way around.
Or, contributing whatever missing bits NSPR has that APR doesn't to APR,
as a proof of concept.
Instead, you're advocating that people join bandwagons and such, but not
providing much technical assistance in doing so. Those who are motivated
to work on APR are much more interested in getting it to work for httpd
2.0 and subversion than in scratching your itch, even if they agree,
"yeah, it's an itch".
Brian
Re: Mixing Apache and Mozilla
Posted by rb...@covalent.net.
> > 2. Incompatible threading libraries. This is not an issue
> > if native threads are used. Native threads are available
> > on the latest releases of almost all the operating systems
> > capable of running Apache.
>
> Again: valid point.
>
> I believe that APR cannot use anything *but* native threads. I recall a push
> for Pth compatibility somewhere along the line, for some codebase. I don't
> recall the specifics, though.
>
> In other words, APR is restricted to native threads, so an NSPR linked in
> with APR would also need to use native threads.
Actually, a _long_, _long_ time ago, I did use Pth with APR. It worked
just fine. I don't really remember everything that has changed since
then, but I'd bet that Pth would work with a little effort.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Mixing Apache and Mozilla
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 23, 2001 at 07:53:02PM -0800, Wan-Teh Chang wrote:
> There are obviously some misconceptions about NSPR which
> I have responded to in private email to avoid a flame war
> on this mailing list.
[ Thankfully, I think we're pretty immune to that here. new-httpd has a
larger subscription base, but even there, I've only seen a few "real"
flame wars in the past few years. Heated arguments, yes. Flame? Nope. ]
> It is also obvious to me that since
> both NSPR and APR have to support their current APIs, the
> only kind of "merger" that could happen is to implement one
> API on top of the other. That is an interesting exercise
> but does not need to be done now.
Agreed. Due to licensing sub/superset issues, my preferred approach is NSPR
on top of APR. The NSPR could then be released under its (current)
GPL/NPL/MPL license without a problem. (*)
If we did APR over NSPR, then APR would pick up add'l restrictions from the
MPL (we'd choose that one, being the least restrictive). The ASF community
would not be extremely receptive to that (for better or worse; that is not
the discussive point here)
(*) once our v1.2 license is completed sometime this year; 1.1 conflicts
with the GPL, although we could fix that for an NSPR/APR bundle.
> Until someone implements one API on top of the other, using
> NSPR and APR in the same process has only two problems that
> I don't think are serious for most Apache users.
> 1. Larger binary size. Disks and RAMs are only getting
> cheaper so a modest code bloat should not be a problem
> for a server box running Apache.
Or Subversion or ... APR has some other users now :-). But the point is
quite valid!
> 2. Incompatible threading libraries. This is not an issue
> if native threads are used. Native threads are available
> on the latest releases of almost all the operating systems
> capable of running Apache.
Again: valid point.
I believe that APR cannot use anything *but* native threads. I recall a push
for Pth compatibility somewhere along the line, for some codebase. I don't
recall the specifics, though.
In other words, APR is restricted to native threads, so an NSPR linked in
with APR would also need to use native threads.
> It would seem like a shame that Apache has to develop APR
> from scratch.
Past tense :-) "had" For all intents and purposes, APR is beta quality and
nearing a release. It is actually quite a bit more stable than the Apache
HTTPD Server.
> But writing new code is fun, and APR has the
> opportunity to learn from and avoid the mistakes and design
> flaws of NSPR.
That was one of the motivators, along with using the accumulated porting
knowledge of the Apache 1.3 code base.
> It is a shame that the MPL that NSPR is
> released under prevents the APR developers from using code
> in NSPR because a lot of knowledge and experience is embodied
> in the NSPR code base. Some of that didn't come easy, such
> as the undocumented (or rather not well documented) features
> that we use after confirming with the OS vendors that they
> will continue to be suppported, the bug workarounds that
> we put in after days of debugging and studying the "knowledge
> base" articles of the OS vendors, and the collective experience
> of the five Netscape engineers who developed NSPR.
Agreed on all points. However, the original motivation for APR (license-
wise) was because NSPR was under MPL 1.0 at the time. There was no way we
could touch it until it moved to the new MPL 1.1 license. That dragged on
for several months before our team said "screw it" and just started APR. We
had motivated people who were willing to invest the time in code
duplication. Not an ideal scenario, but required.
Today, it would be more about licensing philosophy, rather than a need to
avoid the MPL license.
> But I am
> sure that with this group of highly skilled and motivated
> developers and the support many OS vendors give to ASF, APR
> will be a fine product.
We think so :-). Thanks.
> One good point that Jon Smirl made, which was often overlooked
> in the heated discussion, is that there are a lot of Mozilla
> technologies based on NSPR, such as XPCOM, NSS, and LDAP SDK,
> that can be used in other products. As I pointed out above, on
> platforms with native threads, there is no technical problem
> using these NSPR-based technologies with APR. The only blocker
> would again be the MPL under which these open source technologies
> are released under.
The ASF is actually pretty fine with the MPL. But only for "third party"
libraries. While we may include a foreign codebase in our CVS tree, it would
only be present for convenience and redistribution. None of the
ASF-copyrighted code can/would fall under the MPL. Thus, the ASF cannot
assist in the continued development/maintenance of those projects. But we
certainly can use them!
Personally, I'd like to see XPCOM become available within the ASF code
space. I'd like to use it to development Apache components in Python.
> APR has the opportunity and potential to be better than NSPR.
> I'd love to see that happen. My best regards.
Potential.
We don't have NSPR's breadth at the moment. We also don't have the broad
exposure/usage. Those are certainly inhibitive factors (relatively
speaking).
We'll just have to see what happens :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Mixing Apache and Mozilla
Posted by Wan-Teh Chang <wt...@netscape.com>.
There are obviously some misconceptions about NSPR which
I have responded to in private email to avoid a flame war
on this mailing list. It is also obvious to me that since
both NSPR and APR have to support their current APIs, the
only kind of "merger" that could happen is to implement one
API on top of the other. That is an interesting exercise
but does not need to be done now.
Until someone implements one API on top of the other, using
NSPR and APR in the same process has only two problems that
I don't think are serious for most Apache users.
1. Larger binary size. Disks and RAMs are only getting
cheaper so a modest code bloat should not be a problem
for a server box running Apache.
2. Incompatible threading libraries. This is not an issue
if native threads are used. Native threads are available
on the latest releases of almost all the operating systems
capable of running Apache.
It would seem like a shame that Apache has to develop APR
from scratch. But writing new code is fun, and APR has the
opportunity to learn from and avoid the mistakes and design
flaws of NSPR. It is a shame that the MPL that NSPR is
released under prevents the APR developers from using code
in NSPR because a lot of knowledge and experience is embodied
in the NSPR code base. Some of that didn't come easy, such
as the undocumented (or rather not well documented) features
that we use after confirming with the OS vendors that they
will continue to be suppported, the bug workarounds that
we put in after days of debugging and studying the "knowledge
base" articles of the OS vendors, and the collective experience
of the five Netscape engineers who developed NSPR. But I am
sure that with this group of highly skilled and motivated
developers and the support many OS vendors give to ASF, APR
will be a fine product.
One good point that Jon Smirl made, which was often overlooked
in the heated discussion, is that there are a lot of Mozilla
technologies based on NSPR, such as XPCOM, NSS, and LDAP SDK,
that can be used in other products. As I pointed out above, on
platforms with native threads, there is no technical problem
using these NSPR-based technologies with APR. The only blocker
would again be the MPL under which these open source technologies
are released under.
APR has the opportunity and potential to be better than NSPR.
I'd love to see that happen. My best regards.
Wan-Teh
Re: Mixing Apache and Mozilla
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> The APR developers have already stated that we are willing to look at
> merging the two codebases. If the NSPR developers will say the same, then
> we can move forward. If you are asking us to just drop APR, we should
> stop discussing this, because I don't believe that is going to happen.
>
I agree.
Bill
Re: Mixing Apache and Mozilla
Posted by rb...@covalent.net.
> What are the advantages to maintaining two libraries doing the same thing
> with slightly different APIs? Portable run-times are a lot of work, NSPR is
> 68KB times the number of platforms it works on. Supporting a portable
> run-times is a permanent time sink, every time a new OS version is released
> the PR has to be tweaked. I'm sure a new round of tweaking will be needed
> for Windows XP.
>
> Are there technical objections to NSPR from the Apache side?
There are a couple of technical objections to moving to NSPR right now.
#1, we don't want to change Apache right now. We are getting close to a
release, and a major change like a new portable run-time is a lot of work.
#2, this is more than just Apache now. APR already has other users, just
dropping APR on the floor is no longer an option for us. This MUST be a
mutual shift towards each other. Dropping either project on the floor
just isn't going to happen. If NSPR doesn't want to move their APIs
towards APR, then we aren't going to be able to do this. That also
implies that APR would be moving their APIs towards NSPRs of course.
#3, there are features, like pools that NSPR just doesn't support. That
would need to be there before we could even think of merging the two APIs.
APR relies on pools for just about everything, because it gives us a lot
of nice features.
> If Apache will come on to the NSPR bandwagon my next target will be
> Xerces/Xalan. They're building yet another portable run-time.
Apache is not going to just move to NSPR. We are well beyond that point.
We were willing to use NSPR two years ago, but hit a brick wall with
regard to licenses. We set a date that we needed a license we could live
with, and Mozilla didn't give us one, so we started a new project. It is
unfortunate that after we started APR, a new license was created that we
could live with. By the time we had the new license, Apache had already
begun to port to APR however, and changing to NSPR was unlikely.
The APR developers have already stated that we are willing to look at
merging the two codebases. If the NSPR developers will say the same, then
we can move forward. If you are asking us to just drop APR, we should
stop discussing this, because I don't believe that is going to happen.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Mixing Apache and Mozilla
Posted by Jon Smirl <jo...@mediaone.net>.
> > The other goal is the introduction of XPCOM into Apache.
>
> This doesn't require NSPR, does it?
XPCOM is dependent on NSPR.
> I seem to recall that *one* of the reasons that it was argued to do our
> own runtime was that NSPR had a lot of functionality that simply wasn't
> needed by server-side software. I don't have any specifics to add to
> this, but so long as we're dealing at the 10K foot level, let it be said
> that sometimes specialization is a good thing.
Check out the docs for NSPR:
http://www.mozilla.org/projects/nspr/reference/html/index.html
My Windows NSPR DLL is a 68KB zip file.
---
What are the advantages to maintaining two libraries doing the same thing
with slightly different APIs? Portable run-times are a lot of work, NSPR is
68KB times the number of platforms it works on. Supporting a portable
run-times is a permanent time sink, every time a new OS version is released
the PR has to be tweaked. I'm sure a new round of tweaking will be needed
for Windows XP.
Are there technical objections to NSPR from the Apache side?
If Apache will come on to the NSPR bandwagon my next target will be
Xerces/Xalan. They're building yet another portable run-time.
Jon Smirl
jonsmirl@mediaone.net
Re: Mixing Apache and Mozilla
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 22 Feb 2001, Greg Stein wrote:
> 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).
That's good to know, and matches my expectation: the more "utility-like"
or baseline a particular library or application is, the simpler its
license really should be, to encourage wider-spread adoption.
On Fri, 23 Feb 2001, Jon Smirl wrote:
> I was hoping to avoid the creation of a new portable run-time, the APR being
> split out of Apache in the 2.0 project. This could be done by adding
> Apache's special requirements to the existing NSPR. It would also free
> Apache developers to work on other parts of Apache. There are a lot more
> programmers working on Mozilla (most at Netscape) than Apache.
I seem to recall that *one* of the reasons that it was argued to do our
own runtime was that NSPR had a lot of functionality that simply wasn't
needed by server-side software. I don't have any specifics to add to
this, but so long as we're dealing at the 10K foot level, let it be said
that sometimes specialization is a good thing.
> The other goal is the introducton of XPCOM into Apache.
This doesn't require NSPR, does it?
Brian
Re: Mixing Apache and Mozilla
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 23, 2001 at 01:35:25AM -0500, Jon Smirl wrote:
> > 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)
>
> The Mozilla people want to keep maintaining NSPR. There are several paid
> developers working on it and it is the core run-time for Mozilla and other
> products. It has been heavily tested and it is a mature product. A lot of
> thought and effort has been put into the design of NSPR over several years.
> NSPR also contains many features that are not available in APR. Wan-Teh can
> comment more on this since he owns NSPR.
All righty... fair enough. If both teams are able and willing to continue to
do maintenance, and both have hard requirements to maintain their APIs and
compatibility (at least for the medium term), then there isn't much to be
done.
Sure, somebody can take some time to build one API in terms of the other.
I've got no idea who/when that might happen. I think the long term situation
is certainly to build one API in terms of the other.
> I was hoping to avoid the creation of a new portable run-time, the APR being
> split out of Apache in the 2.0 project.
hehe... you're a bit too late. We started coding APR about two years ago.
It's already quite complete and stable. Besides being used in Apache, it is
also being actively used by Subversion and a few Covalent tools/apps.
> This could be done by adding
> Apache's special requirements to the existing NSPR. It would also free
> Apache developers to work on other parts of Apache. There are a lot more
> programmers working on Mozilla (most at Netscape) than Apache.
Unfortunately, a bit late for that. We're too far down the path to switch
Apache from APR to NSPR. We're trying to get a beta out, and revamping the
core library that the server is built upon won't help :-) That would easily
set us back another six months, and /none/ of us can swallow that. Many
people were hoping to ship 2.0 last year.
> The other goal is the introducton of XPCOM into Apache.
This should be possible to do, quite independently of the APR/NSPR issue.
> A simple example of a big piece of work that has already been done. Check
> out NSPR's documentation:
> http://www.mozilla.org/projects/nspr/reference/html/index.html
>
> Any APR experts care to comment on how the two stack up against each other?
NSPR has quite a bit more breadth than APR. Without spending a ton of time,
it would be hard to provide a critical evaluation of the two (i.e. doing a
compare and contrast between the two libraries).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Mixing Apache and Mozilla
Posted by Jon Smirl <jo...@mediaone.net>.
> 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)
The Mozilla people want to keep maintaining NSPR. There are several paid
developers working on it and it is the core run-time for Mozilla and other
products. It has been heavily tested and it is a mature product. A lot of
thought and effort has been put into the design of NSPR over several years.
NSPR also contains many features that are not available in APR. Wan-Teh can
comment more on this since he owns NSPR.
I was hoping to avoid the creation of a new portable run-time, the APR being
split out of Apache in the 2.0 project. This could be done by adding
Apache's special requirements to the existing NSPR. It would also free
Apache developers to work on other parts of Apache. There are a lot more
programmers working on Mozilla (most at Netscape) than Apache.
The other goal is the introducton of XPCOM into Apache.
A simple example of a big piece of work that has already been done. Check
out NSPR's documentation:
http://www.mozilla.org/projects/nspr/reference/html/index.html
Any APR experts care to comment on how the two stack up against each other?
Jon Smirl
jonsmirl@mediaone.net
Re: Mixing Apache and Mozilla
Posted by Greg Stein <gs...@lyra.org>.
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/
Re: Mixing Apache and Mozilla
Posted by Brian Behlendorf <br...@collab.net>.
There are two difference scenarios to consider here:
a) a module that links APR, or Apache, with some part of an MPL-licensed
codebase, for some (optional) advantage, such as being able to build
XPCOM-based modules. This module can be released under the Apache
license, since the MPL is non-viral, and thus checked into an Apache.org
code tree. However, the MPL code itself wouldn't be checked into the
repository (and wouldn't need to be).
b) integrating MPL code into the APR (or httpd, or other Apache project)
codebase. Any code integrated into an Apache project must be assigned to
the ASF by its developers, who certify that they have all the rights to
make such an assignment. Third-party code may be brought in if it places
no restrictions on redistribution over and above the Apache license, so
that the aggregate license on any package can remain the Apache license.
It's not "religion" to state that the ASF's mission is to build
reference-standard-implementing, widely-usable software, and that the
Apache license, mostly by virtue of its simplicity, has been critical to
that goal. Our viewpoint has been that you get the software into as many
hands and products as possible by placing as few requirements as possible,
and then rely that some nontrivial percentage of those developers will see
the wisdom of contributing back.
The MPL is not a bad license, but if only by sheer complexity, it would
hamper this goal of the ASF's, and the Mozilla license authors would
readily agree. As I've said to Mitchell several times, the MPL simply
goes much further than a copyright license should - for example, it talks
a lot about requirements on contributions (such as the patent clause), but
that really should be a function of a separate contributor's agreement,
not the copyright (which is where we deal with patent issues). The same
principle of simplicity applies to both software and licenses - "the
design is complete when you can take nothing more away". Unfortunately,
that is not how lawyers like to think.
On Thu, 22 Feb 2001, Jon Smirl wrote:
> NSPR and XPCOM are already released under GPL, NPL and MPL with terms that
> you can pick the one you want. I doubt that the Mozilla lawyers are going
> to deal with also releasing it under the Apache license until there is real
> chance that it will be adopted.
Note that all the Mozilla lawyers need to do is relicense it under the
Apache license; all the other licenses are supersets, though strictly
speaking the LGPL and GPL are not, since they can't allow the
trademark-based clauses in the Apache license. But that's beside the
point - if there really is interest in combining the NSPR and APR runtimes
into a unified package, then all we need to do is have the appropriate
parties from Mozilla interested in porting their stuff over commit privs
and get them to sign the contributor agreements, and then it's up to them
to get the right to contribute their patches from Mozilla. No wholesale
relicensing of NSPR needed.
Brian
Re: Mixing Apache and Mozilla
Posted by rb...@covalent.net.
On Thu, 22 Feb 2001, Wan-Teh Chang wrote:
> rbb@covalent.net wrote:
> >
> > Jon, please understand that this isn't religion over license issues.
> > Unfortunately, licenses are a matter of law, not opinion. There are
> > people in this group who work for businesses that rely on the Apache
> > license. When I worked for IBM (a little over a year ago, so things may
> > have changed), IBM had a problem with some of the NPL or MPL (I can't
> > remember which). There are IBMers here who are very big contributors.
> > Moving to NSPR might mean that those contributors could no longer
> > contribute back. That is a bad thing IMHO.
>
> That issue must have been resolved because the Mozilla client,
> NSPR, and NSS have all received contributions from IBMers, mostly
> OS/2 porting patches.
>
> For example, see the IBM copyright notice in this NSPR source file:
> http://lxr.mozilla.org/nspr/source/nsprpub/pr/src/md/os2/os2io.c.
That solves IBM, which is the example I gave, but it doesn't cover
everybody. I am really not trying to be difficult, but we do need to be
sure that everybody involved in APR doesn't have a problem with the NPL or
MPL. I know I will need to check with my boss over this, and we need to
check with the ASF, to ensure that we can actually distribute MPL or NPL
licenses code with Apache.
As I said last night, before we spend time on the licenses, can we
actually investigate what exactly we are trying to accomplish together?
How do we want to merge these two codebases? I don't believe anybody is
interested in dropping either codebase, so it will need to be a merger.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Mixing Apache and Mozilla
Posted by Wan-Teh Chang <wt...@netscape.com>.
rbb@covalent.net wrote:
>
> Jon, please understand that this isn't religion over license issues.
> Unfortunately, licenses are a matter of law, not opinion. There are
> people in this group who work for businesses that rely on the Apache
> license. When I worked for IBM (a little over a year ago, so things may
> have changed), IBM had a problem with some of the NPL or MPL (I can't
> remember which). There are IBMers here who are very big contributors.
> Moving to NSPR might mean that those contributors could no longer
> contribute back. That is a bad thing IMHO.
That issue must have been resolved because the Mozilla client,
NSPR, and NSS have all received contributions from IBMers, mostly
OS/2 porting patches.
For example, see the IBM copyright notice in this NSPR source file:
http://lxr.mozilla.org/nspr/source/nsprpub/pr/src/md/os2/os2io.c.
Wan-Teh
Re: Mixing Apache and Mozilla
Posted by Jon Smirl <jo...@mediaone.net>.
IBM is happy with the MPL 1.1 license and is a regular contributor to the
Mozilla project. IBM employees regularly work on the OS/2 version of
Mozilla. I believe IBM's issues were the main reason for the change from MPL
1.0 to 1.1.
Jon Smirl
jonsmirl@mediaone.net
Re: Mixing Apache and Mozilla
Posted by rb...@covalent.net.
On Thu, 22 Feb 2001, Jon Smirl wrote:
> From: <rb...@covalent.net>
> > There is a problem with ignoring the license issues, the license issues
> > are a real issue for a lot of people on this list.
>
> NSPR and XPCOM are already released under GPL, NPL and MPL with terms that
> you can pick the one you want. I doubt that the Mozilla lawyers are going
> to deal with also releasing it under the Apache license until there is real
> chance that it will be adopted. After rereading MPL and the Apache license I
> can't even see a significant difference expect that MPL stops people from
> contributing code containing submarine patents (like Unisys and GIF).
>
> 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.
Jon, please understand that this isn't religion over license issues.
Unfortunately, licenses are a matter of law, not opinion. There are
people in this group who work for businesses that rely on the Apache
license. When I worked for IBM (a little over a year ago, so things may
have changed), IBM had a problem with some of the NPL or MPL (I can't
remember which). There are IBMers here who are very big contributors.
Moving to NSPR might mean that those contributors could no longer
contribute back. That is a bad thing IMHO.
I would really like one of the people who really understands the licensing
issues to speak up here. I know Bill Stoddard has expressed concern in
the past. I also know, and this is not meant to give offense, that Bill
can be a bit paranoid when it comes to licenses. That is a part of his
job, and he is very good at it. If we can convince all of the APR
contributors that the NPL or MPL are okay to use, then we can move forward
regardless of the licensing issues. However, the rest of the message
still must be dealt with.
This won't be fast to happen. I personally will be -1 for moving Apache
over to NSPR at this point. We have done too much to get it to APR, and
making that change will delay the release far too much IMHO.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Mixing Apache and Mozilla
Posted by Jon Smirl <jo...@mediaone.net>.
From: <rb...@covalent.net>
> There is a problem with ignoring the license issues, the license issues
> are a real issue for a lot of people on this list.
NSPR and XPCOM are already released under GPL, NPL and MPL with terms that
you can pick the one you want. I doubt that the Mozilla lawyers are going
to deal with also releasing it under the Apache license until there is real
chance that it will be adopted. After rereading MPL and the Apache license I
can't even see a significant difference expect that MPL stops people from
contributing code containing submarine patents (like Unisys and GIF).
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.
Jon Smirl
jonsmirl@mediaone.net