Mercurial in pure Java

[Andrey Somov]

Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.
The idea is to be able to work on the same repository with both hg and a
pure Java implementation.
Since Jython (most probably) will never be able to run Mercurial, there
is only one option left: to re-write Mercurial in pure Java.

Unfortunately Java does not support/have out of the box some Python
features which are heavily used in Mercurial:
- generators
- decorators
- tuples
- symbolic links
- struct
- heapq
- file-like objects
- slices and negative indices for lists
- functions are not first-class objects and cannot be passed or used as
arguments
- classes cannot be "callable"
- functions may only return one type
- regular expressions look and work slightly different

It means that these (and many other Python features/modules) have to be
somehow reimplemented.
It would be also profitable for Python Mercurial. Since I have to read
and understand each and every line of code I will try to report any
place where the code may be improved (I have already submitted a few
patches to increase code readability)

The main goal of the Java library is not to serve as CLI (here hg is the
best) but to be included in another Java application (IDE for instance).
The big obstacle here is the GPL license. If the Java version is
released under the GPL2 or 3 licenses it will make it impossible to
include the library into many other applications (even Open Source like
Eclipse).
Even though it is possible to write Java code without consulting the
source code (Mercurial is quite well documented) it is very beneficial
to see the source. But then as far as I understand it would be
considered as "Derivative work" it terms of the GPL license.

Here is my question:

May I base the Java library on the Mercurial code but release it with
another Open Source license?

I am specifically interested in Apache License v2.0. (in the same way
how it has happened with JGit)

-
Andrey Somov

[Adrian Buehlmann]

Post by Andrey Somov
Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.
The idea is to be able to work on the same repository with both hg and a
pure Java implementation.
Since Jython (most probably) will never be able to run Mercurial, there
is only one option left: to re-write Mercurial in pure Java.

If you contemplate to reimplement from scratch, have you thought
about using Scala instead of Java?

[Andrey Somov]

Post by Adrian Buehlmann
If you contemplate to reimplement from scratch, have you thought
about using Scala instead of Java?

I would like to target a large developer community. Java is a very
well-known language
(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)
I cannot finish such a huge piece of work alone. I think it is easier to
find contributors in Java then in Scala. Nevertheless since Scala can
use Java code it can later be ported to Scala.

[John D. Mitchell]

I really don't understand why you're not focusing on porting to
Jython. Have you actually tried doing that and run into problems that
people haven't already pointed out?

Thanks,
John

[Andrey Somov]

Post by John D. Mitchell
I really don't understand why you're not focusing on porting to
Jython. Have you actually tried doing that and run into problems that
people haven't already pointed out?
Thanks,
John

Just one argument.
There is a very good library to work with YAML (http://www.yaml.org/) -
PyYAML. PyYAML has been ported to Java, the port is called SnakeYAML.
I measured the performance of PyYAML under Jython and pure Java (SnakeYAML).
The difference was 60 times! Jython runs PyYAML more then 10 times
slower then CPyhton. Jython has a big set of dependencies and requires
an installation. SnakeYAML is just a library with no dependencies.

My conclusion is that you should only target Jython if you do not care
about the performance. I do.

-Andrey

[Stefano Mioli]

Post by Andrey Somov
My conclusion is that you should only target Jython if you do not care
about the performance. I do.

Just a thought: if you are so performance-oriented (a good thing), why not use
plain C?

The cold start of an application, in Java as in .NET, still takes a certain
amount of time.

Just curious about that.

[Adrian Buehlmann]

Post by Andrey Somov

Post by Adrian Buehlmann
If you contemplate to reimplement from scratch, have you thought
about using Scala instead of Java?

I would like to target a large developer community. Java is a very
well-known language
(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

Well. That's indeed news for me :)

Good luck!

[Andrey Somov]

Post by Adrian Buehlmann

Post by Andrey Somov

Post by Adrian Buehlmann
If you contemplate to reimplement from scratch, have you thought
about using Scala instead of Java?

I would like to target a large developer community. Java is a very
well-known language
(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

Well. That's indeed news for me :)
Good luck!

I mean Java is on top while Scala is somewhere at the bottom...

Can I count on any help if the community is close to zero ?

[David Soria Parra]

Post by Andrey Somov
Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.
The idea is to be able to work on the same repository with both hg and a
pure Java implementation.
Since Jython (most probably) will never be able to run Mercurial, there
is only one option left: to re-write Mercurial in pure Java.

Frankly, porting mercurial to jython is actually trivial. Drop buffer()
objects and some posix stuff and you'll fine. I needed 15 min to get
mercurial on jython to clone a repo (well without using fncache for some
reasons).

David

[Martin Geisler]

Post by Andrey Somov
Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.

Please see:

http://hgkit.berlios.de/

[Martin Geisler]

Post by Martin Geisler

Hi all, I like Mercurial. And I am sure a pure Java implementation
would help Mercurial to be spread even wider.

http://hgkit.berlios.de/

But perhaps you cannot use their code since it's licensed under GPLv2?

I take it that the underlying problem is that an Eclipse plugin would be
a derivative work of both Eclipse (EPL) and Mercurial (GPLv2) and so it
must be licensed under incompatible licenses -- resulting in a work
which cannot be distributed at all.

How stupid of Eclipse to chose such a license... :-(

[Andrey Somov]

Post by Martin Geisler
I take it that the underlying problem is that an Eclipse plugin would be
a derivative work of both Eclipse (EPL) and Mercurial (GPLv2) and so it
must be licensed under incompatible licenses -- resulting in a work
which cannot be distributed at all.
How stupid of Eclipse to chose such a license... :-(

That is why I am asking whether I can use another license.
Apache License v2.0 is compatible with both GPL3 and EPL.

[Andrey Somov]

Post by Martin Geisler

Post by Andrey Somov
Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.

http://hgkit.berlios.de/

I have seen it. I could not find there any implementation. Only high
level definitions. The activity ceased. I am afraid the project is dead.

[Martin Geisler]

Post by Andrey Somov

Post by Martin Geisler

Post by Andrey Somov
Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.

http://hgkit.berlios.de/

I have seen it. I could not find there any implementation. Only high
level definitions. The activity ceased. I am afraid the project is dead.

The last activity in the repository is three weeks old, so it doesn't
look dead to me:

http://hg.berlios.de/repos/hgkit/shortlog/?style=paper

But I have no idea about the level of completeness of their
implementation. I've CCed the author of the last changeset, hopefully he
can cast some light on the issue.

[Mirko Friedenhagen]

Post by Martin Geisler

Post by Andrey Somov

Post by Martin Geisler

Post by Andrey Somov
Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.

http://hgkit.berlios.de/

I have seen it. I could not find there any implementation. Only high
level definitions. The activity ceased. I am afraid the project is dead.

The last activity in the repository is three weeks old, so it doesn't
http://hg.berlios.de/repos/hgkit/shortlog/?style=paper
But I have no idea about the level of completeness of their
implementation. I've CCed the author of the last changeset,
hopefully he
can cast some light on the issue.

Hello,

I was actually following the discussion on this group. Right now I am
a bit confused about the way to go. After I took over from Stefan
Chyssler, nobody ever had any interest in the Java-Port or wanted to
be part of it. In the last year one issue was found, so propably HgKit
is not that widespread. The idea for next steps would be to make HgKit
an alternative for CI-systems like Hudson.

As one poster wrote, HgKit only has some very basic stuff + some
commands for local status and update, remote repositories via ssh or
even http are not even started yet, see:

http://bitbucket.org/mfriedenhagen/hgkit/src/tip/src/main/java/org/freehg/hgkit/

Tackling the enormous amount of plugins would be futile IMO.

I have to confess, in between I switched to git for some projects,
whose clean, simple storage method fascinated me. After having done
some work on:
http://bitbucket.org/mfriedenhagen/hgkit/src/tip/src/main/java/org/freehg/hgkit/core/CaseFolding.java
I found mercurial's way of folding strange to say at least (maybe I
should not say this on the mercurial list :-)).

Now I switched back to Mercurial, having trouble bending my mind
around Git's (or remembering how to do stuff). Simple things are not
simple in Git but in Mercurial, so Mercurial rocks for me, I even
worked on the HgBrowser-support of Hudson in the last few weeks (http://bitbucket.org/mfriedenhagen/hudson-mercurial/
).

Regarding the licensing issues, that was one thing Stefan warned me
about. I really did not care as I am not a lawyer. Now it seems after
having looked at the original python code, this seems to hinder me to
implement something under another license. What a big pity. Hey, I
only do not like to not have the source code of software interesting
me, I do not really care about licenses.

Best Regards
Mirko

[Andrey Somov]

Post by Martin Geisler

Post by Andrey Somov
Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.

http://hgkit.berlios.de/

I wonder whether I can get the answer to my question: do I have to
apply the GPL license to the Java port ?
Is it the right place to ask ?
Shall I get the permission from the Mercurial owners ? Shall I forward
this question to FSF ?

-
Andrey

[Matt Mackall]

Post by Andrey Somov

Post by Martin Geisler

Post by Andrey Somov
Hi all,
I like Mercurial. And I am sure a pure Java implementation would help
Mercurial to be spread even wider.

http://hgkit.berlios.de/

I wonder whether I can get the answer to my question: do I have to
apply the GPL license to the Java port ?

If your version is a "derived work", then the answer is yes.

Unfortunately, "derived work" is a legal term, the precise definition of
which can only be determined by testing various theories of it in a
court of law. But it's probably true that if you directly translate
code, you're making a derived work, as would be the case with a book.

[Greg Ward]

Post by Matt Mackall

I wonder whether I can get the answer to  my question: do I have to
apply the GPL license to the Java port ?

If your version is a "derived work", then the answer is yes.
Unfortunately, "derived work" is a legal term, the precise definition of
which can only be determined by testing various theories of it in a
court of law. But it's probably true that if you directly translate
code, you're making a derived work, as would be the case with a book.

Literally translating Mercurial to Java would 1) be very difficult and
painful, and 2) result in very strange-looking Java code. Java has
its own conventions and idioms, and Mercurial's style of mixed
functional and OO programming is not well supported and therefore not
common. (Which is probably why someone suggested Scala: if you want
that kind of code to run under a JVM, Scala is probably a good way to
go.)

That's actually *good* news for Andrey: a cleanroom implementation
that uses native Java idioms would be much less likely to be
considered a derived work, and therefore less likely to require the
GPL. It would also be much more likely to attract contributors from
the Java community. But I doubt that Mercurial is sufficiently well
documented (other than its source code, of course) to allow for a
cleanroom implementation. It all depends how careful you want to be
of legal issues.

At any rate, I strongly suspect that an attempt to reimplement
Mercurial in Java, even if it's for the limited purpose of making
MercurialEclipse work more smoothly, is doomed to fail for one reason:
extensions. That is, even if you get every single feature of core
Mercurial working perfectly (reimplement revlog and its subclasses and
be able to fetch file revisions/changesets; transactions and
committing; push, pull, clone; http and ssh; etc etc), then you're
still a very long way from emulating Mercurial as it behaves in the
wild. That's because I or any other Mercurial user can drop arbitrary
Python code just about anywhere inside Mercurial and change just about
any aspect of its behaviour. Mercurial's extension mechanism is
insanely powerful and flexible, but it also means the only way to
completely mimic what Mercurial does means you need a Python
interpreter at your disposal.

Or at least, that's how I see things. Go ahead. Prove me wrong.
We'll all be really impressed if you pull it off. ;-)

(Also, if you just want to make MercurialEclipse faster and smoother,
maybe all you need is a read-only pure Java implementation. That
means you need to reimplement revlog and friends along with large
chunks of localrepo. That should make anything that requires fetching
history work more smoothly inside Eclipse. But you could still leave
update/network operations -- commit, pull, push -- up to the real
Mercurial via command-line invocations.)

Greg

P.S. and would the next person to write some free software *please*
choose a GPL-compatible license? I mean, really, why can't we all
just use the X11 license and move on? ;-)

