incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: [PROPOSAL][VOTE] Subversion
Date Tue, 10 Nov 2009 16:57:37 GMT
Igor Burilo wrote:
> C. Michael Pilato 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?
> Michael, sure Neon and Serf are optional and it’s absolutely correct from
> the legal point of view. But in this case SVN should work without DAV
> support, which is important for end-users.
> When we talk about licensing issues we mean problem with entire SVN
> acceptance and distribution. In particular, it’s a big problem for Eclipse
> community and companies that stay behind this community. To accept SVN they
> require a legally clean pre-built solution. It means that at least JavaHL
> client should be EPL (Apache 2.0) compatible. Now it doesn’t because of
> Neon. Sure, someone can tell – build distribution yourself with Serf, but we
> understand that result isn’t guaranteed at the current moment, so this
> solution will not be accepted. Another approach to allow users build library
> by themselves will not work, because require knowledge and experience from
> end-users.

I don't quite understand what you're getting at, but you appear to be
mixing up the concepts of "releasing" and "packaging". If the Eclipse
community requires a pre-built solution, then tough luck, they won't get
it from the Subversion project because we never have and never will
release anything but source code. If some package maintainer volunteers
to build binaries specifically for Eclipse, then said maintainer can do
it without including Neon or BDB or a few other optional bits and
pieces, and will end up with a functional Subversion client.

> At the current moment SVN client can’t pass legal review on Eclipse

(something I don't really care about, but) see above; we do not release
any code with an incompatible license.

>  and it
> means that SVN loosing its huge potential there. It’s a perfect example when
> nice technology is blocked by legal tricks. So the perfect solution will be
> to replace Neon by Serf, because it will resolve a lot of issues described
> above with SVN acceptance.

Frankly I've heard so many interesting things about the Eclipse process
from various sources that it appears to me that they're tripping
themselves up on imaginary technicalities. The statements you made about
Subversion's incompatibility with Eclipse seem bogus; since, as I said
above, all the potentially conflicting parts are completely optional and
do not have to be part of any binary package.

What am I missing?

-- Brane

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message