Bitkeeper

Bitkeeper

[Richard Stallman]

    > If you are trying to copy BK, give it up.  We'll simply follow in the
    > footsteps of every other company faced with this sort of thing and change
    > the protocol every 6 months.  Since you would be chasing us you can never
    > catch up.  If you managed to stay close then we'd put digital signatures
    > into the protocol to prevent your clone from interoperating with BK.

I think it would be appropriate at this point to write a free client
that talks with Bitkeeper, and for Linux developers to start switching
to that from Bitkeeper.  At that point, McVoy will face a hard choice:
if he carries out these threats, he risks alienating the community
that he hopes will market Bitkeeper for him.

Re: Bitkeeper

[Rik van Riel]

On Fri, 18 Jul 2003, Richard Stallman wrote:

> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper,

Maybe.  I'll leave that decision to whomever decides to
invest his time and/or money in implementing such software.

> and for Linux developers to start switching to that from Bitkeeper.

That would be a bit premature.  I certainly wouldn't switch
to a piece of software that doesn't exist yet. ;)

To put it more bluntly: free software would have to implement
a very significant amount of Bitkeeper's functionality before
I would ever consider switching to it.

At the moment there simply is no equivalent free alternative
to Bitkeeper, so there's nothing to switch to.  Once such an
alternative exists we could continue this debate.

kind regards,

Rik
-- 
Great minds drink alike.

Re: Bitkeeper

[nick]

How about all of you take a much nicer tilt on this, and ask McVoy (who's
already giveing you the software free) his price to GPL bitkeeper.
	Nick

On Fri, 18 Jul 2003, Rik van Riel wrote:

> On Fri, 18 Jul 2003, Richard Stallman wrote:
> 
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper,
> 
> Maybe.  I'll leave that decision to whomever decides to
> invest his time and/or money in implementing such software.
> 
> > and for Linux developers to start switching to that from Bitkeeper.
> 
> That would be a bit premature.  I certainly wouldn't switch
> to a piece of software that doesn't exist yet. ;)
> 
> To put it more bluntly: free software would have to implement
> a very significant amount of Bitkeeper's functionality before
> I would ever consider switching to it.
> 
> At the moment there simply is no equivalent free alternative
> to Bitkeeper, so there's nothing to switch to.  Once such an
> alternative exists we could continue this debate.
> 
> kind regards,
> 
> Rik
> -- 
> Great minds drink alike.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Bitkeeper

[Shawn]

Wow, I've just totally underestimated the $$ power on this list. ;)

On Fri, 2003-07-18 at 15:22, nick@snowman.net wrote:
> How about all of you take a much nicer tilt on this, and ask McVoy (who's
> already giveing you the software free) his price to GPL bitkeeper.

Re: Bitkeeper

[Alan Cox]

On Gwe, 2003-07-18 at 21:22, nick@snowman.net wrote:
> How about all of you take a much nicer tilt on this, and ask McVoy (who's
> already giveing you the software free) his price to GPL bitkeeper.

Make Larry a clear business case and I'm sure he will. However even
though I don't agree with Larry on a lot of things I do agree that there
isn't a sane case for him to GPL that software.

Larry actually had exactly these and related discussions before he ever
went to Linus and others with the arrangement he proposed about free if
your logs are public.

If you want to make something replace bitkeeper make it better. When
Larry has customers forcing him to write bk to [whatever] convertors
you've won. 

Re: Bitkeeper

[Pavel Machek]

Hi!

> > How about all of you take a much nicer tilt on this, and ask McVoy (who's
> > already giveing you the software free) his price to GPL bitkeeper.
> 
> Make Larry a clear business case and I'm sure he will. However even
> though I don't agree with Larry on a lot of things I do agree that there
> isn't a sane case for him to GPL that software.
> 
> Larry actually had exactly these and related discussions before he ever
> went to Linus and others with the arrangement he proposed about free if
> your logs are public.
> 
> If you want to make something replace bitkeeper make it better. When
> Larry has customers forcing him to write bk to [whatever] convertors
> you've won. 

Well, we already made him write bk to CVS convertor ;-))))))))).

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Bitkeeper

[Jeff Garzik]

THIS IS NOT A BITKEEPER MAILING LIST.

Thanks,

	Jeff

Re: Bitkeeper

[Shawn]

To add to this, why?

I don't mean to jump on anyone, but so long as someone can pull all the
BK data out if Larry gets unreasonable (via the active and existing SVN
or CVS gateways) who the frig cares if there's a BK clone??? If things
got nasty, pull the data and switch unceremoniously switch to SVN or
whatever.

Are there folks out there today with current SVN repos which have all
the BK metadata everyone keeps pissing on about?

On Fri, 2003-07-18 at 15:06, Rik van Riel wrote:
> On Fri, 18 Jul 2003, Richard Stallman wrote:
> 
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper,
> 
> Maybe.  I'll leave that decision to whomever decides to
> invest his time and/or money in implementing such software.
> 
> > and for Linux developers to start switching to that from Bitkeeper.
> 
> That would be a bit premature.  I certainly wouldn't switch
> to a piece of software that doesn't exist yet. ;)

Re: Bitkeeper

[Rik van Riel]

On 18 Jul 2003, Shawn wrote:

> To add to this, why?

That's a good question indeed.

> I don't mean to jump on anyone, but so long as someone can pull all the
> BK data out

You're right.  There is no data lock-in, so there is no reason
at all why we (FSVO "we") would even need a free alternative to
Bitkeeper.

People who really care about Bitkeeper being non-free can work
towards making a free alternative. Some people are doing exactly
that (I bet you won't see them in this thread though, they're
too busy doing useful stuff).

Re: Bitkeeper

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

On Fri, 2003-07-18 15:32:06 -0500, Shawn <core@enodev.com>
wrote in message <1058560325.2662.31.camel@localhost>:
> To add to this, why?
> 
> I don't mean to jump on anyone, but so long as someone can pull all the
> BK data out if Larry gets unreasonable (via the active and existing SVN
> or CVS gateways) who the frig cares if there's a BK clone??? If things
> got nasty, pull the data and switch unceremoniously switch to SVN or
> whatever.

Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
failed because of 4 issues:

	- I couldn't get the initial import patchset (2)
	- I couldn't get two other patchsets
	- One patchset added a file which already existed (11504)

Trying cvsps with the BKCVS gateway, you won't be able to automagically
import all these patchsets into some other SCM. I got the BKCVS->SVN
script and I'm still looking at it. Other than that, I'm to have a deep
look at cvsps if there's some hidden bug which lets it fail on mentioned
four patchsets...

