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.
