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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