[Adrian Buehlmann]

Post by Greg Ward

Post by Matt Mackall

Post by Andrey Somov
I wonder whether I can get the answer to my question: do I have to
apply the GPL license to the Java port ?

If your version is a "derived work", then the answer is yes.
Unfortunately, "derived work" is a legal term, the precise definition of
which can only be determined by testing various theories of it in a
court of law. But it's probably true that if you directly translate
code, you're making a derived work, as would be the case with a book.

Literally translating Mercurial to Java would 1) be very difficult and
painful, and 2) result in very strange-looking Java code. Java has
its own conventions and idioms, and Mercurial's style of mixed
functional and OO programming is not well supported and therefore not
common. (Which is probably why someone suggested Scala: if you want
that kind of code to run under a JVM, Scala is probably a good way to
go.)

Scala has some nice properties that I expect to attract some
Python and Haskell fans to some degree.

I expect Scala to gain quite some traction over the next couple
of years. It has the potential to be the next Java.

Post by Greg Ward
That's actually *good* news for Andrey: a cleanroom implementation
that uses native Java idioms would be much less likely to be
considered a derived work, and therefore less likely to require the
GPL. It would also be much more likely to attract contributors from
the Java community. But I doubt that Mercurial is sufficiently well
documented (other than its source code, of course) to allow for a
cleanroom implementation. It all depends how careful you want to be
of legal issues.

This is pointless. You can't use anything else than GPL version 2.

If such a port has the slightest chance of success, then
people will have to look at the code of mercurial and
they will inevitably implement things in the same way
as the original Python code does it.

For example, take the fncache filename encoding I have done.
You can't tell me you reimplement that encoding without looking at my
original Python code and thus create a derivative work.

So, I'm afraid, I doubt anybody can create a program that can read fncache
repos using anything else than GPL version 2 without violating the copyright
of my contributions.

Post by Greg Ward
At any rate, I strongly suspect that an attempt to reimplement
Mercurial in Java, even if it's for the limited purpose of making
extensions. That is, even if you get every single feature of core
Mercurial working perfectly (reimplement revlog and its subclasses and
be able to fetch file revisions/changesets; transactions and
committing; push, pull, clone; http and ssh; etc etc), then you're
still a very long way from emulating Mercurial as it behaves in the
wild. That's because I or any other Mercurial user can drop arbitrary
Python code just about anywhere inside Mercurial and change just about
any aspect of its behaviour. Mercurial's extension mechanism is
insanely powerful and flexible, but it also means the only way to
completely mimic what Mercurial does means you need a Python
interpreter at your disposal.

Or invent a different extension mechanism.
Implement everything from hgtext in core.

Post by Greg Ward
Or at least, that's how I see things. Go ahead. Prove me wrong.
We'll all be really impressed if you pull it off. ;-)
(Also, if you just want to make MercurialEclipse faster and smoother,
maybe all you need is a read-only pure Java implementation. That
means you need to reimplement revlog and friends along with large
chunks of localrepo. That should make anything that requires fetching
history work more smoothly inside Eclipse. But you could still leave
update/network operations -- commit, pull, push -- up to the real
Mercurial via command-line invocations.)
Greg
P.S. and would the next person to write some free software *please*
choose a GPL-compatible license? I mean, really, why can't we all
just use the X11 license and move on? ;-)

LGPL would have been nice too. I don't see the point in forcing
projects like Eclipse to use mercurial on the command line in
a plug-in, just because they are not allowed to link with the
mercurial API.

[Andrey Somov]

Post by Adrian Buehlmann
So, I'm afraid, I doubt anybody can create a program that can read fncache
repos using anything else than GPL version 2 without violating the copyright
of my contributions.

First, we can choose for a derivative work either GPLv2 or GPLv3 without
asking any permissions since GPLv3 is a successor of GPLv2. But GPLv3
does not help.
Second, if you document the implementation of fncache or somebody will
reverse-engineer the code (like it happened with the NTFS filesystem)
then it is legal to use any license.

-Andrey

[Adrian Buehlmann]

Post by Andrey Somov

Post by Adrian Buehlmann
So, I'm afraid, I doubt anybody can create a program that can read fncache
repos using anything else than GPL version 2 without violating the copyright
of my contributions.

First, we can choose for a derivative work either GPLv2 or GPLv3 without
asking any permissions since GPLv3 is a successor of GPLv2. ..

No. As Matt already made clear on this list.

The license of Mercurial is GPL v. 2. Not "GPL v. 2 or any later".

Post by Andrey Somov
Second, if you document the implementation of fncache or somebody will
reverse-engineer the code (like it happened with the NTFS filesystem)
then it is legal to use any license.

No. It isn't.

One notable difference to your example is that the NTFS filesystem's
original implementation is closed source. That alone changes the
picture a lot.

The code of fncache has already been published. Under GPL v. 2.

Claiming that you haven't looked at it is unreasonable.

[David Soria Parra]

Post by Adrian Buehlmann
The code of fncache has already been published. Under GPL v. 2.

just for the note: git's reimplementation in java (jgit) uses BSD
license although git itself is licensed under gpl. I'm not a laywer and
it's pretty hard to tell what a derived work is.

[Adrian Buehlmann]

Post by David Soria Parra

Post by Adrian Buehlmann
The code of fncache has already been published. Under GPL v. 2.

just for the note: git's reimplementation in java (jgit) uses BSD
license although git itself is licensed under gpl. I'm not a laywer and
it's pretty hard to tell what a derived work is.

Indeed. Being in company with others doing a similar error
is hardly a good argument.

[Andrey Somov]

Post by Adrian Buehlmann

Post by Andrey Somov
First, we can choose for a derivative work either GPLv2 or GPLv3 without
asking any permissions since GPLv3 is a successor of GPLv2. ..

No. As Matt already made clear on this list.
The license of Mercurial is GPL v. 2. Not "GPL v. 2 or any later".

Thank you for the clarification.

Post by Adrian Buehlmann

Post by Andrey Somov
Second, if you document the implementation of fncache or somebody will
reverse-engineer the code (like it happened with the NTFS filesystem)
then it is legal to use any license.

No. It isn't.
One notable difference to your example is that the NTFS filesystem's
original implementation is closed source. That alone changes the
picture a lot.
The code of fncache has already been published. Under GPL v. 2.
Claiming that you haven't looked at it is unreasonable.

Then I claim that MS Internet Explorer must be open sourced since it
implemented CSS 2.1 after Firefox and MS may have a look in the open
implementation.
The pure fact that something is open does not mean it is of any use.

NTFS is only one example. There is SvnKit. (its parent is Open Source)
JGit is even better example. Git is GPLv2 and JGit is under a BSD like
license.

I think I got the answer to my question: I have to stick to GPLv2. Which
makes the whole exercise absolutely useless.

P.S. I wonder what is the future of HgKit ...

[William Dode]

Post by Andrey Somov

Post by Adrian Buehlmann

Post by Andrey Somov
First, we can choose for a derivative work either GPLv2 or GPLv3 without
asking any permissions since GPLv3 is a successor of GPLv2. ..

No. As Matt already made clear on this list.
The license of Mercurial is GPL v. 2. Not "GPL v. 2 or any later".

Thank you for the clarification.

Post by Adrian Buehlmann

Post by Andrey Somov
Second, if you document the implementation of fncache or somebody will
reverse-engineer the code (like it happened with the NTFS filesystem)
then it is legal to use any license.

No. It isn't.
One notable difference to your example is that the NTFS filesystem's
original implementation is closed source. That alone changes the
picture a lot.
The code of fncache has already been published. Under GPL v. 2.
Claiming that you haven't looked at it is unreasonable.

Then I claim that MS Internet Explorer must be open sourced since it
implemented CSS 2.1 after Firefox and MS may have a look in the open
implementation.
The pure fact that something is open does not mean it is of any use.
NTFS is only one example. There is SvnKit. (its parent is Open Source)
JGit is even better example. Git is GPLv2 and JGit is under a BSD like
license.

Maybe we mix patent and license question... isn't it ?

Post by Andrey Somov
I think I got the answer to my question: I have to stick to GPLv2. Which
makes the whole exercise absolutely useless.
P.S. I wonder what is the future of HgKit ...

[Fredrik Jonson]

Post by Andrey Somov
I think I got the answer to my question: I have to stick to GPLv2. Which
makes the whole exercise absolutely useless.

If that is your conclusion I think you interpreted the answers you got the
wrong way -- or perhaps I your initial question. ;)

Seriously, I think that anyone claiming that someone re-implementing hg in any
other language automatically also have to use GLPv2 is very wrong.

Yes, if you where to take the current mercurial code and convert it straight
into java, using the exact same constructs and design, for example with some
imaginary py2java tool or just wrapping jpython around the current code as is,
the result would almost certainly be considered a derivative work and requires
the same license.

