Three years after Linux creator Linus Torvalds began using BitKeeper to manage the Linux kernel source tree, debates have continued to spring up on the Linux kernel mailing list [story]. A BitKeeper press release from nearly a year ago claims that the move has resulted in doubling the pace of Linux kernel development, a claim examined in a later two part interview on NewsForge from last May, including comments from Linus and Larry McVoy [interview]. In spite of this significant boost in productivity, there remains a group who vehemently oppose Linus' choice to use BitKeeper.

In a recent thread, Larry noted that the version of BitKeeper in use by Linux kernel developers uses an unsigned short to count changesets, and that in about 100 days the number of changesets in the Linux kernel source tree will grow too large to fit in this variable. A new version of BK will soon be released to allow developers to continue to work even after this 64 thousand changeset boundary is reached. While explaining this, Larry also noted that there was a plan to update the BK license to provide a more precise definition of what is and what is not allowed. Specifically, as is, the license requires that you agree to not work on another SCM product if you use or have used the free BK product. Larry explains, "we've had some people who have indicated that they believed that if they used BK they were agreeing that they would never work on another SCM system. We can see how it is possible that people would interpret the license that way but that wasn't our intent. What we would like to do is change the language to say that if you use BK you are agreeing that you won't work on another SCM for 1 year after you stop using BK. But after that you would be able to hack on anything that you wanted."

Larry went on to note that the reason for this clause is to prevent people from using the free BK product, then to stop using it to work on a competing product, then to go back and use the free BK product again gathering more ideas, then to stop using it to further work on the competing product, and so on. For anyone unwilling to use BK due to its licensing, there are numerous alternative methods for obtaining up-to-date snapshots of the Linux kernel, and Linus continues to accept plain text patch files from non-BK users.

From: [email blocked] (Larry McVoy)
To:  linux-kernel
Subject: [BK] upgrade will be needed
Date: 	Sun, 13 Feb 2005 18:08:02 -0800

This is a heads up that the BK tree for the kernel is currently at 59,000
changesets give or take a few.  The BK that you are using uses unsigned
shorts for the internal names of each delta which means you folks are
about 100 days away from things no longer working.

The good news is that the openlogging tree for the kernel has 135,000
changesets so we've obviously long since fixed this problem.

The bad news is that you will need to upgrade your BK binary in order
to pass over the 64K changeset boundary.  The data is stored on disk in
ascii so it doesn't matter if you upgrade until you hit the problem but
sooner or later you will need to upgrade.

We'll get the fix into bk-3.2.4 which should be out by the end of the
month.  When we release that we'll send out notice and it would be good
if people gave it a try and let us know if they hit issues because in a
couple of months everyone is going to have to upgrade.

It's possible that we'll be changing the BK license to conform more with
our commercial license but we won't do that without running it by Linus &
Co to make sure that it's acceptable.  One change we'd like to make there
is to clarify the non-compete stuff.  We've had some people who have
indicated that they believed that if they used BK they were agreeing
that they would never work on another SCM system.  We can see how it
is possible that people would interpret the license that way but that
wasn't our intent.  What we would like to do is change the language to
say that if you use BK you are agreeing that you won't work on another
SCM for 1 year after you stop using BK.  But after that you would be
able to hack on anything that you wanted.  That was more of what we
had in mind in the first place but we didn't make it clear.  If you all
thought that using BK meant you had no right to hack on SCM ever again,
that's just not fair.  We need to protect our IP but you should have
the right to choose to go hack SCM if that's what you (our first choice
is that you came and worked here, we really like kernel hackers, but if
you don't want to that's cool too).
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



From: Bartlomiej Zolnierkiewicz [email blocked]
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 13:08:58 +0100

On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy [email blocked] wrote:
> is to clarify the non-compete stuff.  We've had some people who have
> indicated that they believed that if they used BK they were agreeing
> that they would never work on another SCM system.  We can see how it
> is possible that people would interpret the license that way but that
> wasn't our intent.  What we would like to do is change the language to

I always interpreted it the other way, that if I start working on other
SCM I should stop using BK.