However, I want to thank Larry for the BC->CVS gateway. Eventually, some
customers could make some use out of it, but it definitively tells us
that Larry is willing to do more than giving BK away (in most cases for
free (as in beer)) - he's investing in it as well as tryin' to keep us
using it (for what he offers some small presents from time to time such
as hosting service and BK->CVS).

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Bitkeeper

[Larry McVoy]

On Sat, Jul 19, 2003 at 08:42:46PM +0200, Jan-Benedict Glaw wrote:
> Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
> failed because of 4 issues:
> 
> 	- I couldn't get the initial import patchset (2)
> 	- I couldn't get two other patchsets
> 	- One patchset added a file which already existed (11504)

Work with Ben Collins on that.  I don't know what cvsps is so I can't
help you there.  If you can figure out what is wrong with the tree and 
explain what we should do to fix it, we'll give it a tree.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On Sat, 2003-07-19 11:49:44 -0700, Larry McVoy <lm@bitmover.com>
wrote in message <20030719184944.GC24197@work.bitmover.com>:
> On Sat, Jul 19, 2003 at 08:42:46PM +0200, Jan-Benedict Glaw wrote:
> > Have you ever used eg. cvsps with the BK->CVS gateway? I tried this and
> > failed because of 4 issues:
> > 
> > 	- I couldn't get the initial import patchset (2)
> > 	- I couldn't get two other patchsets
> > 	- One patchset added a file which already existed (11504)
> 
> Work with Ben Collins on that.  I don't know what cvsps is so I can't
> help you there.  If you can figure out what is wrong with the tree and 
> explain what we should do to fix it, we'll give it a tree.

Thanks fot hint'n'offer!

Basically, cvsps sucks off the rlog messages and compares any check-in
texts / times of any files to find out what has been checked-in with a
single check-in. That is then called a patchset (cvs_ps_). With some
command line arguments, it'll then output the check-in text as well as a
unified diff.

This information can then be used to feed it to other SCMs or for simple
review tasks. While doing consistency checks, I discivered the mentioned
inconsistency (at patchset 11504 IIRC) as well as some minor glitches (I
had one patchset where the check-in comment changed after I re-fetched
the patchset some days later...).

However, I'm working at spare time on it, so it'll take some time:(

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Bitkeeper

[Larry McVoy]

> Basically, cvsps sucks off the rlog messages and compares any check-in

Hmm.  I would guess that makes rlog very happy.  And sleepy :)

> texts / times of any files to find out what has been checked-in with a
> single check-in. That is then called a patchset (cvs_ps_). With some
> command line arguments, it'll then output the check-in text as well as a
> unified diff.

We're looking at getting some seperate bandwidth for bkbits.net and 
turning on the patch feature of BK/Web.  Then you'll be able to do a

    wget http://linux.bkbits.net/linux-2.5/gnupatch@1.5234

and get something like the following.  I suspect this is better than
cvsps and it will work for all repositories on bkbits.net, not just 
the mainline one.  Is that good enough for what you want?  The format
below repeats for each file in the changeset.

===== man/man1/bk-config-etc.1 1.23.1.1 vs 1.26 =====
02/05/16 13:44:09 wscott@wscott1.homeip.net 1.24 +16 -0
   Document 'trust_window' parameter
02/10/03 11:24:15 wscott@desk.wscott1.homeip.net 1.23.1.2 +9 -0
   Docuement the BK_CONFIG environmental variable

--- 1.23.1.1/man/man1/bk-config-etc.1   Tue Sep 17 12:33:59 2002
+++ 1.26/man/man1/bk-config-etc.1       Thu Oct  3 09:24:49 2002
@@ -30,6 +30,15 @@
 (/etc/BitKeeper/etc/config) then that setting will override any 
 matching key in local config files.  
 .LP
+Also configuration entries can be overridden with the
+.B BK_CONFIG
+environmental variable.  That variable can contain a list of key:value
+pairs seperated by semicolons.  For example:
+.DS
+.BR BK_CONFIG =\c
+.IR key1 : value2 ; key2 : value2 ; key3 : value3\c
+.DE
+.LP
 Minimum content requirements for the BitKeeper/etc/config file 

-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

On Sat, 2003-07-19 12:05:31 -0700, Larry McVoy <lm@bitmover.com>
wrote in message <20030719190531.GB24698@work.bitmover.com>:
> > Basically, cvsps sucks off the rlog messages and compares any check-in
> 
> Hmm.  I would guess that makes rlog very happy.  And sleepy :)

Well, it's not exactly fast and it takes quite some CPU cycles on my
side. However, that's a spare box (HP-PARISC B132L+, 132 MHz) which
doesn't have to do anything else:)

> 
>     wget http://linux.bkbits.net/linux-2.5/gnupatch@1.5234
> 
> and get something like the following.  I suspect this is better than
> cvsps and it will work for all repositories on bkbits.net, not just 
> the mainline one.  Is that good enough for what you want?  The format
> below repeats for each file in the changeset.

That's quite good:) Are file renames also represented as patches (ie.
one file gets removed, another one is added)?

To draw the line, that's exactly what one could wish. It someone isn't
happy with the format, it seems to be easily Perl'ed/sed'ed/...

I've not yet looked at any other trees than the linux-2.5^H6 tree, but
I'm currently spending some time to work on merging some trees to one
(read: I want to merge all the non-i386 linux ports) and that involves
quite some scripting / SCMing and up to now, I've not found the
Super-SCM to achieve that:) Tasks are to get all ports to current 2.6.x,
distribute their patches among them and pushing it (separated in small
pieces) to Linus at some far future...

If I could get perfect patches like that out of bkbits.net (at least for
the projects hosted there), that could potentially ease the task a lot:)

MfG, JBG
PS: http://lug-owl.de/~jbglaw/linux-ports/
PPS: I'm missing quite a lot of informations there - if you're a port
maintainer, please get in contact with me:)

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Bitkeeper

[Trever L. Adams]

On Fri, 2003-07-18 at 15:51, Richard Stallman wrote:
>     > If you are trying to copy BK, give it up.  We'll simply follow in the
>     > footsteps of every other company faced with this sort of thing and change
>     > the protocol every 6 months.  Since you would be chasing us you can never
>     > catch up.  If you managed to stay close then we'd put digital signatures
>     > into the protocol to prevent your clone from interoperating with BK.
> 
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

I can't believe I am going to do this.  Especially, where most of my
contributions to OSS/Free Software are not known on this list and the
argument is stupid.

McVoy, changing the protocol would be extremely stupid.  However, it is
your product, so do as you wish.

