[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] JavaSVN License Change

From: Noel Grandin <noel_at_peralex.com>
Date: 2005-10-21 11:07:55 CEST


Reading through the license, it seems that this change is definitely not
intended to be "commercial friendly".

They appear to be pursuing a dual-license strategy (like Trolltech and

Which is fine, since they wrote the code, but means that it is probably
not EPL-compatible.

Which in turn means that if subclipse aims to eventually move closer to
Eclipse, JavaSVN will need to go.

IANAL, etc, etc.


Mark Phippard wrote:

>This message is addressed to the developers of this project, and also to
>Alex at tmate.org. Alex, if you are not the person that should get this,
>please forward it.
>In case you do not know, tmate.org has posted their license change for
>JavaSVN. If you have not seen it yet, you should visit their site and take
>a look:
>All things considered, it doesn't seem too bad, and even if it is, let's
>face it, the work they have done is pretty remarkable and they have the
>right to do whatever they want with their code. I do think we need to get
>some clarification, perhaps official clarifications, as to how tmate.org
>see's this license applying to our projects.
>First, technically, the only one of our projects that uses JavaSVN is
>svnClientAdapter. Subclipse and svnAnt only talk to svnClientAdapter.
>Second, technically, svnClientAdapter is talking to the Subversion JavaHL
>interface, which JavaSVN has chosen to implement. We do use a JavaSVN
>factory to construct the object that implements the interface, but
>otherwise we do not use any other JavaSVN methods directly. I doubt any of
>this legally matters, but it is worth pointing out.
>Obviously, on a simple level, all of our projects are open source and we
>therefore are eligible to use JavaSVN from our products. At least that is
>how I read things and their license seems fairly simple.
>These are the questions I need to see clear, unequivocal answers to.
>1) Could someone shipping a commercial IDE based on Eclipse, whether it be
>IBM's Rational tools, or SAP, or Borland, or whomever, include the
>Subclipse plugin in their distribution, assuming Subclipse includes
>JavaSVN. In my opinion, if the answer to this is not a definite yes, then
>I see this as a show stopper.
>2) Can someone make a modified version of Subclipse and still use JavaSVN?
>For example, maybe someone wants to do some custom dialogs or something,
>but it is otherwise the Subclipse code? Obviously if they keep the same
>license as Subclipse then I do not see how there could be a problem, but
>what if this were part of a commercial product?
>3) There are definitely people using svnClientAdapter in other projects.
>I do not know that these are anything but internal tools, but what if they
>are not? Does using svnClientAdapter allow you to use JavaSVN? I would
>think if you provide the source for svnClientAdapter, that you are
>technically complying with the license.
>4) I can probably figure out how this applies to svnAnt based on the
>previous three answers, but if anyone can think of any special
>considerations that might apply to svnAnt please post them.
>My company is and has been a member of the Eclipse Foundation. I figured
>at some point, probably after we are at a solid 1.0 stage, I would float
>the idea of moving Subclipse over to Eclipse.org. I suspect that CollabNet
>might be willing to step up and co-sponsor us if this happened, but who
>knows? Anyway, how does our using JavaSVN make this easier or more
>difficult? If JavaSVN were licensed under the CPL or EPL. then I think it
>would make this much easier since Eclipse prefers pure Java solutions.
>Given that it is not licensed under the CPL/EPL, would we have to dump
>JavaSVN as part of doing this?
>Wrapping this up ... I want to keep positive about this. JavaSVN has the
>right to do whatever they want, and frankly their license looks reasonable.
>That being said, if people cannot include Subclipse in commercial projects,
>or otherwise modify Subclipse, then I am not sure that we can continue to
>include it, which would really suck.
>Finally, I am just speaking for myself and I do not think my "vote" counts
>for any more than any one else that contributes. I am interested in
>hearing what others think. Especially those of you that have some
>experience in this area.
>Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
>To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
>For additional commands, e-mail: dev-help@subclipse.tigris.org

NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
 and you wish to receive a copy thereof please send
 an email to email@peralex.com
Received on Fri Oct 21 19:07:55 2005

This is an archived mail posted to the Subclipse Dev mailing list.