On Tue, Nov 10, 2009 at 11:57 AM, Branko Čibej <br...@xbc.nu> wrote: > Igor Burilo wrote: >> 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.
I gave counsel to the Eclipse Foundation and explained that they could provide a fully functioning JavaHL library to users with only EPL compatible code. Basically, you just need to build without Neon, BDB and libintl support. Of the three, the only thing an Eclipse client user needs is Neon, and Serf serves as a viable replacement. I do not know why they never chose to release a binary built this way. I can only assume that Igor and Polarion did not want to make these binaries. -- Thanks Mark Phippard http://markphip.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