Stallman, believe it or not, you used to be someone I looked up to a
great deal.  I still think some of your ideas are great and I would love
to see the entire world as open source.  However, to encourage people to
do things that are known to antagonize others is crazy.  CVS is crap.  I
haven't used Bitkeeper but I have tried a lot of others, and they are
junk.  So, if Bitkeeper is as good as Linus et al think it is, then it
would be insane to do anything to ruin the relationship they have with
Bitkeeper.  Ideology is great, but it does have to be tempered and meted
out so that it can be implemented in a way that brings the most good to
everyone.  At this point, ticking off McVoy will likely do the opposite.

McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
I have said before, I hope there is some way your software can become
more open, but I will leave that up to you and your team to figure out
when and how.

Have a good one everyone.

Trever
--
"All this technology has somehow made you a stranger in your own land."
-- Robert M. Pirsig

Re: Bitkeeper

[Shawn]

I second that "Ata boy!". Larry, thank you, for all the help you gave
Linus in the switch over, all the LK specific tweaks to BK, etc.

On Fri, 2003-07-18 at 15:09, Trever L. Adams wrote:
> McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> I have said before, I hope there is some way your software can become
> more open, but I will leave that up to you and your team to figure out
> when and how.

Re: Bitkeeper

[Larry McVoy]

> McVoy, changing the protocol would be extremely stupid.  

There are problems with the current protocol which can't be fixed without
a protocol rev, problems that many of the kernel developers have asked us
to fix.  Sooner or later we are going to fix them and then there will be
a protocol rev.  It's possible we might do one for legal reasons but I
doubt it.  I was just pointing out to Rory that if he insisted on doing
something in direct violation of our license it wouldn't do him any good
in the long run.

> McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As

My pleasure.  At least that part of all of this has worked out pretty
well.  We still think BK is nowhere near good enough, there is a lot left
to be done.  I just spent the day with one of the MySQL founders talking
about tools for doing reviews, I think those could help.  It might be very
cool, for example, if there was a way to distribute the review process
and have everyone looking over code, recording notes about possible
problems, etc.  Then Dave could grab an espresso, hit the web site,
look over the code he cares about, see the reviews, fix it, move on.
It's sort of "attach the bug report directly to the code" rather than
have a bug report.  Don't know if it will work or not but we may try it.
Stuff like that is potentially useful and part of the reason we think
we're nowhere near done.  
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Trever L. Adams]

On Fri, 2003-07-18 at 17:03, Larry McVoy wrote:
> > McVoy, changing the protocol would be extremely stupid.  
> 
> There are problems with the current protocol which can't be fixed without
> a protocol rev, problems that many of the kernel developers have asked us
> to fix.  Sooner or later we are going to fix them and then there will be
> a protocol rev.  It's possible we might do one for legal reasons but I
> doubt it.  I was just pointing out to Rory that if he insisted on doing
> something in direct violation of our license it wouldn't do him any good
> in the long run.
> 

Ah, sorry.  I was meaning the Microsoft kind of switching is stupid. 
You have tech reasons, great do them.  Mr. McVoy, sorry about my blanket
statement.  You obviously weren't just acting the way I thought you
were.

> > McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> 
> My pleasure.  At least that part of all of this has worked out pretty
> well.  We still think BK is nowhere near good enough, there is a lot left
> to be done.  I just spent the day with one of the MySQL founders talking
> about tools for doing reviews, I think those could help.  It might be very
> cool, for example, if there was a way to distribute the review process
> and have everyone looking over code, recording notes about possible
> problems, etc.  Then Dave could grab an espresso, hit the web site,
> look over the code he cares about, see the reviews, fix it, move on.
> It's sort of "attach the bug report directly to the code" rather than
> have a bug report.  Don't know if it will work or not but we may try it.
> Stuff like that is potentially useful and part of the reason we think
> we're nowhere near done.  

Now that is a fantastic idea, kind of like cvs meets bugzilla in one
product.  I hope you are able to do it.

Anyway, please, everyone either take it private with me, or leave me out
of it.  At this point everyone knows how I feel about the issue and why
I do.  All of these arguments only seem to reinforce those feelings and
thoughts.

RMS thank you for the good you do.  Linus and all, thank you VERY much
for all the good you do.  Larry, thank you for your kind response.

Good day to you all.

Trever
--
"In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away." --
RFC1925: The Twelve Networking Truths

Re: Bitkeeper

[Mike Fedyk]

On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As

One nit.

I don't think Alan is using BK.  I could be wrong though.

Re: Bitkeeper

[Alan Cox]

On Gwe, 2003-07-18 at 23:17, Mike Fedyk wrote:
> On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> > McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> 
> One nit.
> 
> I don't think Alan is using BK.  I could be wrong though.

I'm not - and with the snapshots neither I or anyone else is forced to.

Re: Bitkeeper

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Gwe, 2003-07-18 at 23:17, Mike Fedyk wrote:
> > On Fri, Jul 18, 2003 at 04:09:42PM -0400, Trever L. Adams wrote:
> > > McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> > 
> > One nit.
> > 
> > I don't think Alan is using BK.  I could be wrong though.
> 
> I'm not - and with the snapshots neither I or anyone else is forced to.

For the linux kernel.  The problem is the satellite projects which
adopt bitkeeper less carefully.  Unless there is a general gateway I
have missed.

Eric

Re: Bitkeeper

[Mark Mielke]

On Sat, Jul 19, 2003 at 02:20:31AM -0600, Eric W. Biederman wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > > I don't think Alan is using BK.  I could be wrong though.
> > I'm not - and with the snapshots neither I or anyone else is forced to.
> For the linux kernel.  The problem is the satellite projects which
> adopt bitkeeper less carefully.  Unless there is a general gateway I
> have missed.

They do not provide snapshots?

As long as tar files are distributed for each minor release, there is no
true 'lock in'. If you need a gateway for a specific satellite project,
there are people that could probably hook you up with the software required,
and if there are other people in your situation, one of them probably has
enough CPU + network + disk resources to host it.

The Bit Keeper issue is entirely a philosophical one. I understand
that Linus chooses to use it, because it allows him to be more
efficient. Alan Cox chooses not to use it (I'm not clear on his
reasons, but I assume they are just as good). What more proof do we
need that Bit Keeper is not locking people in?

I don't use it, and have never used it at this point, primarily
because I happen to be in the source management field currently, and I
have chosen to respect Larry's license. I'm certain that if I ever had
a proper need in terms of kernel development, the license could be
waived or altered on a case-by-case basis.

Stallman puts himself 100% in the philosopher's chair. He seems to believe
that any variation or compromise weakens his overall position. Every few
months he starts a flame war just to satisfy his own guilt that rises from
him feeling that he isn't doing enough to 'promote' free projects, even if
the free projects don't exist yet, or are not as feature-full.