> say that if you use BK you are agreeing that you won't work on another
> SCM for 1 year after you stop using BK.  But after that you would be

I don't even plan working on some SCM system, but being
tainted for 1 year for just *using* BK is not worth the price IMHO.

Regards,
Bartlomiej



From: Jeff Sipek [email blocked]
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 10:08:20 -0500

On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy [email blocked] wrote:
> > is to clarify the non-compete stuff.  We've had some people who have
> > indicated that they believed that if they used BK they were agreeing
> > that they would never work on another SCM system.  We can see how it
> > is possible that people would interpret the license that way but that
> > wasn't our intent.  What we would like to do is change the language to
> > say that if you use BK you are agreeing that you won't work on another
> > SCM for 1 year after you stop using BK.  But after that you would be
> 
> I don't even plan working on some SCM system, but being
> tainted for 1 year for just *using* BK is not worth the price IMHO.

I agree, the price is just too high. No matter how much I like BK, I
would give it up.

Jeff.



From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 07:40:15 -0800

On Mon, Feb 14, 2005 at 10:08:20AM -0500, Jeff Sipek wrote:
> On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy [email blocked] wrote:
> > > is to clarify the non-compete stuff.  We've had some people who have
> > > indicated that they believed that if they used BK they were agreeing
> > > that they would never work on another SCM system.  We can see how it
> > > is possible that people would interpret the license that way but that
> > > wasn't our intent.  What we would like to do is change the language to
> > > say that if you use BK you are agreeing that you won't work on another
> > > SCM for 1 year after you stop using BK.  But after that you would be
> > 
> > I don't even plan working on some SCM system, but being
> > tainted for 1 year for just *using* BK is not worth the price IMHO.
> 
> I agree, the price is just too high. No matter how much I like BK, I
> would give it up.

The way some people are reading the license the price is even higher,
they think it is a forever tainted license as it stands today.  I've had
specific requests to clarify this part of the license.

So how would you suggest that we resolve it?  The protection we need is
that people don't get to

    - use BK
    - stop using BK so they can go work on another system
    - start using BK again
    - stop using BK so they can go work on another system
    ...

We could say that if you stop using BK and work on another system then
you can't ever use it again.  We're not going to do that, we've already
had to calm the fears of people who found themselves in that situation
for their job.  

So what do you want us to do?  This isn't a change to take stuff from
you, it's a change that some of your peers asked us to do so they could
use BK (and it would be nice if the people who wanted this are reading
this thread and will speak up so it doesn't look like I'm making it up).

What we've been doing so far is telling people who were worried to act as
if there were a year long gap and they have been happy with that answer
but they are asking for us to put it in the license so they don't have
to depend on some email based side agreement.

It would be nice if you could talk this over amongst yourselves and
suggest an answer.  I can see why you think it is a bad change, I'm hoping
that you can see why other people may want us to make this sort of change.
Maybe if you think about it a bit you'll come up with a better solution.
Or maybe we will.  Either way, I can't be very involved in the process,
I'm taking off for a week long vacation starting Wednesday and I won't
have email access.  Which will be a good way to make sure that if this 
turns into a flame war I won't be prolonging it.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



From: Marcin Dalecki [email blocked]
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 18:14:09 +0100


On 2005-02-14, at 16:40, Larry McVoy wrote:
> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to
>
>     - use BK
>     - stop using BK so they can go work on another system
>     - start using BK again
>     - stop using BK so they can go work on another system
>     ...

Give me a break!
Did may the idea perhaps occur to you that maybe the above wish list is:

1. Utterly immoral.
2. Something you are by no ways entitled to have.

If you want to be compensated for BK then put a price tag on it.
So what are you now trying to do is basically to use peoples wish to 
contribute to
free software as a measure to prohibiting them from competing with your 
commercial endeavor... that simply plain isn't fair play. 



From: Russell Miller [email blocked]
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 09:23:03 -0800

On Monday 14 February 2005 09:14, Marcin Dalecki wrote:

