Binary release artifacts (or What a User Wants)

[Eric Evans <ee...@rackspace.com>]

During the 0.6 cycle Ivy was introduced to manage (most of) our
dependencies, and where possible, jars were removed from svn and no
longer included in binary release artifacts. Recently though this change
has been called into question, with some discussion taking place in
CASSANDRA-850[1].

The 0.6 release is upon us, but if consensus will be to rollback this
change and resume the practice of embedding third-party jars, I strongly
feel we should do that now. I don't want to see 0.6 as a one-off that
we're forced to explain over and over.

BACKGROUND

We've seen a steadily increasing list of dependencies, but it really
exploded between 0.5 and 0.6 (think 2x). This was causing a number of
problems:

1. First and foremost, we were doing a less than perfect job of
maintaining licensing and attribution. The exact requirements here
depend on a number of variables and are fraught with subtleties. Failure
to get this right creates legal risks that the ASF finds unacceptable so
doing it poorly is really not an option.

Ivy "fixed" this problem by side-stepping the issue entirely. If we
aren't shipping it, then there is simply no need to maintain this
documentation.

2. Many of these dependencies have dependencies in turn (and so on).
Sometimes these dependencies (or the dependencies of the dependencies,
etc) share dependencies with other dependencies, but with different
versions. Sound confusing? It can be, yes, and the complexity seems to
grow exponentially to the number of jars we're pulling in.

Ivy fixed this problem because this is precisely what Ivy does, it
resolves a graph of your project dependencies based on a specification
(ivy.xml), and retrieves them.

Or to put all of this more simply... tedious, time consuming, and error
prone tasks were automated away. This however did not come without a
price, and the costs that I see in order of importance are:

1. Downloading arbitrary code off the 'net, (and without a good trust
path).

2. Requiring networking connectivity at install time.

3. Requiring ant to be present at install time.

