How JGit changed from GPLv2 to BSD/EPL
Martin Geisler
Regarding the Java port, then I find it interesting to compare with how
the Java port of Git was made. From what I can see, it started its life
under GPLv2, but it was later changed to BSD/EPL:
http://thread.gmane.org/gmane.comp.version-control.git/81585
http://thread.gmane.org/gmane.comp.version-control.git/82898
Notice how little discussion they had, even though they seem to be in
the same situation as we are! Can anybody explain the difference?
I would very much like to see a Java port of Mercurial -- though I don't
like the language particularly much, I recognize that there is a huge
number of people using it in the "real world" and that it is important
to make Mercurial work out of the box on Eclipse.
I my view, a reimplementation in Java wont be a derivative work. They
are surely deriving the concepts and algorithms, but as long as they
rewrite everything themselves I'm fine with it. I understand that Matt
disagrees since he said that he would not be friendly towards a port
with a non-copyleft license.
In any case, the result is that we make ourselves second-class citizens
in the Java world:
http://article.gmane.org/gmane.comp.version-control.git/115843
People who don't use Java might not care, but when we have people saying
that they are willing to invest time and energi in rewriting things,
then I think it's a huge shame.
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial
Antoine Pitrou
>
> I my view, a reimplementation in Java wont be a derivative work. They
> are surely deriving the concepts and algorithms, but as long as they
> rewrite everything themselves I'm fine with it. I understand that Matt
> disagrees since he said that he would not be friendly towards a port
> with a non-copyleft license.
Well if the main point is to link against Eclipse, and Matt doesn't want
any non-copyleft implementations, I see two possible solutions (apart
from the obvious but delicate one of bypassing Matt's wishes):
- license the reimplementation under the GPL *plus* an exception allowing
linking against Eclipse (you don't have to modify the GPL for it, just
mention both the GPL and the exception in a COPYRIGHT file)
- license the reimplementation under the LGPL -- assuming the LGPL is
compatible with the Eclipse license, which I don't know
(I don't really care about a Java implementation, just proposing ways to
unblock the road)
Antoine.
Adrian Buehlmann
> Hi everybody,
>
> Regarding the Java port, then I find it interesting to compare with how
> the Java port of Git was made. From what I can see, it started its life
> under GPLv2, but it was later changed to BSD/EPL:
>
> http://thread.gmane.org/gmane.comp.version-control.git/81585
> http://thread.gmane.org/gmane.comp.version-control.git/82898
>
> Notice how little discussion they had, even though they seem to be in
> the same situation as we are! Can anybody explain the difference?
For example because they choose to ignore the valid concerns raised in
http://article.gmane.org/gmane.comp.version-control.git/82922
?
Antoine Pitrou
>
> For example because they choose to ignore the valid concerns raised in
> http://article.gmane.org/gmane.comp.version-control.git/82922 ?
If you read the thread you'll see that there's pretty much no controversy
at all, and noone chimed in to say they were against the relicensing. The
message you mention is only someone wanting to make sure all necessary
steps had been done, not someone *opposing* the decision.
Moreover, noone seems to have complained that jgit was a derivative work
*of git* and had to remain under the GPL because they were opposed to a
reimplementation under a non-copyleft license.
So, yes, Martin seems to be right when he says « Notice how little
discussion they had ».
cheers
Antoine.
Adrian Buehlmann
> Le Wed, 30 Sep 2009 13:23:16 +0200, Adrian Buehlmann a écrit :
>> For example because they choose to ignore the valid concerns raised in
>> http://article.gmane.org/gmane.comp.version-control.git/82922 ?
>
> If you read the thread you'll see that there's pretty much no controversy
> at all, and noone chimed in to say they were against the relicensing. The
> message you mention is only someone wanting to make sure all necessary
> steps had been done, not someone *opposing* the decision.
>
> Moreover, noone seems to have complained that jgit was a derivative work
> *of git* and had to remain under the GPL because they were opposed to a
> reimplementation under a non-copyleft license.
>
> So, yes, Martin seems to be right when he says « Notice how little
> discussion they had ».
If you say the GPL does not apply to such a "port" then why do you
continue to post on this list about it then?
Why don't you just do it then?
Antoine Pitrou
>
> If you say the GPL does not apply to such a "port" then why do you
> continue to post on this list about it then?
>
> Why don't you just do it then?
Why do you think I'm interested in "porting" Mercurial ? I've already
stated that I don't personally care about a Java reimplementation. If I
needed one, however, I'd either do it/wait for it, or switch to another
DVCS if I felt there's too much hostility.
As as a Mercurial user, the only thing that /practically/ bothers me (*)
is that I wouldn't want a project I contribute to to choose git or bzr
over Mercurial because Mercurial's Eclipse integration is suboptimal. And
this is what will happen if you have this very bizarre stance on
licensing of third-party implementations of Mercurial.
(*) Apart from the fact that you seem to have this troubling idea that
you "own" algorithms and must be asked for permission, which is the kind
of attitude pretty much everyone in the FS world is opposed to.
Regards
Antoine.
Martin Geisler
> Le Wed, 30 Sep 2009 13:23:16 +0200, Adrian Buehlmann a écrit :
>>
>> For example because they choose to ignore the valid concerns raised in
>> http://article.gmane.org/gmane.comp.version-control.git/82922 ?
>
> If you read the thread you'll see that there's pretty much no
> controversy at all, and noone chimed in to say they were against the
> relicensing. The message you mention is only someone wanting to make
> sure all necessary steps had been done, not someone *opposing* the
> decision.
Indeed, the message is about being careful to respect the right of the
other jgit contributors. Further down in the thread they look at the
contributors to jgit since the beginning of time:
http://article.gmane.org/gmane.comp.version-control.git/82977
> Moreover, noone seems to have complained that jgit was a derivative
> work *of git* and had to remain under the GPL because they were
> opposed to a reimplementation under a non-copyleft license.
Yes, that is the core issue here. Do we really want to say that people
cannot re-implement Mercurial in other languages under their own choice
of license? In my opinion, this is not a question we should just leave
open by saying "it's up to a judge to decide".
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
_______________________________________________
Tom Widmer
> Moreover, noone seems to have complained that jgit was a derivative work
> *of git* and had to remain under the GPL because they were opposed to a
> reimplementation under a non-copyleft license.
Git is a bit different, in that the architecture is simple and all file
formats are fully documented. It is quite simple to re-implement Git
without so much as a glance at the source code (and it has been
re-implemented in several languages, including Python and Java).
Mercurial would probably be a lot trickier, and Bazaar a nightmare -
both have more complex file formats, which aren't well documented except
by the code.
Tom
Theodore Tso
> Hi everybody,
>
> Regarding the Java port, then I find it interesting to compare with how
> the Java port of Git was made. From what I can see, it started its life
> under GPLv2, but it was later changed to BSD/EPL:
>
> http://thread.gmane.org/gmane.comp.version-control.git/81585
> http://thread.gmane.org/gmane.comp.version-control.git/82898
>
> Notice how little discussion they had, even though they seem to be in
> the same situation as we are! Can anybody explain the difference?
JGit was a clean-room implementation from scratch, done using Native
Java idioms. And they made the relicesing change very early in the
JGit project, when the number of contributors to JGit was small and
easy to track down. In fact, there were only five, broken down as
follows:
Percent LOC Author
78% 27607 Shawn O. Pearce
17% 6061 Robin Rosenberg
4% 1518 Dave Watson
0% 4 Thad Hughes
0% 2 Roger C. Soares
------------------------------
100% 35192 total
The contributor list for core git and mercurial would be quite
different; which is why relicesing git or mercurial would both be
quite difficult with both projects being as mature as they are.
Some people on this thread *still* seem to be confusing the difference
between a clean-room implementation effort and a port. The two are
very different things, and have very different legal implications.
- Ted
William Dode
> Le Wed, 30 Sep 2009 12:21:37 +0200, Martin Geisler a écrit :
>>
>> I my view, a reimplementation in Java wont be a derivative work. They
>> are surely deriving the concepts and algorithms, but as long as they
>> rewrite everything themselves I'm fine with it. I understand that Matt
>> disagrees since he said that he would not be friendly towards a port
>> with a non-copyleft license.
>
> Well if the main point is to link against Eclipse, and Matt doesn't want
> any non-copyleft implementations, I see two possible solutions (apart
> from the obvious but delicate one of bypassing Matt's wishes):
>
> - license the reimplementation under the GPL *plus* an exception allowing
> linking against Eclipse (you don't have to modify the GPL for it, just
> mention both the GPL and the exception in a COPYRIGHT file)
> - license the reimplementation under the LGPL -- assuming the LGPL is
> compatible with the Eclipse license, which I don't know
Third possibility : ask eclipse to change their license ;-)
--
William Dodé - http://flibuste.net
Informaticien Indépendant
Brendan Cully
> On Wed, Sep 30, 2009 at 12:21:37PM +0200, Martin Geisler wrote:
> > Hi everybody,
> >
> > Regarding the Java port, then I find it interesting to compare with how
> > the Java port of Git was made. From what I can see, it started its life
> > under GPLv2, but it was later changed to BSD/EPL:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/81585
> > http://thread.gmane.org/gmane.comp.version-control.git/82898
> >
> > Notice how little discussion they had, even though they seem to be in
> > the same situation as we are! Can anybody explain the difference?
>
> JGit was a clean-room implementation from scratch, done using Native
> Java idioms. And they made the relicesing change very early in the
> JGit project, when the number of contributors to JGit was small and
> easy to track down. In fact, there were only five, broken down as
> follows:
>
> Percent LOC Author
> 78% 27607 Shawn O. Pearce
> 17% 6061 Robin Rosenberg
> 4% 1518 Dave Watson
> 0% 4 Thad Hughes
> 0% 2 Roger C. Soares
"clean-room" seems to me to be a stretch, given that the top three
authors all have commits in git too. Shawn has hundreds, going back to
2006. It seems very unlikely that they haven't read any relevant GPL
code.
I also think too much is being made of how simple the git core
is. First of all, revlog + manifest + changelog is also quite simple,
but more importantly, a port that only provides the data store is
frankly not very useful. Anyone is going to have to reimplement a
reasonable subset of the commands too -- and here I don't think it's
clear at all that git is the simple one.
Tom Widmer
Is the python 'dulwich' implementation of Git clean-room?
> I also think too much is being made of how simple the git core
> is. First of all, revlog + manifest + changelog is also quite simple,
> but more importantly, a port that only provides the data store is
> frankly not very useful. Anyone is going to have to reimplement a
> reasonable subset of the commands too -- and here I don't think it's
> clear at all that git is the simple one.
But the re-implementation's commands don't have to behave the same as
git, or offer the same options, as long as the repositories and wire
protocols offered by the re-implementation are compatible. Even git
itself has had a plethora of command sets over the years. In effect, you
implement your own VCS that is based on the git protocols with the
functionality you need (e.g. that which an Eclipse VCS plugin needs, for
example) rather than re-implement all of git (which is extremely
powerful, with lots of obscure commands and options). For example, git
gc and the auto-gc facility is quite complex I imagine, but isn't
necessarily needed at all for a VCS plugin - you can always use command
line git if you need to optimise your repo, and just write to single
object files rather than making pack files when using the re-implementation.
The same is true of an HG re-implementation of course, but I'm not sure
that the formats and protocols are sufficiently well documented that it
can be done without looking at the code.
Tom
Theodore Tso
>
> "clean-room" seems to me to be a stretch, given that the top three
> authors all have commits in git too. Shawn has hundreds, going back to
> 2006. It seems very unlikely that they haven't read any relevant GPL
> code.
>
You're right, I went too far in saying "clean room". However, people
are making making a too much of a big deal about how much you can copy
without it being a copyright violation. One lawyer once gave me her
rule of thumb, which was "one cubical wall". That is, if you looked
at the source code on a computer in one cubical, and then walked over
to another computer located in another cubical on the other side of
the wall, and then attempted a reimplementation, unless you're one of
those people who have photographic memory, you're probably in the
clear. People seem to be forgetting (or maybe they never knew, but
aren't letting their ignorance stop them from making authoratative
statements) that copyright protects the expression of an idea, and
*not* the idea itself. API's are in general not subject to copyright,
and if you implement an algorithm or protocol, in another language,
that's not going to be copyrightable either.
It's quite amazing how much legal cluelessness (and aggressive
arrogance of their cluelessness) has been demonstrated on this list,
really.
> I also think too much is being made of how simple the git core
> is. First of all, revlog + manifest + changelog is also quite simple,
> but more importantly, a port that only provides the data store is
> frankly not very useful. Anyone is going to have to reimplement a
> reasonable subset of the commands too -- and here I don't think it's
> clear at all that git is the simple one.
The git core is better documented, and while git may have a lot more
commands, many of the low level commands are there just to provide
interfaces that were used to create the higher level commands when
they were originally written as shell scripts. So they correspond to
internal interfaces that Mercurial have, except that they all have
full man pages and documented semantics.
- Ted
Bill Barry
> Hi everybody,
>
> Regarding the Java port, then I find it interesting to compare with how
> the Java port of Git was made. From what I can see, it started its life
> under GPLv2, but it was later changed to BSD/EPL:
>
> http://thread.gmane.org/gmane.comp.version-control.git/81585
> http://thread.gmane.org/gmane.comp.version-control.git/82898
>
> Notice how little discussion they had, even though they seem to be in
> the same situation as we are! Can anybody explain the difference?
According to gnu.org, JGit is still available as GPLv2.
http://www.gnu.org/licenses/gpl-faq.html#CanDeveloperThirdParty
Because of the viral nature of the GPL, all derivatives will still be
GPL. I would say this means that Eclipse cannot (in their mainline)
include JGit without relicensing as GPL. Further, nobody can distribute
a proprietary work (or any non-GPLv2 work) which includes the JGit
libraries. It doesn't matter what the contributors say now about the
license, it is still stuck as GPL. Actually the current version of JGit
is in violation of the GPL because they have removed the license headers.
That doesn't mean any project cannot ship JGit alongside whatever they
have. As long as it would be a separate program it should be fine. You
could for instance install Eclipse and then download and install the
Eclipse-JGit-compatibility layer. This compatibility layer must be GPL.
You could do the same thing for Mercurial, develop a java version and
then a plugin for Eclipse. As long as it isn't part of the main app or
required for the main app to provide functionality then it is a separate
application. Eclipse surely has simply a set of interfaces that you need
to implement in order to extend the base functionality. The point being
for this and the other thread:
Mercurial is GPLv2. You have 4 choices:
1. Use the command line interface to interoperate. Output is licensed
with whatever license input has (this is the case according to gnu.org).
License your app however you want.
2. Import Mercurial, use it as a library. App must be licensed GPLv2.
3. Build a non-required plugin which may be installed over top of your
app. Plugin can use command line and be licensed however you want or may
use Mercurial as a library and must be GPLv2. License your app however
you want.
4. Clean room reimplementation of Mercurial under desired license.
Even if we all wanted to change the license of Mercurial (and some of us
don't), we denied ourselves that right when we made it GPL (so did
JGit). It is unfortunate that they fail to understand the restrictions
of the GPL when they claimed to have relicensed it. At least Matt
understood this when he initially chose GPL.
It is a strange idea to ever either dual license with a viral license or
change to/from a viral license. The viral license can never be gotten
rid of once applied (dual licensing under non viral licenses allows the
licensee to choose the license whereas the licensee doesn't get the
choice with a viral license, they must either take it or not use the
app). In practice I don't know of any cases where this issue has been
brought up but it is very much a tricky line to walk (Can the GPL be
injected by a single contribution licensed as such, thus requiring the
entire app to be GPL? Or are contributions only possible under the
license of the app? AFAIK that hasn't been decided in court yet and I am
not going to be the ass who tries).
Matt Mackall
> Hi everybody,
>
> Regarding the Java port, then I find it interesting to compare with how
> the Java port of Git was made. From what I can see, it started its life
> under GPLv2, but it was later changed to BSD/EPL:
And here I was hoping this thread would peter out.
> I my view, a reimplementation in Java wont be a derivative work. They
> are surely deriving the concepts and algorithms, but as long as they
> rewrite everything themselves I'm fine with it. I understand that Matt
> disagrees since he said that he would not be friendly towards a port
> with a non-copyleft license.
Alright, this is going to be the last I have to say on the subject of
licenses for a while. Read it carefully, folks:
Copyright law aside, I do not want to see a clone of Mercurial licensed
under a weak copyleft (eg EPL) that allows proprietary extensions to be
added and users to get locked into them. Not only would that go against
everything I set out to do in creating a free DVCS in the first place,
it would create a compatibility nightmare for users and developers. I
will have a very dim view indeed of anyone who helps bring such a
situation about, especially if their rationale is as flimsy as "I needed
to call Mercurial internals directly from Java." Because frankly, no,
you don't[1].
Is such a non-GPLv2 clone legally possible? Absolutely, if your use of
the original Mercurial source doesn't exceed the bounds of "fair use".
But if you're calling it a "port", you're almost certainly creating a
derived work, which will mean you're violating Mercurial's license, in
addition to already being on my bad side. Not a good position to be in.
You're going to need to consult your own lawyer on what precisely "fair
use" and "derived work" mean, because I don't want to be perceived as
granting any sort of "permission" here.
I've stuck a Licence FAQ here for future reference:
http://mercurial.selenic.com/wiki/LicenseFAQ
Now I'm going to be studiously deleting mail with EPL or Java in the
title unread for a while to get my annoyance level back down to a point
where I can do useful work.
[1] I don't think I've seen a single such complaint from C/C++ or Perl
users, does Java not have a system() call?
--
http://selenic.com : development and support for Mercurial and Linux
Adrian Buehlmann
> (*) Apart from the fact that you seem to have this troubling idea that
> you "own" algorithms and must be asked for permission, which is the kind
> of attitude pretty much everyone in the FS world is opposed to.
This is incorrect. I never claimed that.
I was trying to give some examples in the other thread why I
believe that a reimplementation in Java would be difficult to
describe as not being a derived work.
Now I am wrongfully described as claiming that I own any
algorithms and people would have to ask me for permission
to implement them. I never said that and it is not true!
The potential reimplementation is certainly not a problem
of specific algorithms.
As a side note, you'll likely end up having nearly
the same class names and method names in the Java code
that are in the current mercurial Python code.
So you will very likely have for example a Localrepo class
and a Dirstate class in Java, and these classes will most
likely have most of the methods of their corresponding Python
classes, most likely using the same names (which technically
makes a lot of sense, as people who have contributed
to the Python code quickly recognize the same abstractions
in the Java code).
So you'll most likely end up implementing the use cases
in a very similar way.
Combined with the fact that the Python code is nearly the
only documentation of mercurial, it is quite difficult to
imagine this reimplementation could be done using a
cleanroom approach (so that it enables using a wholly
different license, as others have proposed).
You will most likely have to consult the code for the
Python localrepo class when you implement the Java
Localrepo class.
Obviously, jgit implementors didn't have this same tension,
since their reference implementation was written in C, which
doesn't even have classes or exceptions.
On another note, I *would* love to have a Java (or Scala)
reimplementation of mercurial. And I would like that this
implementation tracks the original Python implementation
as much as possible (regarding features and maybe bugfixes).
But it is my belief that it is difficult to do this
under anything else but the GPL.
Andrey Somov
>
> Indeed, the message is about being careful to respect the right of the
> other jgit contributors.
This is the main reason why I do not want to release my Java
implementation now. Since there is only one contributor it is very easy
to agree on any license :)
>
> Yes, that is the core issue here. Do we really want to say that people
> cannot re-implement Mercurial in other languages under their own choice
> of license? In my opinion, this is not a question we should just leave
> open by saying "it's up to a judge to decide".
>
Yes, it has to be explicit: red or green light.
Imagine the Java implementation is released under a more permissive
license and companies like Eclipse began to use it.
Unfortunately FSF decides that this is a derivative work and the license
agreement is violated.
What is the limit of the developer's responsibility ? May Eclipse send
him a bill which is big enough for his grandchildren to hate him for the
rest of their life ?
-
Andrey
Kyle Altendorf
[snip]
> Mercurial is GPLv2. You have 4 choices:
> 3. Build a non-required plugin which may be installed over top of your
> app. Plugin can use command line and be licensed however you want or may
> use Mercurial as a library and must be GPLv2. License your app however
> you want.
Suppose the library option. As you say, if the plugin links to the
GPLed code then the plugin must be GPLed. Doesn't the same then apply
to the app linking to the GPLed plugin? I suspect there is an
accepted term for this but I would describe it as attempting to use
the plugin as a license wrapper. My understanding is that this
'loophole' does not exist in the GPL (aside from the whole concept of
community and trust making loopholes irrelevant... hopefully).
-kyle
Bill Barry
> Suppose the library option. As you say, if the plugin links to the
> GPLed code then the plugin must be GPLed. Doesn't the same then apply
> to the app linking to the GPLed plugin? I suspect there is an
> accepted term for this but I would describe it as attempting to use
> the plugin as a license wrapper. My understanding is that this
> 'loophole' does not exist in the GPL (aside from the whole concept of
> community and trust making loopholes irrelevant... hopefully).
>
The loophole here is that the plugin is a separate application,
unnecessary for the usage of the underlying application. Consider the
act of writing an extension to Internet Explorer which uses a GPLed
library for retrieving the number of emails you have unread in Gmail.
Because the library is under the GPL, your extension must be. But that
doesn't mean that IE needs to be. I would consider it questionable
territory to ship both the application and the plugin together as one
package, but separately I cannot see an issue.
This should work as long as the license for the application permits
plugins to be written under a different license. The only condition I
know of where that isn't the case is if one app was written in GPL2 and
a plugin needs to use a library written in GPL3 (or the other way
around). As such the plugin would need to be written under both the GPL2
and GPL3 which cannot be done as one of the rules of GPL3 violates one
of the rules of GPL2.
Without this loophole, it would be illegal to run Mercurial on Windows
because an application is really just a plugin for the OS.
Greg Ward
> I would very much like to see a Java port of Mercurial -- though I don't
> like the language particularly much, I recognize that there is a huge
> number of people using it in the "real world" and that it is important
> to make Mercurial work out of the box on Eclipse.
It's already pretty darn close. There's a bit of fussy clicking
around to install MercurialEclipse, but then it works.
MercurialEclipse itself isn't perfect, but then, what software is? In
my 2-3 days of playing around with it, I found a couple of bugs, most
of which were quickly fixed by the maintainers. (The other is easily
avoided: specifically, if you have a configuration error or a broken
extension that causes the "*** failed to import extension" warning,
MercurialEclipse treats that as a fatal error and gives up. Annoying,
but not a showstopper.)
I'm sure there are bits and pieces of MercurialEclipse that are clunky
because they have to go through a command-line interface. I'm sure
there are ways to improve Mercurial's command-line UI to make life
easier for software like MercurialEclipse. But it *works*, dammit.
And attempting to reimplement Mercurial in Java will necessarily lose
one of Mercurial's best features, the extension mechanism.
IMHO someone looking for ways to speed up or improve MercurialEclipse
should look at things like:
* figure out a way to have a captive Mercurial process that you can
control via a socket, to save the overhead of all those Python
interpreters
* should we have a way to disable extensions that change the output
while keeping extensions that enforce local policy?
* should we have a way to disable the 'defaults' config section?
* disable warnings that are only meaningful to a human user at the
command-line?
Such improvements would benefit anyone calling Mercurial from another
process, regardless of language. Plus you could avoid all this silly
licensing talk. Finally, it means you can code in Python rather than
Java, and who wouldn't want that? ;-)
Greg
Martin Geisler
> On Wed, Sep 30, 2009 at 6:21 AM, Martin Geisler <m...@lazybytes.net> wrote:
>> I would very much like to see a Java port of Mercurial -- though I
>> don't like the language particularly much, I recognize that there is
>> a huge number of people using it in the "real world" and that it is
>> important to make Mercurial work out of the box on Eclipse.
>
> It's already pretty darn close. There's a bit of fussy clicking
> around to install MercurialEclipse, but then it works.
Heh, I'm not even using Eclipse -- but I believe that's not the issue.
The goal of a Java version of Mercurial distributed under the EPL is to
have it distributed together with Eclipse. It is said here that the
Eclipse Foundation wont distribute code under the GPL, and so JGit has
an advantage:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=257706#c109
> I'm sure there are bits and pieces of MercurialEclipse that are clunky
> because they have to go through a command-line interface. I'm sure
> there are ways to improve Mercurial's command-line UI to make life
> easier for software like MercurialEclipse. But it *works*, dammit.
> And attempting to reimplement Mercurial in Java will necessarily lose
> one of Mercurial's best features, the extension mechanism.
I don't believe extensions are important here: we're talking about
having Mercurial work out of the box on Eclipse. So the capabilities of
Eclipse will define the working experience, not your custom extensions.
Bryan O'Sullivan
The loophole here is that the plugin is a separate application,
unnecessary for the usage of the underlying application.
Unfortunately, GMail has hidden its "mute this conversation" UI somewhere that I can't locate, so I have to resort to ask every one of you who is contributing to this inane and off-topic discussion to go either somewhere else or just stop.
I don't care which you do, just stop talking about this here, and do it now.
Thank you.
Alpar Juttner
> IMHO someone looking for ways to speed up or improve MercurialEclipse
> should look at things like:
>
> * figure out a way to have a captive Mercurial process that you can
> control via a socket, to save the overhead of all those Python
> interpreters
> * should we have a way to disable extensions that change the output
> while keeping extensions that enforce local policy?
I would propose making --template supported by all commands and all
info; and suggest using through it all the time from other applications.
The current policy of not changing the output at all is both broken
(e.g. because on extensions) and sometime limiting (e.g. I'd love to see
the current changeset marked in `hg log` by default - like `hg log -G`
does. No human would protest, but scripts certainly would). If script
were using --template, we could relax on this policy in the long run.
> * should we have a way to disable the 'defaults' config section?
And making possible (from CLI) to switch off an option that is switched
on in the config file.
> * disable warnings that are only meaningful to a human user at the
> command-line?
Best regards,
Alpar
Hans Meine
> You will most likely have to consult the code for the
> Python localrepo class when you implement the Java
> Localrepo class.
AFAICS, it all boils down to (which has been said before) someone needing to
write technical documentation, most likely while looking at the code, for
*someone else* to be able to legally re-implement hg in e.g. Java.
It looks like a two-step/min.-2 developer process, but doable, no?
HTH,
Hans
Hans Meine
> On Wednesday 30 September 2009 21:10:50 Adrian Buehlmann wrote:
> > You will most likely have to consult the code for the
> > Python localrepo class when you implement the Java
> > Localrepo class.
>
> AFAICS, it all boils down to (which has been said before) someone needing
> to write technical documentation, most likely while looking at the code,
> for *someone else* to be able to legally re-implement hg in e.g. Java.
I am sorry, I occasionally fall into the trap of replying to a posting before
fully reading the rest of the thread. I did not want to open this can of
worms again; actually I am fed up with licensing discussions, too.
Please accept my apologies and have a nice day,
rupert.thurner
> On Wed, 2009-09-30 at 12:21 +0200, Martin Geisler wrote:
> > Hi everybody,
>
> > Regarding the Java port, then I find it interesting to compare with how
> > the Java port of Git was made. From what I can see, it started its life
> > under GPLv2, but it was later changed to BSD/EPL:
>
> And here I was hoping this thread would peter out.
>
> > I my view, a reimplementation in Java wont be a derivative work. They
> > are surely deriving the concepts and algorithms, but as long as they
> > rewrite everything themselves I'm fine with it. I understand that Matt
> > disagrees since he said that he would not be friendly towards a port
> > with a non-copyleft license.
>
> Alright, this is going to be the last I have to say on the subject of
> licenses for a while. Read it carefully, folks:
>
> Copyright law aside, I do not want to see a clone of Mercurial licensed
> under a weak copyleft (eg EPL) that allows proprietary extensions to be
> added and users to get locked into them. Not only would that go against
> everything I set out to do in creating a free DVCS in the first place,
> it would create a compatibility nightmare for users and developers. I
> will have a very dim view indeed of anyone who helps bring such a
> situation about, especially if their rationale is as flimsy as "I needed
> to call Mercurial internals directly from Java." Because frankly, no,
> you don't[1].
seems that really happens, as an example with mercurialeclipse which
now gets extensions in the hgeclipse project like
http://javaforge.com/scmShowFileRevision?proj_id=2828&filename=test%2fcom%2fvectrace%2fMercurialEclipse%2fcommands%2fHgTagClientTests.java&revision=1407&date=Fri+Oct+30+23%3a06%3a00+UTC+2009
saying:
This software is the confidential and proprietary information of ...
shall not disclose such Confidential Information and shall use ...
> Is such a non-GPLv2 clone legally possible? Absolutely, if your use of
> the original Mercurial source doesn't exceed the bounds of "fair use".
> But if you're calling it a "port", you're almost certainly creating a
> derived work, which will mean you're violating Mercurial's license, in
> addition to already being on my bad side. Not a good position to be in.
> You're going to need to consult your own lawyer on what precisely "fair
> use" and "derived work" mean, because I don't want to be perceived as
> granting any sort of "permission" here.
>
> I've stuck a Licence FAQ here for future reference:
>
> http://mercurial.selenic.com/wiki/LicenseFAQ
>
> Now I'm going to be studiously deleting mail with EPL or Java in the
> title unread for a while to get my annoyance level back down to a point
> where I can do useful work.
>
> [1] I don't think I've seen a single such complaint from C/C++ or Perl
> users, does Java not have a system() call?
>
> --http://selenic.com: development and support for Mercurial and Linux
>
> _______________________________________________
> Mercurial mailing list
> Mercur...@selenic.comhttp://selenic.com/mailman/listinfo/mercurial
Benoit Boissinot
> On 30 Sep., 19:50, Matt Mackall <m...@selenic.com> wrote:
> >
> > Alright, this is going to be the last I have to say on the subject of
> > licenses for a while. Read it carefully, folks:
> >
> > Copyright law aside, I do not want to see a clone of Mercurial licensed
> > under a weak copyleft (eg EPL) that allows proprietary extensions to be
> > added and users to get locked into them. Not only would that go against
> > everything I set out to do in creating a free DVCS in the first place,
> > it would create a compatibility nightmare for users and developers. I
> > will have a very dim view indeed of anyone who helps bring such a
> > situation about, especially if their rationale is as flimsy as "I needed
> > to call Mercurial internals directly from Java." Because frankly, no,
> > you don't[1].
>
> seems that really happens, as an example with mercurialeclipse which
> now gets extensions in the hgeclipse project like
> http://javaforge.com/scmShowFileRevision?proj_id=2828&filename=test%2fcom%2fvectrace%2fMercurialEclipse%2fcommands%2fHgTagClientTests.java&revision=1407&date=Fri+Oct+30+23%3a06%3a00+UTC+2009
>
> saying:
> This software is the confidential and proprietary information of ...
> shall not disclose such Confidential Information and shall use ...
This isn't an extension, just some tests. And afaict, MercurialEclipse is
only a wrapper around the command line, it doesn't expose internals.
(please don't start the licensing thread again)
Cheers,
Benoit
--
:wq