Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 22 Feb 2001 10:38:02 -0800 (PST)
From: Brian Behlendorf <brian@collab.net>
To: Jon Smirl <jonsmirl@mediaone.net>
cc: <dev@apr.apache.org>
Subject: Re: Mixing Apache and Mozilla
In-Reply-To: <002201c09cf0$fdce1740$0215a8c0@ne.mediaone.net>
Message-ID: <Pine.BSF.4.31.0102221024430.56176-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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