> Give me a break!
> Did may the idea perhaps occur to you that maybe the above wish list is:
>
> 1. Utterly immoral.
> 2. Something you are by no ways entitled to have.
>
> If you want to be compensated for BK then put a price tag on it.
> So what are you now trying to do is basically to use peoples wish to
> contribute to
> free software as a measure to prohibiting them from competing with your
> commercial endeavor... that simply plain isn't fair play.
>
It is certainly Larry's choice to license his software any way he chooses.

It is my choice whether or not to use it.

BK will never pollute my machine as long as simply using it will restrict me 
from any other development or programming activity.  I can understand it if 
the source code is made available.  If it's just a binary... this is going 
way too far.

--Russell

-- 

Russell Miller - [email blocked] - Agoura, CA



From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 09:49:33 -0800

On Monday 14 February 2005 09:14, Marcin Dalecki wrote:
> 1. Utterly immoral.
> 2. Something you are by no ways entitled to have.
>
> If you want to be compensated for BK then put a price tag on it.

Excellent idea.  At the volumes you are using it now that's $65M/year.
That's what we'd charge for the same number of seats at one commercial
site.  If it were spread out over the thousands of sites like your
usage is then it would be more, there's a lot more overhead.  There are
currently more than 2,200 top level domains using BK for free (where
top level means my-company.com, not my-workstation.my-company.com).

If someone wants to pay for it we'd be happy to negotiate a standard
click-wrap style license as part of the deal.  Everyone would like that
much better it seems.  Are you volunteering to pay?

On Mon, Feb 14, 2005 at 09:23:03AM -0800, Russell Miller wrote:
> It is certainly Larry's choice to license his software any way he chooses.
> 
> It is my choice whether or not to use it.

Yup, it is.  Always has been even for the kernel because of our hard
work to make sure of that.  We respect your choices, please respect ours.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 11:29:20 -0800

On Mon, Feb 14, 2005 at 09:49:32AM -0800, lm wrote:
> If it were spread out over the thousands of sites like your
> usage is then it would be more, there's a lot more overhead.  There are
> currently more than 2,200 top level domains using BK for free (where
> top level means my-company.com, not my-workstation.my-company.com).

http://www.bitkeeper.com/domains.html

is a listing of the domains which have used bk-3.2.3 in the last 4
months.  It's slightly less than the claimed 2,200 because we looked
only at the bk-3.2.3 usage.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



From: Matthew Jacob [email blocked]
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 10:17:35 -0800

> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to
> 
>    - use BK
>    - stop using BK so they can go work on another system
>    - start using BK again
>    - stop using BK so they can go work on another system
>    ...
> 

I guess I don't see the advantage that accrues to BitMover Inc from
this or what you're trying to do here. I'm not trying to add kerosene
to a flame fest here, but I'm definitely scratching my head on this
one.

Is your concern that you don't want to provide a free tool to people
who then turn around to compete with you? That is, you don't want BK
to enable people to do things to harm BK and its ongoing development?

I mean- you're certainly free to impose whatever license you want, and
others are free to be happy or unhappy with that. I'm just trying to
figure out what you're actually trying to accomplish here.




From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 10:56:24 -0800

On Mon, Feb 14, 2005 at 10:17:35AM -0800, Matthew Jacob wrote:
> > So how would you suggest that we resolve it?  The protection we need is
> > that people don't get to
> > 
> >    - use BK
> >    - stop using BK so they can go work on another system
> >    - start using BK again
> >    - stop using BK so they can go work on another system
> >    ...
> > 
> 
> I guess I don't see the advantage that accrues to BitMover Inc from
> this or what you're trying to do here. I'm not trying to add kerosene
> to a flame fest here, but I'm definitely scratching my head on this
> one.
> 
> Is your concern that you don't want to provide a free tool to people
> who then turn around to compete with you? That is, you don't want BK
> to enable people to do things to harm BK and its ongoing development?

All we are trying to do is 

    1.  Provide the open source community with a useful tool.
    2.  Prevent that from turning into the open source community
        creating a clone of our tool.

