Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Mime-Version: 1.0 (Apple Message framework v612)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A7472D68-7153-11D8-9A40-000A958B684A@outerthought.org>
Content-Transfer-Encoding: 7bit
Cc: brian@collab.net
From: Steven Noels <stevenn@outerthought.org>
Subject: Cocoon's Rhino+continuations fork
Date: Mon, 8 Mar 2004 23:55:11 +0100
To: dev@cocoon.apache.org, mozilla-jseng@mozilla.org

(partly in reply to  
http://thread.gmane.org/gmane.comp.mozilla.devel.jseng/3038)

Dear all, more specifically Rhino devs,

the issue with Cocoon's Rhino fork seems to be appearing with  
increasing rate on both the Rhino and Cocoon mailing lists. While the  
discussion underneath remains strictly theoretical unless someone kicks  
in and starts fixing things, I'd like to iterate over a couple of  
thoughts and scenarios, if only as a means to start some common thread,  
maybe even consensus, and to better understand where we stand at ATM. I  
work with the ASF Cocoon project (ASF = Apache Software Foundation).

Cocoon has been investigating the use of continuations as a novel  
approach to web application development quite a while before the  
Rhino+cont fork. It were mainly Ovidiu Predescu and later on Chris  
Oliver who started this exploration, first using a Java-based Scheme  
interpreter, and then by refactoring Rhino in order to add  
continuations support to the interpreter core - this work was done by  
Chris.

Much of this work was done (undeliberately, as the Cocoon community  
needed some time to actually buy the concept) a bit under the radar of  
the Cocoon community, so it took us some time to fully realize that  
Chris' Rhino fork now sits firmly in the core of Cocoon, and that the  
fork situation is less optimal than it should be - most importantly  
from a legal and community perspective.

First of all, there's a legal aspect. While forking is an unevitable  
aspect of open source development, we do need to investigate whether it  
is legal at all to fork and (re)license Rhino+cont under an ASL2.0  
compatible license, in order to ship it with Cocoon.

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  
(http://lxr.mozilla.org/mozilla/source/js/rhino/src/org/mozilla/ 
javascript/Context.java), while others used the newer MPL1.1  
(http://lxr.mozilla.org/mozilla/source/js/rhino/src/org/mozilla/ 
javascript/ClassCache.java). 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 @  
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing

IMHO, it would be nice if the license status of Rhino is cleared out by  
adding the correct license headers to the source files.

But we don't distribute the original Rhino version with Cocoon, we use  
the one hosted at cocoondev.org instead  
(http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/?cvsroot=rhino). 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. One could think Chris is the logical choice as the copyright  
holder, but this might be preposterous: he indeed adapted the code,  
adding some good continuations juice to it, but didn't change the  
license headers. From what I understand from the email archives, he did  
had the intention to eventually merge stuff back into the official  
Rhino trunk, but found no time to do so in due time, and eventually was  
confronted with the situation that merging changes back in became much  
harder than a simple "cvs merge" effort. So the cocoondev.org  
Rhino+cont fork was born, without copyright holder and license, and  
coincidentally became a valuable core component of Cocoon.

Simply put, the clarification of the license status of Rhino would  
already learn us how to properly and legally fork Rhino for Cocoon's  
purposes. Alas, forking and changing package names seems to be the only  
easy way to move forward to address some urgent technical issues ATM:  
when running Cocoon inside the WebLogic container, which ships with the  
official Rhino library, our stuff clashes due to identical package  
names. But before blessing this fork by changing package names, we need  
to find out whether forking and relicensing Rhino under an ASL  
compatible license can be done at all (besides the copyright holder  
stuff, which we eventually might sort out on our own).

On the community perspective, it feels awkward to see a core feature of  
Cocoon depend on a single-person effort, as much as we appreciate the  
work of Chris. Upsofar, not many people joined him in his work, partly  
because the interest of most Cocoon developers lies in the web  
application framework spectrum rather than in language interpreters.  
I'm sure this situation is greatly different in the Rhino community.  
Also, we cannot simply put Chris' fork into Cocoon CVS since the  
development of language interpreters are not part of our mission. The  
use of continuations for webapp development however is becoming a core  
part of our operations, and Rhino seems to be an ideal fit for that  
ATM. Hence we forked and stored the result outside Cocoon CVS - on a  
"friendly platform" however (cocoondev.org).

Of course, forking is a suboptimal situation, and I've been talking  
with various people about other possible scenarios. None of these  
scenarios however solved the merge problem, yet I'd like to put one up  
here as some food for thought.

Without being a Mozilla Rhino intimate, I think it's safe to state that  
Rhino could earn a lot from migrating from Mozilla to the ASF - perhaps  
as a Jakarta project. It would be living in a pool of quite a few nice  
Java projects, and I'm pretty sure it might attract a lot of interest  
and grow its developer base that way. One way of doing this could be by  
starting from the codebase of Chris' fork, which contains Cocoon's  
precious continuations. While merging our continuations with the Rhino  
trunk seems to be a painful process, I understand that the level of  
backporting from the trunk required to bring his version back in line  
with current Rhino evolutions might not be that hard  
(http://article.gmane.org/gmane.comp.mozilla.devel.jseng/3052 seems to  
suggest this). I'm not in the position to confirm this, so I'd like to  
hear the trunk developer's opinion about this.

Summarizing, we're seeking some clarification about the current license  
status of Rhino for our fork, and I hope I've sketched a clear picture  
about what lead us so far. We're not happy with it, yet we depend on  
Chris' valuable work, and we want to preserve it somehow. There's the  
idea about joining the ASF as well, but that won't reduce the merging  
effort ahead of us. In that respect, I'm interested to find out whether  
backporting trunk changes to our fork wouldn't be easier than merging  
the continuations stuff, keeping the same set of functionalities.

I'd love to hear your comments!

Cheers,

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org