Now, if you on the other hand just use the python source code of mercurial
merely as documentation for how mercurial works, and otherwize choose your own
technical solutions and your own code in the java implementation, the work
cannot reasonalby be considered derivative, and you're free to use whatever
license you want.

I agree that a Java implementation using GPLv2 would add very little to the
community. Greg Ward's proposal is probably more serious than he intended, if
you go with a very permissive X11/MIT/BSD license your project can be included
in both Apache and GPL licensed based projects. Of course, choose that path
and be prepared for the possibility that Evil Corp[tm] may also use the code
without ever giving back even a single line of code to the open source
community.

[Matt Mackall]

Post by Fredrik Jonson
Now, if you on the other hand just use the python source code of mercurial
merely as documentation for how mercurial works, and otherwize choose your own
technical solutions and your own code in the java implementation, the work
cannot reasonalby be considered derivative, and you're free to use whatever
license you want.

That may be true. But only a court can say for sure.

Post by Fredrik Jonson
I agree that a Java implementation using GPLv2 would add very little to the
community. Greg Ward's proposal is probably more serious than he intended, if
you go with a very permissive X11/MIT/BSD license your project can be included
in both Apache and GPL licensed based projects. Of course, choose that path
and be prepared for the possibility that Evil Corp[tm] may also use the code
without ever giving back even a single line of code to the open source
community.

You can also expect that I for one would rather unfriendly towards a
non-copyleft implementation of Mercurial.

[Romain Pelisse]

I really think that a "Java-way-to-access-to-Mercurial" would really
provides a better integration for many tools (Eclipse, Ant, Maven...),
hence, help people working with Java by letting them use Mercurial properly.

[Stefano Mioli]

Post by Matt Mackall

Post by Fredrik Jonson
Now, if you on the other hand just use the python source code of mercurial
merely as documentation for how mercurial works, and otherwize choose your own
technical solutions and your own code in the java implementation, the work
cannot reasonalby be considered derivative, and you're free to use whatever
license you want.

That may be true. But only a court can say for sure.

