future of HgKit

[Andrey Somov]

> On Fri, 2009-10-02 at 22:06 +0200, Mirko Friedenhagen wrote:
>> Am 29.09.2009 um 22:41 schrieb Andrey Somov:
>>> Hello Mirko,
>>> (following the discussion in the Mercurial mailing list) may I ask  
>>> you how
>>> do you see the future of HgKit ?
>>> Since it is released under GPL it cannot be used in any major IDE.
>> Well, that's a pity and right now I am not very convinced that having  
>> double licensing with the EPL is even allowed. So the future is  
>> probably doomed as I do not see how I can develop easily without  
>> looking at the python source or documentation. I even do not know  
>> wether the MIT license used by Hudson is compatible with the GPL.
> 
> The MIT license is compatible with basically everything.
> Reimplementation from documentation is also legal. Clean room
> implementation is also legal.
> 
> But the thing I'd like you to focus on is whether or not your code
> enables proprietary embrace of my work. The primary thing people who
> choose the GPL are looking to do is keep their work free and accessible.
> 
> Because the EPL allows proprietary expansions, it provides a good
> launching point for adding MustHaveProprietaryFeatures that locks your
> users into code they can't modify or share, fragments our community, and
> gives us support headaches.
> 
> I'd encourage people who want to go down the route of making a non-GPL
> hg library to stop short of adding direct write support. Not only does a
> read-only implementation limit the avenues for exploitation, it also
> minimizes the risk of introducing new compatibility and corruption
> issues while still gaining most of the performance and integration
> benefits (fast status and history browsing).
> 

Yes indeed, a read-only implementation can support basic continuous 
integration with Hudson (just to clone the source).
But please keep in mind that for a successful build sometimes we need to 
change the source (Maven release plugin). Both Ant and Maven have Apache 
license. GPL does not fit here.
Developers have either to find a solution or to choose another version 
control system.
Whatever the solution is, it will be more flexible then HgKit. Do you 
think anybody will bother to have 2 ways to work with Mercurial?

P.S. Is it worth to spend any time to create an application which will 
be hardly used (if ever) ...
Mercurial is my favorite DVCS. Unfortunately I fail with each and every 
step I do to improve Mercurial-Java integration.

-
Andrey