The reason this is complicated is that we are giving it away for free to
lots and lots of open source people.  If we only sold it there wouldn't
be a problem, it would be 10 years before a copy appeared because far
fewer of the open source crowd would even know it existed.  Giving it
away is almost asking for it to be copied.  The license is a way to say
that the price of free use is agreement you won't use the tool to copy
the tool in any way.

I agree that this sucks, having a license that restricts your creativity
is very annoying.  On the other hand, you don't have to agree to it.
You only have to agree to it if you want the benefits of using the tool.
It's not much different than deciding whether you want to buy it, there
is a cost and a benefit and for some people the benefits outweigh the
costs and for some they don't.

If anyone can think of a better way for us to both let you use the tool
and protect our hard work, I'm listening.  The repeated outrage over the
restrictions isn't any more fun for me than it is for you.  Any answer,
however, has to take our issues into consideration as well as yours.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



From: Matthias Andree <matthias.andree@gmx.de>
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 20:44:28 +0100

On Mon, 14 Feb 2005, Larry McVoy wrote:

> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to
> 
>     - use BK
>     - stop using BK so they can go work on another system
>     - start using BK again
>     - stop using BK so they can go work on another system
>     ...

Add a cancellation period or a relicense block to BK/Free.

For instance:

1. $licensee can cancel his license with 30 days period before end of a
   month

2. BK/Free license is not available to (1) people who have worked on a
   system essentially similar to BK in the past six weeks, (2) people
   who have had their BK/Free license terminated within the past six
   weeks for any reason other than a new BK version becoming available.

> So what do you want us to do?  This isn't a change to take stuff from
> you, it's a change that some of your peers asked us to do so they could
> use BK (and it would be nice if the people who wanted this are reading
> this thread and will speak up so it doesn't look like I'm making it up).

This is, by your leave, ridiculous. I was, so far, allowed to stop using
BK/Free on day #1 and hack non-BK SCM on day #2. I understand you don't
want users to repeat this sequence, use BK on every odd day of month and
hack non-BK SCM on every even day, and I haven't done that (I haven't
hacked SCM).

> What we've been doing so far is telling people who were worried to act as
> if there were a year long gap and they have been happy with that answer
> but they are asking for us to put it in the license so they don't have
> to depend on some email based side agreement.

So have them send a SSAE and pass that note in writing.

-- 
Matthias Andree



From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 12:05:44 -0800




> This is, by your leave, ridiculous. I was, so far, allowed to stop using
> BK/Free on day #1 and hack non-BK SCM on day #2. I understand you don't
> want users to repeat this sequence, use BK on every odd day of month and
> hack non-BK SCM on every even day, and I haven't done that (I haven't
> hacked SCM).

That's not how others are reading it and when we requested clarification
from the legal firm we use for contracts (Fenwick&West if you care) they
said that it could well be interpreted that if you use BK you are giving
up your right to hack on another system.  That wasn't our intent but nor
is it our intent to let you go back and forth.

> > What we've been doing so far is telling people who were worried to act as
> > if there were a year long gap and they have been happy with that answer
> > but they are asking for us to put it in the license so they don't have
> > to depend on some email based side agreement.
> 
> So have them send a SSAE and pass that note in writing.

Do you have any idea how many people are using BK?  If they all asked
for this we'd be passing out more than 200 of these a day for more than
a year.  It's around one per minute.  

We either fix the license or leave it as is, we're not able to do side
agreements with everyone that asks.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



From: Gerold Jury [email blocked]
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 23:24:43 +0100

Hi Larry
Hi Everyone

To me it looks like lot's of users (and myself) simply want to track the 
kernel development very closely.
Some are looking out for a specific bug to be fixed.
Some want to see the direction of some developments going on.
The first place a change arrives at is the bitkeeper repository.
There are others who already have an idea to contribute.
They will already know what the pros and cons of bitkeeper are, or soon find 
out.
Do you think it is possible to make a split licence that will distinguish 
between active changes and passive watching/tracking ?
The web interface does not provide the functionality for a quick overview 
about the latest changes.
It may be sufficient for a part of the people in this discussion.

Regards
Gerold



