Thomas Hallgren wrote:
> As a provider of headless Eclipse plugins, I care a lot about being
> able to create platform agnostic distributions (I expect that to be
> common for most Java shops that doesn't use SWT). For us, using JavaHL
> is really problematic since it effectively removes all distribution
> advantages of using Java.
Eclipse already uses natives for things other than SWT, for instance the
filesystem plugin. So long as there are fragments available for each of
the target platforms, the user should never have to know. However, I do
agree that things would be far simpler if there was a pure Java EPL
licensed alternative.
>
> Doing commercial stuff, I'd avoid JavaSVN due to it's license. I might
> even avoid it doing Open Source since I don't want to contaminate my
> distributions.
>
> Neither has an EPL license and hence, neither can be submitted to
> Eclipse (not at present anyway).
Eclipse uses plenty of non EPL code. However, using non EPL code
requires approval by the Eclispe legal team.
The Subversion license seems to be more like the Apache license, only
requiring you to mention that your product uses code from CollabNet. As
such, the Eclipse legal guys are far more likely to approve it. Whereas
JavaSVN has a more GPL style license
from the TMate website:
"The TMate open source license permits you to use JavaSVN at no charge
under the condition that if you use the software in an application you
redistribute, the complete source code for your application must be
available and freely redistributable under reasonable conditions."
>
> You already conclude that "One of the main problems with CVS that
> Subversion sought to address was the lack of an official API". OK, so
> take the full consequences of that statement. You now submit something
> to the most commonly used Java based IDE. What would be more natural
> then to propose an EPL licensed SVN Java API? If TMate wants to
> relicense their stuff, perfect! If not, how hard can it be to do clean
> room implementation of a new official API using pure Java?
The short answer is: "very hard". You would need to support the SVN
working copy format (not so hard) as well as the FSFS repository type
(really hard). Maintenance would be a major issue. The Subversion team
does a great job of adding new features, which is great for users, but
not so great if you have to maintain your own client implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Thu Jul 6 11:16:14 2006