A few of us have a real love-hate relationship with Stallman. We love what he
has accomplished. We hate how he accomplishes his goals.

The bottom line of all of this, is that Stallman is preaching to the wrong
people. He should stick to press releases and such. Kernel developers just
want to get work done. Any investment into writing a new source management
system would be better served by improving the linux source code. If this
wasn't so, the kernel developers wouldn't be kernel developers. They would
be like me... source management developers... :-)

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: Bitkeeper

[Scott Robert Ladd]

Trever L. Adams wrote
> Stallman, believe it or not, you used to be someone I looked up to a
> great deal.  I still think some of your ideas are great and I would love
> to see the entire world as open source.  However, to encourage people to
> do things that are known to antagonize others is crazy.  CVS is crap.  I
> haven't used Bitkeeper but I have tried a lot of others, and they are
> junk.  So, if Bitkeeper is as good as Linus et al think it is, then it
> would be insane to do anything to ruin the relationship they have with
> Bitkeeper.  Ideology is great, but it does have to be tempered and meted
> out so that it can be implemented in a way that brings the most good to
> everyone.  At this point, ticking off McVoy will likely do the opposite.
> 
> McVoy, thank you for helping Linus, Cox, Miller et al scale better.  As
> I have said before, I hope there is some way your software can become
> more open, but I will leave that up to you and your team to figure out
> when and how.

You are being far too rational for this discussion.

While I may have my disagreements with Larry at times, I appreciate his 
patience in granting BitKeeper to the kernel developers.

RMS is a political idealist -- a good thing, in that such people help 
bring about shifts in society. But like all idealists, he's become 
trapped his dogma, fixated on finding battles to fight, even in other 
people's realms.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Bitkeeper

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 18 July 2003 21:51, Richard Stallman wrote:
>     > If you are trying to copy BK, give it up.  We'll simply follow in the
>     > footsteps of every other company faced with this sort of thing and
>     > change the protocol every 6 months.  Since you would be chasing us
>     > you can never catch up.  If you managed to stay close then we'd put
>     > digital signatures into the protocol to prevent your clone from
>     > interoperating with BK.
>
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

Hi Richard.

You're ready for a small flame-war with Larry? 8-)

First I think, this list isn't the correct place for starting
a bk-flame again.
But I also share your opinion, that it's time to write even a
free client.
But how hard will it be? How big is the knowlege of the
protocols bk uses? It'll be not easy, but for sure very interesting.

- -- 
Regards Michael Buesch
http://www.8ung.at/tuxsoft
Penguin on this machine:  Linux 2.4.21  - i386

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/GFjZoxoigfggmSgRAs7XAJ4tZybSXfPTdk7I9cSIuUYSM72xXACfaeOZ
k2QsR3KsL6HxXXj1y/ECdn0=
=2Wzr
-----END PGP SIGNATURE-----

Re: Bitkeeper

[Shawn]

In my mind it's absolutely not worth it. I believe there are
non-commercial protocol gateways from which a copy of linux (complete
with historical BK metadata) can be pulled and converted from.

Larry has his views whether 99.9999% of people disagree with him or not.
He can change the protocol as he sees fit, and we can pull the source
off of BK if we want.

He has stated before, it would be no skin off his balls (to paraphrase).

On Fri, 2003-07-18 at 15:30, Michael Buesch wrote:
> First I think, this list isn't the correct place for starting
> a bk-flame again.
> But I also share your opinion, that it's time to write even a
> free client.
> But how hard will it be? How big is the knowlege of the
> protocols bk uses? It'll be not easy, but for sure very interesting.

Re: Bitkeeper

[Larry McVoy]

I'm trying hard to stay out of this, I think Richard may be trolling,
but I need to make sure that people understand that what Richard is 
suggesting is violation of our license and copyright.

On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

Our license states that you can't use BK if you are developing a similar
system, i.e., a clone.  Without using BK it's impossible to reverse
engineer BK to create the clone.  So your message seems to be saying
"it would be appropriate at this point to violate the BitKeeper license
in order to write a free client which talks with BitKeeper".

Are you really instructing people to go out and violate our license?  
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Shawn]

Again, to add to that, the very existence of BK2SVN and BK2CVS would
seem support the assertion that the license/copyright allow
"work-(sort-of)-alike" developers like (SVN guys) to use the protocol
gateways. It only prevents them from using BK itself.

Really, the existence of the gateways was the end-all answer to the
arguments folks had. The only thing really left is that the gateways
operate on the charity of Larry.

So, just keep those repos up to date from the gateways, and if they stop
working one day, then bitch. But understand, Larry is well within his
rights in all his assertions; he's just quite a bit right of hard line
GNU.

On Fri, 2003-07-18 at 15:44, Larry McVoy wrote:
> I'm trying hard to stay out of this, I think Richard may be trolling,
> but I need to make sure that people understand that what Richard is 
> suggesting is violation of our license and copyright.
> 
> On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper, and for Linux developers to start switching
> > to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> > if he carries out these threats, he risks alienating the community
> > that he hopes will market Bitkeeper for him.
> 
> Our license states that you can't use BK if you are developing a similar
> system, i.e., a clone.  Without using BK it's impossible to reverse
> engineer BK to create the clone.  So your message seems to be saying
> "it would be appropriate at this point to violate the BitKeeper license
> in order to write a free client which talks with BitKeeper".
> 
> Are you really instructing people to go out and violate our license?  

RE: Bitkeeper

[David Schwartz]

> Our license states that you can't use BK if you are developing a similar
> system, i.e., a clone.  Without using BK it's impossible to reverse
> engineer BK to create the clone.  So your message seems to be saying
> "it would be appropriate at this point to violate the BitKeeper license
> in order to write a free client which talks with BitKeeper".

> Larry McVoy              lm at bitmover.com

	My understanding of the relevant case law in the United States is that
these types of restrictions are not allowed under copyright law itself.
They've only been upheld when they're part of a sale contract. You can
certainly argue that a click to an 'I Agree' link constitutes acceptance of
a sale contract. But if someone sits down at a friend's computer that
happens to have BK on it, or finds a copy of BK on a CD someone left at the
lab, you would have a hard time arguing that they agreed to this contract.

	See, for example, ProCD v. Zeidenberg:

"Copyright law forbids duplication, public performance, and so on, unless
the person wishing to copy or perform the work gets permission; silence
means a ban on copying. A copyright is a right against the world. Contracts,
by contrast, generally affect only their parties; strangers may do as they
please, so contracts do not create "exclusive rights." Someone who found a
copy of SelectPhone(TM) on the street would not be affected by the
shrinkwrap license - though the federal copyright laws of their own force
would limit the finder's ability to copy or transmit the application
program."

	IANAL, and in any event, I don't think any court would look fondly on