Another thing that should be pointed out is that Mercurial is first of all a
"concept", a "set of ideas" (specifically, *your* idea of how SCM can be done,
as Git reflects Linus' idea about the same matter). The actual Python source
code we all know and love is only a practical implementation of that idea.

[Carey Evans]

OTOH, since there isn't a complete and formal description of how Mercurial
works, reading the actual Python code is compulsory.

Someone might have to read the actual Python code, but it might not be
the same person that wrote the Java code. A lot of details could be
worked out simply by observing the current behaviour, too. Wireshark
is surely not a derived work of Microsoft Windows just because it can
decode SMB2, or rsync because it can decode its wire protocol.

Though as Matt said, it's up to the lawyers, and an EPL-compatible
implementation of Mercurial might not be well received in any case.
The intent of the copyright holders counts, too.

[Adrian Buehlmann]

Post by Carey Evans

OTOH, since there isn't a complete and formal description of how Mercurial
works, reading the actual Python code is compulsory.

Someone might have to read the actual Python code, but it might not be
the same person that wrote the Java code.

I doubt this trick would impress a judge. This might work if
the code had not been published and the implementer never had
access to the original code. Beware of reverse engineering
clauses though.

And if we assume it would work, pretty much no one of the current
contributors could contribute to such a port.

And what about those that only responded to a patch posted on the
list?

Post by Carey Evans
A lot of details could be
worked out simply by observing the current behaviour, too. Wireshark
is surely not a derived work of Microsoft Windows just because it can
decode SMB2, or rsync because it can decode its wire protocol.

Again, you neglect the fine detail that the MS sources never have
been published.

For example, for patents (yes I know, code is not a patent..), it makes
a whole difference if something has been published or not.
And what counts as "has been published" can be quite surprising at
times.

There are some situations where claiming to not have read something
doesn't help.

Post by Carey Evans
Though as Matt said, it's up to the lawyers, and an EPL-compatible
implementation of Mercurial might not be well received in any case.
The intent of the copyright holders counts, too.

[Carey Evans]

Post by Adrian Buehlmann
Again, you neglect the fine detail that the MS sources never have
been published.

Part of their sources may be available under the LGPL, or at least
something that their code is a derived work of:
http://www.opengroup.org/dce/download/

I see that Wireshark is available under the GPL version 2 or later,
which does make it compatible with rsync using GPL 3. The PostgreSQL
dissector for Wireshark was written based on the published protocol,
though, and is not licensed under the original BSD license.

Do you believe that there is any way that a program that reads
Mercurial revlogs could _not_ be a derived work of the Python
implementation?

[Mike Meyer]

On Tue, 29 Sep 2009 00:03:30 +0200

Post by Adrian Buehlmann

Post by Carey Evans

OTOH, since there isn't a complete and formal description of how Mercurial
works, reading the actual Python code is compulsory.

Someone might have to read the actual Python code, but it might not be
the same person that wrote the Java code.

I doubt this trick would impress a judge. This might work if
the code had not been published and the implementer never had
access to the original code. Beware of reverse engineering
clauses though.

The code having been published is immaterial - what's important is
that the implementer never had access to the original code. This is a
standard "clean room" re-implementation technique, which was developed
specifically to provide an air-tight defense against copyright
lawsuits. If it didn't work, the world would be a *radically*
different place. Pretty much every IBM-compatible BIOS on the market
was written this way - except IBM's original one. That there are Unix
clones at all depends on this being possible: Linux is a clean-room
reimplementation of the Unix kernel (one of a number of them). SCO
tried to show that the Linux developers had to have violated the
clean-room process; they knew better than to try and show that such a
process violates copyright.

Post by Adrian Buehlmann

Post by Carey Evans
A lot of details could be
worked out simply by observing the current behaviour, too. Wireshark
is surely not a derived work of Microsoft Windows just because it can
decode SMB2, or rsync because it can decode its wire protocol.

Again, you neglect the fine detail that the MS sources never have
been published.

Doesn't matter - the binaries have been published, and they are a work
derived from the source. If you translate the binaries to some other
language, you're producing a derived work. This is why reverse
engineering can infringe copyright.

Post by Adrian Buehlmann
For example, for patents (yes I know, code is not a patent..), it makes
a whole difference if something has been published or not.

Only for establishing priority. Publication doesn't enter into the
question of whether or not you are infringing on a patent. Patents
cover the idea; you infringe them when you use the same idea, even if
you invented it independently. Unless you can invalidate the patent by
proving you (or someone else) invented it before the patent holder -
which is where publication suddenly becomes *very* important.

Copyright covers the *expression*. You infringe it if you copy the
expression, not the idea. If someone had patented the idea of the
DVCS, hg, git, bzr, etc. would all be in violation of the
patent. Since the only thing that happened was copyrighting the code,
others are free to write their own expression of that idea.

You can copyright a user interface. So even a clean room
reimplementation of mercurial would violate copyright if it provided
the same user interface as mercurial.

<mike

[Adrian Buehlmann]

Post by Mike Meyer
On Tue, 29 Sep 2009 00:03:30 +0200

Post by Adrian Buehlmann

Post by Carey Evans

OTOH, since there isn't a complete and formal description of how Mercurial
works, reading the actual Python code is compulsory.

Someone might have to read the actual Python code, but it might not be
the same person that wrote the Java code.

I doubt this trick would impress a judge. This might work if
the code had not been published and the implementer never had
access to the original code. Beware of reverse engineering
clauses though.

The code having been published is immaterial - what's important is
that the implementer never had access to the original code.

Now you have to explain me how participants of the mercurial
mailing lists should manage to never have had access to the code
of mercurial.

Folks, we have the year 2009 now. I wouldn't be surprised if
you could even use Google to search in the mercurial code.

Post by Mike Meyer
This is a
standard "clean room" re-implementation technique, which was developed
specifically to provide an air-tight defense against copyright
lawsuits. If it didn't work, the world would be a *radically*
different place. Pretty much every IBM-compatible BIOS on the market
was written this way - except IBM's original one. That there are Unix
clones at all depends on this being possible: Linux is a clean-room
reimplementation of the Unix kernel (one of a number of them). SCO
tried to show that the Linux developers had to have violated the
clean-room process; they knew better than to try and show that such a
process violates copyright.

And how does that apply to the problem we discuss here?

Post by Mike Meyer

Post by Adrian Buehlmann

Post by Carey Evans
A lot of details could be
worked out simply by observing the current behaviour, too. Wireshark
is surely not a derived work of Microsoft Windows just because it can
decode SMB2, or rsync because it can decode its wire protocol.

Again, you neglect the fine detail that the MS sources never have
been published.

Doesn't matter - the binaries have been published, and they are a work
derived from the source. If you translate the binaries to some other
language, you're producing a derived work. This is why reverse
engineering can infringe copyright.

? We are talking about porting the mercurial sources here.

One of the original poster's goals seemed to be to ged rid of the
restrictions imposed by GPL, so he can use the code in an environment
that is incompatible with GPL software.

So in what sense are binaries relevant here?

Post by Mike Meyer

Post by Adrian Buehlmann
For example, for patents (yes I know, code is not a patent..), it makes
a whole difference if something has been published or not.

Only for establishing priority. Publication doesn't enter into the
question of whether or not you are infringing on a patent.

As I said, we are talking about copyright here. Not about patents.
I just gave an example.

An yes, it does matter if an otherwise patentable technical solution
has been published before or not.

Try to file a patent claim for something that *has* already been
published but no patent claim been filed at the moment of publication.

But we digress.

Post by Mike Meyer
Patents
cover the idea; you infringe them when you use the same idea, even if
you invented it independently. Unless you can invalidate the patent by
proving you (or someone else) invented it before the patent holder -
which is where publication suddenly becomes *very* important.
Copyright covers the *expression*. You infringe it if you copy the
expression, not the idea. If someone had patented the idea of the
DVCS, hg, git, bzr, etc. would all be in violation of the
patent. Since the only thing that happened was copyrighting the code,
others are free to write their own expression of that idea.

"the only thing that happened was copyrighting the code"

No. For one thing, Matt published a paper about how revlog works
for an SCM. That would affect others trying to file a patent claim
for the same technique.

Post by Mike Meyer
You can copyright a user interface. So even a clean room
reimplementation of mercurial would violate copyright if it provided
the same user interface as mercurial.

You digress even more.

I think it is fruitless to continue like this on this thread. If there
are people who want to try forcing a wholly different license
on a port of mercurial and they believe that they will succeed by
merely switching the implementation language, then they are of course
free to test that in court. The next step would then be to make
a closed source derived commercial product out of that -- since it is
then based on a "new" license that allows that, isn't it? Good luck!

I for one would not want to risk wasting my time on such an attempt,
as I believe it is nearly impossible not to make a derived work
of mercurial. Simply switching to another implementation
language doesn't change anything for sure.

The original python code is so clean and at such a high level
that it almost serves as an executable specification. Trying to
claim not to have derived from that is highly risky at best.
We are not talking about starting from a huge pile of illegible
and crude assembler code. But we do talk about switching from
GPL to wholly different license.

Obviously, this is just my personal opinion and this is no legal
advice at all, since I am not a lawyer.

The whole point why I am posting at all on this thread is that
I might have been interested in contributing to port to a compile
time type checking language (preferring Scala over Java, specifically).
But if one of the project's main goals is to circumvent the GPL and
the Java switch is taken as a "helpful" excuse for doing that,
then I am not interested at all.

[Alexander Schatten]

As much as I personally would like to have a Java implementation of Mercurial (as I am practically 100% in Java projects, yet love Mercurial), I believe that the GPL problem would be very hard to overcome.

(As a sidenote: I *personally* believe that GPL-licensing is a pretty bad idea; it is in my opinion against the Open Source idea as it in effect closes the source code for many applications; just my opinion. However, that is the situation we are facing here.)

I believe a way *could* be just taking the hg commands plus a re-engineering of the protocols as a basis.

Having said that, this seems to be a pretty intense piece of work, legally problematic and even if accomplished: the next problems are around the corner: the Java group has to reeingineer each new Mercurial function or has, in effect, forked Mercurial and we have what the world needs: another DSCM.

So, in my opinion this is a waste of energy. It could be a good idea though, to try to get Mercurial running stable within Jython. Then we could easily embed it in Java tools and access it with Java API without hassle.

(However, the unfortunate GPL thing is still in the way e.g. if someone would want to embed it.)


Just my opinion.


Alex

[Andrey Somov]

I am afraid the discussion goes to a different direction.
My question is not whether the Java port is derived work or not. For me
it is clearly derived work since I am not only going to look at the code
but also to import the changes during the maintenance of Python Mercurial.

My question is whether the community (copyright holders ?) object if the
port is released with another Open Source license - Apache License v2.0

- we get a port to a statically typed language
- Java developers will get a convenient tool
- Mercurial will work on platforms where Python is not available

Post by Adrian Buehlmann
If the exercise was to try to circumvent the license restrictions
imposed by GPL v2 by just switching the programming language, then the
risk that you violate that license is very high.

As far as I see from the discussion if the Mercurial developers do not
see any threat to the Python Mercurial then I get almost green light.

-Andrey

[Dirkjan Ochtman]

Post by Andrey Somov
My question is whether the community (copyright holders ?) object if the
port is released with another Open Source license - Apache License v2.0
- we get a port to a statically typed language
- Java developers will get a convenient tool
- Mercurial will work on platforms where Python is not available

It seems to me that, if your Java version of Mercurial is clearly a
derived work, then you're bound by the terms of the GPL to license
your Java port as GPL as well. This is supposedly what the viral
nature of the GPL is all about.

Second, since the body of copyright holders for Mercurial is rather
large (and, if I'm not mistaken, some of them might be unwilling), I
don't think an exception is very feasible.

Cheers,

Dirkjan

[Alexander Schatten]

Ok, sorry for the weird subject, don't know how to express it clearer. The thing is:

I have a project currently in SVN. Now, part of the project is closed source (a book actually) the other part is intended to become open source. Now the hg convert extension with includes and exludes is great and I managed to write a script in no time to create two Mercurial repositories from the one SVN. That's great.

Now the challenge: I want to put the Open Source part to Google Code, but there were still certain documents and files in there that are not intended for the public (e.g. containing server rsync statements, personal emails and the like).

Now, I could easily write excludes for the still existing files. I just wonder (the project is more than three years old): are there probably some problematic files still in the history, that were once deleted with svn delete, hence are not visible today.


So now back to my question: is there a way, to get a list of all files in the history of a Mercurial project that ever have been deleted (but of course are still in the repository)?

Having such a list, I could figure if there might be still problematic files in the converted project.

Is this a weird request?


thanks a lot.


Alex

[Carey Evans]

Post by Andrey Somov
- we get a port to a statically typed language
- Java developers will get a convenient tool
- Mercurial will work on platforms where Python is not available

All of these points are still valid for a GPLv2 licenced port of
Mercurial. The one that isn't is, "Eclipse and NetBeans plugins can
embed Mercurial rather than executing a separate program," since their
licenses are not compatible with the GPL.

Other things are not so clearly a derived work, like parsing just
enough of the data under .hg to work out which files are modified
without running hg status, using completely new code.

[Andrey Somov]

Post by Carey Evans

Post by Andrey Somov
- we get a port to a statically typed language
- Java developers will get a convenient tool
- Mercurial will work on platforms where Python is not available

All of these points are still valid for a GPLv2 licenced port of
Mercurial. The one that isn't is, "Eclipse and NetBeans plugins can
embed Mercurial rather than executing a separate program," since their
licenses are not compatible with the GPL.

Why do need a Java port then ? We can keep using hg.
But this way is ugly, slow and it requires a separate installation of
Python and Mercurial even for those who do not use Python.

Post by Carey Evans
Other things are not so clearly a derived work, like parsing just
enough of the data under .hg to work out which files are modified
without running hg status, using completely new code.

[Andrew Lentvorski]

Post by Matt Mackall
You can also expect that I for one would rather unfriendly towards a
non-copyleft implementation of Mercurial.

And, to be honest, this is really more key than anything else, no?

Can a non-copyleft Mercurial be built legally? Almost certainly.
However, you'd better know how to jump through some major legal hoops to
prove this as you're going to make more than a few people quite angry.

At that point, why bother? You're implementation will always be treated
like a second-class pariah and users won't want to use it anyway.

Your best bet is probably a plugin into a Mercurial running in Jython.
This avoids requiring users to do a separate binary install of Python
onto their system.

While I find git and mercurial roughly equivalent, I have a slight
preference for mercurial over git because git was a second-class citizen
on Windows for a long time. If, however, my development were primarily
on Eclipse and I had issues getting mercurial installed everywhere I
needed but could get git because its a part of Eclipse, I would switch.
<shrug>

The license is what the license is. Live with it or vote with your feet.

The developers get the first word, but the users *always* get the last word.

-a

[Adrian Buehlmann]

Post by Andrey Somov
I think I got the answer to my question: I have to stick to GPLv2. Which
makes the whole exercise absolutely useless.

If the exercise was to port the implementation to a strongly typed
language that provides lots of checks at compile time, then the
exercise might very well be interesting. But the effort would
be considerable.

If the exercise was to try to circumvent the license restrictions
imposed by GPL v2 by just switching the programming language, then the
risk that you violate that license is very high.

[Antoine Pitrou]

For example, take the fncache filename encoding I have done. You can't
tell me you reimplement that encoding without looking at my original
Python code and thus create a derivative work.

This is stupid. Just because you reproduce some algorithm that you read
in a copyrighted textbook or program doesn't mean you are subject to the
copyright of that textbook/program. If it was the case it would be
impossible to develop any software at all.
(it is the very problem with software patents by the way, which are a
completely different issue than copyright)

Besides, the one important question is not:
« would a Java rewrite be considered a derivative work? »
It is:
« would be the Mercurial authors be angry (and perhaps sue) if such a
Java implementation were licensed under another OSS license than the GPL
v2? »

If the answer to the latter question is « no », then the question of what
a court would decide is irrelevent since nobody will sue you. Remember,
free software is not about licenses and legalese; it is about
communities, culture and mutual trust.

Regards

Antoine.

[Alexander Schatten]

Post by Antoine Pitrou
« would be the Mercurial authors be angry (and perhaps sue) if such a
Java implementation were licensed under another OSS license than the GPL
v2? »
If the answer to the latter question is « no », then the question of what
a court would decide is irrelevent since nobody will sue you. Remember,
free software is not about licenses and legalese; it is about
communities, culture and mutual trust.

This is unfortunately a massive misunderstanding of the legal situation as I understand it. Even if ALL contributors (which is in itself unlikely) of Mercurial would have no problem that a derivative work is offered under a different license, the undertaking is a big risk.

EVERYONE also outside the Mercurial community (even your neighbour or colleague who does not like you) can sue you an the basis of the GPL license of Mercurial if you produce derivative work grounded on GPL.

The main issue is, and this is probably legally really difficult to answer, if a Java port is derivative work or not. (And this was discussed in other threads already; and is probably pretty depending on the strategy the Java team would apply, as I mentioned in my previous posting) This is the only question that really counts.


Alex

[William Dode]

Post by Alexander Schatten
The main issue is, and this is probably legally really difficult to
answer, if a Java port is derivative work or not

And what about a python port *from the java port* ;-) ?

[Antoine Pitrou]

Post by Alexander Schatten
EVERYONE also outside the Mercurial community (even your neighbour or
colleague who does not like you) can sue you an the basis of the GPL
license of Mercurial if you produce derivative work grounded on GPL.

No. Only one of the copyright holders can sue you for copyright
infringement.

[Andrey Somov]

Post by Antoine Pitrou
« would a Java rewrite be considered a derivative work? »
« would be the Mercurial authors be angry (and perhaps sue) if such a
Java implementation were licensed under another OSS license than the GPL
v2? »
If the answer to the latter question is « no », then the question of what
a court would decide is irrelevent since nobody will sue you. Remember,
free software is not about licenses and legalese; it is about
communities, culture and mutual trust.

I was of the same opinion when I was asking the question. Now I think
GPL creates problems for the Open Source communities and culture.
It is not EPL (Eclipse) or Apache licenses which do not want other
projects to be included it is GPL which objects to co-operate if certain
criteria are not met.
I see a very clear message - do not use GPL unless you have to.

-
Andrey

[Adrian Buehlmann]

Post by Andrey Somov

Post by Antoine Pitrou
« would a Java rewrite be considered a derivative work? »
« would be the Mercurial authors be angry (and perhaps sue) if such a
Java implementation were licensed under another OSS license than the GPL
v2? »
If the answer to the latter question is « no », then the question of what
a court would decide is irrelevent since nobody will sue you. Remember,
free software is not about licenses and legalese; it is about
communities, culture and mutual trust.

I was of the same opinion when I was asking the question. Now I think
GPL creates problems for the Open Source communities and culture.

Some would say non-GPL projects create problems.

But I agree that the whole plethora of open source licenses is a
problem.

Post by Andrey Somov
It is not EPL (Eclipse) or Apache licenses which do not want other
projects to be included it is GPL which objects to co-operate if certain
criteria are not met.

Basically, we have two unidirectionally incompatible kinds of open source
licenses today: GPL and BSD-like.

The two are incompatible in the sense that you can pull BSD-licensed
code into GPL projects. But you cannot pull GPL code into BSD-like
projects or switch a project from GPL to BSD-like.

Once GPL, it is GPL forever.

People that pick and love the GPL mostly do it because they don't
want their code taken by company X, modified and extended for product
Y and sold *without* publishing the modified code.

But interestingly, the GPL allows to use modified code internally
without publishing the modifications.
As long as you don't give away or sell binaries created from the
modified code, you are free to keep your modifications private.

We can assume that all kinds of companies do that today.
For a large company "internal use" means a lot of users.
And they can provide services based on such modified GPL
code. Think of a web server using unpublished variants of
GPL'ed software.

GPL doesn't even allow a BSD-like licensed software to link with
libraries licensed under GPL. Only LGPL allows that.

Post by Andrey Somov
I see a very clear message - do not use GPL unless you have to.

GPL has significant implications, yes. Don't pick it if
you don't want them.

[Adrian Buehlmann]

Post by Antoine Pitrou

For example, take the fncache filename encoding I have done. You can't
tell me you reimplement that encoding without looking at my original
Python code and thus create a derivative work.

This is stupid. Just because you reproduce some algorithm that you read
in a copyrighted textbook or program doesn't mean you are subject to the
copyright of that textbook/program. If it was the case it would be
impossible to develop any software at all.

Antoine, I'm sorry that you seem to get angry here. It might help to
understand that I am not the one who picked the GPL v. 2 for mercurial.
I have contributed to mercurial and my contributions are thus
bound to the GPL v. 2. Forever. Because those contributions are based on a
revision of mercurial subject to the GPL v. 2 and on discussions on the -devel
mailing list, which in the case of fncache are specifically significantly
based on important ideas and suggestions by Peter Arrenbrecht and Matt Mackall
(And certainly others as well who participated in that thread back then.
I can't remember all of them right now without digging through the
archives).

Back to your post. You seem to be misunderstand something here.

If we have, say 30 important technical ideas in mercurial, implemented
in Python and this implementation copyrighted and licensed to everybody
under the terms of the GPL v. 2.

Then assume you find those exact 30 technical solutions in the sources
of another project that openly announces that it is a "better" variant
of mercurial with a much more liberal license. I say better here,
because the initiator of the port claims that the ported code is not
restricted anymore by by the very restrictive GPL (I'm not talking
about Andrey here, since he already admitted that his port would be
a derivative work - hence by subject to the GPL v. 2 I say...).

And a lot of people trust that initiator. And start using the "ported"
code in each and every way that the "new" license magically "allows"
now. Including company X who takes that code and modifies it to create
product Y and sell it. Without publishing their changes to the code.
Because the new "magic" license allows that. All based on that
poor initiator's brittle judgement.

Then all I say is it could be hard to convince a court that this
is not a derivative work of mercurial. The initiator of the port
would have to claim that in order to defend the license switch, since
this is the only way to get rid of the GPL.

The GPL is very invasive, you see. It is viral on nature.
Like it or not, be disappointed, or pissed off: it doesn't matter.
The GPL still applies. To Mercurial.

And the imagine the judge may then get some lists with arguments filed by
the parties.

One such entry on the list could then be the observation that
the fncache encoding algorithm in the offending port
(again -- offending, because of the incompatible license)
uses the exact same "algorithm" as the original python code.

Parties will show the code samples of mercurial and the
magic port. How do you think will those code examples
compare for the fncache encoding?

That's why I said "For example, take the fncache filename encoding".

I agree that finding the fncache filename encoding in another
-- possibly non GPL -- open source SCM might not be enough for
that other project to count as a derivative work.

But if you find 29 other similar technical tricks in that port, I fear
the kitchen might get a lot hotter.

Post by Antoine Pitrou
(it is the very problem with software patents by the way, which are a
completely different issue than copyright)
« would a Java rewrite be considered a derivative work? »
« would be the Mercurial authors be angry (and perhaps sue) if such a
Java implementation were licensed under another OSS license than the GPL
v2? »
If the answer to the latter question is « no », then the question of what
a court would decide is irrelevent since nobody will sue you. Remember,
free software is not about licenses and legalese; it is about
communities, culture and mutual trust.

I'm sorry, but free software is a whole lot about licenses and
legalese *iff* you announce to start a fork of mercurial with
an incompatible license.

If you plan to break the GPL, then what culture exactly
is that then, please? And how can we have "mutual trust"
in each other then?

If you want to take that risk, please go on.
It might be that it will not have a direct influence on you
as a contributor to that "magic" port. But your effort could
be wasted.

I don't say I'll sue you. But I can't say the contrary either.
All I can say is that the code is licensed to you under GPL v. 2.

[Andrey Somov]

... And start using the "ported"
code in each and every way that the "new" license magically "allows"
now. Including company X who takes that code and modifies it to create
product Y and sell it. Without publishing their changes to the code.
Because the new "magic" license allows that.

What is the problem ? How does it make any harm to Mercurial ?

IBM takes Apache web server makes some modifications and sells it as
part of WebSphere. Why does it make Apache server any worse ?
They still contribute to the core, they still report bugs, they still
spread the application and they still help to make it better.
And they do not force me to use WebSphere.
I do not say I would like to take this path but I do not mind if
somebody takes the port and makes a beautiful GUI application out of it.
It will make my life better.

-
Andrey

P.S. Thank you for your time and being patent with explanations...

[William Dode]

Post by Andrey Somov

... And start using the "ported"
code in each and every way that the "new" license magically "allows"
now. Including company X who takes that code and modifies it to create
product Y and sell it. Without publishing their changes to the code.
Because the new "magic" license allows that.

What is the problem ? How does it make any harm to Mercurial ?

The question you should ask also is why theses others projects didn't
use GPL license ? They will answer that this license is viral. Like if
to be free was a disease !

[Alexander Schatten]

Post by Andrey Somov
What is the problem ? How does it make any harm to Mercurial ?
IBM takes Apache web server makes some modifications and sells it as
part of WebSphere. Why does it make Apache server any worse ?
They still contribute to the core, they still report bugs, they still
spread the application and they still help to make it better.
And they do not force me to use WebSphere.
I do not say I would like to take this path but I do not mind if
somebody takes the port and makes a beautiful GUI application out of it.
It will make my life better.

I am afraid, you are not getting the point at all here. What you describe here is YOUR opinion. Your opinion is fine. It is also MY opinion, this is why *I* would NEVER choose GPL as a license. *I* believe it is a pretty bad idea to use GPL in nearly all cases. This is MY and YOUR opinion. And everyone has to accept different opinions.

However, in this situation YOUR and MY opinion are totally, utterly irrelevant. The guys picked GPL. They decided by whatever reason. NOW that is a contract that you accept when you use the Software. That's how it is. You and I can accept it, or leave.



Alex

[Adrian Buehlmann]

Post by Andrey Somov

... And start using the "ported"
code in each and every way that the "new" license magically "allows"
now. Including company X who takes that code and modifies it to create
product Y and sell it. Without publishing their changes to the code.
Because the new "magic" license allows that.

What is the problem ? How does it make any harm to Mercurial ?

Some people see that as a slap in their face if a company
earns money based on their unpaid work and that company
doesn't want to share some of the changes.

That's the main problem of the BSD like licenses.

Post by Andrey Somov
IBM takes Apache web server makes some modifications and sells it as
part of WebSphere. Why does it make Apache server any worse ?

It doesn't. But some people don't want to give away their
hard work for nothing under such an arrangement.

Post by Andrey Somov
They still contribute to the core, they still report bugs, they still
spread the application and they still help to make it better.

That might well be.

Post by Andrey Somov
And they do not force me to use WebSphere.

But if you want a nifty new feature that is only available
in WebSphere, then you only get it if you pay for it.

Some people don't want to share their code to be used
like that.

Post by Andrey Somov
I do not say I would like to take this path but I do not mind if
somebody takes the port and makes a beautiful GUI application out of it.
It will make my life better.

Ok. I'm hoping we can end this subject now and move
on to more on-topic things (i.e. about using and improving
mercurial).

Maybe there are more specific lists out there about
GPL license questions.

[Paul Moore]

Post by Adrian Buehlmann
Maybe there are more specific lists out there about
GPL license questions.

Sadly, it appears that every list is the place to have endless
arguments about open source licenses :-(

Please, can this thread die?
Paul.

[Martin Geisler]

Post by Paul Moore

Post by Adrian Buehlmann
Maybe there are more specific lists out there about
GPL license questions.

Sadly, it appears that every list is the place to have endless
arguments about open source licenses :-(

It's not sad -- it shows that there are people who care about moving the
project to other platforms where they find other license terms better.
It would be very sad if nobody in the Java world cared for Mercurial and
they just all went along with JGit:

http://article.gmane.org/gmane.comp.version-control.git/115843

Post by Paul Moore
Please, can this thread die?

I don't think we should just ignore the problem.

I think the interesting question is this: will Matt ask the Software
Freedom Conservancy to look into legal action if a Java port appears
under a non-copyleft license?

[Theodore Tso]

Post by Martin Geisler
It's not sad -- it shows that there are people who care about moving the
project to other platforms where they find other license terms better.
It would be very sad if nobody in the Java world cared for Mercurial and
http://article.gmane.org/gmane.comp.version-control.git/115843

One of the reasons why it was easier to create a re-implementation of
git was because the low-level data structures and algorithms of git
are very well documented. (Originally, in the main git man page,
which contributed to git's reputation of being hard to understand, but
that's since been moved away so the average user doesn't need to worry
about things.) Furthermore, while JGIT was being implemented, the
folks asked questions about whether some detail of (for example) how
packs were constructed was an implementation detail or something that
could be assumed to be something that would be guaranteed for
long-term interoperability's sake, and folks on the git list were
quite supportative about answering such questions and documenting the
answers to make interoperable implementations possible.

Post by Martin Geisler

Post by Paul Moore
Please, can this thread die?

I don't think we should just ignore the problem.
I think the interesting question is this: will Matt ask the Software
Freedom Conservancy to look into legal action if a Java port appears
under a non-copyleft license?

You're asking the wrong question. "Port" usually implies that you
straight translation of the code, and that normally *is* a derivative
work, which means you need to get the permission of all of the
copyright holders to release it under a different license.

The real question is whether Matt and the mercurial community are
willing to be supportive about someone creating an independent,
interoperable reimplementation of the Mercurial DSCM. If the answer
is yes, the next question is whether you intend to be compatible just
at the protocol level, and/or at the on-disk repository level.

Both from a software engineering perspective, as well as a legal
perspective, the best way to begin (I would suggest) is to start by
documenting protocol and repository storage formats. Once you have
documentation, you can start implementing from the specifications. At
that point, you're not really porting, you are documenting (which
would be a good thing for the Mercurial community) and then
re-implementing, in native Java (and not Python) idiom, a new
implementation of the Mercurial DSCM.

If you don't like that solution, to other possibilities are of course
to simply use Jython (which has already been suggested) or just
calling the Mercurial program by executing the cli requests from a
Java driver program. Both of these two solutions will be much less
work, and the second may actually be more performant in the end,
unless you have really good Java implementation skills.

(It's really hard to write performant Java code on top of 20 layers of
abstractions, which is why most Java programmers have a
deer-caught-in-headlights look when you ask them about concepts such
as "cache footprint" or "cache line misses". Hence, the overhead of
creating a new process each time you need to run a hg command
implemented in Python supplemented with C code for speed may be more
than compensated with the speed advantages of not trying to implement
complex algorithms in Java, unless you have really mad Java
programming skillz. If you've ever been forced to use a commercial
Java/Eclipse-implemented mail program which takes a full second to
delete a message and then repaint the screen with the next message in
your inbox, while chewing up over a gig and a half of physical memory
--- well, it's really sad....)

- Ted

[Martin Geisler]

Post by Theodore Tso

Post by Martin Geisler
It's not sad -- it shows that there are people who care about moving
the project to other platforms where they find other license terms
better. It would be very sad if nobody in the Java world cared for
http://article.gmane.org/gmane.comp.version-control.git/115843

One of the reasons why it was easier to create a re-implementation of
git was because the low-level data structures and algorithms of git
are very well documented. [...]

Thanks for the explaination about jgit! I always figured we had okay
documentation for hte low-level stuff, but after looking at

http://mercurial.selenic.com/wiki/Revlog
http://mercurial.selenic.com/wiki/RevlogNG

I guess the documentation is mostly in the code.

Post by Theodore Tso

Post by Martin Geisler
I think the interesting question is this: will Matt ask the Software
Freedom Conservancy to look into legal action if a Java port appears
under a non-copyleft license?

You're asking the wrong question. "Port" usually implies that you
straight translation of the code, and that normally *is* a derivative
work, which means you need to get the permission of all of the
copyright holders to release it under a different license.

I see, I was not aware that the word "port" carried such a meaning.
Sorry sorry about the confusion :-)

Post by Theodore Tso
The real question is whether Matt and the mercurial community are
willing to be supportive about someone creating an independent,
interoperable reimplementation of the Mercurial DSCM.

Yes, that is the question I thought I asked :-)

Post by Theodore Tso
If the answer is yes, the next question is whether you intend to be
compatible just at the protocol level, and/or at the on-disk
repository level.
Both from a software engineering perspective, as well as a legal
perspective, the best way to begin (I would suggest) is to start by
documenting protocol and repository storage formats. Once you have
documentation, you can start implementing from the specifications. At
that point, you're not really porting, you are documenting (which
would be a good thing for the Mercurial community) and then
re-implementing, in native Java (and not Python) idiom, a new
implementation of the Mercurial DSCM.