From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 14:57:04 -0800

On Mon, Feb 14, 2005 at 11:24:43PM +0100, Gerold Jury wrote:
> Hi Larry
> Hi Everyone
> 
> Do you think it is possible to make a split licence that will distinguish 
> between active changes and passive watching/tracking ?

A lot of people have told us to create two products, the free product
and the commercial product, and license the free product with standard
licensing terms.  The expectation is that we would somehow make the free
product less desirable so that people bought the commercial product.

That's an excellent suggestion if our only goal is to make money, that
makes the free product sort of a teaser and the commercial product the
real deal.  However, the goal really is to help the open source
community, Linux in particular.  If we give away crippled software then
all the people who say we are just a money grubbing corporation are
more or less correct.  At that point we aren't giving away the good
stuff and it was always the goal that you got the latest and greatest
because that's what can do you the most good.

However, it sure sounds like the noisy people would be a lot happier
with a stripped down BK that didn't have as many of the restrictions.
And a possible out for even the open source users is that they buy seats
if they really need the more powerful features.  Or we could donate
some on a case by case basis.

If the hackers who are using BK can reach agreement that it would be
better if the BK they had didn't move forward unless they got commercial
seats then we could start moving towards a license on the free product
that was less restrictive.  What that would mean is that the BK you have
is basically it, we'd not advance it other than keeping it up to date
with the protocol and/or file formats of the commercial version.  If you
think BK is good enough, fast enough, done enough that you don't want
what we have coming down the pike we can go that route.

I suspect that the heavy lifters really would like a faster BK with more
features that help them get their job done but the rank and file could
care less, they just want checkin/checkout.  
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



From: David Lang <david.lang@digitalinsight.com>
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 15:23:47 -0800 (PST)

Larry, I don't think he's talking about making the free bk be a striped 
down version, I think he's talking about having two different free 
versions.

version 1
what you have today with the license you need to protect yourself

version 2
a version with no check-in capability at all, all it can do is passivly 
mirror a repository to a local system and check-out a tree to a local 
system. since this version won't have any of your 'secret sauce merging 
stuff' in it it may be possible for you to use a license that doesn't need 
to include the non-compete clause.

anyone doing development would need version1, but there are a number of 
people who have bitkeeper installed but only use it to check out versions 
and really don't care about the differences between bk and cvs for this 
(and for this purpose the differences are mainly network efficiancies)

Assuming that this is techincaly posible (my memory is warning me that the 
pull from a remote repository may be a 'check-in' as things are currently 
written) I think the risk to you would that the new license would let some 
of the people who want to reverse-engineer things use this 'fetch-only' 
version and see some of the meta-data, I don't know if you can leave out 
enough of the stuff you care about to be willing to loose the rest.

As you acknowledged in your presentation this last weekend, the people at 
the bottom of the tree don't get much benifit from bitkeeper, this applies 
even more so to the people who are read-only to the system.

this does mean that there would be somehat of a commiter/non-commiter 
split, with the difference between them being those who agree to the 
non-compete license of #1 and those who don't and use #2 to have a local 
read-only copy and have to use normal patches to submit changes up the 
tree.

David Lang

  On Mon, 14 Feb 2005 [email blocked] wrote:

> Date: Mon, 14 Feb 2005 14:57:04 -0800
> From: [email blocked]
> Cc: Linux Kernel Mailing List [email blocked],
>     Jeff Sipek [email blocked],
>     Bartlomiej Zolnierkiewicz [email blocked]
> Subject: Re: [BK] upgrade will be needed
> 
> On Mon, Feb 14, 2005 at 11:24:43PM +0100, Gerold Jury wrote:
>> Hi Larry
>> Hi Everyone
>>
>> Do you think it is possible to make a split licence that will distinguish
>> between active changes and passive watching/tracking ?
>
> A lot of people have told us to create two products, the free product
> and the commercial product, and license the free product with standard
> licensing terms.  The expectation is that we would somehow make the free
> product less desirable so that people bought the commercial product.
>
> That's an excellent suggestion if our only goal is to make money, that
> makes the free product sort of a teaser and the commercial product the
> real deal.  However, the goal really is to help the open source
> community, Linux in particular.  If we give away crippled software then
> all the people who say we are just a money grubbing corporation are
> more or less correct.  At that point we aren't giving away the good
> stuff and it was always the goal that you got the latest and greatest
> because that's what can do you the most good.
>
> However, it sure sounds like the noisy people would be a lot happier
> with a stripped down BK that didn't have as many of the restrictions.
> And a possible out for even the open source users is that they buy seats
> if they really need the more powerful features.  Or we could donate
> some on a case by case basis.
>
> If the hackers who are using BK can reach agreement that it would be
> better if the BK they had didn't move forward unless they got commercial
> seats then we could start moving towards a license on the free product
> that was less restrictive.  What that would mean is that the BK you have
> is basically it, we'd not advance it other than keeping it up to date
> with the protocol and/or file formats of the commercial version.  If you
> think BK is good enough, fast enough, done enough that you don't want
> what we have coming down the pike we can go that route.
>
> I suspect that the heavy lifters really would like a faster BK with more
> features that help them get their job done but the rank and file could
> care less, they just want checkin/checkout.
> --
> ---
> Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email blocked]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare



From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 16:03:43 -0800

On Mon, Feb 14, 2005 at 03:23:47PM -0800, David Lang wrote:
> Larry, I don't think he's talking about making the free bk be a striped 
> down version, I think he's talking about having two different free 
> versions.

Leaving aside the $600K/year or so it would cost us to do that...

> this does mean that there would be somehat of a commiter/non-commiter 
> split, with the difference between them being those who agree to the 
> non-compete license of #1 and those who don't and use #2 to have a local 
> read-only copy and have to use normal patches to submit changes up the 
> tree.

And how does the CVS gateway not provide this today?  We effectively
have exactly what you are describing.  And long ago I offered what I
called the tarball + patch server with an open source client for all
trees on bkbits.net - here it is:  http://lkml.org/lkml/2003/12/14/47
If people had stopped flaming long enough to look at that it would 
be installed on bkbits today and any repo hosted there would have an
automatic real-time gateway with no license problems.  Heck, we could
even export the changeset comments into ChangeLog as Keith suggested
here: http://lkml.org/lkml/2003/12/14/92 .  

People didn't seem interested and I came with the conclusion, rightly or
wrongly, that the vast majority of the people who did real work didn't
care about the license and the noisy people just wanted to pick a fight.
If I was wrong and this is valuable I can look into putting it up on
bkbits.net.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



From: Steven Rostedt [email blocked]
To: Larry McVoy [email blocked]
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 20:00:59 -0500

On Mon, 2005-02-14 at 16:35 -0800, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 07:14:11PM -0500, Steven Rostedt wrote:
> > On Mon, 2005-02-14 at 16:00 -0800, Larry McVoy wrote:
> > > How about this?
> > > 
> > > http://lkml.org/lkml/2003/12/14/47
> > 
> > I don't know about others, but it solves my issues.  I'm one of the many
> > that use BK not for the changes, but just for the snapshots. This seems
> > to do it.  Warning, you will still not please a lot of the complainers
> > on the list, but myself (and others) would be satisfied.
> 
> Well it would sure help if you said that in public.  Unless people ask
> for this we aren't going to go build it and support it on bkbits.net.
> It needs to solve problems for a pile of people or we can't afford to do
> it.
> 

I wasn't very active on the list back then, but post something like this
again and I'll second it publicly. You may have already done so, but I
might have missed it. I'll cc the LKML to make this public anyway.

> > As someone mentioned. Still do what you were going to do (keep BK free
> > for Open Source albeit the restriction). But have this for those of us
> > that can't go with the restriction, but still like the latest snapshots
> > of the kernel. In essence, two free versions, where one is "more free"
> > but also "crippled".
> 
> There are HUGE costs with maintaining multiple versions, I'd like to
> avoid that.  We've specced out what it would cost us to maintain 
> old/new versions that talked to each other and it's more or less twice
> as much engineering because you have to backport each new feature needed
> for compat, you have to figure out which bugs have to be backported,
> etc., etc.  It is very very expensive and takes up the resources of our
> most important people.