someone who deliberately contrived a method to claim they're not subject to
the license.

	DS

RE: Bitkeeper

[Shawn]

Maybe you're right, but to the point of the conversation, 'taint worth
it to fight it.

The worst thing anyone can do is go off half cocked, make a challenge,
and *poof*, the protocol gateways disappear, because now Larry is
spending his time & $$ with the lawsuit, and takes down the protocol
gateways.

So, in essence, I say pick the battles that are worth fighting, and then
only the battles that are worth winning.

On Fri, 2003-07-18 at 16:08, David Schwartz wrote:
> > Our license states that you can't use BK if you are developing a similar
> > system, i.e., a clone.  Without using BK it's impossible to reverse
> > engineer BK to create the clone.  So your message seems to be saying
> > "it would be appropriate at this point to violate the BitKeeper license
> > in order to write a free client which talks with BitKeeper".
> 
> > Larry McVoy              lm at bitmover.com
> 
> 	My understanding of the relevant case law in the United States is that
> these types of restrictions are not allowed under copyright law itself.
> They've only been upheld when they're part of a sale contract. You can
> certainly argue that a click to an 'I Agree' link constitutes acceptance of
> a sale contract. But if someone sits down at a friend's computer that
> happens to have BK on it, or finds a copy of BK on a CD someone left at the
> lab, you would have a hard time arguing that they agreed to this contract.
> 
> 	See, for example, ProCD v. Zeidenberg:
> 
> "Copyright law forbids duplication, public performance, and so on, unless
> the person wishing to copy or perform the work gets permission; silence
> means a ban on copying. A copyright is a right against the world. Contracts,
> by contrast, generally affect only their parties; strangers may do as they
> please, so contracts do not create "exclusive rights." Someone who found a
> copy of SelectPhone(TM) on the street would not be affected by the
> shrinkwrap license - though the federal copyright laws of their own force
> would limit the finder's ability to copy or transmit the application
> program."
> 
> 	IANAL, and in any event, I don't think any court would look fondly on
> someone who deliberately contrived a method to claim they're not subject to
> the license.
> 
> 	DS

Re: Bitkeeper

[Alan Cox]

On Gwe, 2003-07-18 at 21:44, Larry McVoy wrote:
> I'm trying hard to stay out of this, I think Richard may be trolling,
> but I need to make sure that people understand that what Richard is 
> suggesting is violation of our license and copyright.

Actually your license is simply irrelevant in most of thre world. You
aren't allowed to forbid reverse engineering for interoperability.

Re: Bitkeeper

[David Lang]

actually I think that your case for ignoring the 'no reverse engineering'
would be far better if you paid for a bitkeeper license, but when you are
being allowed to use it for free on the condition that you use it specific
ways (no reverse engineering and public access to changeset info) saying
that you will eliminate complying with those terms but still get to use it
for free isn't being very reasonable.

David Lang

 On 18 Jul 2003, Alan Cox wrote:

> Date: 18 Jul 2003 22:23:30 +0100
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: Larry McVoy <lm@bitmover.com>
> Cc: Richard Stallman <rms@gnu.org>,
>      Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: Bitkeeper
>
> On Gwe, 2003-07-18 at 21:44, Larry McVoy wrote:
> > I'm trying hard to stay out of this, I think Richard may be trolling,
> > but I need to make sure that people understand that what Richard is
> > suggesting is violation of our license and copyright.
>
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Bitkeeper

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Fri, 18 Jul 2003 22:23:30 BST, Alan Cox said:

> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.

http://marc.theaimsgroup.com/?l=linux-kernel&m=100374609914587&w=2

2.2.20pre11
o	Security fixes
	| Details censored in accordance with the US DMCA

And there's the resignation letter from ALS from a certain LKML regular, too....

Now what's this about the "simply irrelevant"?  Now admittedly the DMCA issues
were on the criminal side of the legal system rather than the civil side, but
the same "You land at the airport and have a chat with the sheriff's deputy"
issue still applies - it's merely a lawsuit rather than an arrest warrant...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Bitkeeper

[Alan Cox]

On Gwe, 2003-07-18 at 22:54, Valdis.Kletnieks@vt.edu wrote:
> Now what's this about the "simply irrelevant"? 

"in most of the world"

If everyone spent the time replacing bitkeeper instead of beating up
Larry they'd get a lot further. I appreciate beating up Larry is more
fun but....

Re: Bitkeeper

[Trever L. Adams]

On Fri, 2003-07-18 at 17:23, Alan Cox wrote:
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.

Well, here in the US the right to reverse engineer may be gone.  It lost
out in a recent case.  Hopefully that isn't telling of the future and
future court cases.

Long live that right everywhere, even if the US sticks its legal head up
a dark, dark tunnel.

Trever
--
"Love is friendship set on fire." -- French Proverb

Re: Bitkeeper

[Larry McVoy]

On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> 	My understanding of the relevant case law in the United States is that
> these types of restrictions are not allowed under copyright law itself.

On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.

    "Judge, I want to violate this license on this product that I got
    for free because it's not free enough".

    "Judge, we give it out for free and we also developed technology
    to transfer the data out of our product and into a GPLed product,
    we do that at our expense and even host the competing GPLed repos
    for free and they still want to violate the license"

Who do you think is going to win that one?

Besides, have you considered that it is that license you appear to
dislike so much which provides for the product, the hosting, the free
public machines, the support, all of that?  It's a pile of money and
time and I don't see RMS steppng forward with an open checkbook.

The license means we have a revenue stream.  We use a significant portion
of that revenue stream to help Linux.  If the revenue stream goes away
then so do the services we provide to you for free.  They obviously
have value or you wouldn't be using them.  
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Marcus Metzler]

Larry McVoy writes:
 > Who do you think is going to win that one?
 > 
 > Besides, have you considered that it is that license you appear to
 > dislike so much which provides for the product, the hosting, the free
 > public machines, the support, all of that?  It's a pile of money and
 > time and I don't see RMS steppng forward with an open checkbook.
 > 
 > The license means we have a revenue stream.  We use a significant portion
 > of that revenue stream to help Linux.  If the revenue stream goes away
 > then so do the services we provide to you for free.  They obviously
 > have value or you wouldn't be using them.  
 > -- 
 > ---

Oh come on, you use Linux for testing and improving your software and
spin it in such a way that you do something charitable. From all your
mailings on this list I don't get the impression that you would do
anything that is not to improve your profit. I bet you can tax deduct
all that money you allegedly spend on linux and thereby increase your profit.

