You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2004/03/08 23:55:11 UTC
Cocoon's Rhino+continuations fork
(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
Re: Cocoon's Rhino+continuations fork
Posted by Stefano Mazzocchi <st...@apache.org>.
Hey Paul, welcome back! :-)
Paul Russell wrote:
> On 10 Mar 2004, at 19:51, Steven Noels wrote:
>
>> (OT for the non-ASF folks:) You seem to suggest that inclusion of
>> non-ASL-licensed library dependencies inside ASF distributions should
>> be deprecated, favoring a CPAN or FreeBSD ports -like mechanism
>> instead. This will definitely lower the ease of use for end-users,
>> which have been complaining already that we don't ship a binary
>> distribution of Cocoon, let alone that we would ship a download which
>> requires them to either hunt down additional packages themselves, or
>> have an internet connection when installing Cocoon.
>
>
> ... which brings me around to something I've been pondering for a while.
> Since Cocoon is a bit of a 'hub' in the open source world, it brings
> together a stack of external libraries. Including these in the core
> source distribution is clunky and painful for everyone. Have we
> considered using Maven or similar to help manage these dependancies? I'm
> still playing catch up with the architectural changes within cocoon
> (this is still very much a part time job for me right now), so I don't
> know how this would tie up with Blocks. I do know however that the
> Geronimo project uses Maven to great effect, and they do separate
> modules with their own code trees etc, so this may be a prior art.
>
> Thoughts?
Search the wiki and for "blocks" and read that first :-)
--
Stefano.
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Torsten Curdt <tc...@vafer.org>.
> Yep. And we should also think about the users of our users: can they be
> expected to go through the same download-on-demand scenario before even
> taking a quick look whether Cocoon fits their bill?
Is it really much more complicated to download?
It does not have to be always on demand...
Let's assume we distribute
cocoon-2.whatever-src.tgz
without any external jars and we have a
repository with each individual jar.
rhino.jar
itext.jar
jetty.jar
....
If we could (are alound) to provide an archiv
for convenience,
cocoon-2.whatever-dependencies.tgz
We'd only have *two* instead of one downloads.
After the download you have all dependencies
on disk. The download-on-demand system should
utilize the archiv and no further downloads-on-demand
are necessary since everything is already there.
IMO this should not make much of a difference
for anyone who wants to try Cocoon.
--
Torsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Posted by Steven Noels <st...@outerthought.org>.
On 12 Mar 2004, at 09:05, Ugo Cei wrote:
> Reinhard Pötz wrote:
>> And instead of investing to much time in all those things we should
>> make CocoonBlocks become reality ASAP because they will solve those
>> dependencies very elgantly.
>
> I'd say *most* of those dependencies, but not all of them. Flowscript
> is part of the core, for instance.
Yep. And we should also think about the users of our users: can they be
expected to go through the same download-on-demand scenario before even
taking a quick look whether Cocoon fits their bill?
</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
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Reinhard Pötz <re...@apache.org>.
Carsten Ziegeler wrote:
>Reinhard Pötz wrote:
>
>
>>And instead of investing to much time in all those things
>>we should
>>make CocoonBlocks become reality ASAP because they will
>>solve those
>>dependencies very elgantly.
>>
>>
>
>Yes, but imho we need a solution for 2.1.x as well. If we would
>wait for blocks we could not do another 2.1.x release.
>
>
Good point. Let's wait on the results of the current discussions and
then we can decide.
--
Reinhard
RE: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Pötz wrote:
>
> And instead of investing to much time in all those things
> we should
> make CocoonBlocks become reality ASAP because they will
> solve those
> dependencies very elgantly.
Yes, but imho we need a solution for 2.1.x as well. If we would
wait for blocks we could not do another 2.1.x release.
Carsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Reinhard Pötz <re...@apache.org>.
Ugo Cei wrote:
> Reinhard Pötz wrote:
>
>> And instead of investing to much time in all those things we should
>> make CocoonBlocks become reality ASAP because they will solve those
>> dependencies very elgantly.
>
>
> I'd say *most* of those dependencies, but not all of them. Flowscript
> is part of the core, for instance.
>
> Ugo
>
>
Yes, that true. But we have also also thought about modularizing Cocoon
core (see Cocoon modules) - e.g. different environements - and if
*licences* makes it necessary we can also have a flowscript module.
--
Reinhard
Re: Using Maven (or something similar) for dependencies?
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Reinhard Pötz wrote:
>
>> And instead of investing to much time in all those things we should
>> make CocoonBlocks become reality ASAP because they will solve those
>> dependencies very elgantly.
>
>
> I'd say *most* of those dependencies, but not all of them. Flowscript is
> part of the core, for instance.
very true, real block are not enough.
We need two systems: a higher level one (real blocks) and a lower level
one (jars).
There are two ways of doing a package distributor:
1) package it yourself [rpm,deb,war]
2) provide metadata and tools [port,gentoo]
I came to the conclusion (also after working with gump for a while) that
2) is the way to go. [thanks to Pier for opening my eyes on this!]
but the painful thing is that not all jars are distributable standalone
for legal reasons.
--
Stefano.
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Ugo Cei <u....@cbim.it>.
Reinhard Pötz wrote:
> And instead of investing to much time in all those things we should make
> CocoonBlocks become reality ASAP because they will solve those
> dependencies very elgantly.
I'd say *most* of those dependencies, but not all of them. Flowscript is
part of the core, for instance.
Ugo
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Reinhard Pötz <re...@apache.org>.
Bertrand Delacretaz wrote:
> Le Jeudi, 11 mars 2004, à 23:06 Europe/Zurich, Paul Russell a écrit :
>
>> On 10 Mar 2004, at 19:51, Steven Noels wrote:
>>
>>> (OT for the non-ASF folks:) You seem to suggest that inclusion of
>>> non-ASL-licensed library dependencies inside ASF distributions
>>> should be deprecated, favoring a CPAN or FreeBSD ports -like
>>> mechanism instead. This will definitely lower the ease of use for
>>> end-users, which have been complaining already that we don't ship a
>>> binary distribution of Cocoon, let alone that we would ship a
>>> download which requires them to either hunt down additional packages
>>> themselves, or have an internet connection when installing Cocoon.
>>
>>
>> ... which brings me around to something I've been pondering for a
>> while. Since Cocoon is a bit of a 'hub' in the open source world, it
>> brings together a stack of external libraries. Including these in the
>> core source distribution is clunky and painful for everyone. Have we
>> considered using Maven or similar to help manage these dependancies?
>> ....
>
>
> Sounds like the way to go, intelligently downloading dependencies from
> some non-ASF repository should solve most, maybe all of the licensing
> problems, and help make Cocoon more lightweight for many uses.
>
> IIRC last time this was discussed the debate quickly moved to a heated
> discussion on the relative merits of Maven and other similar tools -
> if we're going to discuss this again, we must be careful to focus on
> the goals rather than on the tools!
>
> -Bertrand
>
Yep, the discussion is not Maven yes or not but do we want to distribute
Cocoon as a complete package or not. I would prefer having a complete
distribution (as long as it is possible from a legal POV) because it
*is* easier for our users.
And instead of investing to much time in all those things we should make
CocoonBlocks become reality ASAP because they will solve those
dependencies very elgantly.
--
Reinhard
RE: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Pötz wrote:
>
> Stephan Michels wrote:
>
> >Am Fr, den 12.03.2004 schrieb Bertrand Delacretaz um 07:47:
> >
> >
> >>Sounds like the way to go, intelligently downloading
> dependencies from
> >>some non-ASF repository should solve most, maybe all of the
> licensing
> >>problems, and help make Cocoon more lightweight for many uses.
> >>
> >>IIRC last time this was discussed the debate quickly moved
> to a heated
> >>discussion on the relative merits of Maven and other
> similar tools -
> >>if we're going to discuss this again, we must be careful to
> focus on
> >>the goals rather than on the tools!
> >>
> >>
> >
> >You don't need to migrate to maven to have the automatic download
> >mechanism, see Ruper(http://krysalis.org/ruper/). Should be easy to
> >integrate into the existing build system. I think this is the way to
> >go.
> >
> >
> Or maybe Ant-get is enough
> (http://ant.apache.org/manual/CoreTasks/get.html)
>
We have to fetch only those jars that aren't allowed in our CVS.
I think the first step should be to list those jars and then we
can see what we can do with each of them. And downloading them
during the build should be imho the last option.
So, do we have a list?
Carsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Reinhard Pötz <re...@apache.org>.
Stephan Michels wrote:
>Am Fr, den 12.03.2004 schrieb Bertrand Delacretaz um 07:47:
>
>
>>Sounds like the way to go, intelligently downloading dependencies from
>>some non-ASF repository should solve most, maybe all of the licensing
>>problems, and help make Cocoon more lightweight for many uses.
>>
>>IIRC last time this was discussed the debate quickly moved to a heated
>>discussion on the relative merits of Maven and other similar tools - if
>>we're going to discuss this again, we must be careful to focus on the
>>goals rather than on the tools!
>>
>>
>
>You don't need to migrate to maven to have the automatic download
>mechanism, see Ruper(http://krysalis.org/ruper/). Should be easy to
>integrate into the existing build system. I think this
>is the way to go.
>
>
Or maybe Ant-get is enough (http://ant.apache.org/manual/CoreTasks/get.html)
--
Reinhard
Re: Using Maven (or something similar) for dependencies? (Was:
Cocoon's Rhino+continuations fork)
Posted by Stephan Michels <st...@apache.org>.
Am Fr, den 12.03.2004 schrieb Bertrand Delacretaz um 07:47:
>
> Sounds like the way to go, intelligently downloading dependencies from
> some non-ASF repository should solve most, maybe all of the licensing
> problems, and help make Cocoon more lightweight for many uses.
>
> IIRC last time this was discussed the debate quickly moved to a heated
> discussion on the relative merits of Maven and other similar tools - if
> we're going to discuss this again, we must be careful to focus on the
> goals rather than on the tools!
You don't need to migrate to maven to have the automatic download
mechanism, see Ruper(http://krysalis.org/ruper/). Should be easy to
integrate into the existing build system. I think this
is the way to go.
Stephan.
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Stefano Mazzocchi <st...@apache.org>.
Geoff Howard wrote:
> Yes, that's the point indeed. ASL is supposed to be a business-friendly
> license. If Cocoon uses distribution-time tricks to technically comply
> with the ASL but in the process nullifies its intent for some users, we
> have failed IMO.
Geoff, we already comply with the license.
It's just that Brian is afraid that the ASF can be sued back for
"unfaithfull labelling" if some of our users is sued because they tought
that "everything" was simply under the ASF license.
I personally think that if there is a problem of "unfaithfull labeling"
we just have to clarify the label, not stop selling the product entirely!
but I'm not who decides these things and I'm not lawyer.
--
Stefano.
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Torsten Curdt <tc...@vafer.org>.
> Is a company using Cocoon to deliver web applications redistributing
> Cocoon? (yes, I think).
That's the question! I'd say no ...as long as you
don't bundle it and sell it as part of you software
removing the license or the like.
But AFAIU you may use those (for us) problematic
jars in your project. But hell - I am no lawyer.
> Then from what I can tell, a good portion of
> even our own committers, not to mention people on the users list would
> have a problem.
Of course that would give a different picture.
>> If it's really a problem for the ones distributing is still
>> the question anyway (I doubt it) But this way it's not the
>> ASF that would have to take the responsibility for that.
>>
>> I guess that's the point
>
> Yes, that's the point indeed. ASL is supposed to be a business-friendly
> license. If Cocoon uses distribution-time tricks to technically comply
> with the ASL but in the process nullifies its intent for some users, we
> have failed IMO.
Sure I hear what you are saying ...but
may those users use the jars for their
projects if they were downloading them
by theirselves?
If yes - this is only a trick to circumvent
the redistribution clause. If not - they
may not use them anyway. And hiding this behind
the ASL doesn't make it any better.
Especially for the ASF!
cheers
--
Torsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Geoff Howard <co...@leverageweb.com>.
Torsten Curdt wrote:
>>> Isn't this missing the whole point of the current licensing
>>> discussion? If we cook up a system that allows us to create and
>>> distribute cocoon but that product now cannot be used to build a
>>> commercial application without questions of further license
>>> requirements (source code availability, etc.) have we served our
>>> users well?
>>
>>
>>
>> That's exactly the problem I have with this library system. Isn't
>> Apache stuff that common because of its ease of use? I don't want to
>> do license checking for every dependent project I get from somewhere.
>> Moving this to the users is just a poor move and should be avoided if
>> possible. It's not just about downloading one more JAR.
>
>
> Well, AFAIU they will only run into the same legal hassle if
> they try to *redistribute* cocoon as a whole!! So no problem
> for the simple user.
Is a company using Cocoon to deliver web applications redistributing
Cocoon? (yes, I think). Then from what I can tell, a good portion of
even our own committers, not to mention people on the users list would
have a problem.
> If it's really a problem for the ones distributing is still
> the question anyway (I doubt it) But this way it's not the
> ASF that would have to take the responsibility for that.
>
> I guess that's the point
Yes, that's the point indeed. ASL is supposed to be a business-friendly
license. If Cocoon uses distribution-time tricks to technically comply
with the ASL but in the process nullifies its intent for some users, we
have failed IMO.
Geoff
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Torsten Curdt <tc...@vafer.org>.
>> Isn't this missing the whole point of the current licensing
>> discussion? If we cook up a system that allows us to create and
>> distribute cocoon but that product now cannot be used to build a
>> commercial application without questions of further license
>> requirements (source code availability, etc.) have we served our users
>> well?
>
>
> That's exactly the problem I have with this library system. Isn't Apache
> stuff that common because of its ease of use? I don't want to do license
> checking for every dependent project I get from somewhere. Moving this
> to the users is just a poor move and should be avoided if possible. It's
> not just about downloading one more JAR.
Well, AFAIU they will only run into the same legal hassle if
they try to *redistribute* cocoon as a whole!! So no problem
for the simple user.
If it's really a problem for the ones distributing is still
the question anyway (I doubt it) But this way it's not the
ASF that would have to take the responsibility for that.
I guess that's the point
--
Torsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 12.03.2004 13:14, Geoff Howard wrote:
> Isn't this missing the whole point of the current licensing discussion?
> If we cook up a system that allows us to create and distribute cocoon
> but that product now cannot be used to build a commercial application
> without questions of further license requirements (source code
> availability, etc.) have we served our users well?
That's exactly the problem I have with this library system. Isn't Apache
stuff that common because of its ease of use? I don't want to do license
checking for every dependent project I get from somewhere. Moving this
to the users is just a poor move and should be avoided if possible. It's
not just about downloading one more JAR.
Joerg
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Stefano Mazzocchi <st...@apache.org>.
Geoff Howard wrote:
> Bertrand Delacretaz wrote:
>
>> Sounds like the way to go, intelligently downloading dependencies from
>> some non-ASF repository should solve most, maybe all of the licensing
>> problems, and help make Cocoon more lightweight for many uses.
>>
>> IIRC last time this was discussed the debate quickly moved to a heated
>> discussion on the relative merits of Maven and other similar tools -
>> if we're going to discuss this again, we must be careful to focus on
>> the goals rather than on the tools!
>
>
>
> Isn't this missing the whole point of the current licensing discussion?
> If we cook up a system that allows us to create and distribute cocoon
> but that product now cannot be used to build a commercial application
> without questions of further license requirements (source code
> availability, etc.) have we served our users well?
wait!
let's keep reasonable here, ok?
We are distributing cocoon today and it's *already* a legal hell to go
thru to find out how to package cocoon in a commercial product and
redistribute it. The cocoon *code* is licensed under the apache license,
the libraries are licensed according to the /legal directory, as we
specify in the README file.
Brian thinks that this is not enough and yields the false impression
that *everything* is licensed under the apache license.
Not everybody agrees with him.
But due to the nature of cocoon, installations are just that: installations.
99% of our users do not redistribute cocoon as part of their system.
They use it to provide a service. And, if they do redistribute cocoon as
a part of their software, they will need to comply to *ALL* the licenses
that we ship.
[but since we did the job for them to screen the compatibilities, they
have to make sure that they comply to the other things, like IP and
patent rights]
If we do not redistribute, say, Rhino, this makes it more obvious that
they have to comply to the license because they have to download it
themselves... but if we do it thru a package manager, well, it's the
same thing.
IMHO, stopping distributing libraries under the MPL doesn't buy us
nothing, the legal issues are all already there, we should just make it
more obvious when the user downloads our distribution.
NOTE: legal issues are nasty with IP and patents anyway. Open source is
not freeing you from living in the real world, unfortunately.
--
Stefano.
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Vendredi, 12 mars 2004, à 13:14 Europe/Zurich, Geoff Howard a écrit :
> Bertrand Delacretaz wrote:
>
>> Sounds like the way to go, intelligently downloading dependencies
>> from some non-ASF repository should solve most, maybe all of the
>> licensing problems, and help make Cocoon more lightweight for many
>> uses.
>>
>> IIRC last time this was discussed the debate quickly moved to a
>> heated discussion on the relative merits of Maven and other similar
>> tools - if we're going to discuss this again, we must be careful to
>> focus on the goals rather than on the tools!
>
>
> Isn't this missing the whole point of the current licensing
> discussion? If we cook up a system that allows us to create and
> distribute cocoon but that product now cannot be used to build a
> commercial application without questions of further license
> requirements (source code availability, etc.) have we served our users
> well? ...
There are several blocks already (fins for example) which cannot be
distributed with Cocoon because of incompatible licenses, even though
for many users these licenses wouldn't be a problem. This causes these
components to get less visibility than they might deserve.
I think it can only serve Cocoon to have a mechanism where such
"license-incompatible" stuff can be better integrated from our user's
point of view.
IMO, allowing dependencies to be downloaded automatically from non-ASF
sites would help in this respect, whatever the outcome of the current
discussion about licensing is.
So I think it makes sense to discuss these matters (dependencies
management and licensing issues) separately.
-Bertrand
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's
Rhino+continuations fork)
Posted by Geoff Howard <co...@leverageweb.com>.
Bertrand Delacretaz wrote:
> Sounds like the way to go, intelligently downloading dependencies from
> some non-ASF repository should solve most, maybe all of the licensing
> problems, and help make Cocoon more lightweight for many uses.
>
> IIRC last time this was discussed the debate quickly moved to a heated
> discussion on the relative merits of Maven and other similar tools -
> if we're going to discuss this again, we must be careful to focus on
> the goals rather than on the tools!
Isn't this missing the whole point of the current licensing discussion?
If we cook up a system that allows us to create and distribute cocoon
but that product now cannot be used to build a commercial application
without questions of further license requirements (source code
availability, etc.) have we served our users well?
Geoff
Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Jeudi, 11 mars 2004, à 23:06 Europe/Zurich, Paul Russell a écrit :
> On 10 Mar 2004, at 19:51, Steven Noels wrote:
>> (OT for the non-ASF folks:) You seem to suggest that inclusion of
>> non-ASL-licensed library dependencies inside ASF distributions should
>> be deprecated, favoring a CPAN or FreeBSD ports -like mechanism
>> instead. This will definitely lower the ease of use for end-users,
>> which have been complaining already that we don't ship a binary
>> distribution of Cocoon, let alone that we would ship a download which
>> requires them to either hunt down additional packages themselves, or
>> have an internet connection when installing Cocoon.
>
> ... which brings me around to something I've been pondering for a
> while. Since Cocoon is a bit of a 'hub' in the open source world, it
> brings together a stack of external libraries. Including these in the
> core source distribution is clunky and painful for everyone. Have we
> considered using Maven or similar to help manage these dependancies?
> ....
Sounds like the way to go, intelligently downloading dependencies from
some non-ASF repository should solve most, maybe all of the licensing
problems, and help make Cocoon more lightweight for many uses.
IIRC last time this was discussed the debate quickly moved to a heated
discussion on the relative merits of Maven and other similar tools - if
we're going to discuss this again, we must be careful to focus on the
goals rather than on the tools!
-Bertrand
Re: Cocoon's Rhino+continuations fork
Posted by Paul Russell <wo...@paulrussell.org>.
On 10 Mar 2004, at 19:51, Steven Noels wrote:
> (OT for the non-ASF folks:) You seem to suggest that inclusion of
> non-ASL-licensed library dependencies inside ASF distributions should
> be deprecated, favoring a CPAN or FreeBSD ports -like mechanism
> instead. This will definitely lower the ease of use for end-users,
> which have been complaining already that we don't ship a binary
> distribution of Cocoon, let alone that we would ship a download which
> requires them to either hunt down additional packages themselves, or
> have an internet connection when installing Cocoon.
... which brings me around to something I've been pondering for a
while. Since Cocoon is a bit of a 'hub' in the open source world, it
brings together a stack of external libraries. Including these in the
core source distribution is clunky and painful for everyone. Have we
considered using Maven or similar to help manage these dependancies?
I'm still playing catch up with the architectural changes within cocoon
(this is still very much a part time job for me right now), so I don't
know how this would tie up with Blocks. I do know however that the
Geronimo project uses Maven to great effect, and they do separate
modules with their own code trees etc, so this may be a prior art.
Thoughts?
Paul
--
Paul Russell
work@paulrussell.org
Re: Cocoon's Rhino+continuations fork
Posted by Steven Noels <st...@outerthought.org>.
On 09 Mar 2004, at 19:38, Brian Behlendorf wrote:
> 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
>> (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
>
> 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.
Just to get this point clear: we never suggested that we could simply
change the license of Rhino as non-copyright holders, and "just make it
ASL". I was thinking that the license terms of the MPL1.1 (which seems
to be the more liberal of the tri-license) didn't impose any extra
requirements outside the ASL scope for projects shipping a *library*
version of Rhino or a derivate of Rhino.
It has never been the intention to move the sourcecode of Chris' fork
to ASF CVS - not only because of legal and ownership issues, but
primarily because it ain't a community project. The intention was to
find legal clarity for the sourcecode of the forked version, hosted
*outside* ASF CVS - and to check out whether we could ship a compiled
and packaged library version of (a forked version of) Rhino with
Cocoon.
At the same time, we are interested in convergence with the Rhino trunk
version, but I'm afraid that (a) we would be the only folks interested
in seeing continuations inside Rhino ATM, and (b) no-one is
volunteering to do the painful refactoring & remerging anyhow. And
while we were at it, we figured to kindly nag the Rhino folks to change
their license to the same level of liberality as ours.
Admittedly, interlocking all these actions brings a whole lot of
problems together.
(OT for the non-ASF folks:) You seem to suggest that inclusion of
non-ASL-licensed library dependencies inside ASF distributions should
be deprecated, favoring a CPAN or FreeBSD ports -like mechanism
instead. This will definitely lower the ease of use for end-users,
which have been complaining already that we don't ship a binary
distribution of Cocoon, let alone that we would ship a download which
requires them to either hunt down additional packages themselves, or
have an internet connection when installing Cocoon.
</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
Re: Cocoon's Rhino+continuations fork
Posted by Brian Behlendorf <br...@collab.net>.
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 apache.org 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
> (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
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 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.
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 'cocoondev.org') 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 mozilla.org.
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
Apache.org CVS tree - it must be distributed separately and linked at
runtime.
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 Apache.org. I would strongly suggest that
collaboration around Rhino continue at mozilla.org, in any event, since
the Mozilla developers do appear willing to look at continuations and open
to participation by others.
Brian
Re: Cocoon's Rhino+continuations fork
Posted by Steven Noels <st...@outerthought.org>.
On 08 Mar 2004, at 23:55, Steven Noels wrote:
> (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).
fyi: I'm talking off-list with some Mozilla folks. So our message was
heard.
</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