On Nov 10, 2009, at 9:16 AM, Mark Phippard wrote: > On Tue, Nov 10, 2009 at 10:10 AM, Greg Stein <gst...@gmail.com> wrote: >> On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato <cmpil...@collab.net> wrote: >>> ... >>> I certainly understand why license issues would be a concern. But I could >>> use an education about why this particular case matters. We currently ship >>> Neon in a separate tarball from Subversion's core code for the convenience >>> of our users, but if that's a problem, we can stop doing so. Subversion >>> doesn't require Neon. Or Serf. You can have a perfectly valid, working, >>> Subversion client and server that doesn't use a DAV layer at all. The >>> Subversion community has never released binaries -- ever -- not do we plan >>> to. So users and package maintainers are free to assemble Subversion with >>> the optional bits they care to provide for their consumers. >>> >>> Igor, is there a particular concern that you can elaborate on here if only >>> for my education? >> >> If the Apache software is *non-functional* without the LGPL software, >> then you are effectively requiring downstream users to link themselves >> into the LGPL licensing. >> >> Since Subversion does not require any LGPL to function, then we should >> be just fine. I plan to run this past legal-discuss for verification >> (along with our optional GNOME, KDE, and BDB dependencies). I seem to >> recall from the legal web pages there is no specific mention of our >> case, so wanted to double-check and then possible add our use-case to >> those pages. >> >> Regarding serf and Neon, I think that serf will be just fine to have >> as a default. It has been totally functional for many of us (cmpilato >> is a serf skeptic :-P) > > He is not the only one :) > > That said, I think the point is why should the default matter? We can > either optionally use Neon or we cannot. Even if Neon is the default, > if someone builds with only Serf then it becomes the default. > > As Mike says, we do not provide binaries so we will not be asking to > distribute any of these libraries. We will need to find out if it is > OK to still supply our dependencies tarball for convenience.
And if we can't ship the deps tarballs, you won't find me (the current release manager) shedding any tears. I don't have any statistics to back it up, but I tend to thinks the deps tarball is pretty underutilized. I don't think it would have a negative impact on our users or release process. -Hyrum --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org