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
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
>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: email@example.com
>For additional commands, e-mail: firstname.lastname@example.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@example.com
Received on Fri Oct 21 19:07:55 2005