You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by ivelin <iv...@apache.org> on 2003/03/27 14:35:08 UTC
[ANN] XMLForm as a standalone servlet toolkit
I've decided to extract XMLForm as a standalone toolkit in order to be able
to faster develop experimental branches without affecting Cocoon.
The plan is to merge more successful advancements back into Cocoon.
Also, it can hopefully be a jumping board for beginners and smaller projects
that are not ready for the full sophistication of Cocoon.
http://www.cocoonhive.org/xmlform/index.html
Enjoy,
-=Ivelin=-
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Steven Noels <st...@outerthought.org>.
On 27/03/2003 14:35 ivelin wrote:
> I've decided to extract XMLForm as a standalone toolkit in order to be able
> to faster develop experimental branches without affecting Cocoon.
I find this sad and would like to see a real rationale, and how you
'plan' to recontribute 'advancements'.
In case you were thinking to easily merge your changes, developed
outside this community, back into the main Cocoon trunk when you see
fit, don't expect us to be there: you are forking on your own reasons,
after all.
Also, _you_ as an individual cannot license changes under the ASF
license, since this requires the ASF to be the copyright holder, which I
understand is not the goal you are seeking. You will need to properly
prepare your own license, optionally making it ASL compatible.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Torsten Curdt <tc...@dff.st>.
> I've decided to extract XMLForm as a standalone toolkit in order to be able
> to faster develop experimental branches without affecting Cocoon.
>
> The plan is to merge more successful advancements back into Cocoon.
>
> Also, it can hopefully be a jumping board for beginners and smaller projects
> that are not ready for the full sophistication of Cocoon.
Hm... Ivelin, do you really think this is the right sign?
--
Torsten
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Steven Noels <st...@outerthought.org>.
On 27/03/2003 14:35 ivelin wrote:
> I've decided to extract XMLForm as a standalone toolkit in order to be able
> to faster develop experimental branches without affecting Cocoon.
I find this sad and would like to see a real rationale, and how you
'plan' to recontribute 'advancements'.
In case you were thinking to easily merge your changes, developed
outside this community, back into the main Cocoon trunk when you see
fit, don't expect us to be there: you are forking on your own reasons,
after all.
Also, _you_ as an individual cannot license changes under the ASF
license, since this requires the ASF to be the copyright holder, which I
understand is not the goal you are seeking. You will need to properly
prepare your own license, optionally making it ASL compatible.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: License and patching/forking
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> On 1/4/03 23:36, "Stefano Mazzocchi" <st...@apache.org> wrote:
>
>
>>Artur Bialecki wrote:
>>
>>>Thanks for the info it makes things clearer for me. But lets say
>>>I do have to "fork" cocoon for the reasons you mentioned and I have
>>>to name it something different. Do I have to change all references
>>>to apache/cocoon in all the sources. (eg. changing Cocoon.java
>>>to Baboon.java and all references to that class). This sounds
>>>like maintenance nightmare.
>>
>>nono, as noted before, there is nothing in the license that covers
>>package names.
>
>
> I suggested it in a response to Gianugo.
>
> And not really sure about that... I noted it because IIRC in the past XML4J
> was a backport from Xalan-J 1.x and was using the com.ibm package names for
> that reason... But either I am wrong, or someone gave some more
> clarifications higher up...
I think they did it to "play nicely" with us. IBM understood the
community implications of not clearly separating XML4j from Xerces. (and
also because, in case they lost control of the community, they had a
already-preforked-without-friction escape path. IBM has been burned by
lack of control over software built with others (those guys in redmond,
for example) and clearly knows how to protect their interests)
> Thinking out loud... What if someone modifies an org.apache.cocoon class in
> an incompatible way and distributes it incorporated in a product called
> "Comanche Baboon" ???
That's his choice. For sure I won't be *that* responsive to his/her help
queries after such a move.
The gold rule is "respect and you'll be respected" or "since we helped
you, the least you can do is not to harm us".
If you go against this on purpose, even after you've been advised of
better ways of doing it, well, legal threats are the things that should
worry you the least. :-)
Stefano.
Re: License and patching/forking
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 1/4/03 23:36, "Stefano Mazzocchi" <st...@apache.org> wrote:
> Artur Bialecki wrote:
>> Thanks for the info it makes things clearer for me. But lets say
>> I do have to "fork" cocoon for the reasons you mentioned and I have
>> to name it something different. Do I have to change all references
>> to apache/cocoon in all the sources. (eg. changing Cocoon.java
>> to Baboon.java and all references to that class). This sounds
>> like maintenance nightmare.
>
> nono, as noted before, there is nothing in the license that covers
> package names.
I suggested it in a response to Gianugo.
And not really sure about that... I noted it because IIRC in the past XML4J
was a backport from Xalan-J 1.x and was using the com.ibm package names for
that reason... But either I am wrong, or someone gave some more
clarifications higher up...
Thinking out loud... What if someone modifies an org.apache.cocoon class in
an incompatible way and distributes it incorporated in a product called
"Comanche Baboon" ???
Pier
Re: License and patching/forking
Posted by Stefano Mazzocchi <st...@apache.org>.
Artur Bialecki wrote:
> Thanks for the info it makes things clearer for me. But lets say
> I do have to "fork" cocoon for the reasons you mentioned and I have
> to name it something different. Do I have to change all references
> to apache/cocoon in all the sources. (eg. changing Cocoon.java
> to Baboon.java and all references to that class). This sounds
> like maintenance nightmare.
nono, as noted before, there is nothing in the license that covers
package names.
You simply can't refer to the *entire* thing as 'cocoon' anymore.
> In the following situation what would the best approach be.
> I need to cache the DOM of included files in XIncludeTransformer.
> The changes include modifying very few lines of code and addition
> of configuration option. Also lets assume that extending the
> XIncludeTrasformer is not possible or it doesn't make sense.
> So do I modify XIncludeTransformer and fork cocoon or
> do I create my own component by stilling 99% of the code from
> XIncludeTransformer.
In case your patch is not accepted, I would do this.
> Are there other options.
Submit a patch for that particular behavior. If that is not accepted,
submit a patch that would turn the code extensible and you extend that
component with your code.
Copying 99% of the code is the last solution because in the future you
are very likely to keep maintaining that code yourself. Instead, if you
extend the component, you are likely to inherit all future bugfixes and
advances.
> What if I do submit a patch and it gets accepted for
> next release but I can't use the new release since it breaks
> other things. Can I use my old patched release forever?
The golden rule is ethics: if you aren't doing anything that can bring
potential damage to the community, you are going to be safe and nobody
is going to enfoce the license upon you.
We trust our users enough to know that any harm done to this community
is done to themselves.
Our ecosystem is protecting ourselves much more than any license.
Stefano.
License and patching/forking (was: RE: [ANN] XMLForm as a standalone servlet toolkit)
Posted by Artur Bialecki <ar...@digitalfairway.com>.
Thanks for the info it makes things clearer for me. But lets say
I do have to "fork" cocoon for the reasons you mentioned and I have
to name it something different. Do I have to change all references
to apache/cocoon in all the sources. (eg. changing Cocoon.java
to Baboon.java and all references to that class). This sounds
like maintenance nightmare.
In the following situation what would the best approach be.
I need to cache the DOM of included files in XIncludeTransformer.
The changes include modifying very few lines of code and addition
of configuration option. Also lets assume that extending the
XIncludeTrasformer is not possible or it doesn't make sense.
So do I modify XIncludeTransformer and fork cocoon or
do I create my own component by stilling 99% of the code from
XIncludeTransformer. Are there other options.
What if I do submit a patch and it gets accepted for
next release but I can't use the new release since it breaks
other things. Can I use my old patched release forever?
I'm not asking for the "official" statement ;)
Thanks,
Artur...
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: April 1, 2003 4:35 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [ANN] XMLForm as a standalone servlet toolkit
>
>
> Please note this is not an official statement on behalf of the
> foundation. If you need an official one, please contact the Apache
> Licencing Group at (licensing@apache.org).
>
> These are only my thinking based on passed experiences and threads on
> that licensing@ mail list.
>
> Kevin O'Neill wrote:
>
> > I understand your point and agree with it. I would like to
> however ask
> > some follow up questions :).
>
> > Say I'm building with cocoon 2.0.4 and there is a bug in
> the foo. I fix
> > that bug in the version of coccon that I supply to my
> client. Under normal
> > circumstances I would supply the client with the code
> (including third
> > party code, patched or not) of the product I'm working on.
> Can I supply
> > the patched version?
>
> Sure. You are fully allowed to redistributed a modified codebase.
>
> But there are a few issues:
>
> 1) you can't call it "Apache Cocoon" anymore, unless the ASF
> gives you
> written permission. Even if you change one line, it's *your*
> own fork,
> thus you have to name it something different.
>
> 2) you have to state what license applies to your modification.
>
> Note that this is being *very* picky.
>
> Usually (and this happened several times in the past with HTTPd,
> expecially for different distributions), as long as you
> *DO*NOT* modify
> the behavior of Cocoon in any significant way (and a bugfix, or the
> addition of a few lines in the README.txt file and so on are
> considered
> harmless changes), the ASF is perfectly fine with that even if, in
> theory, the license doesn't allow you to do that and still retain the
> 'Apache Cocoon' name in your distribution.
>
> Please understand that the reason for protecting the cocoon
> brand is to
> avoid you distributing something that is *NOT* cocoon anymore
> with its
> name, thus, in fact, abusing the name and its visibility.
>
> As long as this community doesn't have the perception that
> you are doing
> it, you are fine and safe even if you blurred the lines of
> the license a
> little.
>
> > Now lets say that I enhance one of the existing components
> to extend the
> > functionality in some way of the component (say allow for
> an addition
> > configuration option). Can I supply this version?
>
> This is more tricky as you are, in fact, altering the
> functionality in a
> significant way.
>
> As I said, if you don't distribute the code with the name
> 'cocoon' you
> are fine even if you throw away half of the code and write
> another half
> yourself.
>
> If not, well, you are potentially providing confusion to the customer
> because he is not able to replace 'your version' of cocoon with ours
> transparently and this means, in fact, that 'your version' is
> not cocoon
> anymore and the license doesn't give you the right of calling it so.
>
> > What if I've submitted both enhancements as patches and
> they have been
> > excepted for the HEAD version?
>
> If you modifications are waiting for a release to be out, then your
> customer *will* be able to switch to an official release and
> it's just a
> matter of specifying the release number.
>
> In that case, you could distribute a CVS snapshot and all is well.
>
> > What if they haven't?
>
> The eventuality that a bugfix is *rejected* is close to zero.
> Maybe it's
> not fixed as you did, but the bug will be fixed sooner or later and
> normally, if you provide a patch, it's much easier to patch
> it with your
> patch than to write another one.
>
> So for bugfixes I don't see any problem.
>
> For enhancements, there is a chance they are rejected.
>
> If this is the case, you are, in fact, forking. This prevents
> you from
> calling your distributed cocoon 'cocoon'.
>
> If you don't care, just change the name and say that 'my own little
> software' is based on Apache Cocoon 2.1.whatever and you are fine.
>
> If you care (because your customer cares!), then my
> suggestion would be
> to ship cocoon unmodified and then ship along side your enhanced
> component, with a different package name and under your own license
> (which could well be compatible with the ASF but allow potential
> placement into the HEAD in the future, but that's up to you.)
>
> >>But defining an package and import it (or extend it) are
> two entirely
> >>different things because they can't do any harm.
> >
> > I think this sort of stuff should be in a licensing FAQ.
>
> Sigh, that FAQ has been work in progress for two years now,
> along with
> the Apache License 2.0
>
> maybe one day both will see the light.
>
> But don't hold your breath for it.
>
> Stefano.
>
>
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Stefano Mazzocchi <st...@apache.org>.
Please note this is not an official statement on behalf of the
foundation. If you need an official one, please contact the Apache
Licencing Group at (licensing@apache.org).
These are only my thinking based on passed experiences and threads on
that licensing@ mail list.
Kevin O'Neill wrote:
> I understand your point and agree with it. I would like to however ask
> some follow up questions :).
> Say I'm building with cocoon 2.0.4 and there is a bug in the foo. I fix
> that bug in the version of coccon that I supply to my client. Under normal
> circumstances I would supply the client with the code (including third
> party code, patched or not) of the product I'm working on. Can I supply
> the patched version?
Sure. You are fully allowed to redistributed a modified codebase.
But there are a few issues:
1) you can't call it "Apache Cocoon" anymore, unless the ASF gives you
written permission. Even if you change one line, it's *your* own fork,
thus you have to name it something different.
2) you have to state what license applies to your modification.
Note that this is being *very* picky.
Usually (and this happened several times in the past with HTTPd,
expecially for different distributions), as long as you *DO*NOT* modify
the behavior of Cocoon in any significant way (and a bugfix, or the
addition of a few lines in the README.txt file and so on are considered
harmless changes), the ASF is perfectly fine with that even if, in
theory, the license doesn't allow you to do that and still retain the
'Apache Cocoon' name in your distribution.
Please understand that the reason for protecting the cocoon brand is to
avoid you distributing something that is *NOT* cocoon anymore with its
name, thus, in fact, abusing the name and its visibility.
As long as this community doesn't have the perception that you are doing
it, you are fine and safe even if you blurred the lines of the license a
little.
> Now lets say that I enhance one of the existing components to extend the
> functionality in some way of the component (say allow for an addition
> configuration option). Can I supply this version?
This is more tricky as you are, in fact, altering the functionality in a
significant way.
As I said, if you don't distribute the code with the name 'cocoon' you
are fine even if you throw away half of the code and write another half
yourself.
If not, well, you are potentially providing confusion to the customer
because he is not able to replace 'your version' of cocoon with ours
transparently and this means, in fact, that 'your version' is not cocoon
anymore and the license doesn't give you the right of calling it so.
> What if I've submitted both enhancements as patches and they have been
> excepted for the HEAD version?
If you modifications are waiting for a release to be out, then your
customer *will* be able to switch to an official release and it's just a
matter of specifying the release number.
In that case, you could distribute a CVS snapshot and all is well.
> What if they haven't?
The eventuality that a bugfix is *rejected* is close to zero. Maybe it's
not fixed as you did, but the bug will be fixed sooner or later and
normally, if you provide a patch, it's much easier to patch it with your
patch than to write another one.
So for bugfixes I don't see any problem.
For enhancements, there is a chance they are rejected.
If this is the case, you are, in fact, forking. This prevents you from
calling your distributed cocoon 'cocoon'.
If you don't care, just change the name and say that 'my own little
software' is based on Apache Cocoon 2.1.whatever and you are fine.
If you care (because your customer cares!), then my suggestion would be
to ship cocoon unmodified and then ship along side your enhanced
component, with a different package name and under your own license
(which could well be compatible with the ASF but allow potential
placement into the HEAD in the future, but that's up to you.)
>>But defining an package and import it (or extend it) are two entirely
>>different things because they can't do any harm.
>
> I think this sort of stuff should be in a licensing FAQ.
Sigh, that FAQ has been work in progress for two years now, along with
the Apache License 2.0
maybe one day both will see the light.
But don't hold your breath for it.
Stefano.
RE: [ANN] XMLForm as a standalone servlet toolkit
Posted by Artur Bialecki <ar...@digitalfairway.com>.
Hello all,
I would like to see an official replay to Kevin's questions.
Thanks,
Artur...
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Kevin O'Neill
>
> I understand your point and agree with it. I would like to however ask
> some follow up questions :).
>
> Say I'm building with cocoon 2.0.4 and there is a bug in the
> foo. I fix
> that bug in the version of coccon that I supply to my client.
> Under normal
> circumstances I would supply the client with the code (including third
> party code, patched or not) of the product I'm working on.
> Can I supply
> the patched version?
>
> Now lets say that I enhance one of the existing components to
> extend the
> functionality in some way of the component (say allow for an addition
> configuration option). Can I supply this version?
>
> What if I've submitted both enhancements as patches and they have been
> excepted for the HEAD version?
>
> What if they haven't?
>
> > But defining an package and import it (or extend it) are
> two entirely
> > different things because they can't do any harm.
>
> I think this sort of stuff should be in a licensing FAQ.
>
> > Stefano.
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
On Fri, 28 Mar 2003 11:25:00 +0100, Stefano Mazzocchi wrote:
> Kevin O'Neill wrote:
>
>> I don't believe that points 4 and 5 are violated by "package
>> org.apache.xmlform" any more than the statement "import
>> org.apache.xmlform"; the license precludes neither one of these things.
>
> There is a huge difference between
>
> package org.apache.xmlform;
>
> and
>
> import org.apache.xmlform.*;
>
> and the reason is that the first is a describer, the second is a
> reference.
>
> If you describe your stuff with a name or trademark or sign that is owned
> by somebody else and it can be shown that you do *harm* to the trademark
> owner when you do, you can get sued for damages.
>
> If you reference an entity with its name, this is fair use and cannot
> cause any harm if properly placed in context.
>
> The reason why 'package org.apache...' can harm the foundation is, for
> example, name clashing. A package name is a unique identifier for a class,
> if there is a package name collision in the classloader, it is impossible
> to reference one class from another.
>
> So, if apache decides to use the org.apache.whatever package and somebody
> else used it already, there is potential harm.
>
> The policy of protecting the package name is to avoid further problems
> down the road.
I understand your point and agree with it. I would like to however ask
some follow up questions :).
Say I'm building with cocoon 2.0.4 and there is a bug in the foo. I fix
that bug in the version of coccon that I supply to my client. Under normal
circumstances I would supply the client with the code (including third
party code, patched or not) of the product I'm working on. Can I supply
the patched version?
Now lets say that I enhance one of the existing components to extend the
functionality in some way of the component (say allow for an addition
configuration option). Can I supply this version?
What if I've submitted both enhancements as patches and they have been
excepted for the HEAD version?
What if they haven't?
> But defining an package and import it (or extend it) are two entirely
> different things because they can't do any harm.
I think this sort of stuff should be in a licensing FAQ.
> Stefano.
-k.
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Stefano Mazzocchi <st...@apache.org>.
Kevin O'Neill wrote:
> I don't believe that points 4 and 5 are violated by "package
> org.apache.xmlform" any more than the statement "import
> org.apache.xmlform"; the license precludes neither one of these things.
There is a huge difference between
package org.apache.xmlform;
and
import org.apache.xmlform.*;
and the reason is that the first is a describer, the second is a reference.
If you describe your stuff with a name or trademark or sign that is
owned by somebody else and it can be shown that you do *harm* to the
trademark owner when you do, you can get sued for damages.
If you reference an entity with its name, this is fair use and cannot
cause any harm if properly placed in context.
The reason why 'package org.apache...' can harm the foundation is, for
example, name clashing. A package name is a unique identifier for a
class, if there is a package name collision in the classloader, it is
impossible to reference one class from another.
So, if apache decides to use the org.apache.whatever package and
somebody else used it already, there is potential harm.
The policy of protecting the package name is to avoid further problems
down the road.
But defining an package and import it (or extend it) are two entirely
different things because they can't do any harm.
Stefano.
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 28 March 2003 17:45, Pier Fumagalli wrote:
> On 28/3/03 6:54 am, "Kevin O'Neill" <ke...@rocketred.com.au> wrote:
> > 5. Products derived from this software may not be called "Apache", nor
> > may "Apache" appear in their name, without prior written permission of
> > the Apache Software Foundation.
> It is not 4 in my own opinion... I believe it's more point 5:
> "Apache" may not appear in the name of a product derived from this
> software: clearly a single Java class is an entity of its own... If it's a
> modified version of our copy it's a "derived product" and the derived
> product name (only THAT class I can download through CVS) is
> "org.apache.abcde.MyOwn"...
Yeah, I think it is rather safe to say that if you "derive" from Apache code
you can not use
package org.apache...
without permission.
Irony is, if you don't derive from Apache sources, I strongly doubt that the
Sun "package name recommendations" will hold up in court, and I doubt that
ASF will challange such.
There is actually a twist here.
If I derive the class org.apache.abc.Def with an additional line of code,
would I then have to move the class elsewhere, and change the 200 references
in other classes, and by modifying those classes, have to move all other
classes as well??
If so, then I am violating the Apache license in my JServ hack to serve WML
content...
Niclas
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 28/3/03 6:54 am, "Kevin O'Neill" <ke...@rocketred.com.au> wrote:
> On Fri, 28 Mar 2003 03:07:01 +0000, Pier Fumagalli wrote:
>
>> On 28/3/03 0:41, "Gianugo Rabellino" <gi...@apache.org> wrote:
>>
>>> What am I missing?
>>
>> org.APACHE...
>>
>> That name is protected by the license AFAIK, but am no lawyer at all...
>
> I'm also not a lawyer but I find the statement worrying and if someone is
> going to say something in illegal, they'd better be right.
>
> Take a look at the two statements regarding name use.
>
> 4. The names "Apache Cocoon" and "Apache Software Foundation" must not be
> used to endorse or promote products derived from this software without
> prior written permission. For written permission, please contact
> apache@apache.org.
>
> 5. Products derived from this software may not be called "Apache", nor may
> "Apache" appear in their name, without prior written permission of the
> Apache Software Foundation.
>
> I don't believe that points 4 and 5 are violated by "package
> org.apache.xmlform" any more than the statement "import
> org.apache.xmlform"; the license precludes neither one of these things.
> If the ASF is going to enforce the former using these statements are we
> all going to need written permission to import apache packages or
> implement apache interfaces.
It is not 4 in my own opinion... I believe it's more point 5:
"Apache" may not appear in the name of a product derived from this software:
clearly a single Java class is an entity of its own... If it's a modified
version of our copy it's a "derived product" and the derived product name
(only THAT class I can download through CVS) is "org.apache.abcde.MyOwn"...
So, the name "Apache" appear in the name of the product derived from our
software, this product being the single class someone modified.
At least this is my personal opinion.
Pier
BTW (Standard disclaimer as per last email in this thread applies)
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
On Fri, 28 Mar 2003 03:07:01 +0000, Pier Fumagalli wrote:
> On 28/3/03 0:41, "Gianugo Rabellino" <gi...@apache.org> wrote:
>
>> What am I missing?
>
> org.APACHE...
>
> That name is protected by the license AFAIK, but am no lawyer at all...
I'm also not a lawyer but I find the statement worrying and if someone is
going to say something in illegal, they'd better be right.
Take a look at the two statements regarding name use.
4. The names "Apache Cocoon" and "Apache Software Foundation" must not be
used to endorse or promote products derived from this software without
prior written permission. For written permission, please contact
apache@apache.org.
5. Products derived from this software may not be called "Apache", nor may
"Apache" appear in their name, without prior written permission of the
Apache Software Foundation.
I don't believe that points 4 and 5 are violated by "package
org.apache.xmlform" any more than the statement "import
org.apache.xmlform"; the license precludes neither one of these things.
If the ASF is going to enforce the former using these statements are we
all going to need written permission to import apache packages or
implement apache interfaces.
-k.
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 28 March 2003 17:44, Stefano Mazzocchi wrote:
> I'm pretty sure that if I identified my namespaces with something like
> "http://www.microsoft.com/whatever", I would get their lawyers knocking
> on my doors even if, I'm sure, there is no license I signed or
> clicked-thru that prevented me from doing it.
If you are born after ~1975 or so, you signed over all your rights to MS at
birth. Don't you remember that? ;o)
Niclas
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Stefano Mazzocchi <st...@apache.org>.
Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>
>> I have looked at the code you distribute and you are in clear
>> violation of the ASF license and the ASF guidelines for these reasons:
>
>
> OK, I don't want to delve into whether Ivelin's move is right or not
> from a community POV (but yes, I do share Steven and Torsten's
> concerns). This email sounds a bit too much like a threat to me, while I
> tend to assume that Ivelin was and is in good faith and unwilling to
> hurt anyone.
when I wear my PMC chair hat (and it's going to be a rare event), I am
an officer of the foundation, trying to protect the interests of the
foundation.
If the Ivelin's code is exploited, or infringes a patent, or is sued by
someone and the foundation didn't have proper oversight, the foundation
can get in trouble and *I*, as the PMC chair, I'm going to feel ashamed
for having let this happening.
I'm *NOT* stating that Ivelin is doing this on purpose, hell no, but I'm
pretty sure that he didn't understand the legal implications of his move
and he needs to act quickly about it: either compliying with the ASF
license or with the ASF code development policies.
> Anyway, since you are making a point on legal stuff, with my lawyer hat
> on, I'm afraid that either I misunderstood at all the Apache license or
> you're just wrong when you say:
>
>> 2) you are distributing ASF-copyrighted code from outside the ASF
>> infrastructure.
>
>
> I don't see what is the problem here: do you mean that I can't
> distribute Cocoon, or HTTPD, or Tomcat on my very own FTP server? Why
> that? Since when? The Apache license looks pretty clear to me when it
> comes to freedom to redistribute stuff and indeed I don't see why and
> how this can be seen as a violation. And if that's a violation, well...
> I guess that there are plenty of Internet resources that are
right, let me restate:
- you are distributing *MODIFIED* ASF-copyrighted code from outside the
ASF infrastructure, and this in violation of the ASF practices and
considered bad from an ethical point of view. It also removes legal PMC
oversight and makes the ASF vulnerable to legal attacks.
> As per package names, well... I guess it's questionable: I'm not sure
> that articles 4 and 5 cover even package names: actually one might say
> that *taking away* "org.apache" from the package name is a licence
> violation since it's a way to hide where the software comes from. OTOH,
> keeping those names might be confusing so I don't really know where to
> stand. For sure it's not polite and savy, but I'm not dead sure that
> it's illegal (meaning defendable in court).
You are right, there is nothing in the license that covers java package
names explicitly. As a matter of fact, though, the java package
namespaces are used to identify resources uniquely. And if you are
abusing this namespace without the legal rights to the names, you are
potentially hurting the owner. This scheme comes from the URI space and
this space is legally *owned* by the foundation.
I'm pretty sure that if I identified my namespaces with something like
"http://www.microsoft.com/whatever", I would get their lawyers knocking
on my doors even if, I'm sure, there is no license I signed or
clicked-thru that prevented me from doing it.
Stefano.
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by ivelin <iv...@apache.org>.
> <pmc-chair-hat-on>
>
> Much nicer, but there are still a few issues:
>
> 1) you are shipping your code with the Apache Software License and you
> are granting copyright to the ASF for your stuff. This is still not
> acceptable for the ASF guidelines since there is no proper legal
> oversight on what you do on your own.
>
> Common practice is to use a modified version of the apache license that
> give you credits for, for examples look at Chaperon's or Krysalis'
> licenses or other Apache-derived licenses.
Thanks for the tip. I changed license.txt.
>
> The use of the original apache license for non-ASF stuff is not allowed.
>
> Also make sure to remove all cocoon-related things from your license.
I think I did.
>
> 2) you are using the 'org.xmlform' package name but the domain doesn't
> appear to be registered. I would suggest you to use the
> org.cocoonhive.xmlform package name or register the xmlform.org domain
> to protect yourself from future legal issues on package name abuses.
Thanks again. Just registered the domain.
>
> </pmc-chair-hat-on>
>
> Stefano.
Ivelin
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Stefano Mazzocchi <st...@apache.org>.
ivelin wrote:
> Made the requested chages.
> Please verify if they work for ASF?
<pmc-chair-hat-on>
Much nicer, but there are still a few issues:
1) you are shipping your code with the Apache Software License and you
are granting copyright to the ASF for your stuff. This is still not
acceptable for the ASF guidelines since there is no proper legal
oversight on what you do on your own.
Common practice is to use a modified version of the apache license that
give you credits for, for examples look at Chaperon's or Krysalis'
licenses or other Apache-derived licenses.
The use of the original apache license for non-ASF stuff is not allowed.
Also make sure to remove all cocoon-related things from your license.
2) you are using the 'org.xmlform' package name but the domain doesn't
appear to be registered. I would suggest you to use the
org.cocoonhive.xmlform package name or register the xmlform.org domain
to protect yourself from future legal issues on package name abuses.
</pmc-chair-hat-on>
Stefano.
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by ivelin <iv...@apache.org>.
Made the requested chages.
Please verify if they work for ASF?
-=Ivelin=-
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, March 28, 2003 4:16 AM
Subject: Re: [ANN] XMLForm as a standalone servlet toolkit
> ivelin wrote:
>
> > So, Stefano, since you have your PMC chairman hat on, tell me if we can
> > create an incubator project
> > I will gladly commit the new code to it.
> > If not, what other options do you suggest.
>
> You took part of cocoon and forked it.
>
> You didn't say anything about this, you just acted and announced it.
>
> The ASF license gives you the right to fork a project and since
> "XMLForm" is not covered by the cocoon license, you are fully entitled
> to call it so.
>
> It is enough that you:
>
> 1) place the cocoon license in your distribution
> 2) change the package names from org.apache.xmlform to anything that
> doesn't start with org.apache
> 3) grant copyright of the code you own full rights to to yourself
>
> or
>
> 1) stop distributing it and work with us for a solution.
>
> If one of the two is done, I can remove my PMC chair hat and put it back
> in the closet. From a PMC legal oversight standpoint, there is no
> difference between one move or another.
>
> - o -
>
> Now, I take my PMC chair hat off. I'm no more an ASF officer. I'm acting
> as simple cocoon committer, like you and many others here.
>
> Instead of you choosing by yourself what is good for that part of the
> Cocoon code, I would like to see a proposal discussed by the community.
>
> Stefano.
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Stefano Mazzocchi <st...@apache.org>.
ivelin wrote:
> So, Stefano, since you have your PMC chairman hat on, tell me if we can
> create an incubator project
> I will gladly commit the new code to it.
> If not, what other options do you suggest.
You took part of cocoon and forked it.
You didn't say anything about this, you just acted and announced it.
The ASF license gives you the right to fork a project and since
"XMLForm" is not covered by the cocoon license, you are fully entitled
to call it so.
It is enough that you:
1) place the cocoon license in your distribution
2) change the package names from org.apache.xmlform to anything that
doesn't start with org.apache
3) grant copyright of the code you own full rights to to yourself
or
1) stop distributing it and work with us for a solution.
If one of the two is done, I can remove my PMC chair hat and put it back
in the closet. From a PMC legal oversight standpoint, there is no
difference between one move or another.
- o -
Now, I take my PMC chair hat off. I'm no more an ASF officer. I'm acting
as simple cocoon committer, like you and many others here.
Instead of you choosing by yourself what is good for that part of the
Cocoon code, I would like to see a proposal discussed by the community.
Stefano.
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
ivelin wrote:
>>The difference is that we all chipped in as part of the
>>community to help finish the re-factoring. All that we
>>heard from you was bleating from the sidelines, urging us
>>to release a product that is not ready.
>>
>>
>
>You should probably speak for yourself instead of hiding behind "we all".
>It is by far not a proven fact that waiting forever for the perfect release
>serves this project better than releasing smaller increments more often.
>
>I will not enumerate the other people who are no less valuable contributors
>and were also "bleating" about the release cycle.
>
Please stop enumerating people's contributions. All that is in Cocoon's
CVS is owned by the community. Sure, we are more concerned by what we
initially wrote, but, as a committer, you can update anything anywhere.
>It should probably ring a bell to you when people are back porting XMLForm
>into 2.0 just so they can use it in a stable release.
>
>
A few questions : why haven't *you* back ported XMLForm into 2.0 ? What
prevented *you* to do it ? And if other people did it, why haven't *you*
incorporated their patches in the 2.0 branch, if this is something that
itches you so much ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by ivelin <iv...@apache.org>.
>
> The difference is that we all chipped in as part of the
> community to help finish the re-factoring. All that we
> heard from you was bleating from the sidelines, urging us
> to release a product that is not ready.
You should probably speak for yourself instead of hiding behind "we all".
It is by far not a proven fact that waiting forever for the perfect release
serves this project better than releasing smaller increments more often.
I will not enumerate the other people who are no less valuable contributors
and were also "bleating" about the release cycle.
It should probably ring a bell to you when people are back porting XMLForm
into 2.0 just so they can use it in a stable release.
Ivelin
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by David Crossley <cr...@indexgeo.com.au>.
ivelin wrote:
> Steven Noels wrote:
>
> > Exactly. Then again, Ivelin is looking into making XMLForm
> > independent from Cocoon IIUC from the freebuilder CVS.
> > I don't know whether a branch
> > would liberate him sufficiently enough (which is if course
> > not our concern).
>
> The goal is to be able to enhance this module without having
> to worry about other moving parts of Cocoon.
> A stable naked cocoon would work fine if there was one.
> Perhabs when all the blocks clean up is finished that will be feasible.
> Another option is to have a stable 2.1, which proved not realistic.
It would be realistic if we all spent time to help.
You are not the only one who has been affected by the
process to strengthen the Cocoon-2.1 foundations. When it
went unstable we all had issues and our own work was slowed.
The difference is that we all chipped in as part of the
community to help finish the re-factoring. All that we
heard from you was bleating from the sidelines, urging us
to release a product that is not ready.
<snip/>
> > Code developed _outside_ this community always needs to go through
> > explicit donation/copyright transfer before being able to be contributed
> > to the Cocoon project. And it seems like Ivelin was taking this
> > recontribution for granted.
>
> Not taking anything for granted.
> I've been around for a while and have a good idea how the community works.
This current debacle is demonstrating that you may not know.
<snip/>
--David
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by ivelin <iv...@apache.org>.
>
> I could be opening a can of worms here, but can I butt in and ask if this
move
> was promted out of frustration with the somewhat messy build and samples
> refactoring?
This played its part too.
>
> New Guy Geoff
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Geoff Howard <co...@leverageweb.com>.
At 09:27 AM 3/28/2003, Ivelin wrote:
> > On 28/03/2003 5:22 Vadim Gritsenko wrote:
> >
> > > What about creating an (experimental) branch for xmlform?
>
>That would be nice.
>
> >
> > Exactly. Then again, Ivelin is looking into making XMLForm independent
> > from Cocoon IIUC from the freebuilder CVS. I don't know whether a branch
> > would liberate him sufficiently enough (which is if course not our
>concern).
>
>The goal is to be able to enhance this module without having to worry about
>other moving parts of Cocoon.
>A stable naked cocoon would work fine if there was one.
>Perhabs when all the blocks clean up is finished that will be feasible.
>Another option is to have a stable 2.1, which proved not realistic.
<snip/>
>Ivelin
I could be opening a can of worms here, but can I butt in and ask if this move
was promted out of frustration with the somewhat messy build and samples
refactoring?
New Guy Geoff
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by ivelin <iv...@apache.org>.
> On 28/03/2003 5:22 Vadim Gritsenko wrote:
>
> > What about creating an (experimental) branch for xmlform?
That would be nice.
>
> Exactly. Then again, Ivelin is looking into making XMLForm independent
> from Cocoon IIUC from the freebuilder CVS. I don't know whether a branch
> would liberate him sufficiently enough (which is if course not our
concern).
The goal is to be able to enhance this module without having to worry about
other moving parts of Cocoon.
A stable naked cocoon would work fine if there was one.
Perhabs when all the blocks clean up is finished that will be feasible.
Another option is to have a stable 2.1, which proved not realistic.
>
> W.r.t. legal things, I think Pier & Gianugu are right. Ivelin can do
> whatever he wants with the code, if he sticks a copy of our license,
> proper acknowledgements and the correct copyright holder onto the code.
Just did that. I did not mean to ignore or disrespect ASF or any of the
members.
Let me know if the changes that I made in CVS are not sufficient.
>
> Code developed _outside_ this community always needs to go through
> explicit donation/copyright transfer before being able to be contributed
> to the Cocoon project. And it seems like Ivelin was taking this
> recontribution for granted.
Not taking anything for granted.
I've been around for a while and have a good idea how the community works.
>
> Anyhow, I would prefer the abundant references to Apache & Cocoon to be
> removed from that website. Being a committer means people trust you to
> work _inside_ a community, and one should not use his apache.org address
> to endorse personal endavours.
Changed the email address and removed some of the references.
Ivelin
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Steven Noels <st...@outerthought.org>.
On 28/03/2003 5:22 Vadim Gritsenko wrote:
> What about creating an (experimental) branch for xmlform?
Exactly. Then again, Ivelin is looking into making XMLForm independent
from Cocoon IIUC from the freebuilder CVS. I don't know whether a branch
would liberate him sufficiently enough (which is if course not our concern).
W.r.t. legal things, I think Pier & Gianugu are right. Ivelin can do
whatever he wants with the code, if he sticks a copy of our license,
proper acknowledgements and the correct copyright holder onto the code.
Code developed _outside_ this community always needs to go through
explicit donation/copyright transfer before being able to be contributed
to the Cocoon project. And it seems like Ivelin was taking this
recontribution for granted.
Anyhow, I would prefer the abundant references to Apache & Cocoon to be
removed from that website. Being a committer means people trust you to
work _inside_ a community, and one should not use his apache.org address
to endorse personal endavours.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Vadim Gritsenko <va...@verizon.net>.
ivelin wrote:
...
>So, Stefano, since you have your PMC chairman hat on, tell me if we can
>create an incubator project.
>I will gladly commit the new code to it.
>If not, what other options do you suggest.
>
What about creating an (experimental) branch for xmlform?
Vadim
>-=Ivelin=-
>
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
ivelin wrote:
>>That is not the issue. We mean that a "community" member
>>would discuss any perceived issue with their peers. You did
>>not provide cocoon-dev with feedback or notify about a problem.
>>
>>
>
>Over the last few months I have asked multiple times when is 2.1 going to be
>labeled Alpha.
>Maybe you did not follow my messages.
>When I indicated the problem with the ever moving and always about to be
>ready HEAD,
>Sylvain Walez told me to hush, because I was ruining the good spirit of the
>community.
>
Are you referring to
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104421545406191&w=2 ?
I never told you to hush, but said that, rather than complaining about
"others" having broken "your" XMLForm "contribution", you could also get
your hands dirty and help fix it or at least give constructive comments.
The community I was referring to is Avalon, which has been hit so hard
by code ownership problems. And we, Cocoon community, don't want to see
this happen here.
Also, you asked several times "when will 2.1 be released" ? If this is
an itch that scratches you, then why not - again - getting your hands
dirty, if not on code, at least on a task schedule or some proposals ?
An OSS community is a loose group that is driven by the desires and
needs of its members. You cannot expect others to do something for you
unless then find some interest in it. And complaining is not the right
way to gain people's interest.
And now you tell us that many people asked you privately about XMLForm.
Have you read Cocoon's "Who we are" page ? It says : "We ask that you
please do not send us emails privately asking for support. We are
non-paid volunteers who help out with the project and we do not
necessarily have the time or energy to help people on an individual
basis. Instead, we have setup mailing lists which often contain hundreds
of individuals who will help answer detailed requests for help. The
benefit of using mailing lists over private communication is that it is
a shared resource where others can also learn from common mistakes and
as a community we all grow together."
Why haven't you mentioned the problems raised by the private emails you
received to the list ? We could have solved them _together_.
>><snip/>
>>
>>
>>>>At least *I* honstely don't see a good reason for XMLForm
>>>>becoming it's own Apache project - sorry.
>>>>
>>>>
>>>Others disagree with you.
>>>I have been asked numerous times via private emails, if it
>>>can be used independently for smaller projects?
>>>It can be cleanly isolated and interfaced with cocoon via
>>>some sort of adapter.
>>>This only confirms the value and need for blocks.
>>>
>>>
>>Then why don't you stay and help us sort out the blocks.
>>
>>
>
>You are INcorrectly assuming that I have left Cocoon.
>There are a lot of people with strong opinions on the blocks.
>I do not feel like I can be of value at this stage.
>Nevertheless I am monitoring the progress and looking forward to a final design decision and an API.
>
>
>
>>There is no better place to ensure clean separation and
>>adaptability than here on cocoon-dev. We would actually
>>help clean up the xmlforms code, but going your way you
>>are on your own.
>>
>>
>
>I like Bertrand's idea of going Chaperon or jfor's way.
>
Preliminary note : I'm a happy JFor and Chaperon user.
IMO, Chaperon and JFor may be considered differently than XMLForm : one
of the main evolutions of Cocoon is going through is growing from a
publication framework to a web application framework. Flow script and
XMLForm are two important parts in this evolution. My opinion is that
XMLForm is more "core" to Cocoon than Chaperon and JFor.
>I see no reason why discussion should not be carried on cocoon-dev.
>In fact it already started... ;)
>I feel bad that it started somewhat sour, but I'm sure we'll work it out.
>
Ok, so please explain us what are the problems that were raised in
private emails.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by ivelin <iv...@apache.org>.
>
> That is not the issue. We mean that a "community" member
> would discuss any perceived issue with their peers. You did
> not provide cocoon-dev with feedback or notify about a problem.
Over the last few months I have asked multiple times when is 2.1 going to be
labeled Alpha.
Maybe you did not follow my messages.
When I indicated the problem with the ever moving and always about to be
ready HEAD,
Sylvain Walez told me to hush, because I was ruining the good spirit of the
community.
>
> <snip/>
> >
> > > At least *I* honstely don't see a good reason for XMLForm
> > > becoming it's own Apache project - sorry.
> >
> > Others disagree with you.
> > I have been asked numerous times via private emails, if it
> > can be used independently for smaller projects?
> > It can be cleanly isolated and interfaced with cocoon via
> > some sort of adapter.
> > This only confirms the value and need for blocks.
>
> Then why don't you stay and help us sort out the blocks.
You are INcorrectly assuming that I have left Cocoon.
There are a lot of people with strong opinions on the blocks.
I do not feel like I can be of value at this stage.
Nevertheless I am monitoring the progress and looking forward to a final
design decision and an API.
> There is no better place to ensure clean separation and
> adaptability than here on cocoon-dev. We would actually
> help clean up the xmlforms code, but going your way you
> are on your own.
I like Bertrand's idea of going Chaperon or jfor's way.
I see no reason why discussion should not be carried on cocoon-dev.
In fact it already started... ;)
I feel bad that it started somewhat sour, but I'm sure we'll work it out.
Ivelin
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by David Crossley <cr...@indexgeo.com.au>.
ivelin wrote:
>
(And why did he not make any attempt to attribute who said what?)
>
> Someone said:
> > I am sure goodwill is a main reason but some question come to my mind
> >
> > *) why don't you wanna share your thoughts with us and let us
> > (or at least some of us) together steer the direction of XMLForms?
>
> Wrong assumption!
> I always welcome feedback, comments and improvements, even if I
> don't agree with some of them.
That is not the issue. We mean that a "community" member
would discuss any perceived issue with their peers. You did
not provide cocoon-dev with feedback or notify about a problem.
<snip/>
>
> > At least *I* honstely don't see a good reason for XMLForm
> > becoming it's own Apache project - sorry.
>
> Others disagree with you.
> I have been asked numerous times via private emails, if it
> can be used independently for smaller projects?
> It can be cleanly isolated and interfaced with cocoon via
> some sort of adapter.
> This only confirms the value and need for blocks.
Then why don't you stay and help us sort out the blocks.
There is no better place to ensure clean separation and
adaptability than here on cocoon-dev. We would actually
help clean up the xmlforms code, but going your way you
are on your own.
--David
Re: [ANN] XMLForm as a standalone servlet toolkit (decoupling XMLForm?)
Posted by ivelin <iv...@apache.org>.
This is what I consider best of both worlds.
At this point I can use some more specific direction?
One way is to maintain the cocoon.action.XMLFormAction and
cocoon.transformation.XMLFormTransformer,
while the rest of the XMLForm code can be isolated.
Other ideas?
-=Ivelin=-
----- Original Message -----
From: "Bertrand Delacretaz" <bd...@codeconsult.ch>
To: <co...@xml.apache.org>
Sent: Friday, March 28, 2003 11:02 AM
Subject: Re: [ANN] XMLForm as a standalone servlet toolkit (decoupling
XMLForm?)
Le Vendredi, 28 mars 2003, à 17:58 Europe/Zurich, Bertrand Delacretaz a
écrit :
> ...Then it might be ideal to refactor and just take the *core XMLForm*
> out of Cocoon as a separate project...
Let me correct myself here: if XMLForm is cleanly decoupled from the
rest of Cocoon it does not have to be hosted elsewhere, the code could
stay here with maybe an alternate build for the standalone XMLForm?
This would let you benefit from this community *and* from standalone
users.
-Bertrand=
Re: [ANN] XMLForm as a standalone servlet toolkit (decoupling XMLForm?)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 28 mars 2003, à 17:58 Europe/Zurich, Bertrand Delacretaz a
écrit :
> ...Then it might be ideal to refactor and just take the *core XMLForm*
> out of Cocoon as a separate project...
Let me correct myself here: if XMLForm is cleanly decoupled from the
rest of Cocoon it does not have to be hosted elsewhere, the code could
stay here with maybe an alternate build for the standalone XMLForm?
This would let you benefit from this community *and* from standalone
users.
-Bertrand
Re: [ANN] XMLForm as a standalone servlet toolkit (decoupling XMLForm?)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 28 mars 2003, à 15:40 Europe/Zurich, ivelin a écrit :
> ...I have been asked numerous times via private emails, if it can be
> used
> independently for smaller projects?
> It can be cleanly isolated and interfaced with cocoon via some sort of
> adapter....
Then it might be ideal to refactor and just take the *core XMLForm* out
of Cocoon as a separate project, like Chaperon and jfor do for example,
they are hosted on SF with just minimal adapter stuff in the Cocoon
codebase and use ASF-compatible licenses.
If you could do this first and *then* move the core XMLForm out of
Cocoon it might be much better technically (=decoupling) and
community-wise than having an external project than strongly depends on
Cocoon code and vice-versa.
-Bertrand
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by ivelin <iv...@apache.org>.
> > Let me explain, maybe the goodwill will prevail.
> > Otherwise this will turn into another example of a sad finish of an
exciting
> > jorney.
>
> <snip/>
>
> I am sure goodwill is a main reason but some question come to my mind
>
> *) why don't you wanna share your thoughts with us and let us
> (or at least some of us) together steer the direction of XMLForms?
Wrong assumption!
I always welcome feedback, comments and improvements, even if I don't agree
with some of them.
>
> *) how do you wanna contribute back? this might become harder as
> we currently might think. the "standalone version" thing really
> points that way.
>
> *) project and communication wise this might give an unwanted
> perspective that XMLForm might not be maintained under the
> cocoon umbrella anymore. not a good marketing...
I don't like hosting elsewhere either, but what are the options?
>
> *) why don't you go the scratchpad way?
Does this mean that in order for someone who wants to help with the
experimental code to build and run,
they will have to get and build the whole latest 2.1 HEAD? If so, then not a
good option.
Too many moving parts in 2.1., a lot of dependencies and coupling. I want to
focus on one thing at a time.
If we can dedicate a piece in scratchpad to build a module which can be
build and use on its own, then that's cool, I'll go for it.
> Is that the main reason for this - you wanna catch up with the XForms
> standard?
What do you mean?
Look at Chiba
> At least *I* honstely don't see a good reason for XMLForm becoming it's
> own Apache project - sorry.
Others disagree with you.
I have been asked numerous times via private emails, if it can be used
independently for smaller projects?
It can be cleanly isolated and interfaced with cocoon via some sort of
adapter.
This only confirms the value and need for blocks.
Ivelin
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt wrote:
>> Let me explain, maybe the goodwill will prevail.
>> Otherwise this will turn into another example of a sad finish of an
>> exciting
>> jorney.
>
>
> <snip/>
>
> I am sure goodwill is a main reason but some question come to my mind
>
> *) why don't you wanna share your thoughts with us and let us
> (or at least some of us) together steer the direction of XMLForms?
>
> *) how do you wanna contribute back? this might become harder as
> we currently might think. the "standalone version" thing really
> points that way.
>
> *) project and communication wise this might give an unwanted
> perspective that XMLForm might not be maintained under the
> cocoon umbrella anymore. not a good marketing...
>
> *) why don't you go the scratchpad way?
>
>
>> Now, let's do some constructive talking.
>>
>> You probably remember the endless threads that were started in the
>> last few
>> months regarding the complexity of Cocoon and the fact that it
>> continuously
>> misses its release dates.
>> I am only refering to them to point out that not everything is perfect
>> around here.
>>
>> More specificly:
>> As it stands XMLForm is way behind the XForms standards.
>
>
> Is that the main reason for this - you wanna catch up with the XForms
> standard?
>
> <snip/>
>
>> So, Stefano, since you have your PMC chairman hat on, tell me if we can
>> create an incubator project.
>> I will gladly commit the new code to it.
>> If not, what other options do you suggest.
>
>
> At least *I* honstely don't see a good reason for XMLForm becoming it's
> own Apache project - sorry.
>
> Why not scratchpad?
I fully agree with the above.
Ivelin, if you have some ideas about XMLForm, why don't you want to
discuss them here ?
Also, one of the purpose of blocks is to allow different areas of Cocoon
to have different levels of maturity : a block can be marked as
alpha/unstable. So why not working with the community in an "XMLForm2"
block ?
XMLForm is an important new feature in 2.1, and many people already use
it. So let's make it better together here.
What I foresee if you fork it is that Cocoon's XMLForm will evolve
quickly in response to its user feedback, while you will be let alone on
your side with your fork with no community to provide you features and
enhancements. Is this what you want ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Torsten Curdt <tc...@dff.st>.
> Let me explain, maybe the goodwill will prevail.
> Otherwise this will turn into another example of a sad finish of an exciting
> jorney.
<snip/>
I am sure goodwill is a main reason but some question come to my mind
*) why don't you wanna share your thoughts with us and let us
(or at least some of us) together steer the direction of XMLForms?
*) how do you wanna contribute back? this might become harder as
we currently might think. the "standalone version" thing really
points that way.
*) project and communication wise this might give an unwanted
perspective that XMLForm might not be maintained under the
cocoon umbrella anymore. not a good marketing...
*) why don't you go the scratchpad way?
> Now, let's do some constructive talking.
>
> You probably remember the endless threads that were started in the last few
> months regarding the complexity of Cocoon and the fact that it continuously
> misses its release dates.
> I am only refering to them to point out that not everything is perfect
> around here.
>
> More specificly:
> As it stands XMLForm is way behind the XForms standards.
Is that the main reason for this - you wanna catch up with the XForms
standard?
<snip/>
> So, Stefano, since you have your PMC chairman hat on, tell me if we can
> create an incubator project.
> I will gladly commit the new code to it.
> If not, what other options do you suggest.
At least *I* honstely don't see a good reason for XMLForm becoming it's
own Apache project - sorry.
Why not scratchpad?
--
Torsten
RE: [ANN] XMLForm as a standalone servlet toolkit
Posted by Reinhard Pötz <re...@gmx.net>.
Ivelin,
> From: ivelin [mailto:ivelin@apache.org]
>
> Now, let's do some constructive talking.
>
> You probably remember the endless threads that were started
> in the last few months regarding the complexity of Cocoon and
> the fact that it continuously misses its release dates. I am
> only refering to them to point out that not everything is
> perfect around here.
>
> More specificly:
> As it stands XMLForm is way behind the XForms standards.
> It was about a year ago when Torsten, Konstantin, and I
> invested a lot of time to bring to light the initial version
> of what seems to be a significant improvement to Cocoon.
> Since then it has been polished by many people and stabilized
> somewhere around September last year. Ever since, I have been
> planning to invest time into another major release which
> would bring the module up to the latest standards. However
> such an initiative will obviously require a lot of
> discussions, trial, errors and rollbacks, I did not want to
> jeopardize the 2.1 release which has been first planned for
> release in November and has been postponed indefinitely ever
> since. It is hard to not notice that C2.1 has been in the
> "clean-up" stage forever. I understand that moving to a top
> level domain is time consuming and it is very important for
> the future of the project.
>From my point of view please don't move out the further development of
XMLForms from the Cocoon CVS. I think the Cocoon control flow would have
never become part of Cocoon if Ovidiu had created his own project ...
(but mayme I'm wrong here).
But there are also some other reasons to have the further development of
XMLForms within Cocoon:
- there are many other parts of Cocoon which are changing (control
flow) or
newly created - you can integrate them into XMLForms at once
- you can freeze the current status of XMLForms for
the upcoming Cocoon 2.1 distribution and put the new
development in
- there are many developers and lurkers who have a look at cocoon-dev
- XMLForms are an integral part of Cocoon (a framework within the
framework) and should be developed by the community
(what would you do if you make further developments within your
sourceforge project and then you come back to Cocoon and ask
for a vote to include it and your vote is not accepted because
of some reasons e.g. incompatible changes, ...)
Only some thoughts of a XMLForms user ...
Best regards,
Reinhard
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by ivelin <iv...@apache.org>.
Let me explain, maybe the goodwill will prevail.
Otherwise this will turn into another example of a sad finish of an exciting
jorney.
Threats will not lead to the best outcome, so drop them.
It is trivial to change the package names and include the ASF license in the
distribution.
All other "legal issues" can be worked out as well.
I have not breached a signed contract or intentionally harmed anyone, so
back off and open your minds.
If not helped too much, I have at least not caused any harm to this
community so it is the least to say surprising to see such reactions.
Now, let's do some constructive talking.
You probably remember the endless threads that were started in the last few
months regarding the complexity of Cocoon and the fact that it continuously
misses its release dates.
I am only refering to them to point out that not everything is perfect
around here.
More specificly:
As it stands XMLForm is way behind the XForms standards.
It was about a year ago when Torsten, Konstantin, and I invested a lot of
time to bring to light the initial version of what seems to be a significant
improvement to Cocoon.
Since then it has been polished by many people and stabilized somewhere
around September last year.
Ever since, I have been planning to invest time into another major release
which would bring the module up to the latest standards.
However such an initiative will obviously require a lot of discussions,
trial, errors and rollbacks, I did not want to jeopardize the 2.1 release
which has been first planned for release in November and has been postponed
indefinitely ever since.
It is hard to not notice that C2.1 has been in the "clean-up" stage forever.
I understand that moving to a top level domain is time consuming and it is
very important for the future of the project.
So, Stefano, since you have your PMC chairman hat on, tell me if we can
create an incubator project.
I will gladly commit the new code to it.
If not, what other options do you suggest.
-=Ivelin=-
----- Original Message -----
From: "Pier Fumagalli" <pi...@betaversion.org>
To: <co...@xml.apache.org>
Sent: Thursday, March 27, 2003 9:07 PM
Subject: Re: [ANN] XMLForm as a standalone servlet toolkit
> On 28/3/03 0:41, "Gianugo Rabellino" <gi...@apache.org> wrote:
>
> > What am I missing?
>
> org.APACHE...
>
> That name is protected by the license AFAIK, but am no lawyer at all...
>
> Plus, I believe that we have some board resolution implying that all code
> owned and copyrighted by the ASF must be stored and actively developed on
> the ASF managed infrastructure...
>
> Basically, you can MIRROR a cvs tree, but the minute you contribute to it
it
> becomes a "product derived" of some sort, and therefore follows another
path
> (you can't use the "Apache" name, the copyright must be different)...
>
> Basically everything developed outside of our infrastructure NEEDS to have
> to have a "copyright transfer" license signed by all parties... It's a
> friggin' mess (headache warning ahead) :-(
>
> If it isn't "illegal", let's put another word there: the code is
> "unacceptable" by the foundation (as far as my understanding goes)
>
> I'm no lawyer, nor I want to make a stance of good or bad intentions (I'm
> not a community activist either)... Just reporting what I grasped given my
> position on the infrastructure PMC and being a member...
>
> (Read: see Jakarta's Maven example in recent times)
>
> Pier
>
> BTW (and I have to say this) with this email I don't pretend to endorse
any
> whatsoever rule or regulation dictated or implied by the Apache Software
> Foundation itself. The view expressed above only is my own, gathered from
my
> experience and my very little and inadequate understanding of law. In any
> whatsoever case, my views do not represent nor endorse the Foundation
> "official" view on the matter. For official clarification by the ASF, the
> only authority I can see is the Foundation board either expressing them
> directly or through his appointed PMC representative (in the Cocoon PMC I
> believe this person is Stefano, but not being on the PMC, I lost track of
> that as well).
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 28/3/03 0:41, "Gianugo Rabellino" <gi...@apache.org> wrote:
> What am I missing?
org.APACHE...
That name is protected by the license AFAIK, but am no lawyer at all...
Plus, I believe that we have some board resolution implying that all code
owned and copyrighted by the ASF must be stored and actively developed on
the ASF managed infrastructure...
Basically, you can MIRROR a cvs tree, but the minute you contribute to it it
becomes a "product derived" of some sort, and therefore follows another path
(you can't use the "Apache" name, the copyright must be different)...
Basically everything developed outside of our infrastructure NEEDS to have
to have a "copyright transfer" license signed by all parties... It's a
friggin' mess (headache warning ahead) :-(
If it isn't "illegal", let's put another word there: the code is
"unacceptable" by the foundation (as far as my understanding goes)
I'm no lawyer, nor I want to make a stance of good or bad intentions (I'm
not a community activist either)... Just reporting what I grasped given my
position on the infrastructure PMC and being a member...
(Read: see Jakarta's Maven example in recent times)
Pier
BTW (and I have to say this) with this email I don't pretend to endorse any
whatsoever rule or regulation dictated or implied by the Apache Software
Foundation itself. The view expressed above only is my own, gathered from my
experience and my very little and inadequate understanding of law. In any
whatsoever case, my views do not represent nor endorse the Foundation
"official" view on the matter. For official clarification by the ASF, the
only authority I can see is the Foundation board either expressing them
directly or through his appointed PMC representative (in the Cocoon PMC I
believe this person is Stefano, but not being on the PMC, I lost track of
that as well).
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
> I have looked at the code you distribute and you are in clear violation
> of the ASF license and the ASF guidelines for these reasons:
OK, I don't want to delve into whether Ivelin's move is right or not
from a community POV (but yes, I do share Steven and Torsten's
concerns). This email sounds a bit too much like a threat to me, while I
tend to assume that Ivelin was and is in good faith and unwilling to
hurt anyone.
Anyway, since you are making a point on legal stuff, with my lawyer hat
on, I'm afraid that either I misunderstood at all the Apache license or
you're just wrong when you say:
> 2) you are distributing ASF-copyrighted code from outside the ASF
> infrastructure.
I don't see what is the problem here: do you mean that I can't
distribute Cocoon, or HTTPD, or Tomcat on my very own FTP server? Why
that? Since when? The Apache license looks pretty clear to me when it
comes to freedom to redistribute stuff and indeed I don't see why and
how this can be seen as a violation. And if that's a violation, well...
I guess that there are plenty of Internet resources that are
As per package names, well... I guess it's questionable: I'm not sure
that articles 4 and 5 cover even package names: actually one might say
that *taking away* "org.apache" from the package name is a licence
violation since it's a way to hide where the software comes from. OTOH,
keeping those names might be confusing so I don't really know where to
stand. For sure it's not polite and savy, but I'm not dead sure that
it's illegal (meaning defendable in court).
What am I missing?
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
Re: [ANN] XMLForm as a standalone servlet toolkit
Posted by Stefano Mazzocchi <st...@apache.org>.
PMC chait hat on:
ivelin wrote:
> I've decided to extract XMLForm as a standalone toolkit in order to be able
> to faster develop experimental branches without affecting Cocoon.
I have looked at the code you distribute and you are in clear violation
of the ASF license and the ASF guidelines for these reasons:
1) you ship cocoon code without the license
2) you are distributing ASF-copyrighted code from outside the ASF
infrastructure.
3) you used the org.apache.xmlform namespace without authority
> The plan is to merge more successful advancements back into Cocoon.
...
> Also, it can hopefully be a jumping board for beginners and smaller projects
> that are not ready for the full sophistication of Cocoon.
Please, understand your move is illegal.
Resolve the above issues or I'll have to report this to the ASF board.
Stefano.