(some parts snipped - just trying to bring this to a solution suggestion)
But I don't like this, of course. It wasn't our intention to fork, we just ended up using a fork written by a Cocoon committer outside the Cocoon project.
Forks are bad business, usually, unless one-way and finite lifetime, in my opinion. Here, there is a chance to reunify. I'm all for that, if people are willing to spend the extra effort.
Speaking for myself as in IANAL-and-could-never-play-one, I find bi/tri/quad licensing even more confusing - in terms of practical usage. But that's what happened with Rhino upsofar, I presume, so I guess I'll have to dive in and learn about it. ;-)
Mozilla favors its kind of copyleft, but not the GPL's. We have tri-licensed under MPL/LGPL/GPL terms only in order to prevent duplication of effort in the GPL'd world, where tainting and other terms of the GPL mean that MPL'd code can't be mixed. We tri-licensed under .../LGPL/GPL because LGPL is not compatible with GPL: although you can use LGPL'd code as it if were GPL'd, you can't do the reverse, and many embeddings of Gecko are LGPL'd for good reason (_pace_ rms), not GPL'd.
We also can host code more permissively licensed, under MIT-X or BSD-modern (or ASL, I suppose -- but I haven't read the ASL yet! Sorry, Brian) terms, but we do so only to fill in gaps in build and target host environment libraries. We don't want our primary source so permissively licensed. We value give-back for our primary source, but file-wise (MPL) give-back, not whole-program-tainting (GPL) give-back, which scares away too many companies that use Mozilla code in combination with closed source.
Thanks for all the clarifications, Brendan - truly appreciated.
It looks like this case brings a whole lot of ramifications to the table, and quite a lot of them would depend on forthcoming ASF board policy w.r.t. requirements for licenses of libraries shipped with ASF projects. Ideally, a CPAN-like approach will shift the burden of license compliance a bit to the end-user, although I'm afraid that this still won't quite address the redistribution issue when people go and shrink-wrap an ASF project into a proprietary product, and expect the same liberal license conditions to be applicable as they are used to with the Apache license (no warranty implied, credits required and don't abuse the ASF brand).
My two main concerns ATM is that (a) such a CPAN infrastructure will take some time to materialize (although this exact event might trigger some progress and add weight to the importance of actually going down that path), and that (b) for the particular case of our Rhino fork, it will also take time before a volunteer is found which actually brings our changes back into sync with the Mozilla trunk version.
I'd like to repeat that there has never been any intention to bring the fork to the ASF as a standalone project, without consent and a joint effort being established between us and the Mozilla team to eventually end up with a proper merger and donation of the project as a whole to the ASF. Since you explained that Mozilla isn't likely to go down that path any time soon (and this remains a strictly theoretical exercise anyhow if the Rhino community isn't interested in this move), IMHO this situation calls for a pragmatical solution with hope and ambitions for a definitive one in the future.
Anyway... I must now appeal to a good deal of goodwill from Mozilla's side on this matter. Apache Cocoon is an active open source project, with a fairly large group of committers and a much larger group of users, and has been in development for several years now. While clearly we passed the borderline of legality with the adoption of Chris' Rhino fork, it was with the best intentions and not with the idea to "not give back" to the Mozilla community. It was an act of convenience, and ultimately also an appreciation of the fine work of the Rhino developers - embedding the continuations stuff into Rhino was a convenience act since we had no ambitions to venture into the world of language interpreters - this isn't part of our mission. Still, we need those continuations, and need them badly. I'm confident that over time, more people will learn about continuations and might eventually make the leap and join the development team of Rhino - yet up until now it's just Chris who sits on the frontier between Cocoon and Rhino. But that might change if we get to explore continuations (as a user) in the coming months and years.
From all the discussions of the last few days, I now think there's a pragmatical solution for our problem - i.e. a AL-compatible (quad-)licensing of the Rhino codebase, like the AL 2.0 or some MIT/X/BSD variant. If Mozilla is able to provide us with such a license, I'm confident we can escape from this jeopardous situation, which has transformed the distribution of Cocoon into an illegal act. From there on, we can fork, retain license and copyright (as we should) for the non-modified files to where they belong, and publish our modifications, outside the Apache project, as a Rhino fork, on cocoondev.org - which has no ties with the ASF. At the very least, we could then be confident that we are still able to ship Cocoon with the forked Rhino library.
That would already solve the most acute problems right now and might eventually attract possible other Rhino developers who might partake with the work of remerging continuations back into the Rhino project. While I would understand it if you would react with a "lazy butts - better start doing that right away", I can only say that I can't promise that (a) this can get done in an timeframe which wouldn't jeopardize Cocoon's near future, and (b) from what I see right now, it isn't unlikely that future policy requirements from the ASF board will dictate us to move away from inclusion of any non-AL-licensed library into Cocoon anyway, and the CPAN-like infrastructure which would facilitate us to do so is still much in its design phase, let alone in active development.
I know this isn't the ideal solution, but I'm afraid that, unless Chris volunteers for the reintegration work and does so in short time (which no-one can expect from him since this is volunteer work anyhow), there's very limited chance that the Cocoon community can come up with patches for reintegration: no language interpreter gurus over here. Besides, even if we would be able to come up with that, we would still have problems to package the Rhino library with Cocoon, since its distributions terms are ATM a bit narrower than the AL ones. By broadening up the licensing terms of Rhino, we could confidently proceed with a legal adjustment of all this, and hopefully in the end entice people to take a better look at what Rhino has to offer - something which, if not based on code donations right now, surely will be good for Rhino's future.
It is not our intention to market our fork as a separate product or to dilute Rhino's brand, and we will hastily refer people interested in a Java JavaScript interpreter towards the official version.
Thanks for your time and consideration.
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
