Hello Mark,
> 1) Let's say IBM wants to include Subclipse with all of
> their Rational distributions. As long as they are just
> including the plugin the same way we distribute it then there
> are no issues and no JavaSVN license is required.
Correct.
> 2) Let's say that IBM includes Subclipse but they have
> modified parts of it, like some of our dialogs. Or maybe
> they have added some other feature they require.
>
> a) If the modifications they make to Subclipse are available
> via open source, then they do not need a license for JavaSVN.
> b) If the modifications are not made available, then they
> would either require a license for JavaSVN (or remove it as
> part of their customizations).
Correct.
> 3) If Subclipse someday provides extensions points for
> additional functionality, then commercial closed-source
> plugins can use those extension points without requiring a
> JavaSVN license, provided of course that they are using the
> standard Subclipse install in the first place.
Correct, with some limitations. For instance I could imagine that one could
develop an application that will depend on Subclipse, but will use mainly
JavaSVN library included into it - either directly, or through
svnClientAdapter API. This case goes to point 2.b from my point of view.
> 4) Anyone using svnClientAdapter in internal projects do not
> require a license because they are not making the results of
> that work available to others as part of any kind of
> commercial enterprise?
Yes, using JavaSVN (as standalone library or via svnClientAdapter)
internally - in a company build server or reporting tool is not considered
as "redistribution", so no limitations are applied in this case.
> Assuming these issues are worked out, the other thing to talk
> about are the changes you feel we need to make in Subclipse
> (and svnClientAdapter and svnAnt) to be compliant with the
> terms of your license. For example, we do not ship the
> source code as part of the normal plugin distribution and
> while we can certainly distribute your license agreement and
> other items like that, as you are probably aware these items
> are far from visible in the Eclipse UI. The only visible
> place I can think of where we could add the required
> attributions are in the click-thru license agreement you get
> when you install a plugin.
Of course, I would like Subclipse to include references to JavaSVN whenever
it is possible - all help files, licenses and UI should contain links to
TMate web site :)
So, to figure out some compromise solution I would suggest the following:
1) Please, include JavaSVN COPYING file into subclipse.core plugin
2) If possible, please display this license text in that click-thru
agreement you've mentioned.
3) When user selects "Help->About->Feature Details", there is a short text
with links displayed for Subclipse, It will be great, if you'll add a link
to http://tmate.org/ to that text. Something like - "This feature includes
JavaSVN library (link)"
4) In case you'll have a help page like "aknowledgments" or "links", please
add link to JavaSVN web site to that page.
I think above will be enough.
Regarding Subclipse source code: I'm not aware of the exact reasons for
making Subclipse repository read-protected, and it will be better (from the
license point of view) to make it world-readable, but in case there are some
important (or technical) reasons to keep it read-protected, current access
policy is ok. As far as I understood guest account information could be
easily obtained from the mailing list or upon request.
I imagine that the main "target audience" for the new JavaSVN license are
closed-source applications that uses or would like to use JavaSVN in their
proprietary applications, mainly content management systems that uses
Subversion to store data, Subversion monitoring tools, issues trackers
integrated with Subversion, other utilities that run on the server side.
JavaSVN is not only a transparent replacement for JavaHL, it also adds value
by providing direct access to Subversion protocol, thus allowing to build
faster and smarter tools. Major IDEs, i.e. Eclipse and IntelliJ IDEA already
uses JavaSVN and my goal is not to prevent Eclipse or SvnAnt users from
using JavaSVN, but instead make them use it as part of stable end-user
product, like Subclipse is, so that at the moment developers will need
reliable pure java Subversion solution it will be very close to them, inside
the IDE they are using. [Hope NetBeans will got rid of their "profiles" one
day :)]
So, in case you'll eventually decide to move Subclipse to Eclipse.org, there
should be no problems with re-licensing JavaSVN with EPL-compatible license
for Subclipse, - I think everyone will benefit from Subclipse (with JavaSVN
inside) being part of Eclipse.
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 17:20
> To: dev@subclipse.tigris.org
> Cc: alex@tmate.org
> Subject: [Subclipse-dev] Re: JavaSVN License Change
>
> Alex,
>
> Thanks for taking the time to reply. Your comments are encouraging.
>
> I think a document that clearly states how this impacts
> Subclipse and svnClientAdapter would be great. Let me
> restate some of the things I think you are saying.
>
> 1) Let's say IBM wants to include Subclipse with all of
> their Rational distributions. As long as they are just
> including the plugin the same way we distribute it then there
> are no issues and no JavaSVN license is required.
>
> 2) Let's say that IBM includes Subclipse but they have
> modified parts of it, like some of our dialogs. Or maybe
> they have added some other feature they require.
>
> a) If the modifications they make to Subclipse are available
> via open source, then they do not need a license for JavaSVN.
> b) If the modifications are not made available, then they
> would either require a license for JavaSVN (or remove it as
> part of their customizations).
>
> 3) If Subclipse someday provides extensions points for
> additional functionality, then commercial closed-source
> plugins can use those extension points without requiring a
> JavaSVN license, provided of course that they are using the
> standard Subclipse install in the first place.
>
> 4) Anyone using svnClientAdapter in internal projects do not
> require a license because they are not making the results of
> that work available to others as part of any kind of
> commercial enterprise?
>
> These things all seem reasonable.
>
> Assuming these issues are worked out, the other thing to talk
> about are the changes you feel we need to make in Subclipse
> (and svnClientAdapter and svnAnt) to be compliant with the
> terms of your license. For example, we do not ship the
> source code as part of the normal plugin distribution and
> while we can certainly distribute your license agreement and
> other items like that, as you are probably aware these items
> are far from visible in the Eclipse UI. The only visible
> place I can think of where we could add the required
> attributions are in the click-thru license agreement you get
> when you install a plugin.
>
> Thanks
>
> Mark
>
>
> ______________________________________________________________
> _______________
> 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
>
>
Received on Tue Oct 25 03:23:33 2005