I don't know the architecture of the tool, but I've worked on some
pretty big projects, that could disable most of the tool with just a
simple config option. Heck, the Linux kernel does this.  But if the
design of the tool is such that you can't disable features without
destroying others (like removing IE from Windows),  then I guess this is
not an option. 

I guess you are dealing with three groups of people.

1) The ones paying you. The companies that spend money to get things
done.  -- Needs full version of BK.

2) The Open Source developers, Linus and others that like BK and will
work with it with whatever license you give it. -- Needs strong version
of BK. Probably no more than 100 users (or less).

3) The Open Source users, tweakers, hackers that are not the core
developers. -- Needs only to checkout the kernel. Probably over 1000
users.  I fall in this category.

This is why we have asked about three versions. Obviously, Linus and
friends are the most important part for the Linux community, so even if
it hurts 2000 other people that only want to download the lastest
snapshots from BK, it really doesn't matter.  Let us complain, but
unless Linus decides to go elsewhere, we are stuck.  So don't do the
crippled version if it hurts Linus.

-- Steve



From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 19:01:45 -0800

On Mon, Feb 14, 2005 at 08:00:59PM -0500, Steven Rostedt wrote:
> I guess you are dealing with three groups of people.
> 
> 1) The ones paying you. The companies that spend money to get things
> done.  -- Needs full version of BK.

Agreed.

> 2) The Open Source developers, Linus and others that like BK and will
> work with it with whatever license you give it. -- Needs strong version
> of BK. Probably no more than 100 users (or less).

We could handle these guys by selling/donating commercial seats.
But while we started out with the goal of helping the Linux effort,
specifically Linus, other open source projects have gotten past
the license and found value in the product: mysql, xaraya, xen, etc.
Whatever we do we can't do anything which would disrupt their efforts,
that's not reasonable.

> 3) The Open Source users, tweakers, hackers that are not the core
> developers. -- Needs only to checkout the kernel. Probably over 1000
> users.  I fall in this category.

Would the tarball + patch server suffice for you?  We could make a
ChangeSet file which had bk changes -v output in it and that would 
give you a fairly useful set of version information.  For those who
don't know, bk changes -v is output in time sorted order of changesets
with the changeset comments then each file's comments like the output
below.  

This server wouldn't be much use for someone trying to track down the
source of a bug, you'd really need the BK2CVS tree for that or a BK
tree.  In some ways, the BK2CVS tree is far nicer because you can do
binary search on it, but as Roman/Pavel/et al have pointed out sometimes
the commits in the CVS tree are too coarse if the cset you want is a
merge of 20 changesets on a branch.  In that case you want the BK tree.

But for people trying to easily track the head the tarball server might
be just the ticket.  Erik (codepoet guy) would probably love it (right?).
If it would help people feel better about us and/or make their lives easier
we can set up that server for all the repos on bkbits.net.  I suspect
that it would help at least some people out there.

--lm

ChangeSet@1.2044, 2005-02-14 18:09:02+00:00, [email blocked]
+3 -0
  [ARM] Fix sparse warnings for Integrator builds.
  
  Add some missing __iomem annotations for Integrator machines.
  
  Signed-off-by: Russell King [email blocked]

  arch/arm/mach-integrator/impd1.c@1.9, 2005-02-14 18:03:31+00:00, [email blocked] .linux.org.uk +1 -1
    Add sparse __iomem annotations.

  arch/arm/mach-integrator/time.c@1.9, 2005-02-14 18:03:31+00:00, [email blocked].  linux.org.uk +4 -4
    Add sparse __iomem annotations.
    Use "dev" rather than "rtc_base" for the device id when requesting
    the RTC interrupt.

  drivers/input/serio/ambakmi.c@1.13, 2005-02-14 18:03:31+00:00, [email blocked] inux.org.uk +1 -1
    Add sparse __iomem annotations.


