cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <>
Subject Re: Binary release artifacts (or What a User Wants)
Date Thu, 18 Mar 2010 16:46:05 GMT
On Thu, 2010-03-18 at 10:15 -0600, Jesse McConnell wrote:
> > The binary release artifacts created by the `release' target in
> > build.xml, (they look something like
> > apache-cassandra-$VERSION-bin.tar.gz on the mirrors).
> actually I was asking about the problematic artifacts inside that
> distribution that were in question as to whether you could
> redistribute or not, the licenses mentioned below are enough to go on
> looking through there ought to answer a lot of the questions, but if
> your in doubt on anything in particular I would recommend assembling a
> list of all the dependencies you want to redistibute and their
> associated licenses and compile it all into an issue on the LEGAL jira
> project.
> that way you guys are clear on what you can and can't redistribute in
> official apache releases 

This is not an issue of whether or not we can distribute these jars, (we
can). It boils down to the _requirements_ of distributing them, i.e. the
inclusion of license text and attribution notices as required.

So long as we are properly documenting license and attribution, we can
check all of these jars into subversion and ship them in our release
artifacts. No one is disputing this. We used to do this.

If we are not distributing them at all, then there is no requirement
that we include this documentation. No one is disputing this. This is
how we are doing it now.

It has been suggested that we dynamically retrieve these third-party
jars using Ivy and add them to the binary release artifact without the
licensing and attribution documentation. This would be *awesome*. One 4
line patch applied to build.xml and everyone gets what they want.
However, I am disputing the notion that we can legally distribute these
third-party jars this way. I don't think we can (I want to be wrong).

Eric Evans

View raw message