Anyway, this is no subject for the kernel list. Let those who want to
support Larry use bitkeeper and those who rather use free software use
something else.

Marcus

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: Bitkeeper

[Adrian Bunk]

On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > 	My understanding of the relevant case law in the United States is that
> > these types of restrictions are not allowed under copyright law itself.
> 
> On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > Actually your license is simply irrelevant in most of thre world. You
> > aren't allowed to forbid reverse engineering for interoperability.
> 
>     "Judge, I want to violate this license on this product that I got
>     for free because it's not free enough".
> 
>     "Judge, we give it out for free and we also developed technology
>     to transfer the data out of our product and into a GPLed product,
>     we do that at our expense and even host the competing GPLed repos
>     for free and they still want to violate the license"
> 
> Who do you think is going to win that one?
>...

"Judge, our current German copyright law explicitely states that such a
 clause is void."


> Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Bitkeeper

[Larry McVoy]

On Sat, Jul 19, 2003 at 10:42:19PM +0200, Adrian Bunk wrote:
> On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> > On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > > 	My understanding of the relevant case law in the United States is that
> > > these types of restrictions are not allowed under copyright law itself.
> > 
> > On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > > Actually your license is simply irrelevant in most of thre world. You
> > > aren't allowed to forbid reverse engineering for interoperability.
> > 
> >     "Judge, I want to violate this license on this product that I got
> >     for free because it's not free enough".
> > 
> >     "Judge, we give it out for free and we also developed technology
> >     to transfer the data out of our product and into a GPLed product,
> >     we do that at our expense and even host the competing GPLed repos
> >     for free and they still want to violate the license"
> > 
> > Who do you think is going to win that one?
> >...
> 
> "Judge, our current German copyright law explicitely states that such a
>  clause is void."

No, it isn't.  Your case law is based on a *purchase* or *lease* of a
product for *money*.  If you paid us money, you'd have a point.  But
you didn't.  You get to use the product for free and until there is 
some case law which says otherwise, we get to make any rules we like.
And our rules say you can't reverse engineer.  Too bad for you if you
don't like it, I'm not exactly overflowing with sympathy for someone 
who paid nothing and is now complaining that they aren't allowed to 
reverse engineer and steal what they didn't pay for.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Adrian Bunk]

On Sat, Jul 19, 2003 at 02:57:40PM -0700, Larry McVoy wrote:
> On Sat, Jul 19, 2003 at 10:42:19PM +0200, Adrian Bunk wrote:
> > On Fri, Jul 18, 2003 at 03:27:02PM -0700, Larry McVoy wrote:
> > > On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> > > > 	My understanding of the relevant case law in the United States is that
> > > > these types of restrictions are not allowed under copyright law itself.
> > > 
> > > On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > > > Actually your license is simply irrelevant in most of thre world. You
> > > > aren't allowed to forbid reverse engineering for interoperability.
> > > 
> > >     "Judge, I want to violate this license on this product that I got
> > >     for free because it's not free enough".
> > > 
> > >     "Judge, we give it out for free and we also developed technology
> > >     to transfer the data out of our product and into a GPLed product,
> > >     we do that at our expense and even host the competing GPLed repos
> > >     for free and they still want to violate the license"
> > > 
> > > Who do you think is going to win that one?
> > >...
> > 
> > "Judge, our current German copyright law explicitely states that such a
> >  clause is void."
> 
> No, it isn't.  Your case law is based on a *purchase* or *lease* of a

There is no case law in Germany. Case law is somethig that is only used 
in England and the USA.

In Germany there are laws for _everything_. Rules like who owns the
swarm of bees when several swarms of bees unite aren't made at court,
they are explicitely written in laws.

German judges don't read 200 years old judicial decisions, they read 
written laws.

Please ask a lawyer about the differences between the English/US and the 
continental Europe law system if you don't believe me.

> product for *money*.  If you paid us money, you'd have a point.  But
> you didn't.  You get to use the product for free and until there is 
> some case law which says otherwise, we get to make any rules we like.
> And our rules say you can't reverse engineer.  Too bad for you if you
> don't like it, I'm not exactly overflowing with sympathy for someone 
> who paid nothing and is now complaining that they aren't allowed to 
> reverse engineer and steal what they didn't pay for.

The current German copyright law doesn't talk about money. If you allow 
someone to use a copy the law explicitely states that some kind of 
contract clauses (e.g. a complete prohibition of disassembling) are 
simply void.

> Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Bitkeeper

[Larry McVoy]

On Sun, Jul 20, 2003 at 12:28:38AM +0200, Adrian Bunk wrote:
> > product for *money*.  If you paid us money, you'd have a point.  But
> > you didn't.  You get to use the product for free and until there is 
> > some case law which says otherwise, we get to make any rules we like.
> > And our rules say you can't reverse engineer.  Too bad for you if you
> > don't like it, I'm not exactly overflowing with sympathy for someone 
> > who paid nothing and is now complaining that they aren't allowed to 
> > reverse engineer and steal what they didn't pay for.
> 
> The current German copyright law doesn't talk about money. If you allow 
> someone to use a copy the law explicitely states that some kind of 
> contract clauses (e.g. a complete prohibition of disassembling) are 
> simply void.

Alan pointed out to me that the EU rules are for interoperability and they
do not allow reverse engineering for the purposes of learning how a product
works.

Since BK can export any and *all* data and metadata from a one line command,
it's awfully hard to make the argument that you are reverse engineering 
for interoperability.  You can get your data as flat files, diffs, unified
diffs, context diffs.  You can get your checkin comments in any format you
want.  It's trivial to get data in and out of BK.  

You can even get all of that from a web server so you don't have to sully
your hands with evil BK software.

So where is the law that says it is OK to reverse engineer when the product
already provides everything you could possibly want for interoperability?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Adrian Bunk]

