[PATCH 2 of 5 RFC] hglib: a wrapper around hg's cmdserver, written in Python

Matt Mackall mpm at selenic.com
Fri Jun 3 15:52:56 CDT 2011


On Fri, 2011-06-03 at 23:04 +0300, Idan Kamara wrote:
> # HG changeset patch
> # User Idan Kamara <idankk86 at gmail.com>
> # Date 1307111464 -10800
> # Node ID 15c24865581d773d00dec51ebd0cbe222feec6e0
> # Parent  5b9901ab0f4c60450ecd5c112fd937493a043667
> hglib: a wrapper around hg's cmdserver, written in Python

> diff -r 5b9901ab0f4c -r 15c24865581d contrib/hglib/hglib.py
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/contrib/hglib/hglib.py	Fri Jun 03 17:31:04 2011 +0300
> @@ -0,0 +1,100 @@
> +# hglib.py
> +#
> +#  Copyright Matt Mackall <mpm at selenic.com>


[I love when code I didn't write shows up in the world with my name on
it. It makes me feel very productive.

There are absolutely no copyright assignment requirements in this
project. I think such requirements are harmful to the spirit and
practice of open source development and you should feel free to put your
own name on your original work if you so choose.

But if you'd rather (and if you're writing some new piece of Mercurial),
you have permission to cut and paste mine. Your name will show up in the
changelog anyway.]

> +# This software may be used and distributed according to the terms of the
> +# GNU General Public License version 2 or any later version.

We should probably (a) MIT-license this code and (b) put it in a
separate repo.

One of the goals here is to enable license-incompatible code to talk to
Mercurial efficiently while maintaining a clear separation. And we want
people to be able to port this code to Java, Ruby, C#, etc. and use a
community-appropriate license when they do so without worrying about
clean-room issues.

Also, this will probably end up being fairly thin - there won't be much
room for "embracing and extending" here because you can't reach through
the server pipe and add proprietary magic to the core. So we should go
with a license that's maximally compatible. 

Keeping the repo separate serves two goals. First, we want to have a
very clear dividing line between what's GPL and what's not, so people
aren't tempted to augment the protocol with proprietary extensions.
Second, we want to keep the library API as version-independent as
possible: if you have apps that are using hglib 0.1, that shouldn't
prevent you from upgrading Mercurial to 2.0.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list