cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: Cocoon's Rhino+continuations fork
Date Tue, 09 Mar 2004 18:38:16 GMT

This message is cc'd to the PMC for the Cocoon project, as there are
specific instructions below that I feel the PMC needs to be aware of,
regarding removing Rhino from the ASF repository.  I've also cc'd the XML
PMC, as a search on reveals that Batik is also using Rhino, and
that must also be discontinued.

On Mon, 8 Mar 2004, Steven Noels wrote:
> This is troubled partly by the license status of Rhino itself. Upon
> personal investigation a while ago, I found some source files which
> where licensed using the NPL1.1
> (
> javascript/, while others used the newer MPL1.1
> (
> javascript/ I think it is safe to state that the
> intended overall license of Rhino was the tri-license combo MPL 1.1/GPL
> 2.0/LGPL 2.1 - which seems to be OK for redistribution as a library
> with an ASF project according to the unofficial ASF license FAQ @

No.  No no no.  You may not relicense MPL or NPL software under the Apache
license, whether 1.1 or 2.0, unless you (or the collective-you) are the
copyright holders.  The MPL and NPL place requirements on redistributed
works that are not completely satisfied by the Apache license.  When one
picks up any Apache software, and we tell them "it's under the Apache
license", we mean that license to apply to the *whole* of the software; it
is not acceptable for there to be a part of that code that places greater
requirements or restrictions than the Apache license.  Thus, even though
the MPL is not a "viral" license, when combined with other software the
net license on the whole work must be the aggregate of the terms of the
individual licenses.

The Wiki is not an officially maintained document; I see more
misconceptions and questions on that page than I have the time to even
start to address right now.  If it says anywhere that Apache projects may
incorporate MPL or NPL licensed code into an Apache CVS tree, please
remove that statement.

If you are using any code that originated from Mozilla or from other
developers not associated with the ASF (or ASF developers not making a
contribution of their work to the ASF specifically) then Cocoon as a whole
can not be licensed under the Apache license.  Sorry.  If Cocoon is today
being distributed in such a manner, it must be removed from Apache's
distribution directory until the licensing issue can be resolved. You may
petition the board for an exemption from the standard licensing for Apache
software, but you'll have to explain to them how it got to this state and
how it'll be fixed.

> But we don't distribute the original Rhino version with Cocoon, we use
> the one hosted at instead
> ( So first
> of all, we need to find out whether this fork can be effectively
> licensed under an ASL2.0 compatible license (preferably the ASL license
> itself). For that, it needs a copyright holder, which doesn't exist
> ATM.

Not correct.  There is always a holder of the copyright.  In the case
where there are multiple holders, like this (Mozilla for the original
Rhino, and whomever has touched it on '') then all holders
must agree to a relicensing.  This is why the ASF requires developers to
give us the right to relicense, to make management of these kinds of
things a whole lot easier.

As it stands right now, the Cocoon developers must remove any software
from the ASF's CVS tree that has a MPL or NPL license, or any derivative
work of such software.  We're not being Nazis here - it's simply not
technically correct nor moral or ethical to be redistributing someone
else's work under a more permissive license than the author allows.

Once that is done, there are a couple of options.

First, assuming no relicensing by the Mozilla organization of Rhino, the
Cocoon developers can:

a) Work with the Mozilla community on integration of continuations and
other patches into the actively-maintained Rhino project on
Then, figure out a way for Cocoon to link to Rhino at runtime, since Rhino
may not be distributed as part of the Cocoon package.

b) If there is simply a disagreement in technical direction, and the
Mozilla Rhino developers do not want to implement continuations, then you
may of course fork Rhino - but not as an Apache project.  Do whatever
you'd like on cocoondev or sourceforge or whatever, but the license on
your derivative work must conform to the requirements of the MPL.  And
again, it could not be integrated into Cocoon directly or checked into an CVS tree - it must be distributed separately and linked at

On the other hand, if Mozilla *is* willing to consider adding either the
Apache license as another license, or relicensing Rhino entirely under the
MIT/X license (which would be compatible with nearly all licenses), *then*
in the scenarios above, Rhino may be incorporated directly into Cocoon,
and a "fork" could be hosted at  I would strongly suggest that
collaboration around Rhino continue at, in any event, since
the Mozilla developers do appear willing to look at continuations and open
to participation by others.


View raw message