That is what I meant: that someone sits down and writes a new program
that can read/write revlogs, talk with other Mercurial's over the
network, etc.

But I did not expect that it would be a problem for them to look at the
Mercurial source in order to see exactly how each file format works.

Post by Theodore Tso
If you don't like that solution, to other possibilities are of course
to simply use Jython (which has already been suggested) or just
calling the Mercurial program by executing the cli requests from a
Java driver program. Both of these two solutions will be much less
work, and the second may actually be more performant in the end,
unless you have really good Java implementation skills.

The goal is not only to call Mercurial from Java but instead to
read/write Mercurial clones using BSD/EPL licensed code, which can then
be shipped with Eclipse. At least that's my understanding...

[Theodore Tso]

Post by Martin Geisler
The goal is not only to call Mercurial from Java but instead to
read/write Mercurial clones using BSD/EPL licensed code, which can then
be shipped with Eclipse. At least that's my understanding...

The high level goal is to be able to ship an Eclipse-based product
that will work with Mecurial repositories, though, right? You can
ship multiple programs with different licenses together, as long as
you fulfill the requirements of the license. Some Linux distributions
ship closed-source Java Run-time Environment together with a GPL'ed
kernel and other GPL'ed userspace utilities, and this isn't a problem
at all.

So I wouldn't be too quick to rule out having a Eclipse plugin,
written in Java, call out to Python-based Mercurial cli. This doesn't
violate any licenses. It does mean that you have to ship Python as
well as the Mercurial python scripts and the source to the tiny C bits
of Mercurial --- but there is plenty of space on most CD's, and it
doesn't take that long to download Python+mercurial. In any case,
please don't use the GPL license as an excuse; there's no reason why
everything has to have the same license. Heck, even Microsoft has
been known to ship some GPL'ed code in their products; they are just
have to be in separate executables and they have to ship source for
the GPL'ed components in their products.

