Hello All,
First, I would like to say, that keeping Sublipse using JavaSVN is very
important for JavaSVN and TMate Software. It gives JavaSVN more credibility,
widens its audience. So, I would like to put my best efforts to keep JavaSVN
as part of Subclipse and svnAnt. Unfortunately, I'm not a lawyer but reality
puts me in a situation where I have to deal with all that licensing things,
so I would appreciate all your suggestions on this topic.
As far as I understood after reading comments in this mailing list, one of
the concerns is that JavaSVN license will "infect" the whole Eclipse, as it
is not compatible with Eclipse license (EPL). From my point of view, it is
not correct, and I would like to reflect this in the license. JavaSVN is
used by Subclipse, but it is not used by Eclipse itself or other plugins
that runs in Eclipse environment. Subclipse license is compatible with
JavaSVN's one and should not cause any problems for Subclipse users.
> 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.
Just including Subclipse into commerical IDE based on Eclipse does not
violate JavaSVN's license as soon as Subclipse keeps its current license, so
my answer is "yes".
> 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?
I would consider this as "Subclipse extension". As soon as this extension
doesn't violate JavaSVN's license (i.e. source code for this extension is
available), there will be no problem with extending Subclipse. In case
source code of extension is not available, company that develops this
extension needs to license JavaSVN.
> 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.
Yes, technically it complies, but violates the spirit of the license from my
point of view. Using JavaSVN through SVNClientAdapter in closed source
application should require licensing of JavaSVN, because "end-user"
application actually uses JavaSVN code to access Subversion repository in
this case.
I'm not sure whether it could be included into the license text, but the
idea of the license is that those part of applications (that directly or
inderectly uses JavaSVN) that provides end-user functionality should either
redistribute source code or license JavaSVN to be used in that application.
Subclipse, or application that uses JavaSVN thorugh svnClientAdapter are
examples of such applications.
Internal use (that is probably most common use case for svnClientAdapter and
svnAnt) is not considered as "redistribution".
> 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.
I think of svnAnt as a separate application, so as soon as svnAnt source
code is available, svnAnt users should not license JavaSVN.
> 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.
I would consider including Subclipse and modifing Subclipse (along with
license change) as two different cases. While first is allowed, second is
allowed only when modified source code is available (as modified Subclipse
is not Subclipse anymore). Otherwise commercial application vendor may
either exclude JavaSVN or license it.
So... What do you think on a special "JavaSVN-Subclipse" license? This
license could be made EPL-compatible, but will cover only Subclipse
application. This will explicitly allow users to include Subclipse with
JavaSVN into commercial applications, however will still disallow
closed-source Subclipse modifications. However, such modifications still
will be allowed in case Subclipse is modified/extended with the help of
extension points.
Alexander Kitaev,
TMate Software,
http://tmate.org/
http://jetbrains.com/tmate/
> -----Original Message-----
> From: Mark Phippard [mailto:markp@softlanding.com]
> Sent: Friday, October 21, 2005 02:59
> To: dev@subclipse.tigris.org
> Cc: alex@tmate.org
> Subject: JavaSVN License Change
>
>
> 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:
>
> http://tmate.org/svn/licensing/index.html
>
> 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.
>
> Thanks
>
> Mark
>
>
> ______________________________________________________________
> _______________
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe
> Plc by IBM Email Security Management Services powered by MessageLabs.
> ______________________________________________________________
> _______________
>
Received on Sat Oct 22 00:53:57 2005