Mark Phippard wrote:
>Noel Grandin <email@example.com> wrote on 10/21/2005 05:07:55 AM:
>>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.
>Taking the example of a commercial IDE based on Eclipse. If they include
>the Subclipse plugin in that distribution, and Subclipse is open source,
>then are they complying with the license? IANAL either, but it would
>really seem to violate the spirit of the Eclipse environment if one
>library used by one plugin could "infect" the entire IDE with its license
I think you hit the nail on the head. My interpretation of the license
is that it would infect the entire project. Which means, it can not be
included with Subclipse unless Subclipse itself "infects" the entire
I understand why TMate is doing this change, and it follows a prevalent
wind in the open source community. However, dual licensing is easier to
implement/understand with applications. JavaSVN being a low level
library makes it very tricky, indeed.
I do not think there is any doubt that a free Java library that
implements SVN is needed. One approach would be to take a version prior
to the license change, and start maintaining it ourselves. However, this
would make things really messy and might annoy the people that have
helped us a lot in the past. On the other hand, I do not see a quick
solution to help TMate reaps the rewards for their hard work with a free
license. Recognition goes only so far...
Received on Sat Oct 22 00:04:34 2005