- Ted

[Alexander Schatten]

-------- Original-Nachricht --------

Datum: Wed, 30 Sep 2009 22:29:05 -0400
Betreff: Re: Mercurial in pure Java
The high level goal is to be able to ship an Eclipse-based product
that will work with Mecurial repositories, though, right? You can
ship multiple programs with different licenses together, as long as
you fulfill the requirements of the license. Some Linux distributions
ship closed-source Java Run-time Environment together with a GPL'ed
kernel and other GPL'ed userspace utilities, and this isn't a problem
at all.

Yes, but I think there is a misunderstanding here: the question is not what you ship together, but what is linked together.

If the judge asks you, if you can remove the JRE and Linux is still working (except for Java programs) you can say yes; if he asks you if you can put the JRE to a different Linux distribution and Java programs are still working, you can also answer "yes".

But if he asks you, if you can remove Mercurial and the Mercurial Eclipse plugin is still working, the answer is clearly "No". The Plugin only works with Mercurial. Not with GIT, not with Bazaar. Insofar it is pretty hard linked. And that is imho a significant issue that makes the plugin derivative work.


Alex

[Alpar Juttner]

Post by Alexander Schatten
Yes, but I think there is a misunderstanding here: the question is not
what you ship together, but what is linked together.
If the judge asks you, if you can remove the JRE and Linux is still
working (except for Java programs) you can say yes; if he asks you if
you can put the JRE to a different Linux distribution and Java
programs are still working, you can also answer "yes".
But if he asks you, if you can remove Mercurial and the Mercurial
Eclipse plugin is still working, the answer is clearly "No".

But the analogous question here is if JRE is still working when
the kernel is removed, isn't it?

Regards,
Alpar

Post by Alexander Schatten
The
Plugin only works with Mercurial. Not with GIT, not with Bazaar.
Insofar it is pretty hard linked. And that is imho a significant issue
that makes the plugin derivative work.
Alex
_______________________________________________
Mercurial mailing list
http://selenic.com/mailman/listinfo/mercurial

[Theodore Tso]

Post by Alexander Schatten
Yes, but I think there is a misunderstanding here: the question is
not what you ship together, but what is linked together.
If the judge asks you, if you can remove the JRE and Linux is still
working (except for Java programs) you can say yes; if he asks you
if you can put the JRE to a different Linux distribution and Java
programs are still working, you can also answer "yes".
But if he asks you, if you can remove Mercurial and the Mercurial
Eclipse plugin is still working, the answer is clearly "No". The
Plugin only works with Mercurial. Not with GIT, not with
Bazaar. Insofar it is pretty hard linked. And that is imho a
significant issue that makes the plugin derivative work.

This is not at all correct. The question is whether something is a
derived work or not. Copyright licenses get their power from
copyright law, and so at the end of the day, it is not a matter of
whether one program is dependent on another, but a matter of copyright
law, and what it means for something to be a derived work.

By your reasoning, a shell script which runs a GPL'ed program, or a C
program which runs a GPL'ed program using the system(3) library
function, must be under the GPL since the shell script or the C
program wouldn't function if the GPL'ed program exists. This is of
course nonsense. Proprietary programs can run GPL'ed programs without
getting infected by the GPL license. This has been well established
for a long, LONG time.

If you don't believe me, ask the FSF or the SFLC. But please don't
make authoratative statements about copyright law, or attempt to give
legal advice, when you are clearly clueless about such matters.

- Ted

[Remy Blank]

Post by Theodore Tso
So I wouldn't be too quick to rule out having a Eclipse plugin,
written in Java, call out to Python-based Mercurial cli.

And if the CLI is not good enough, write a GPL-2 plugin for Mercurial
that provides an RPC interface to the Mercurial code through
stdin/stdout or a socket, and use that interface from your Eclipse plugin.

It still requires Python to run, though.

-- Remy

[Antoine Pitrou]

Post by Remy Blank
And if the CLI is not good enough, write a GPL-2 plugin for Mercurial
that provides an RPC interface to the Mercurial code through
stdin/stdout or a socket, and use that interface from your Eclipse plugin.
It still requires Python to run, though.

Or Jython :)

[Tom Widmer]

Post by Remy Blank

Post by Theodore Tso
So I wouldn't be too quick to rule out having a Eclipse plugin,
written in Java, call out to Python-based Mercurial cli.

And if the CLI is not good enough, write a GPL-2 plugin for Mercurial
that provides an RPC interface to the Mercurial code through
stdin/stdout or a socket, and use that interface from your Eclipse plugin.
It still requires Python to run, though.

That's probably the way to go. No licencing issues since all code that
is a derivative work of Mercurial is GPLed, and you just need the user
to do the 'obvious' thing of installing Mercurial separately, which
they'd probably do anyway.

That's also quite likely to be the most performant approach without a
lot of work.

