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
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 debat
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
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 ma
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 co
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.)
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 requ
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
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 assu
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
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
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
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 bloc
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
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, f
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 a
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
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,
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 po
19 matches
Mail list logo