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
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'' ]
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
> 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