Tom

[Andrey Somov]

Post by Tom Widmer

Post by Remy Blank

Post by Theodore Tso
So I wouldn't be too quick to rule out having a Eclipse plugin,
written in Java, call out to Python-based Mercurial cli.

And if the CLI is not good enough, write a GPL-2 plugin for Mercurial
that provides an RPC interface to the Mercurial code through
stdin/stdout or a socket, and use that interface from your Eclipse plugin.
It still requires Python to run, though.

That's probably the way to go. No licencing issues since all code that
is a derivative work of Mercurial is GPLed, and you just need the user
to do the 'obvious' thing of installing Mercurial separately, which
they'd probably do anyway.
That's also quite likely to be the most performant approach without a
lot of work.
Tom

I wanted to stay away but I cannot...

Python has heapq module which implements "the priority queue algorithm."
Why to bother to implement it in Python ? Why not to take it from Java ?
It is simple:

- download and install Java
- install library which implements the priority queue algorithm
- take care that the Java version matches the one required by the library
- write a small Java program for the interface
- launch Java from Python and execute the program
- parse the output taking care that another version of Java or the
library may change it
- get the result and use in your Python program

Is it the way to go ? (I hope you can see the symmetry with Python and
Mercurial)

-
Andrey

[William Dode]

Post by Andrey Somov
Python has heapq module which implements "the priority queue algorithm."
Why to bother to implement it in Python ? Why not to take it from Java ?
- download and install Java
- install library which implements the priority queue algorithm
- take care that the Java version matches the one required by the library
- write a small Java program for the interface
- launch Java from Python and execute the program
- parse the output taking care that another version of Java or the
library may change it
- get the result and use in your Python program
Is it the way to go ? (I hope you can see the symmetry with Python and
Mercurial)

I use postgresql from python, and i never thought about porting it to
python. There is a pure python driver for this but i even don't use this
one.

[Andrey Somov]

Post by William Dode

Post by Andrey Somov
Python has heapq module which implements "the priority queue algorithm."
Why to bother to implement it in Python ? Why not to take it from Java ?
- download and install Java
- install library which implements the priority queue algorithm
- take care that the Java version matches the one required by the library
- write a small Java program for the interface
- launch Java from Python and execute the program
- parse the output taking care that another version of Java or the
library may change it
- get the result and use in your Python program
Is it the way to go ? (I hope you can see the symmetry with Python and
Mercurial)

I use postgresql from python, and i never thought about porting it to
python. There is a pure python driver for this but i even don't use this
one.

When you are satisfied with usage and performance - no problem.

If we have a way to talk to Mercurial through a socket...
(I an afraid this is the only way though.)

-
Andrey

[Boris Samorodov]

Post by Andrey Somov
What is the problem ? How does it make any harm to Mercurial ?

The problem is license. Either accept it and use GPL in a derivered
work or don't create a derivered work.

Post by Andrey Somov
IBM takes Apache web server makes some modifications and sells it as

IBM can do it according to license.

Post by Andrey Somov
part of WebSphere. Why does it make Apache server any worse ?
They still contribute to the core, they still report bugs, they still
spread the application and they still help to make it better.

IBM is not forced to do it according to license.

Apache is under, well, apache. Mercurial is under GPL v. 2.
Accept and use. Don't accept -- don't use.

Suppose, your question is why was GPL v. 2 used for Mercurial. This
question *now* is useless. It *was* done. Either accept or... well,
you already know. ;-)

[Dirkjan Ochtman]

Can we all just end this thread now? Lets leave arguing about licenses
to the actual lawyers.

Cheers,

Dirkjan

[Antoine Pitrou]

Post by Adrian Buehlmann
Antoine, I'm sorry that you seem to get angry here. It might help to
understand that I am not the one who picked the GPL v. 2 for mercurial.

I wasn't angry at anyone in particular. I just happen to have witnessed,
a lot of times in the past, some free software guys fighting in arguments
about legalese when there was no point in doing so :-)

Post by Adrian Buehlmann
If we have, say 30 important technical ideas in mercurial, implemented
in Python and this implementation copyrighted and licensed to everybody
under the terms of the GPL v. 2.

[...]

Post by Adrian Buehlmann
Then all I say is it could be hard to convince a court that this is not
a derivative work of mercurial.

You are talking about "technical ideas". Ideas are not copyrighteable.

"Technical ideas" can be subject to software patents, granted; and that's
the reason why *every* reasonable free software person is against
software patents. Because holding an exclusive right on an idea (or
"technical solution") stops progress immediately. And I certainly hope
Mercurial authors haven't submitted any software patents on the ideas
they used in Mercurial!

Besides, if an algorithm, due to its specification, has one obvious
implementation, then it should come as no surprise that two distinct
implementations of that algorithm will look similar. Do you think that if
you write a bubble sort, it makes your routine a derivative work of
whatever implementation of the bubble sort you might have read before,
just because it "looks like the same"?

(I don't know how fncache works, but if it's just a sequence of escaping
and hashing steps, then most reasonable implementations will reproduce
the same steps in the same order.)

Post by Adrian Buehlmann
If you plan to break the GPL, then what culture exactly is that then,
please? And how can we have "mutual trust" in each other then?

Oh, but my whole point is that it is *not* about breaking the GPL (which
isn't really, obviously, broken). It is about respecting (or not) the
authors' wishes.

And if Matt isn't happy to see non-copylefted implementations of
Mercurial then, yes, a non-copyleft implementation would break that
mutual trust. But that's because Matt decides (and publicly said) it
would. Not because Mercurial is under the GPL, regardless of whether it
is actually broken or not.

(that's also the reason we use mailing-lists to discuss all this instead
of speaking through lawyers and settling things in front of courts!)

Regards

Antoine.

[cbcurl]

Post by Antoine Pitrou
You are talking about "technical ideas". Ideas are not copyrighteable.

No, but API's are. You cannot legally implement hg's API without
honoring its license.

[Antoine Pitrou]

Post by cbcurl

Post by Antoine Pitrou
You are talking about "technical ideas". Ideas are not copyrighteable.

No, but API's are. You cannot legally implement hg's API without
honoring its license.

Then what about the people who reimplemented the GNU readline library
under a non-GPL license? I've not heard about the FSF sueing them.

And I'm not even talking about the various projects to re-implement the
Win32 APIs for non-Windows systems. Can you show me an actual lawsuit
where someone was *condemned* for reimplementing an existing, publicly
accessible API on the basis that the API is copyrighted?

(I'm not talking about other possible reasons, like the fact that there's
a software patent, or that the implementor didn't have any legal access
to the API in the first place)

[Tom Widmer]

Post by cbcurl

Post by Antoine Pitrou
You are talking about "technical ideas". Ideas are not copyrighteable.

No, but API's are. You cannot legally implement hg's API without
honoring its license.

In the US at least, I don't think so, since you can't copyright
functionality:
http://www.eetimes.com/news/design/showArticle.jhtml?articleID=201801579

I doubt it is different in Europe.

Tom

[Robert Kern]

Post by Tom Widmer

Post by cbcurl

Post by Antoine Pitrou
You are talking about "technical ideas". Ideas are not copyrighteable.

No, but API's are. You cannot legally implement hg's API without
honoring its license.

In the US at least, I don't think so, since you can't copyright
http://www.eetimes.com/news/design/showArticle.jhtml?articleID=201801579
I doubt it is different in Europe.

This is, for example, why Wine can implement the Windows API without violating
Microsoft's copyright.

[cbcurl]

Post by Tom Widmer

Post by cbcurl

Post by Antoine Pitrou
You are talking about "technical ideas". Ideas are not copyrighteable.

No, but API's are. You cannot legally implement hg's API without
honoring its license.

In the US at least, I don't think so, since you can't copyright
functionality:http://www.eetimes.com/news/design/showArticle.jhtml?articleID=201801579
I doubt it is different in Europe.

That's good. Does this extend to the command set as well?

[Theodore Tso]

Post by cbcurl

Post by Tom Widmer

Post by cbcurl

Post by Antoine Pitrou
You are talking about "technical ideas". Ideas are not copyrighteable.

No, but API's are. You cannot legally implement hg's API without
honoring its license.

In the US at least, I don't think so, since you can't copyright
functionality:http://www.eetimes.com/news/design/showArticle.jhtml?articleID=201801579
I doubt it is different in Europe.

That's good. Does this extend to the command set as well?

Not in the United States. See:

http://progfree.org/Copyright/copyright.html

Note that the League for Programming Freedom and the Free Software
Foundation called boycotts against Lotus Software while the court case
was being decided, and that both the LPF and the FSF stated position
on Interface Copyrights is that they are Evil. That's because to the
extent that the FSF has implemented programs that replace Unix
programs --- like gawk, bison, ls, rm, etc., --- if copyright extended
to interfaces, it would apply to coreutils, gawk, sed, glibc, etc.
Fortuntaely, it doesn't.

I'll note also that the command set for hg, bzr, and git all look very
similar to each other, and to predecessor systems, such as BitKeeper.
And no, that's not a copyright problem either.

<Sigh>

- Ted

[Andrey Somov]

Post by Greg Ward

Post by Matt Mackall

Post by Andrey Somov
I wonder whether I can get the answer to my question: do I have to
apply the GPL license to the Java port ?

If your version is a "derived work", then the answer is yes.
Unfortunately, "derived work" is a legal term, the precise definition of
which can only be determined by testing various theories of it in a
court of law. But it's probably true that if you directly translate
code, you're making a derived work, as would be the case with a book.

Literally translating Mercurial to Java would 1) be very difficult and
painful, and 2) result in very strange-looking Java code. Java has
its own conventions and idioms, and Mercurial's style of mixed
functional and OO programming is not well supported and therefore not
common. (Which is probably why someone suggested Scala: if you want
that kind of code to run under a JVM, Scala is probably a good way to
go.)
That's actually *good* news for Andrey: a cleanroom implementation
that uses native Java idioms would be much less likely to be
considered a derived work, and therefore less likely to require the
GPL. It would also be much more likely to attract contributors from
the Java community. But I doubt that Mercurial is sufficiently well
documented (other than its source code, of course) to allow for a
cleanroom implementation. It all depends how careful you want to be
of legal issues.
At any rate, I strongly suspect that an attempt to reimplement
Mercurial in Java, even if it's for the limited purpose of making
extensions. That is, even if you get every single feature of core
Mercurial working perfectly (reimplement revlog and its subclasses and
be able to fetch file revisions/changesets; transactions and
committing; push, pull, clone; http and ssh; etc etc), then you're
still a very long way from emulating Mercurial as it behaves in the
wild. That's because I or any other Mercurial user can drop arbitrary
Python code just about anywhere inside Mercurial and change just about
any aspect of its behaviour. Mercurial's extension mechanism is
insanely powerful and flexible, but it also means the only way to
completely mimic what Mercurial does means you need a Python
interpreter at your disposal.
Or at least, that's how I see things. Go ahead. Prove me wrong.
We'll all be really impressed if you pull it off. ;-)
(Also, if you just want to make MercurialEclipse faster and smoother,
maybe all you need is a read-only pure Java implementation. That
means you need to reimplement revlog and friends along with large
chunks of localrepo. That should make anything that requires fetching
history work more smoothly inside Eclipse. But you could still leave
update/network operations -- commit, pull, push -- up to the real
Mercurial via command-line invocations.)
Greg
P.S. and would the next person to write some free software *please*
choose a GPL-compatible license? I mean, really, why can't we all
just use the X11 license and move on? ;-)

