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.