> This is why we have asked about three versions. Obviously, Linus and
> friends are the most important part for the Linux community, so even if
> it hurts 2000 other people that only want to download the lastest
> snapshots from BK, it really doesn't matter.  Let us complain, but
> unless Linus decides to go elsewhere, we are stuck.  So don't do the
> crippled version if it hurts Linus.
> 
> -- Steve
> 

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



From: Steven Rostedt [email blocked]

Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 22:39:44 -0500

On Mon, 2005-02-14 at 19:01 -0800, Larry McVoy wrote:

> Would the tarball + patch server suffice for you?  We could make a
> ChangeSet file which had bk changes -v output in it and that would 
> give you a fairly useful set of version information.  For those who
> don't know, bk changes -v is output in time sorted order of changesets
> with the changeset comments then each file's comments like the output
> below.  
> 

This is perfect for me. The only time I've ever used BK was when someone
told me that I needed the lastest snapshot from the bk-tree.  What I do
with the kernel is to port it, write drivers or customize it for
customers. So I'm not in the development part of the kernel (although
I'll report bugs and fixes when I find them). I really believe that the
majority that download the kernel from BK are doing things like I am and
not part of the core development team. 

Currently, I'm working on a customization of Ingo's RT version, so
really at the moment I don't even need access to BK. But with my
previous job, I was downloading the bk version quite a lot. But just to
get the latest updates. So what you have suggested would have been all
that I needed.  As I've mentioned, earlier. I work from job to job and
my needs change with each one. I joined in this discussion because it
could have affected me quite a bit, since someday I might be hired to
work on a SCM tool, and I'm very careful about NDAs and the like.
 
-- Steve

PS - I'm packing up now to drive to Boston. See everyone at
LinuxWorld ;-)



From: Ed Tomlinson [email blocked]
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 21:13:14 -0500

On Monday 14 February 2005 10:40, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 10:08:20AM -0500, Jeff Sipek wrote:
> > On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy [email blocked] wrote:
> > > > is to clarify the non-compete stuff.  We've had some people who have
> > > > indicated that they believed that if they used BK they were agreeing
> > > > that they would never work on another SCM system.  We can see how it
> > > > is possible that people would interpret the license that way but that
> > > > wasn't our intent.  What we would like to do is change the language to
> > > > say that if you use BK you are agreeing that you won't work on another
> > > > SCM for 1 year after you stop using BK.  But after that you would be
> > > 
> > > I don't even plan working on some SCM system, but being
> > > tainted for 1 year for just *using* BK is not worth the price IMHO.
> > 
> > I agree, the price is just too high. No matter how much I like BK, I
> > would give it up.
> 
> The way some people are reading the license the price is even higher,
> they think it is a forever tainted license as it stands today.  I've had
> specific requests to clarify this part of the license.
> 
> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to

How about just reversing it.  If you work on another scm you cannot use
_free_ bk for 1 year after you stop. 

Ed Tomlinson



From: [email blocked] (Larry McVoy)
Subject: Re: [BK] upgrade will be needed
Date: 	Mon, 14 Feb 2005 18:40:18 -0800

On Mon, Feb 14, 2005 at 09:13:14PM -0500, Ed Tomlinson wrote:
> > The way some people are reading the license the price is even higher,
> > they think it is a forever tainted license as it stands today.  I've had
> > specific requests to clarify this part of the license.
> > 
> > So how would you suggest that we resolve it?  The protection we need is
> > that people don't get to
> 
> How about just reversing it.  If you work on another scm you cannot use
> _free_ bk for 1 year after you stop. 

Hi Ed, thanks for the thought.  We've discussed this idea before with
some managers of open source developers and found that no matter which
one we pick some people don't like it.  People tend to cluster up based on
whether they value working on $SCM more or using BK more.  If they want to
preserve the ability to move people to working on competing products then
they would like the option you suggested.  If they are more interested
in using BK then they would prefer the other way.  The people we spoke
with were far more interested in the ability to move people onto BK when
they needed to.

But it's a good idea and we'd certainly be willing to flip to your way
on a case by case basis.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

• Archive of above thread