Rob Vermeulen wrote:
I have read that, oddly enough OpenSymphony's oscache, which uses
APL,
does ship with jgroups support built in. Apparentley they don't
think it is a problem.
You are right Rico, this is strange. Oscache is not a small open source
project.
Are they already being
I have read that, oddly enough OpenSymphony's oscache, which uses APL,
does ship with jgroups support built in. Apparentley they don't
think it is a problem.
You are right Rico, this is strange. Oscache is not a small open source
project.
Are they already being sued? ...
Rob
So I think the application where these classes are included (eg
MMBase-core) needs to follow section 6.
I agree with that, but that doesn't pose a challenge, because the
requirements are not that difficult to fullfill.
The problem isn't we can't
So where does this requirement to change our license come from ?
As far as I see we only need to comply to section 6, which requires
us as said above to allow new verions and reverse engineering of
our code to make it work (which is easy as we provide
On Fri, Apr 15, 2005 at 10:47:19AM +0200, Kees Jongenburger wrote:
So where does this requirement to change our license come from ?
As far as I see we only need to comply to section 6, which requires
us as said above to allow new verions and reverse engineering
Kees Jongenburger wrote:
So where does this requirement to change our license come from ?
As far as I see we only need to comply to section 6, which requires
us as said above to allow new verions and reverse engineering of
our code to make it work (which is easy as we
Joost Diepenmaat wrote:
On Fri, Apr 15, 2005 at 10:47:19AM +0200, Kees Jongenburger wrote:
So where does this requirement to change our license come from ?
As far as I see we only need to comply to section 6, which requires
us as said above to allow new verions and reverse