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.

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