On Sat, Jul 19, 2003 at 03:39:56PM -0700, Larry McVoy wrote:
> On Sun, Jul 20, 2003 at 12:28:38AM +0200, Adrian Bunk wrote:
> > > product for *money*.  If you paid us money, you'd have a point.  But
> > > you didn't.  You get to use the product for free and until there is 
> > > some case law which says otherwise, we get to make any rules we like.
> > > And our rules say you can't reverse engineer.  Too bad for you if you
> > > don't like it, I'm not exactly overflowing with sympathy for someone 
> > > who paid nothing and is now complaining that they aren't allowed to 
> > > reverse engineer and steal what they didn't pay for.
> > 
> > The current German copyright law doesn't talk about money. If you allow 
> > someone to use a copy the law explicitely states that some kind of 
> > contract clauses (e.g. a complete prohibition of disassembling) are 
> > simply void.
> 
> Alan pointed out to me that the EU rules are for interoperability and they
> do not allow reverse engineering for the purposes of learning how a product
> works.
> 
> Since BK can export any and *all* data and metadata from a one line command,
> it's awfully hard to make the argument that you are reverse engineering 
> for interoperability.  You can get your data as flat files, diffs, unified
> diffs, context diffs.  You can get your checkin comments in any format you
> want.  It's trivial to get data in and out of BK.  
> 
> You can even get all of that from a web server so you don't have to sully
> your hands with evil BK software.
> 
> So where is the law that says it is OK to reverse engineer when the product
> already provides everything you could possibly want for interoperability?

Current German copyright law says things like that clauses that forbit 
to gather information about the ideas behind a program through normal 
program usage are void.

IANAL, and we are entering an area where you need a lawyer that reads 
both your licensing terms and the copyright law to tell exactly what is 
allowed and what isn't allowed.

My main point is:
There are countries that have laws that are different from US laws (yes,
there's a world outside the USA...). If I download software from your
server it is possible that my local law is the one that is valid for the
contract between us (independent of whether I pay for the software or
whether you give it for free) and my local laws might be different from
the jurisdiction in the USA.

> Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Bitkeeper

[Larry McVoy]

On Sun, Jul 20, 2003 at 01:45:19AM +0200, Adrian Bunk wrote:
> There are countries that have laws that are different from US laws (yes,
> there's a world outside the USA...). If I download software from your
> server it is possible that my local law is the one that is valid for the
> contract between us (independent of whether I pay for the software or
> whether you give it for free) and my local laws might be different from
> the jurisdiction in the USA.

Let's try and simplify this because having a legal discussion is pointless.
Our position is that we gave something out for free with an understanding
that you wouldn't reverse engineer it.  Regardless of your legal rights or
lack thereof, should you attempt to reverse engineer BK we'll simply stop
giving BK out for free.  See?  Simple.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Tupshin Harper]

Larry McVoy wrote:

>On Sun, Jul 20, 2003 at 01:45:19AM +0200, Adrian Bunk wrote:
>  
>
>>There are countries that have laws that are different from US laws (yes,
>>there's a world outside the USA...). If I download software from your
>>server it is possible that my local law is the one that is valid for the
>>contract between us (independent of whether I pay for the software or
>>whether you give it for free) and my local laws might be different from
>>the jurisdiction in the USA.
>>    
>>
>
>Let's try and simplify this because having a legal discussion is pointless.
>Our position is that we gave something out for free with an understanding
>that you wouldn't reverse engineer it.  Regardless of your legal rights or
>lack thereof, should you attempt to reverse engineer BK we'll simply stop
>giving BK out for free.  See?  Simple.
>  
>
No, it's not simple (and this part, unlike much of the rest of this 
discussion, is relevant to this list). If you stopped giving it out for 
free, then it would cease to be a viable tool for Linux development.

-Tupshin

Re: Bitkeeper

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On Sat, 19 Jul 2003 17:10:05 PDT, Tupshin Harper said:

> No, it's not simple (and this part, unlike much of the rest of this 
> discussion, is relevant to this list). If you stopped giving it out for 
> free, then it would cease to be a viable tool for Linux development.

It's called "Killing the goose that lays the golden eggs".

And although Larry has his philanthropic side, if he has to decide between
"helping Linux development" and "making sure the bills get paid".....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Bitkeeper

[Jeff Garzik]

THIS IS NOT A BITKEEPER LIST.

Thanks,

	Jeff

Re: Bitkeeper

[Jeff Garzik]

LINUX KERNEL IS NOT A BITKEEPER MAILING LIST.

Regards,

	Jeff

Re: Bitkeeper

[jiho]

Larry McVoy wrote:
> Let's try and simplify this because having a legal discussion is pointless.
> Our position is that we gave something out for free with an understanding
> that you wouldn't reverse engineer it.  Regardless of your legal rights or
> lack thereof, should you attempt to reverse engineer BK we'll simply stop
> giving BK out for free.  See?  Simple.

Now that *is* legal, and reasonable (in the legal sense) as well.


-- Jim Howard  <jiho@c-zone.net>

Re: Bitkeeper

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Sat, 19 Jul 2003 17:02:32 PDT, Larry McVoy said:
> Let's try and simplify this because having a legal discussion is pointless.
> Our position is that we gave something out for free with an understanding
> that you wouldn't reverse engineer it.  Regardless of your legal rights or
> lack thereof, should you attempt to reverse engineer BK we'll simply stop
> giving BK out for free.  See?  Simple.

You know guys, Larry would spend a lot less time having to make threats
like this if people didn't start off by saying "Let's see how we can get a free
Bitkeeper".   I've seen *LOTS* of philosophical posturing and arguing about
whether it's moral to rip Larry's software off, and what countries make it legal
to do so.

I've only seen *ONE* person (who's name I've forgotten but who needs to be
praised) suggest finding some *FUNDING* for Larry so he doesn't worry about his
revenue stream getting hosed.

So Larry - *IF* funding was there, would you consider a business model similar
to Hans Reiser's?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Bitkeeper

[Larry McVoy]

On Sat, Jul 19, 2003 at 08:30:53PM -0400, Valdis.Kletnieks@vt.edu wrote:
> So Larry - *IF* funding was there, would you consider a business model similar
> to Hans Reiser's?

