On Monday 14 February 2005 03:08, Larry McVoy wrote:
> 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).
Hi, 

do you mean "if you use BK you are agreeing that you won't work on another
SCM for 1 year after you stop using BK." for the kernel tree and developers or in general?

i think this statement is just a kind of trying the MicrosoftBeingTheOneAndOnly way.
it's a kind of extortion - use bk or die :/
if it is really being that way - say goodbye to bk as soon as possible.

regards
mws