cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: Cocoon's Rhino+continuations fork
Date Thu, 11 Mar 2004 13:23:44 GMT
On 09 Mar 2004, at 22:48, Brendan Eich wrote:

(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


Mime
View raw message