I'd consider anything which resulted in a healthy business.  The choices
we've made to date have been 100% focussed on staying healthy so we can
grow as a company and continue to support Linux (and the other open
source guys, but I personally only care about Linus - he's unique),
and our commercial customers.  We've been approached by investors and
companies which wished to buy us outright and I passed on both because
it was clear that they wanted one thing: money.  They would have shut
down the free use of BK in less than a day after the deal was done.

The thing you need to consider is that the Linux community is not that
different than our commercial customers - both need us to be healthy so
that we can support them.  Healthy costs a lot of money.

Part of the problem is that people are extremely short sighted.  Until we
gave you BK nobody had any idea that a system like this was possible.
We can see a lot of problems with BK and a lot of problems in the
development process of Linux (and other systems) that maybe we can help
make easier.  When people think about funding us they think about the
$$$ it would take to have a couple of guys doing bug fixes.  That's not
good enough.  We need the dollars to do the next thing that helps make
development work better.  BK is fine but it is not the end all answer.
There is a lot of work in bug tracking, project management, review tools,
web interfaces, etc.  We're not going to be interested in any business
model that means we get enough money to fix some bugs but not enough to
solve the next set of problems.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Bitkeeper

[Jeff Garzik]

THIS IS NOT A BITKEEPER MAILING LIST.

Thank you,

	Jeff

Re: Bitkeeper

[jiho]

(I spared the list a couple of messages by forgetting to CC 'em....)


Larry McVoy wrote:
> On Sat, Jul 19, 2003 at 04:53:40PM -0700, jiho@c-zone.net wrote:
> 
>>Larry McVoy wrote:
>>
>>>So where is the law that says it is OK to reverse engineer when the product
>>>already provides everything you could possibly want for interoperability?
>>
>>Antitrust law.  The purpose of antitrust law is to further competition, not 
>>merely interoperability.
> 
> The day I'm worried about antitrust law is the day I'm rich enough to retire.

I infer a creeping sense of humor.


-- Jim Howard  <jiho@c-zone.net>

Re: Bitkeeper

[Pavel Machek]

Hi!

> > 	My understanding of the relevant case law in the United States is that
> > these types of restrictions are not allowed under copyright law itself.
> 
> On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> > Actually your license is simply irrelevant in most of thre world. You
> > aren't allowed to forbid reverse engineering for interoperability.
> 
>     "Judge, I want to violate this license on this product that I got
>     for free because it's not free enough".

Its not free at all.

Alan is right, that parts of licence agreement are irrelevant in
Europe, and what RMS is suggesting is perfectly legal here. Like it or
not. Don't try to make "RMS suggested something ilegal" case. Thanx,
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Bitkeeper

[Jörn Engel]

On Fri, 18 July 2003 15:51:36 -0400, Richard Stallman wrote:
> 
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

I've told other people before and I'll tell you again:
Please, pretty please, leave linux-kernel for discussions about the
linux kernel and leave the bitkeeper flames for those that enjoy
electronic pyrotechnic.

Apart from that: Larry is right.  Noone cared about crappy ol' cvs
until bk came alone and showed what everyone already knew.  If you
didn't have to improve cvs back then, it is still as good as it was,
so thy improve it now?  Pure jealousy?

Jörn

-- 
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown

Re: Bitkeeper

[Svein Ove Aas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fredag 18. juli 2003, 23:06, skrev Jörn Engel:
> On Fri, 18 July 2003 15:51:36 -0400, Richard Stallman wrote:
> > I think it would be appropriate at this point to write a free client
> > that talks with Bitkeeper, and for Linux developers to start switching
> > to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> > if he carries out these threats, he risks alienating the community
> > that he hopes will market Bitkeeper for him.
>
> I've told other people before and I'll tell you again:
> Please, pretty please, leave linux-kernel for discussions about the
> linux kernel and leave the bitkeeper flames for those that enjoy
> electronic pyrotechnic.
>
> Apart from that: Larry is right.  Noone cared about crappy ol' cvs
> until bk came alone and showed what everyone already knew.  If you
> didn't have to improve cvs back then, it is still as good as it was,
> so thy improve it now?  Pure jealousy?

No, I think we'd improve CVS because bk came along and showed us what we 
already knew.

Bitkeeper *is* better, but as long as the ideas those improvements are based 
on don't get patented there is no reason for us not to claim them for 
ourselves.

Summa summarum:
Having a Free CVS is good.
Having a useful BitKeeper is sometimes better.
Having a Free CVS with all the features of BK would be best.


- - Svein Ove Aas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/GG4H9OlFkai3rMARAkt/AKCdvO7UCiK2AdBKZg0sSoXghmW6vgCfedcB
zKSd79Dwa/ZPwijYMtR3lO0=
=Xuj7
-----END PGP SIGNATURE-----

BK is not heaven, sure [Was: Re: Bitkeeper]

[J.A. Magallon]

On 07.19, Svein Ove Aas wrote:
[...]
> 
> Summa summarum:
> Having a Free CVS is good.
> Having a useful BitKeeper is sometimes better.
> Having a Free CVS with all the features of BK would be best.
> 

Oh, please, stop thinking BitKeeper is the best thing since sliced bread !!!
I have never used BK. I just use CVS as client. I have not looked at SVN.
BK sure surpasses every other SCM tool.
But please, stop thinking about BK clones, BK features, all BK.

As I read in some posts in this thread, people is doing useful work on
a free SCM. Could you all put your efforts on generating a list of
features/requirements you would like for a SCM system specialized for kernel
development, and send them to the developers, instead of arguing about
legal impact of reverse-engineering BK. And let the developers think about
protocols, work flow, ways to do things, and so on. They can find a way
not even similiar to the BK one, and even better...

That way perhaps in one year you could suck data from BK and at least try
a new system...

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.22-pre6-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-0.3mdk))

Re: Bitkeeper

[James Simmons]

These threads are getting annoying :-<

offtopic crap (was Re: Bitkeeper)

[David S. Miller]

On Sat, 19 Jul 2003 00:50:46 +0100 (BST)
James Simmons <jsimmons@infradead.org> wrote:

> These threads are getting annoying :-<

I agree.  As vger postmaster I think I'll start shitcanning them, but
unfortunately most of these threads startup while I'm sleeping so it's
hard for me to get a regexp in place to block the thread.

So, let me put it this way, if you start a BK flame thread it is _YOU_
who I will blacklist from posting to vger.kernel.org

Re: offtopic crap (was Re: Bitkeeper)

[Jeff Garzik]

David S. Miller wrote:
> So, let me put it this way, if you start a BK flame thread it is _YOU_
> who I will blacklist from posting to vger.kernel.org


No more horribly-offtopic RMS trolls?  :)

	Jeff

Re: Bitkeeper

[Zack Brown]

Hi folks,

On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
>     > If you are trying to copy BK, give it up.  We'll simply follow in the
>     > footsteps of every other company faced with this sort of thing and change
>     > the protocol every 6 months.  Since you would be chasing us you can never
>     > catch up.  If you managed to stay close then we'd put digital signatures
>     > into the protocol to prevent your clone from interoperating with BK.
> 
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper.  At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.

I'm against Richard inflaming the situation without really helping, but since
the issue's come up again, I just thought I'd put in a good word for arch here:

The arch project is no longer just a bunch of shell scripts. Tom
Lord has rewritten it in C (and called the C version 'tla'), and it's
self-hosting. Developers are actually contributing to development using arch
itself now. These seem like very big milestones to me.

There's still quite a bit of work to do on it (and a steep learning curve), but
personally, I think it's the project with the best chance of success. Anyone
who's interested in this issue might consider contributing to arch development
instead of duking it out on lkml.

Be well,
Zack

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Zack Brown