Bugzilla – Full Text Bug Listing
| Summary: | Voting: Subclipse as default SVN support provider | ||
|---|---|---|---|
| Product: | Community | Reporter: | anatoly techtonik <techtonik> |
| Component: | Cross-Project | Assignee: | Cross-Project issues <cross-project.inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, eclipse.org-architecture-council, gunnar, igor.burilo, markphip, Mike_Wilson, mober.at+eclipse, oisin.hurley, prakash, remy.suen, Szymon.Brandys, tomasz.zarna, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
anatoly techtonik
#284551 is the alternative proposal. Actual link is bug #284551. There is a license issue that prevents from bundling Subclipse into Eclipse SDK. IMO this is also a reason why Subclipse is not available on Eclipse update sites. I'm afraid that first Subclipse would have to become and Eclipse Foundation project. Then we could have this voting. Right now this is INVALID or at least WONTFIX. Mike, should I move it to Community/Cross-Project (or any other category)? Subclipse is licensed under Eclipse Public License - v 1.0. If Eclipse license is not allowed in Eclipse then please state why, so the rest of us could get a picture. In any case everybody should be free to vote to express their opinion even if lawyers won't allow to pack Subclipse into Eclipse distribution. (In reply to comment #4) > Subclipse is licensed under Eclipse Public License - v 1.0. If Eclipse license > is not allowed in Eclipse then please state why, so the rest of us could get a > picture. If I'm not wrong, Subclipse depends on the libraries that are not under EPL. One approach to this is packaging subversion support with some of the EPP packages (assuming no legal issues). (In reply to comment #5) > If I'm not wrong, Subclipse depends on the libraries that are not under > EPL. Could you, please, be more specific if you know where the problem is. As far as I can see Subclipse uses libraries with BSD-like licenses that require giving attribution to authors and do not overuse names without specific written permission. Are these requirements really incompatible with Eclipse? Subclipse - EPL 1.0 SVNClientAdapter - Apache 2.0 (proxy for various underlying libraries, may use command line interface if any of library licenses are unsuitable) http://subclipse.tigris.org/source/browse/subclipse/trunk/svnClientAdapter/license.txt?view=markup Libraries: http://subclipse.tigris.org/source/browse/subclipse/trunk/svnClientAdapter/lib/ Ganymed - BSD-like + MIT Sequence - BSD-like Subversion API (choose one): Command line - BSD-like JavaHL (JNI) - BSD-like SVNKit (Java Native) - BSD-like with GPL-ish third clause, that requires written permission from TMate Software for workaround So where is the problem, specifically? (In reply to comment #7) > So where is the problem, specifically? I don't know the details but you can read what the Subclipse team had to say when they decided to pull their proposal out. http://subclipse.tigris.org/eclipse-proposal.html Asked a question about current status in Subclipse support forum. Awaiting moderation approval. http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2377126 From the text of the proposal it looks like Subclipse developers feel like existing development ecosystem won't benefit from moving from tigris.org tools to Eclipse domain as a necessary step to become official Eclipse project. But even if Subclipse is not an Eclipse project, can it still be bundled with common Eclipse downloads? (In reply to comment #9) I'm copying the architecture council since this is more or less a frequently asked question. > But even if Subclipse is not an Eclipse project, can it still be bundled with > common Eclipse downloads? There is a small chance doing so -- the com.ibm.icu bundle and other 3rd party bundles from Orbit are also distributed from Eclipse.org. BUT 1. Eclipse.org can only distribute stuff that's 100% IP clean and licensed with a license compatible with the EPL. Note that just the EPL license is not sufficient, IP cleanliness must also be checked -- otherwise some developer could claim that stuff is licensed under EPL while it really infringes somebody's IP. 2. The IP cleanliness checks must be made at Eclipse.org -- either by an IP Review or by only having committers/contributors to the code which have signed an Eclipse Committer Agreement (in which they basically promise they won't ever infringe anybody's IP and abide by IP due diligence). 3. Since Subclipse developers are not committers today, an IP Review / code scan would be necessary. Because of the effort and workload doing this, it cannot be done too often. In other words, Subclipse would need to commit to officially releasing their stuff at a given point in time, such that the IP review can then take place. Today, if I'm not mistaken, Subclipse more or less distributes weekly builds from their update site but not well-defined releases. There may be more obstacles, but these are the ones I can think of today. Fact is, being an Eclipse project does come at a cost (release reviews, development process, IP due diligence) but does give the benefit of 100% IP cleanliness which commercial adopters of Eclipse.org technology value. You cannot have the benefit (approved Eclipse.org download) without a cost. Who would be willing to pay the cost? > 3. Since Subclipse developers are not committers today, an IP Review / code > scan would be necessary. Because of the effort and workload doing this, > it cannot be done too often. In other words, Subclipse would need to > commit to officially releasing their stuff at a given point in time, such > that the IP review can then take place. Hang on - let's not overstate the case here. In every case of third-party libraries, we adjoin the source code to the IP review request. There is no requirement on the third-party source to commit to *anything*. It's up to the user of the code to pick the right release and make sure that it goes through IP control. > Today, if I'm not mistaken, Subclipse more or less distributes weekly > builds from their update site but not well-defined releases. > > There may be more obstacles, but these are the ones I can think of today. Fact > is, being an Eclipse project does come at a cost (release reviews, development > process, IP due diligence) but does give the benefit of 100% IP cleanliness > which commercial adopters of Eclipse.org technology value. > > You cannot have the benefit (approved Eclipse.org download) without a cost. Who > would be willing to pay the cost? I know you are attempting to set an expectation here, Martin, but it comes across as a "strong encouragement not to" :) I would suggest that this would be a good time to actually go through the IP process with the subclipse code and get the issue sorted out once and for all, before we get into the tube for Helios. --oh (In reply to comment #11) Thanks Oisin. When I wrote my comment, I kinda already knew that I might be stirring into something that would bring up yet more questions that answers :) > It's up to the user of the code to pick the right release and make sure > that it goes through IP control. That's right, of course. But just assuming for a moment that some Eclipse Packages would contain subclipse, the users of those packages would expect getting the latest on each train release, no? My point is: the IP due diligence process must be done in one step. It's hard to push in patches, fixes etc at a later time... that's where 3rd party contributions are different than projects "living" at Eclipse. Therefore, at the time the IP process is done, one should be reasonably sure that not too many bugfixes or patches will be needed afterwards. > I would suggest that this would be a good time to actually go through > the IP process with the subclipse code and get the issue sorted out > once and for all, before we get into the tube for Helios. Well, as mentioned before, somebody (at Eclipse) would need to start that IP process, well aware that this does come at a cost for all the projects (since the Legal team would have less time for other requests). In Orbit, when a new lib gets requested, one must first state that it will actually be used in some project. So before we just initiate the IP process, we need to be sure that we need and want Subclipse as a 3rd party lib. What would be the benefit... especially given the fact that Subversive does exist as an Eclipse project already? In my opinion, having 2 svn providers is just detrimental for everyone to start with... Subclipse is going to have the same problems in the IP process that Subversive has had. Namely, that the Subversion libraries themselves are not going to be accepted because it has dependencies that are licensed with LGPL. That said, in a private email exchange with Mike Milinkovich a year ago I did let him know that Subversion can be compiled without these dependencies. The main one needed is libneon, which Subversion uses for HTTP access. There is now a replacement option named libserf that is Apache 2 licensed. With Subversion 1.7 it is slated to be the default, but you've been able to build Subversion with just Serf and not Neon since 1.5 was released in 2008. Subversion also uses libintl for localization of messages, but again, you can just build Subversion without that library and have all messages only in English. Finally, the BerkeleyDB libraries are licensed with the Sleepycat license which may not be acceptable. However, a Subversion client only needs these libraries to access a BDB repository via file:// URL. Given that it is a rare use case, and BDB has not been the default format since Subversion 1.2, I would just build the client without BDB support. CollabNet does not include BDB support in its binaries and rarely hears complaints. All of the other Subversion dependencies should pass IP review without problem. You know my problem with all of this was that back when Eclipse 1.0 came out and in the early days Eclipse was supposed to be about building an ecosystem that tools and vendors could plugin to and work together. Somewhere along the way that seems to have been lost and now everything has to come from Eclipse itself. There is no real ecosystem or support for that ecosystem. Rather than make it easier and more robust to manage the plugins you have installed, the focus instead is on just avoiding those problems by providing a zillion different packages where that has all been done. I like Eclipse and appreciate the work done by the foundation and community, but I am happy with where Subclipse is today. As I said on the Subclipse forum, if someone wants to create packages that include Subclipse, I'll be happy to help, but I do not plan to move Subclipse to the Eclipse foundation. -1 Eclipse shouldn't promote any single SCM client in any download package. Instead p2 should be utilized to provide the user with options to install SCM providers (of their choice) "on demand". Thus, a "link" to the Subclipse (and a few other SCM providiers') p2 repository would be better (IMHO!). Thanks for comment, Mark, but I don't think that the Eclipse Foundation is that bad nurturing it's Community :) I think I fully understand your position. But your comment also made me think what it is that the bug submitter really wants. Formulating it as a Scrum User Story (submitter correct me if I'm wrong!), I'd say that it's actually two things: 1. As an Eclipse user, I'd like to download a package like JEE that includes a pre-configured SVN provider, such that I can start working right away without extra configuration hassles. I don't care what adapter it is, as long as it works. Now I'd think that all the Eclipse member distros already fulfill this request. I just tried out http://poweredbypulse.com, and it allowed me to configure my profile easily including SVN. There's many other distros such as Yoxos, Myeclipse and more which EXACTLY solve the problem of integrating EPL and non-EPL contents. In the sense of a healthy Ecosystem, these distribution providers provide added value to the core Eclipse components. I'd argue that it's just not the Eclipse Foundation's job to provide everything preconfigured (remember: open source frameworks and exemplary tools, that's what Eclipse projects should provide!) Now the Foundation webpages could probably do a better job pointing at the distributions; the richness of the existing Galileo packages does give some false impression that they provide "everything" that a user may want. That's wrong! But that's a broader issue which should be discussed in a separate bug and likely needs discussion in the Board of Directors, since business aspects of members are touched. But I think that this "voting" bug has a second aspect: 2. As an Eclipse user, I'd like to get advice which of the many subversion options is best for me, such that I can pick the right installation from the start. I'm confused by 2 projects + 2 connectors. Now in the sense of a healthy ecosystem, one may think it is normal that users have many choices (and again the member distros can alleviate the end user's pain here). Furthermore, nobody can bless one svn solution over another... there is no one "better", they are just "different". For end users, though, this *is* *really* *painful*. I have spent days configuring my own system for svn+ssh access from Windows to Eclipse. Tried one client first, found it slow, tried the other, got stuck in some caching issue, tried JavaHL, didn't get rid of password prompts, so back to svnKit... stil caching issues... gave up and moved to TortoiseSVN, but that's bad in terms of Workflow... so back to Eclipse, finding JavaHL is "stronly recommended" so back to that... browsing mailing lists... found FAQ's that didn't answer my problem or had broken links... WHAT A MESS! And, where I as a user would normally try to help by creating bug reports, making suggestions, writing howto's etc I must say that the situation of having two different providers keeps me from doing so since there is no One Recommended Way of doing it (which I could file my bugs against). From an Eclipse Foundation point of view, I'm tempted to close this bug as NOT_ECLIPSE but then on the other hand I do see the submitter's problem is not at all solved. So here are some suggestions how we could improve the situation. Each one could be followed up separately with a bug. Mitigation ideas: ----------------- 1. SVN provider projects could do a better job getting new users up to speed. Better FAQs, pre-integrated packages, better HOWTO's... Surely the SVN providers could point to member distros from their homepages. 2. Somebody could set up a wiki page comparing the svn solutions technically, and/or start a poll e.g. http://doodle.com to vote. 3. Eclipse website could point to member distros from the package download. But why should one distro be favored over another? May be difficult politically. I believe this was a step in this direction: http://www.eclipse.org/membership/special_programs/member-downloads-program.php Getting the Eclipse foundation to integrate SVN into their downloadable packages is problematic not only from an IP point of view (as was discussed), but also from a political point of view (compared to the member distros). And while it may be svn today, the need for some other non-EPL goodie will come up next. I think it's not the foundation's job doing that integration. I don't think anything will change here. Especially as EGit/GIT are being promoted as the future SCM Systems for Eclipse. I don't mean to cut off discussion, if you thing there's more to have, please reopen. Thank you for the discussion. (In reply to comment #16) > I don't think anything will change here. Especially as EGit/GIT are being > promoted as the future SCM Systems for Eclipse. > > I don't mean to cut off discussion, if you thing there's more to have, please > reopen. > > Thank you for the discussion. For completeness, we (the EF) are moving forward with Git in response to overwhelming enthusiasm from the committer community. CVS support will be deprecated in the near future, but SVN will continue so long as there is support from the committers (i.e. we are not purposefully promoting Git over SVN; we're just promoting Git). As for what we put in the packages... I would suggest that what we (the Eclipse projects) do is but one of our concerns; SVN is used by a very large portion of our user community--that should be what we focus on when considering what we should put in the packages. FWIW, I have a hard time considering including non-eclipse.org functionality (i.e. Subclipse) when similar functionality is available from an eclipse.org project (i.e. Subversive). |