I must say I agree which each and every word you are saying except the
conclusion - "an attempt to reimplement Mercurial in Java is doomed to
fail".
Java has examples of flexible plugin infrastructure (Ant, Eclipse) which
prove to work. But with Java limitations, of course. You cannot "drop
arbitrary Python code just about anywhere inside Mercurial and change
just about any aspect of its behaviour". In Java you are given a sandbox
with a well defined interface. I do not see this as a restriction.
I also recognize extensions as the biggest challenge but because of the
different reason: they are changing all the time. Once the code is
stable it can be ported to Java and the port can follow the maintenance
of its parent.

Post by Greg Ward
very long way from emulating Mercurial as it behaves in the wild

We do not need everything and now!

I am pretty sure all the _technical_ issues can be solved.

Disclosure:
I am finishing the read-only version of my Java port. As you already
mentioned I "need to reimplement revlog and friends along with large
chunks of localrepo". As long as a lot of config, util, dirstate,
context etc.
Once this code is stable and it works (delegating all the updates to hg)
it can be released to the public.
The main obstacle here is the license. If the code is released under GPL
and it gets some contributions it will be almost impossible to change
the license since we have to get a permission from all the contributors.
That is why I am asking whether there is a way to use another license.

-Andrey

[Greg Ward]

Post by Andrey Somov
I must say I agree which each and every word you are saying except the
conclusion - "an attempt to reimplement Mercurial in Java is doomed to
fail".

Yes, I rather expected you would disagree with that. ;-)

Post by Andrey Somov
Java has examples of flexible plugin infrastructure (Ant, Eclipse) which
prove to work. But with Java limitations, of course.

Yes of course. And you could implement such an infrastructure for
Mercurial-in-Java. And then, given enough time, you could reimplement
MQ and win32text and purge and all the other extensions that ship with
Mercurial. Given even more time, you could reimplement popular
non-bundled extensions.

But you can't possibly know about all the custom extensions that
people have written for their own use and not released publicly.
(E.g. I've written a couple of extensions to implement our local
policy. They are presumably of no interest to the outside world, so
I'm not going to bother releasing them.)

All that means is that you can't do a perfect feature-for-feature
reimplementation. More concretely, it means that MercurialEclipse
will *always* have to run "hg commit" (or equivalent Python code) in
order to have the same effect as a command-line commit. If it doesn't
do that, then it's not going to run my Python hooks (or use my local
extensions), and I won't be happy.

Greg

[Axel Hecht]

Hi,

hooking up my thoughts on this discussion pseudo-randomly in the thread
here.

The discussion clearly shows that innovating mercurial tools and integration
of hg into software outside the GPL ecosystem is bad, in whatever legal
interpretation of that word.

I wonder if that is/was intentional.

Rather than continuing based on speculation, I'll break here and wait for an
answer.

Axel

[William Dode]

--===============0432315225==
Content-Type: multipart/alternative; boundary=00032555a2d214ff260474a0e4f9
--00032555a2d214ff260474a0e4f9
Content-Type: text/plain; charset=ISO-8859-1
Hi,
hooking up my thoughts on this discussion pseudo-randomly in the thread
here.
The discussion clearly shows that innovating mercurial tools and integration
of hg into software outside the GPL ecosystem is bad, in whatever legal
interpretation of that word.
I wonder if that is/was intentional.

One of the points that made me choose mercurial vs bazaar for example is
that, like the kernel, the copyright is owned by each contributor.

[Mike Meyer]

On Mon, 28 Sep 2009 12:37:56 +0200

Post by Axel Hecht
The discussion clearly shows that innovating mercurial tools and integration
of hg into software outside the GPL ecosystem is bad, in whatever legal
interpretation of that word.
I wonder if that is/was intentional.

Intent carries an implied subject - the person with the intent in
question. If you care about some specific person, you should say who
that is.

Meanwhile, I'll answer for the one I know. The intent of the author of
the original GPL was to produce the results you have observed. The
preamble to the GPL makes this clear. The GNU manifesto also sheds
some light on this subject. The LGPL loosens things a little, but the
revisions of the GPL proper have generally increased what's often
referred to as the "viral" nature of the gpl.

<mike

[marco gaddoni]

Post by Andrey Somov
Hi all,
Since Jython (most probably) will never be able to run Mercurial, there
is only one option left: to re-write Mercurial in pure Java.

this is not true.
i got some basic hg commangs ( ci, co, clone, diff) working
in jython.
had to fix a couple of bugs in jython (i hope the fix will
be included in 2.5rc3) and had to wrap the calls to
buffer() in hg with a function that in jython do
some string copying. ugly, but working.

hg in jython is (at least in my pc) really slow
so i lost some interest.
a full fun of the regression tests is over an hour.

if there is interest i can post my hacks somewhere.

[Andrey Somov]

Post by marco gaddoni
hg in jython is (at least in my pc) really slow
so i lost some interest.
a full fun of the regression tests is over an hour.

I am of the same impression.

[Tom Widmer]

Post by Andrey Somov

Post by marco gaddoni
hg in jython is (at least in my pc) really slow
so i lost some interest.
a full fun of the regression tests is over an hour.

I am of the same impression.

Surely optimizing it, using a combination of native Java code and even
JNI code is the way to go - that's a massively smaller job that starting
from scratch, and extensions will work.

CPython based mercurial has quite a bit of native code, so you'd have
job matching it without doing the same in Jython (at least using native
Java for some core parts).

Tom

[marco gaddoni]

Post by Tom Widmer

Post by Andrey Somov

Post by marco gaddoni
hg in jython is (at least in my pc) really slow
so i lost some interest.
a full fun of the regression tests is over an hour.

I am of the same impression.

Surely optimizing it, using a combination of native Java code and even
JNI code is the way to go - that's a massively smaller job that starting
from scratch, and extensions will work.
CPython based mercurial has quite a bit of native code, so you'd have
job matching it without doing the same in Jython (at least using native
Java for some core parts).
Tom

most of the problems came from the vm startup.
i think hat something like nailgun
(http://martiansoftware.com/nailgun/index.html)
can improve the situation there.
i tryed to use it but had some problems loading
le mercurial libraries inside the server.
maybe operator problem.

OTOH, if you need to host mercurial in a
long runnning service jython might be just
fine for the work.

[Alexander Schatten]

Ok, sorry for the weird subject, don't know how to express it clearer. The thing is:

I have a project currently in SVN. Now, part of the project is closed source (a book actually) the other part is intended to become open source. Now the hg convert extension with includes and exludes is great and I managed to write a script in no time to create two Mercurial repositories from the one SVN. That's great.

Now the challenge: I want to put the Open Source part to Google Code, but there were still certain documents and files in there that are not intended for the public (e.g. containing server rsync statements, personal emails and the like).

Now, I could easily write excludes for the still existing files. I just wonder (the project is more than three years old): are there probably some problematic files still in the history, that were once deleted with svn delete, hence are not visible today.


So now back to my question: is there a way, to get a list of all files in the history of a Mercurial project that ever have been deleted (but of course are still in the repository)?

Having such a list, I could figure if there might be still problematic files in the converted project.

Is this a weird request?


thanks a lot.


Alex


p.s.: sorry for double post; last one accidentilly got attached to wrong thread...

[Robert Bauck Hamar]

Post by Alexander Schatten
I have a project currently in SVN. Now, part of the project is closed source (a book actually) the other part is intended to become open source. Now the hg convert extension with includes and exludes is great and I managed to write a script in no time to create two Mercurial repositories from the one SVN. That's great.
Now the challenge: I want to put the Open Source part to Google Code, but there were still certain documents and files in there that are not intended for the public (e.g. containing server rsync statements, personal emails and the like).
Now, I could easily write excludes for the still existing files. I just wonder (the project is more than three years old): are there probably some problematic files still in the history, that were once deleted with svn delete, hence are not visible today.
So now back to my question: is there a way, to get a list of all files in the history of a Mercurial project that ever have been deleted (but of course are still in the repository)?

Perhaps
hg log --template '{file_dels}\n'
will get you started?

See also <URL: http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html>

[Benoit Boissinot]

Post by Alexander Schatten
So now back to my question: is there a way, to get a list of all files
in the history of a Mercurial project that ever have been deleted (but
of course are still in the repository)?

Compare the list given by (in python):

repo.store.datafiles()

and hg manifest.

regards,

Benoit

[Adrian Buehlmann]

Post by Alexander Schatten
I have a project currently in SVN. Now, part of the project is closed source (a book actually) the other part is intended to become open source. Now the hg convert extension with includes and exludes is great and I managed to write a script in no time to create two Mercurial repositories from the one SVN. That's great.
Now the challenge: I want to put the Open Source part to Google Code, but there were still certain documents and files in there that are not intended for the public (e.g. containing server rsync statements, personal emails and the like).
Now, I could easily write excludes for the still existing files. I just wonder (the project is more than three years old): are there probably some problematic files still in the history, that were once deleted with svn delete, hence are not visible today.
So now back to my question: is there a way, to get a list of all files in the history of a Mercurial project that ever have been deleted (but of course are still in the repository)?
Having such a list, I could figure if there might be still problematic files in the converted project.
Is this a weird request?

The cifiles extension can give a list of all files
that have ever been checked-in in any revision

http://mercurial.selenic.com/wiki/CifilesExtension