4. One extra step in the install process, (i.e. invoking `ant
ivy-retrieve')

I know a lot of people wouldn't consider (1) and (2) to be real issues,
(just look at how popular Maven is), so YMMV. I personally don't think
(3) and (4) are that onerous but I can't disagree with the
weird-to-require-a-build-tool argument, or that one more step in Getting
Started is still one more step.

So to me, this boils down to deciding whether the cure is worse than the
disease.

Thoughts?


[1]: https://issues.apache.org/jira/browse/CASSANDRA-850

-- 
Eric Evans
eevans@rackspace.com

Re: Binary release artifacts (or What a User Wants)

[Ian Holsman <li...@holsman.net>]

On 3/18/10 8:21 AM, Eric Evans wrote:
> During the 0.6 cycle Ivy was introduced to manage (most of) our
> dependencies, and where possible, jars were removed from svn and no
> longer included in binary release artifacts. Recently though this change
> has been called into question, with some discussion taking place in
> CASSANDRA-850[1].
>
> The 0.6 release is upon us, but if consensus will be to rollback this
> change and resume the practice of embedding third-party jars, I strongly
> feel we should do that now. I don't want to see 0.6 as a one-off that
> we're forced to explain over and over.
>    

my opinion is to keep ivy.
from what you said it is relatively painless for a customer to get the 
3rd party jars via ivy-retrieve on their build machine.

and I really hope people aren't just grabbing the jar file and deploying 
it in production ;-0

I don't see any negatives, except for the crazy developer who downloads 
the jar and gets on a plane for 5 hours, and kicks himself when he 
realizes he can't code.



> BACKGROUND
>
> We've seen a steadily increasing list of dependencies, but it really
> exploded between 0.5 and 0.6 (think 2x). This was causing a number of
> problems:
>
> 1. First and foremost, we were doing a less than perfect job of
> maintaining licensing and attribution. The exact requirements here
> depend on a number of variables and are fraught with subtleties. Failure
> to get this right creates legal risks that the ASF finds unacceptable so
> doing it poorly is really not an option.
>
> Ivy "fixed" this problem by side-stepping the issue entirely. If we
> aren't shipping it, then there is simply no need to maintain this
> documentation.
>
> 2. Many of these dependencies have dependencies in turn (and so on).
> Sometimes these dependencies (or the dependencies of the dependencies,
> etc) share dependencies with other dependencies, but with different
> versions. Sound confusing? It can be, yes, and the complexity seems to
> grow exponentially to the number of jars we're pulling in.
>
> Ivy fixed this problem because this is precisely what Ivy does, it
> resolves a graph of your project dependencies based on a specification
> (ivy.xml), and retrieves them.
>
> Or to put all of this more simply... tedious, time consuming, and error
> prone tasks were automated away. This however did not come without a
> price, and the costs that I see in order of importance are:
>
> 1. Downloading arbitrary code off the 'net, (and without a good trust
> path).
>
> 2. Requiring networking connectivity at install time.
>
> 3. Requiring ant to be present at install time.
>
> 4. One extra step in the install process, (i.e. invoking `ant
> ivy-retrieve')
>
> I know a lot of people wouldn't consider (1) and (2) to be real issues,
> (just look at how popular Maven is), so YMMV. I personally don't think
> (3) and (4) are that onerous but I can't disagree with the
> weird-to-require-a-build-tool argument, or that one more step in Getting
> Started is still one more step.
>
> So to me, this boils down to deciding whether the cure is worse than the
> disease.
>
> Thoughts?
>
>
> [1]: https://issues.apache.org/jira/browse/CASSANDRA-850
>
>    

Re: Binary release artifacts (or What a User Wants)

[Johan Oskarsson <jo...@oskarsson.nu>]

Paul Querna wrote:
> On Wed, Mar 17, 2010 at 4:21 PM, Eric Evans <ee...@rackspace.com> wrote:
>> During the 0.6 cycle Ivy was introduced to manage (most of) our
>> dependencies, and where possible, jars were removed from svn and no
>> longer included in binary release artifacts. Recently though this change
>> has been called into question, with some discussion taking place in
>> CASSANDRA-850[1].
>>
>> The 0.6 release is upon us, but if consensus will be to rollback this
>> change and resume the practice of embedding third-party jars, I strongly
>> feel we should do that now. I don't want to see 0.6 as a one-off that
>> we're forced to explain over and over.
>>
>> BACKGROUND
>>
>> We've seen a steadily increasing list of dependencies, but it really
>> exploded between 0.5 and 0.6 (think 2x). This was causing a number of
>> problems:
>>
>> 1. First and foremost, we were doing a less than perfect job of
>> maintaining licensing and attribution. The exact requirements here
>> depend on a number of variables and are fraught with subtleties. Failure
>> to get this right creates legal risks that the ASF finds unacceptable so
>> doing it poorly is really not an option.
>>
>> Ivy "fixed" this problem by side-stepping the issue entirely. If we
>> aren't shipping it, then there is simply no need to maintain this
>> documentation.
>>
>> 2. Many of these dependencies have dependencies in turn (and so on).
>> Sometimes these dependencies (or the dependencies of the dependencies,
>> etc) share dependencies with other dependencies, but with different
>> versions. Sound confusing? It can be, yes, and the complexity seems to
>> grow exponentially to the number of jars we're pulling in.
>>
>> Ivy fixed this problem because this is precisely what Ivy does, it
>> resolves a graph of your project dependencies based on a specification
>> (ivy.xml), and retrieves them.
>>
>> Or to put all of this more simply... tedious, time consuming, and error
>> prone tasks were automated away. This however did not come without a
>> price, and the costs that I see in order of importance are:
>>
>> 1. Downloading arbitrary code off the 'net, (and without a good trust
>> path).
>>
>> 2. Requiring networking connectivity at install time.
>>
>> 3. Requiring ant to be present at install time.
>>
>> 4. One extra step in the install process, (i.e. invoking `ant
>> ivy-retrieve')
>>
>> I know a lot of people wouldn't consider (1) and (2) to be real issues,
>> (just look at how popular Maven is), so YMMV. I personally don't think
>> (3) and (4) are that onerous but I can't disagree with the
>> weird-to-require-a-build-tool argument, or that one more step in Getting
>> Started is still one more step.
>>
>> So to me, this boils down to deciding whether the cure is worse than the
>> disease.
>>
>> Thoughts?
> 
> Lack of java-devness showing: Can't the -bin tarball just include the
> 'ivy-retrieve' step pre-done?
> 
> At least then everyone will test the same -bin, significantly reducing
> the lack of trusted path in problems 1 & 2.

This is what I would also suggest, I don't have anything against using 
ivy to fetch jars for developers. BUT what I think we should do is add 
the jar files downloaded by ivy to the binary distribution to make it as 
easy as possible for users, especially new ones.

I hope that at least one of the two developers (contributor and 
reviewer/committer) involved in any patches that add a new dependency 
would remember to add the correct information to the notice.

We should probably add a section about it here if we decide to go down 
this path: http://wiki.apache.org/cassandra/HowToContribute

Re: Binary release artifacts (or What a User Wants)

[Jesse McConnell <je...@gmail.com>]

>> yes, and my point is that if there is any question in your guys minds
>> on if it is allowed or not that is an issue for apache legal (via
>> jira) for a definitive answer
>>
>>
>
> so.. if you have a question for them.. go ping them.. no need anyone else to
> paraphrase it.. just go ahead and ask.
>

I think I was misunderstood, if so I am sorry...

to me this thread originates from developers of cassandra not clear on
what they can and can't do for distribution for cassandra releases (or
at least what they would need to do) and soliciting feedback on what
users want.

my feedback as a user of cassandra was that I think the idea of having
to install ant and use ivy to make a cassandra distribution usable is
hinky at best

my feedback as an apache committer and having dealt with a mess of
this licensing goop was that if the developers of cassandra have any
questions on what they can and can't do then they need to ask apache
legal

fwiw, I think Erik is completely correct in his thinking that they
aren't able to redistribute the ivy-retrieve goop without declaring
it.  its not like you could use gpl dependencies and just call it good
by running ant to download it after you installed your app and before
it was run.  I am sure some of the dependencies in question are
required to operate since I have had to bring them in to run cassandra
embedded...so I don't even know that the release process currently in
place is allowed but that is the PMC's responsibility to make sure
they follow apache policy, if they feel they are, great!

cheers!
jesse

Re: Binary release artifacts (or What a User Wants)

[Ian Holsman <li...@holsman.net>]

On 3/19/10 5:36 AM, Jesse McConnell wrote:
>
> yes, and my point is that if there is any question in your guys minds
> on if it is allowed or not that is an issue for apache legal (via
> jira) for a definitive answer
>
>    

so.. if you have a question for them.. go ping them.. no need anyone 
else to paraphrase it.. just go ahead and ask.

> I am not a lawyer, but I'll play one on a mailing list..
>    
please don't.
it doesn't help anyone.
if you think you need a legal opinion then get one.

you (and your companies) circumstances are unique, and as such you 
should hire your
own legal representation to analyze the situation and how it works in 
your circumstances. (called a legal opinion I think)

don't assume that your circumstances meet the need of the general public 
as every one is different.

we as a project do our best effort to make sure we have the right 
attribution and licensing.
but we are not lawyers, and our interpretation of what a license means 
might be different than yours.
even lawyers who have looked at these things aren't 100% in agreement to 
what cross-linking and stuff like that means
as it hasn't gone through a legal case where a judge has made a ruling 
which makes it harder to point to something and say this is the right stuff.


so .. let me repeat. if you think there is an issue, get your own lawyer 
to read the licenses and give you their legal opinion
and follow that. that is what they are there for.

Ivy and maven downloading dependent jars seems to work well for most 
projects. the legal thing about if they/can't they has been discussed to 
death
a million times.. go google it. there is no right answer.
> cheers!
> jesse
>
>    

Re: Binary release artifacts (or What a User Wants)

[Jesse McConnell <je...@gmail.com>]

> 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).
>

yes, and my point is that if there is any question in your guys minds
on if it is allowed or not that is an issue for apache legal (via
jira) for a definitive answer

I am not a lawyer, but I'll play one on a mailing list..

As a consumer of the cassandra project it is of critical importance
that I am clearly given what license and attribution is required for
both cassandra and any underlying dependencies which are required for
it to operate at its base functionality.  In my mind any tactic to get
around the spirit of the apache license or release policy to this
effect would be a 'bad thing' (tm).

Yes the onus is on me to validate that any system I deploy or software
that I write does not violate my personal or corporate polices, this
is not an area to play fast and loose with.  Clear attribution and
licensing is critically important in this day and age.

I would certainly be responsible for managing licensing for any third
party libraries I wanted to use to connect to cassandra as a client of
course if I was using something not distributed with cassandra itself.

I suspect you'll have to bite the bullet, but if there is any
confusion on the correct way to go with this, passing it by legal is
the way to go.

cheers!
jesse

Re: Binary release artifacts (or What a User Wants)

[Eric Evans <ee...@rackspace.com>]

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
> 
> http://www.apache.org/legal/resolved.html
> 
> 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
eevans@rackspace.com

Re: Binary release artifacts (or What a User Wants)

[Jesse McConnell <je...@gmail.com>]

> 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

http://www.apache.org/legal/resolved.html

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

cheers,
jesse


>> apache legal has been very helpful on this in the past for maven, and
>> the maven release process has done a lot of work in terms of making
>> the release process at apache sane and legal
>
> I've tried to find comparable maven or ivy-based projects to see how
> others handle this, (without luck). Comparable here means having release
> artifacts that are more than just jars, (i.e. containing config samples,
> startup scripts, etc), with dependencies not developed at the ASF, and
> which cover a range of different licensing (MIT, BSD, Public domain,
> etc).
>
> Again, having our cake and eating too would be better than choosing the
> lesser of evils, so any suggestions would be well received.
>
> --
> Eric Evans
> eevans@rackspace.com
>
>

Re: Binary release artifacts (or What a User Wants)

[Eric Evans <ee...@rackspace.com>]

On Thu, 2010-03-18 at 09:28 -0600, Jesse McConnell wrote:
> >> +1 to have your official 'distribution' contain everything needed
> to
> >> run
> >
> > It remains to be seen whether this can legally be done.
> 
> sorry, I didn't see which artifacts would be problematic for this,
> could you call them out?

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).

> apache legal has been very helpful on this in the past for maven, and
> the maven release process has done a lot of work in terms of making
> the release process at apache sane and legal 

I've tried to find comparable maven or ivy-based projects to see how
others handle this, (without luck). Comparable here means having release
artifacts that are more than just jars, (i.e. containing config samples,
startup scripts, etc), with dependencies not developed at the ASF, and
which cover a range of different licensing (MIT, BSD, Public domain,
etc).

Again, having our cake and eating too would be better than choosing the
lesser of evils, so any suggestions would be well received.

-- 
Eric Evans
eevans@rackspace.com

Re: Binary release artifacts (or What a User Wants)

[Jesse McConnell <je...@gmail.com>]

>> +1 to have your official 'distribution' contain everything needed to
>> run
>
> It remains to be seen whether this can legally be done.

sorry, I didn't see which artifacts would be problematic for this,
could you call them out?

apache legal has been very helpful on this in the past for maven, and
the maven release process has done a lot of work in terms of making
the release process at apache sane and legal

jesse

Re: Binary release artifacts (or What a User Wants)

[Eric Evans <ee...@rackspace.com>]

On Thu, 2010-03-18 at 10:13 -0500, Jesse McConnell wrote:
> imo the 'distribution' you produce should come bundled with everything
> you need to run it, it is very awkward to drop the distro on a bare
> box and then have to install ant just to bootstrap that distribution
> into a usable state

No one is arguing that bundling wouldn't make it easier, or that it
shouldn't be as easy as we can reasonably make it.

> +1 to use ivy to not park jars in svn
> 
> +1 to have your official 'distribution' contain everything needed to
> run 

It remains to be seen whether this can legally be done.

-- 
Eric Evans
eevans@rackspace.com

Re: Binary release artifacts (or What a User Wants)

[Jesse McConnell <je...@gmail.com>]

imo the 'distribution' you produce should come bundled with everything
you need to run it, it is very awkward to drop the distro on a bare
box and then have to install ant just to bootstrap that distribution
into a usable state

+1 to use ivy to not park jars in svn

+1 to have your official 'distribution' contain everything needed to run

jesse

--
jesse mcconnell
jesse.mcconnell@gmail.com



On Thu, Mar 18, 2010 at 10:10, Eric Evans <ee...@rackspace.com> wrote:
> On Wed, 2010-03-17 at 23:32 -0500, Paul Querna wrote:
>> > Lack of java-devness showing: Can't the -bin tarball just include
>> the
>> > 'ivy-retrieve' step pre-done?
>> >
>> > At least then everyone will test the same -bin, significantly
>> reducing
>> > the lack of trusted path in problems 1 & 2.
>> >
>>
>> Sorry, forgot to finish with bits about the legal parts.
>>
>> Most (all?) the language about NOTICE and LICESE files is specifically
>> related to the source distribution, not the release artifacts -- as
>> long as anyone else can get the same binary artifacts from the source
>> that was voted on, what is actually contained in the binary artifacts
>> is much less concerning, as long as we do respect the licenses of the
>> things we include.
>
> I would love for this to be OK, but I'm skeptical that it is. Both the
> BSD and AL licenses explicitly state that you must include license and
> attribution when redistributing ("in Source or Object form").
>
>> C-dev-world: We build win32 binaries using msvc. We distribute them,
>> even distribute mod_ssl, which has a large dependency on OpenSSL, but
>> AFAIK we don't go around appending the entire OpenSSL License to the
>> httpd's LICENSE or NOTICE files?
>
> But you aren't actually shipping OpenSSL (in source or binary) are you?
> mod_ssl is only linked against OpenSSL?
>
> --
> Eric Evans
> eevans@rackspace.com
>
>

Re: Binary release artifacts (or What a User Wants)

[Eric Evans <ee...@rackspace.com>]

On Wed, 2010-03-17 at 23:32 -0500, Paul Querna wrote:
> > Lack of java-devness showing: Can't the -bin tarball just include
> the
> > 'ivy-retrieve' step pre-done?
> >
> > At least then everyone will test the same -bin, significantly
> reducing
> > the lack of trusted path in problems 1 & 2.
> >
> 
> Sorry, forgot to finish with bits about the legal parts.
> 
> Most (all?) the language about NOTICE and LICESE files is specifically
> related to the source distribution, not the release artifacts -- as
> long as anyone else can get the same binary artifacts from the source
> that was voted on, what is actually contained in the binary artifacts
> is much less concerning, as long as we do respect the licenses of the
> things we include.

I would love for this to be OK, but I'm skeptical that it is. Both the
BSD and AL licenses explicitly state that you must include license and
attribution when redistributing ("in Source or Object form").

> C-dev-world: We build win32 binaries using msvc. We distribute them,
> even distribute mod_ssl, which has a large dependency on OpenSSL, but
> AFAIK we don't go around appending the entire OpenSSL License to the
> httpd's LICENSE or NOTICE files?

But you aren't actually shipping OpenSSL (in source or binary) are you?
mod_ssl is only linked against OpenSSL?

-- 
Eric Evans
eevans@rackspace.com

Re: Binary release artifacts (or What a User Wants)

[Paul Querna <pa...@querna.org>]

On Wed, Mar 17, 2010 at 11:24 PM, Paul Querna <pa...@querna.org> wrote:
> On Wed, Mar 17, 2010 at 4:21 PM, Eric Evans <ee...@rackspace.com> wrote:
>>
>> During the 0.6 cycle Ivy was introduced to manage (most of) our
>> dependencies, and where possible, jars were removed from svn and no
>> longer included in binary release artifacts. Recently though this change
>> has been called into question, with some discussion taking place in
>> CASSANDRA-850[1].
>>
>> The 0.6 release is upon us, but if consensus will be to rollback this
>> change and resume the practice of embedding third-party jars, I strongly
>> feel we should do that now. I don't want to see 0.6 as a one-off that
>> we're forced to explain over and over.
>>
>> BACKGROUND
>>
>> We've seen a steadily increasing list of dependencies, but it really
>> exploded between 0.5 and 0.6 (think 2x). This was causing a number of
>> problems:
>>
>> 1. First and foremost, we were doing a less than perfect job of
>> maintaining licensing and attribution. The exact requirements here
>> depend on a number of variables and are fraught with subtleties. Failure
>> to get this right creates legal risks that the ASF finds unacceptable so
>> doing it poorly is really not an option.
>>
>> Ivy "fixed" this problem by side-stepping the issue entirely. If we
>> aren't shipping it, then there is simply no need to maintain this
>> documentation.
>>
>> 2. Many of these dependencies have dependencies in turn (and so on).
>> Sometimes these dependencies (or the dependencies of the dependencies,
>> etc) share dependencies with other dependencies, but with different
>> versions. Sound confusing? It can be, yes, and the complexity seems to
>> grow exponentially to the number of jars we're pulling in.
>>
>> Ivy fixed this problem because this is precisely what Ivy does, it
>> resolves a graph of your project dependencies based on a specification
>> (ivy.xml), and retrieves them.
>>
>> Or to put all of this more simply... tedious, time consuming, and error
>> prone tasks were automated away. This however did not come without a
>> price, and the costs that I see in order of importance are:
>>
>> 1. Downloading arbitrary code off the 'net, (and without a good trust
>> path).
>>
>> 2. Requiring networking connectivity at install time.
>>
>> 3. Requiring ant to be present at install time.
>>
>> 4. One extra step in the install process, (i.e. invoking `ant
>> ivy-retrieve')
>>
>> I know a lot of people wouldn't consider (1) and (2) to be real issues,
>> (just look at how popular Maven is), so YMMV. I personally don't think
>> (3) and (4) are that onerous but I can't disagree with the
>> weird-to-require-a-build-tool argument, or that one more step in Getting
>> Started is still one more step.
>>
>> So to me, this boils down to deciding whether the cure is worse than the
>> disease.
>>
>> Thoughts?
>
> Lack of java-devness showing: Can't the -bin tarball just include the
> 'ivy-retrieve' step pre-done?
>
> At least then everyone will test the same -bin, significantly reducing
> the lack of trusted path in problems 1 & 2.
>

Sorry, forgot to finish with bits about the legal parts.

Most (all?) the language about NOTICE and LICESE files is specifically
related to the source distribution, not the release artifacts -- as
long as anyone else can get the same binary artifacts from the source
that was voted on, what is actually contained in the binary artifacts
is much less concerning, as long as we do respect the licenses of the
things we include.

C-dev-world: We build win32 binaries using msvc. We distribute them,
even distribute mod_ssl, which has a large dependency on OpenSSL, but
AFAIK we don't go around appending the entire OpenSSL License to the
httpd's LICENSE or NOTICE files?

Maybe httpd is wrong, but rules causing so much pain shouldn't exist
unless there really is a legal basis for them, not some half finished
recommendation on the Incubator website.

Re: Binary release artifacts (or What a User Wants)

[Paul Querna <pa...@querna.org>]

On Wed, Mar 17, 2010 at 4:21 PM, Eric Evans <ee...@rackspace.com> wrote:
>
> During the 0.6 cycle Ivy was introduced to manage (most of) our
> dependencies, and where possible, jars were removed from svn and no
> longer included in binary release artifacts. Recently though this change
> has been called into question, with some discussion taking place in
> CASSANDRA-850[1].
>
> The 0.6 release is upon us, but if consensus will be to rollback this
> change and resume the practice of embedding third-party jars, I strongly
> feel we should do that now. I don't want to see 0.6 as a one-off that
> we're forced to explain over and over.
>
> BACKGROUND
>
> We've seen a steadily increasing list of dependencies, but it really
> exploded between 0.5 and 0.6 (think 2x). This was causing a number of
> problems:
>
> 1. First and foremost, we were doing a less than perfect job of
> maintaining licensing and attribution. The exact requirements here
> depend on a number of variables and are fraught with subtleties. Failure
> to get this right creates legal risks that the ASF finds unacceptable so
> doing it poorly is really not an option.
>
> Ivy "fixed" this problem by side-stepping the issue entirely. If we
> aren't shipping it, then there is simply no need to maintain this
> documentation.
>
> 2. Many of these dependencies have dependencies in turn (and so on).
> Sometimes these dependencies (or the dependencies of the dependencies,
> etc) share dependencies with other dependencies, but with different
> versions. Sound confusing? It can be, yes, and the complexity seems to
> grow exponentially to the number of jars we're pulling in.
>
> Ivy fixed this problem because this is precisely what Ivy does, it
> resolves a graph of your project dependencies based on a specification
> (ivy.xml), and retrieves them.
>
> Or to put all of this more simply... tedious, time consuming, and error
> prone tasks were automated away. This however did not come without a
> price, and the costs that I see in order of importance are:
>
> 1. Downloading arbitrary code off the 'net, (and without a good trust
> path).
>
> 2. Requiring networking connectivity at install time.
>
> 3. Requiring ant to be present at install time.
>
> 4. One extra step in the install process, (i.e. invoking `ant
> ivy-retrieve')
>
> I know a lot of people wouldn't consider (1) and (2) to be real issues,
> (just look at how popular Maven is), so YMMV. I personally don't think
> (3) and (4) are that onerous but I can't disagree with the
> weird-to-require-a-build-tool argument, or that one more step in Getting
> Started is still one more step.
>
> So to me, this boils down to deciding whether the cure is worse than the
> disease.
>
> Thoughts?

Lack of java-devness showing: Can't the -bin tarball just include the
'ivy-retrieve' step pre-done?

At least then everyone will test the same -bin, significantly reducing
the lack of trusted path in problems 1 & 2.