Re: [ANN] XMLForm as a standalone servlet toolkit

[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: License and patching/forking

[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

[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

[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)

[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.
> 
>