RFC: BK license change

RFC: BK license change

[Larry McVoy]

No, we're not GPLing it but we are making a few adjustments and wanted to
make sure that it was an improvement, not a regression, in the eyes of
the free users.  Sorry for the intrusion, I'll be as brief as possible.

You can read the new license at http://www.bitkeeper.com/bkl.txt but I'll
summarize the changes here.

3(a) Propagation to openlogging.org.  The old license insisted that
     you log your changes within 7 days; several people pointed out
     that they are spending their dotcom dollars sitting on an island
     hacking the kernel and they may not have connectivity every 7 days.
     Or something.  We upped the limit to 21 days, that should be 
     enough, I have to believe that you check your mail every three weeks
     if you are doing work.

3(c) Maintaining Open Source.  Our intent was that the free use of
     BitKeeper was for the purpose of helping the open source community;
     it was not to provide commercial users a free product.  We have had
     a number of cases where managers up to VPs have told their engineers
     "just don't put anything useful in the checkin comments and then we
     can use it for free".  Not what we had in mind.  So we're adding
     a clause which says that we reserve the right to insist that you
     make your repositories available on a public port within 15 days
     of the request.

     We understand that lots of legit open source users have very good
     reasons for not wanting their changes made public, e.g., they
     are working on a security fix.  We are absolutely not going to
     ask these sorts of repositories be forced out in the open and if
     you are concerned about that we can work out some sort of written
     agreement to that effect.  We're very much committed to supporting
     open source development, in particular the Linux kernel and even
     more specifically Linus, he's a critical resource.

     The only people we're going after are those people who are clearly
     not part of the open source community.  We thought about saying we
     would only enforce this if they were working on source which did
     not have an open source license and rejected it for the following
     reason: there are commercial companies working on open source,
     using BitKeeper to do so, and not sharing their changes for as
     long as they can to get a competitive edge in the marketplace.
     There is nothing wrong with that under the terms of the GPL, but we
     don't have to support what we view as commercial activity for free.
     Open means open, it's about sharing, not money, in our opinion.

     It's a hard nut to crack, you can't just say "it's free if you are
     doing everything out in the open" because there are legit reasons
     for hiding.  There also commercial reasons for hiding and our view
     is that if that is what you are doing, you should be paying for
     the tools.  BK is free as a way to help people help each other.

4.4. Remove the $20,000 support clause.  We had a clause that said that we
     could shut you down if you cost us more than $20K in support.
     This was a widely hated clause and we're aware of that.  It was
     there as a way to try and shut down those people who were really
     commercial.  Since the previous change will effectively do that,
     we don't need this clause.  That removes the fear that we'll shut
     down bkbits or the kernel's use of BK.

That's it on the licensing stuff.  Since I'm here, here's some BK status.

We're in discussions with a very Linux friendly hosting service (4000
Linux servers hosted) to move bkbits.net and openlogging.org to their site
in exchange for BK licenses.  This should make the bkbits.net service
have more bandwidth and the benefit of a an extremely well connected
and well run hosting environment.  We don't need the bandwidth, BK is
super stingy with bandwidth, but it's cool to have bkbits.net in an
air conditioned, UPSed, multi peered environment instead of my office.
We're psyched about this, it's a good thing.

We're working on closing the first commercial deal which we can tie to the
use of BK by the kernel team.  If this actually happens, I'm going to take
$25K of the deal and "give" it to Linus as "BK bucks" which he can spend.
What means is that he has $25K to spend on BK features that he wants.
This is above and beyond stuff that we're doing already, it's a way
to give him the power to insist that we do some work that we wouldn't
do otherwise.  In general, we'd like to make a policy of doing this sort
of thing.  To date, we can't credit the open source use of BK with any
commercial business.  If that changes, that's good for us but it should 
also be good for the kernel.

--lm

Re: [Bitkeeper-announce] RFC: BK license change

[david parsons]

Larry McVoy wrote:
> 
> No, we're not GPLing it but we are making a few adjustments and wanted to
> make sure that it was an improvement, not a regression, in the eyes of
> the free users.  Sorry for the intrusion, I'll be as brief as possible.
> 

> 3(c) Maintaining Open Source.  Our intent was that the free use of
>      BitKeeper was for the purpose of helping the open source community;
>      it was not to provide commercial users a free product.  We have had
>      a number of cases where managers up to VPs have told their engineers
>      "just don't put anything useful in the checkin comments and then we
>      can use it for free".  Not what we had in mind.  So we're adding
>      a clause which says that we reserve the right to insist that you
>      make your repositories available on a public port within 15 days
>      of the request.

    This addendum is somewhat [1] annoying, because I switched over to
    BK for _everything_ a couple of years ago and now I've got a
    moderately large body of stuff that is NOT open source (my resume,
    my dns, little proofs of concept projects that I did for people.
    I've not made one red penny off any of this [particularly since the
    economy has gone south and put me out of work for the past year.
    But I'm still not opensourcing my resume.]) that's under bitkeeper.
    If I upgrade to a bk that uses the new license, then I get to play
    the exciting game of ``break the new license and defraud my former
    employers'' [2], which is about as appealing as Linus's alternative
    approach to resolving software patent issues.

                  ____
    david parsons \bi/ [1: pronounced ``extremely'']
                   \/  [2: or, alternatively, buy it, but this involves
			   bitmover actually telling me how much it would
			   cost AND having a job[3] so I could buy it.]
		       [3: The Oregon economy really sucks, so this is
			   filed under the category of ``sick jokes'' ]

Re: BKWeb Feature request [Was: BK license change]

[Larry McVoy]

> Is it possible somehow to sort the cset(s) according to the time they were
> applied to the local tree, and not when they were originally committed?

If this is a correct statement of what you want, we're building it:

    Instead of seeing events in time order of creation, you want to
    see the events in order of arrival in a particular repository.

I agree that the current view is useless when what you want to know is
when did this change finally make it into the tree?

We're working on a "stack" of incoming events.  BK/Web will use this to
give you the display you want and bk undo will be able to use this to
roll your repository backwards by "popping" the stack.  You could do

	while true
	do	bk undo -sf
	done

and when it gets done, you'll have no repository, it will have popped it
away.  bk unpull will just be come a special case of popping the stack.

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

BKWeb Feature request [Was: BK license change]

[Sam Ravnborg]

Hi Larry.

Speaking about Bitkeeper, I have a feature request.
The view of changesets on bkbits is usefull, but the sorting does not
give the full picture.

Follow this example:
bk pull http://linux.bkbits.net/linux-2.5
- Do some editing
- Check in changes
- Test the changes a few days
- Submit the cset(s) to Linus
Linus do a bk pull from my repository

When accessing bkbits via the web interface, the canges are listed
sorted after the time I did the modifications, not when Linus actually 
did the bk pull, so they may be preceeded by maybe 100 cset's.

Is it possible somehow to sort the cset(s) according to the time they were
applied to the local tree, and not when they were originally committed?

	Sam