There have been numerous flame wars and discussions on the lkml regarding the use of BitKeeper in Linux kernel development [story] [story] [story] [story] [story]. During one of these earlier wars, Linux creator Linus Torvalds explained his position, "Would I prefer to use a tool that didn't have any restrictions on it for kernel maintenance? Yes. But since no such tool exists, and since I'm personally not very interested in writing one, _and_ since I don't have any hangups about using the right tool for the job, I use BitKeeper."
BitKeeper is a source management tool provided under any of three licenses, one of which - the BKL - can make BitKeeper available for free (as in free beer). Tom Gall posted a question to the lkml when he noticed a clause in the BKL intended to prevent an individual or organization from using BitKeeper under this free license if they or their employer develops, produces, sells or resells a competing product. Yet another lengthy discussion followed.
Some contributers to this discussion seem to overlook two simple facts: First, that BitKeeper is also available under commercial (non-free) licensing, and second, that BitKeeper is and always has been primarily a commercial product (hence the sarcastic title of this article). Granted, the wording of any legal verbiage is open to interpretation, but as BitMover founder Larry McVoy [interview] has publicly interpreted this clause as "if you make or sell a competing product, you don't get to use ours for free", there seems little risk it can be used to attain other ends. In any case, for now Linus and many other Linux kernel developers have chosen to utilize BitKeeper in their efforts, and it is still possible to view the latest code (within 3 hours) without using BitKeeper via archives such as this one set up by Rik van Riel [interview].
That said, there are many interesting points raised during this discussion. Read on for the full thread...
Update (October 6 @ 9am EST): Hourly snapshots of the latest 2.5 development tree can also be found here on ftp.kernel.org. Linus sarcastically summarized complaints, "Big boo-hoo, bitkeeper is evil, and Linus doesn't manually do any more what BK plus a few scripts does better for us automatically."
From: tom_gall
To: linux-kernel
Subject: New BK License Problem?
Date: Fri, 4 Oct 2002 15:55:55 -0500
Greetings all,
I noticed Larry recently changed the license on bk. Once clause in
particular struck me and I thought I'd better point it out for your
reactions...
Specifically from Section 3:
(d) Notwithstanding any other terms in this License, this
License is not available to You if You and/or your
employer develop, produce, sell, and/or resell a
product which contains substantially similar capabil-
ities of the BitKeeper Software, or, in the reason-
able opinion of BitMover, competes with the BitKeeper
Software.
Doesn't this affect maintainers all across the map that work for
distros such as RedHat, SuSE, Connectiva, etc? Obviously these distros
SELL as part of their respective products CVS and similar tools. Or
even non-distro open source shops, you even resell CVS or the like in
some way and you'd be in trouble.
While I am all for Larry having a profitable business, this would seem
to be a change which is not Open Source developer friendly.
Regards,
Tom
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Fri, 4 Oct 2002 14:08:02 -0700
> I noticed Larry recently changed the license on bk. Once clause in
This isn't a recent change at all, I know it is at least 6 months old
because it was included in
BitKeeper version is bk-2.1.6-pre5 20020330075529 for x86-glibc22-linux
Built by: lm@redhat71.bitmover.com in /build/bk-2.1.x-lm/src
Built on: Sat Mar 30 00:14:45 PST 2002
> (d) Notwithstanding any other terms in this License, this
> License is not available to You if You and/or your
> employer develop, produce, sell, and/or resell a
> product which contains substantially similar capabil-
> ities of the BitKeeper Software, or, in the reason-
> able opinion of BitMover, competes with the BitKeeper
> Software.
>
> Doesn't this affect maintainers all across the map that work for
> distros such as RedHat, SuSE, Connectiva, etc? Obviously these distros
> SELL as part of their respective products CVS and similar tools. Or
> even non-distro open source shops, you even resell CVS or the like in
> some way and you'd be in trouble.
Distributions do not *SELL* CVS, they distribute CVS. We choose those
words with care for exactly that reason. All the clause is saying is
that if you are a competitor you don't get to use our product for free.
That it, in our opinion, a perfectly reasonable position to take.
> While I am all for Larry having a profitable business, this would seem
> to be a change which is not Open Source developer friendly.
The clause is specifically designed to target those companies which
produce or sell commercial SCM systems. That's why we explicitly
left out "distribute". The open source developers have nothing to
worry about.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: tom_gall
Subject: Re: New BK License Problem?
Date: Fri, 4 Oct 2002 16:33:30 -0500
On Friday, October 4, 2002, at 04:08 PM, Larry McVoy wrote:
>> (d) Notwithstanding any other terms in this License, this
>> License is not available to You if You and/or your
>> employer develop, produce, sell, and/or resell a
>> product which contains substantially similar capabil-
>> ities of the BitKeeper Software, or, in the reason-
>> able opinion of BitMover, competes with the BitKeeper
>> Software.
>>
>> Doesn't this affect maintainers all across the map that work for
>> distros such as RedHat, SuSE, Connectiva, etc? Obviously these
>> distros
>> SELL as part of their respective products CVS and similar tools. Or
>> even non-distro open source shops, you even resell CVS or the like in
>> some way and you'd be in trouble.
>
> Distributions do not *SELL* CVS, they distribute CVS.
Of course they sell CVS. I give them money, they give me a CD, that CD
has CVS on it.
If I have a support contract with that distro and CVS breaks they will
fix it.
I don't doubt if I went to the various distros with money in hand for
extra features for CVS they would put them in.
> We choose those
> words with care for exactly that reason. All the clause is saying is
> that if you are a competitor you don't get to use our product for free.
> That it, in our opinion, a perfectly reasonable position to take.
Yeah I understand what your intent is and I'm not flaming you. I have a
problem with the wording in that claus. Unfortunately you're not a
lawyer so your stated intent means little, it's the language in the
license that has meaning.
Regards,
Tom
From: Rob Landley
Subject: Re: New BK License Problem?
Date: Fri, 4 Oct 2002 20:50:06 -0400
On Friday 04 October 2002 05:33 pm, tom_gall wrote:
> Yeah I understand what your intent is and I'm not flaming you. I have a
> problem with the wording in that claus. Unfortunately you're not a
> lawyer so your stated intent means little, it's the language in the
> license that has meaning.
Actually, his stated intent means an awful lot, if you can get it in writing.
Which, thanks to the archived nature of this list, you have. (Remember, the
legal basis for contract law is just informed consent and the recording
thereof. The license itself is merely a formal and carefully worded version
of "what he said".)
A verbal contract may only be worth the paper it's printed on, but it IS
legally binding if you can prove it. And even relatively casual statements,
if recorded, can show up to haunt you in court later on.
Larry said who he wouldn't sue. If he then goes and sues them, these old
emails show in court and undercut his case in a big way. That's not a
guarantee in any judicial system that could let OJ off and give a million
dollars to a woman who spills McDonalds coffee on herself, but it's probably
about as good as you're going to get.
> Regards,
>
> Tom
Rob
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Fri, 4 Oct 2002 14:38:32 -0700
> > Distributions do not *SELL* CVS, they distribute CVS.
>
> Of course they sell CVS. I give them money, they give me a CD, that CD
> has CVS on it.
That's your opinion. That's not our opinion.
> Yeah I understand what your intent is and I'm not flaming you. I have a
> problem with the wording in that claus. Unfortunately you're not a
> lawyer so your stated intent means little, it's the language in the
> license that has meaning.
We're not changing the wording in the license just because you have a
problem with it. Unless some lawyer wants to explain to me why this
wording doesn't do what I want it to do, and unless I actually believe
they are operating in the best interests of BitMover, the language
stands as it is.
Unless you are competing with us you have no reason to be worried.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Dr. David Alan Gilbert
Subject: Re: New BK License Problem?
Date: Fri, 4 Oct 2002 23:16:39 +0100
* Larry McVoy (lm@bitmover.com) wrote:
> We're not changing the wording in the license just because you have a
> problem with it. Unless some lawyer wants to explain to me why this
> wording doesn't do what I want it to do, and unless I actually believe
> they are operating in the best interests of BitMover, the language
> stands as it is.
Just to be clear; does that term in the license affect a company, or its
employees, that is a competitor of yours if they use bitkeeper in a way
unrelated to the competition aspect?
So for example is an employee of a competitor or the competitor itself allowed
to download the linux kernel source using bitkeeper?
Lets take that previous question and split it into 2:
a) If they use the kernel source for something irrelevent to the
competing product.
b) If they use the kernel source for something relevent to the
competing product (e.g. if they were to take the kernel and produce a
proprietary module for accessing their system, or even just just use
the kernel on the server they happen to store their products source
on).
I'd definitly find it objectionable if (a) came under the license
conditions and a bit disturbing for (b).
Anyway, wouldn't you be flattered if a competitor decided to use
bitkeeper to store their code in?
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy
gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex /
_________________________|_____ http://www.treblig.org |_______/
From: Roman Zippel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 00:36:16 +0200 (CEST)
Hi,
On Fri, 4 Oct 2002, Dr. David Alan Gilbert wrote:
> Just to be clear;
... this is completely offtopic, can this _please_ be moved to a bk list?
Thanks.
bye, Roman
From: David S. Miller
Subject: Re: New BK License Problem?
Date: Fri, 04 Oct 2002 17:04:51 -0700 (PDT)
From: Roman Zippel
Date: Sat, 5 Oct 2002 00:36:16 +0200 (CEST)
On Fri, 4 Oct 2002, Dr. David Alan Gilbert wrote:
> Just to be clear;
... this is completely offtopic, can this _please_ be moved to a bk list?
Thanks.
It is very ontopic because it affects a number of kernel developers.
Whether you like BK or not, it is the primary source management tool
used by Linus and others, it is even documented in the source tree as
such.
Therefore, such a license change could change that, so it's a relavant
topic.
And finally, as the person who has to maintain this list and deal with
the daily bounce pool this list generates every day, I declare it as
ontopic so :-P~~~~~~
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Fri, 4 Oct 2002 17:32:16 -0700
> Whether you like BK or not, it is the primary source management tool
> used by Linus and others, it is even documented in the source tree as
> such.
>
> Therefore, such a license change could change that, so it's a relavant
> topic.
And in the "for what it is worth" department, when we contemplate changes
to the BKL, we've made a practice of discussing them here first. We try
and keep it to a minimum, it's not exactly a popular topic, but we also
make sure that we don't surprise anyone who is paying attention.
I know that some of our license decisions have been, err, less than
warmly received, but we are operating in good faith, we want to help
the kernel folks, and that policy hasn't changed and won't change as
long as I own more than 50% of BitMover stock (still do, working
hard to keep it so).
IBM recently became worried that they were violating the license and
we are working out a waiver for them because it is obvious that their
work is valued by the kernel community. It's a little weird because
I frequently argue against the SMP/NUMA stuff that IBM does, but that's
technical and BK licenses are business and I don't mix the two, that would
be both insane and unethical. So rest assured, all you IBMers and anyone
else who cares, IBM and BitMover are figuring out a way that all the
IBM hackers can keep on using BK if that's what they want. One hacker,
when told that they might not be able to use BK anymore, asked if she
could buy a copy with her own money. I haven't been told who that was
but when I find out, she gets a BK t-shirt and our undieing support.
That's what we like to see :)
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Roman Zippel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 12:26:49 +0200 (CEST)
Hi,
On Fri, 4 Oct 2002, David S. Miller wrote:
> It is very ontopic because it affects a number of kernel developers.
Does it? So far it was only a question and there are better places than
lkml to research it.
> Whether you like BK or not, it is the primary source management tool
> used by Linus and others, it is even documented in the source tree as
> such.
I don't care about bk and I wouldn't care about such questions either, if
Larry wouldn't use every such opportunity to publicly jerk off about bk.
bye, Roman
From: David S. Miller
Subject: Re: New BK License Problem?
Date: Sat, 05 Oct 2002 03:23:00 -0700 (PDT)
From: Roman Zippel
Date: Sat, 5 Oct 2002 12:26:49 +0200 (CEST)
I don't care about bk and I wouldn't care about such questions either, if
Larry wouldn't use every such opportunity to publicly jerk off about bk.
Pure comedy :-)
From: David S. Miller
Subject: Re: New BK License Problem?
Date: Fri, 04 Oct 2002 16:02:16 -0700 (PDT)
From: Larry McVoy
Date: Fri, 4 Oct 2002 14:08:02 -0700
The clause is specifically designed to target those companies which
produce or sell commercial SCM systems. That's why we explicitly
left out "distribute". The open source developers have nothing to
worry about.
I don't have any problems with what you're trying to achieve, but my
fear is that it doesn't even do that.
Nothing in your license changes stops someone from dark-room
duplicating bitkeeper. Just as clone Intel processors are sold
quite legally today. Intel lost their attempts to stop that and
my current guess is that you have a smaller legal representation
than Intel has :-)
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Fri, 4 Oct 2002 16:33:35 -0700
On Fri, Oct 04, 2002 at 04:02:16PM -0700, David S. Miller wrote:
> From: Larry McVoy
> Date: Fri, 4 Oct 2002 14:08:02 -0700
>
> The clause is specifically designed to target those companies which
> produce or sell commercial SCM systems. That's why we explicitly
> left out "distribute". The open source developers have nothing to
> worry about.
>
> I don't have any problems with what you're trying to achieve, but my
> fear is that it doesn't even do that.
>
> Nothing in your license changes stops someone from dark-room
> duplicating bitkeeper.
That's fine, if someone wants to redo it without using it, that's fair,
at least to the extent that it doesn't violate any IP rights. That's not
the problem we're solving. What we are saying is "If you make or sell
a competing product, you don't get to use ours for free". That's all.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: David S. Miller
Subject: Re: New BK License Problem?
Date: Fri, 04 Oct 2002 16:28:28 -0700 (PDT)
From: Larry McVoy
Date: Fri, 4 Oct 2002 16:33:35 -0700
What we are saying is "If you make or sell a competing product, you
don't get to use ours for free". That's all.
Ok, thanks for the clarification.
From: Ben Collins
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 13:54:37 -0400
> > (d) Notwithstanding any other terms in this License, this
> > License is not available to You if You and/or your
> > employer develop, produce, sell, and/or resell a
> > product which contains substantially similar capabil-
> > ities of the BitKeeper Software, or, in the reason-
> > able opinion of BitMover, competes with the BitKeeper
> > Software.
> >
> > Doesn't this affect maintainers all across the map that work for
> > distros such as RedHat, SuSE, Connectiva, etc? Obviously these distros
> > SELL as part of their respective products CVS and similar tools. Or
> > even non-distro open source shops, you even resell CVS or the like in
> > some way and you'd be in trouble.
>
> Distributions do not *SELL* CVS, they distribute CVS. We choose those
> words with care for exactly that reason. All the clause is saying is
> that if you are a competitor you don't get to use our product for free.
> That it, in our opinion, a perfectly reasonable position to take.
Larry, I develop for the Subversion project. Does that mean my license
to use bitkeeper is revoked?
I've also been wanting to use bitkeeper to create a Subversion mirror of
the kernel repository, but I suspect that my usage falls seriously into
this category, as my reasons for doing so are three-fold; allow access
to the bkbits repo to folks who don't want to use bk, but with all the
joys of an SCM (history, changesets, etc.); stress test Subversion
against a real-world high-activity repo; promote Subversion.
Would it be your intention that your license disallow my type of work? I
think it does.
Ben
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 11:25:52 -0700
On Sat, Oct 05, 2002 at 01:54:37PM -0400, Ben Collins wrote:
> Larry, I develop for the Subversion project. Does that mean my license
> to use bitkeeper is revoked?
Yes. It has been since we shipped that license or when you started working
on Subversion, whichever came last.
> I've also been wanting to use bitkeeper to create a Subversion mirror of
> the kernel repository, but I suspect that my usage falls seriously into
> this category, as my reasons for doing so are three-fold; allow access
> to the bkbits repo to folks who don't want to use bk, but with all the
> joys of an SCM (history, changesets, etc.); stress test Subversion
> against a real-world high-activity repo; promote Subversion.
>
> Would it be your intention that your license disallow my type of work? I
> think it does.
You bet it does. The Subversion folks would like nothing better than
to displace BK. That's fine, but they don't get to use BK to do it.
You're absolutely correct that you could use BK to make Subversion better.
It is not our job to help you make Subversion better and we've made that
clear for a long time.
We're a business. We're a business which happens to be committed to
helping the kernel team because we think that the kernel is vital to
the world at large. Helping the kernel absolutely does not translate
to helping people who happen to be our competitors. By your own
description and by our experience with you, you would be a competitor.
And since we're here, I'll take this opportunity to remind you that when I
asked about getting a netwinder so I could support the ARM folks, you were
the guy who sent me mail saying you had some that you weren't using and
that we couldn't have one because you didn't like our license. If I recall
it was either that mail exchange or a subsequent one in which you made it
clear that you were working on Subversion so Subversion could replace BK.
You're the guy that refused to help us help the community. And you made
it clear that you'd be delighted if Subversion was made good enough to
replace BK and you were working towards that goal. I can't imagine a
better example of someone who we absolutely do not want to support and
do not want using BK. I am explicitly stating that it is our view that
your use of BK is violation of our license.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Ben Collins
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 14:35:21 -0400
On Sat, Oct 05, 2002 at 11:25:52AM -0700, Larry McVoy wrote:
> On Sat, Oct 05, 2002 at 01:54:37PM -0400, Ben Collins wrote:
> > Larry, I develop for the Subversion project. Does that mean my license
> > to use bitkeeper is revoked?
>
> Yes. It has been since we shipped that license or when you started working
> on Subversion, whichever came last.
>
> > I've also been wanting to use bitkeeper to create a Subversion mirror of
> > the kernel repository, but I suspect that my usage falls seriously into
> > this category, as my reasons for doing so are three-fold; allow access
> > to the bkbits repo to folks who don't want to use bk, but with all the
> > joys of an SCM (history, changesets, etc.); stress test Subversion
> > against a real-world high-activity repo; promote Subversion.
> >
> > Would it be your intention that your license disallow my type of work? I
> > think it does.
>
> You bet it does. The Subversion folks would like nothing better than
> to displace BK. That's fine, but they don't get to use BK to do it.
> You're absolutely correct that you could use BK to make Subversion better.
> It is not our job to help you make Subversion better and we've made that
> clear for a long time.
Wow. You've got some bad memory, and some bad prejudice. Fact is, I've
heard many Subversion core developers say, and I quote, "If BK were
open-sourced, we'd just pack up and go home". Fact is, Subversion is not
geared to replace BK, nor has the Subversion team ever claimed it as
such. Fact is, the website clearly states it is a CVS replacement, which
is not on par with what BK does else BK would never have come into
existence.
Sure, let's dig up the old ARM thread we had almost a year ago in
private email and use it to fuel flames in a legitimate thread. Of
course I thought you were about business, yet suddenly this has turned
personal. Let's also not forget some of the helpful emails I've sent you
in private.
You've clearly made your point. I'll delete my copy of BK since I have
no legal license to use it. That's all I wanted to know.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
From: Lars Marowsky-Bree
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 20:41:53 +0200
On 2002-10-05T11:25:52,
Larry McVoy said:
> > I've also been wanting to use bitkeeper to create a Subversion mirror of
> > the kernel repository, but I suspect that my usage falls seriously into
> > this category, as my reasons for doing so are three-fold; allow access
> > to the bkbits repo to folks who don't want to use bk, but with all the
> > joys of an SCM (history, changesets, etc.);
Larry, could you please explain whether _this_ part is fine doing (even if not
by a subversion developer as per your license). Then someone (who wasn't
involved in building the gateway) can run it and not break your license.
I'd suggest that you need to have an interoperability clause for Open Source
software. Otherwise using BK for kernel development suddenly seems like a very
bad idea, because the community has suddenly been locked out of developing a
free SCM (ie, working on CVS, Subversion etc); he couldn't be an effective
kernel developer today (ie, using BK) and also continue working on the other
open source project...
You know I am rather fond of BK and your goals in general, but that would just
suck.
Sincerely,
Lars Marowsky-Br�e
--
Principal Squirrel
Research and Development, SuSE Linux AG
``Immortality is an adequate definition of high availability for me.''
--- Gregory F. Pfister
From: Ben Collins
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 15:06:38 -0400
> free SCM (ie, working on CVS, Subversion etc); he couldn't be an effective
> kernel developer today (ie, using BK) and also continue working on the other
> open source project...
I don't want to get the wrong point across. I don't use BK to do kernel
development. I live just fine without it, and my patches get accepted
just fine by Linus, Marcelo and DaveM. The Linux1394 project survives
using Subversion for our repository.
Now, other more serious kernel developers who have been using BK for
some time, may one day find they'd like to help a competing project.
They have to make a choice between the means that they develop for the
linux kernel and helping a project they have become interested in.
Suddenly all the kernel developers who have staked their work in BK
cannot work on a "competing" product to BK, without changing their
development model.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
From: Rik van Riel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 21:27:25 -0300 (BRT)
On Sat, 5 Oct 2002, Ben Collins wrote:
> I've also been wanting to use bitkeeper to create a Subversion mirror of
> the kernel repository,
You don't need to use bitkeeper for that, you can download all the
bitkeeper changesets as patches from my ftp site:
ftp://nl.linux.org/pub/linux/bk2patch/
cheers,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: september@surriel.com trac@trac.org
From: Ben Collins
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 20:32:17 -0400
On Sat, Oct 05, 2002 at 09:27:25PM -0300, Rik van Riel wrote:
> On Sat, 5 Oct 2002, Ben Collins wrote:
>
> > I've also been wanting to use bitkeeper to create a Subversion mirror of
> > the kernel repository,
>
> You don't need to use bitkeeper for that, you can download all the
> bitkeeper changesets as patches from my ftp site:
>
> ftp://nl.linux.org/pub/linux/bk2patch/
Oh, but that may be useless, unless you regenerate your patches whenever
the tree is reparented. I ran into this while trying to do the same
thing. Basing it on the ChangeSet ID is a waste, and it needs to be
based on the ChangeSet key instead (the ChangeSet ID for a given key can
change when a merge is done).
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
From: Rik van Riel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 21:53:17 -0300 (BRT)
On Sat, 5 Oct 2002, Ben Collins wrote:
> > ftp://nl.linux.org/pub/linux/bk2patch/
>
> Oh, but that may be useless, unless you regenerate your patches whenever
> the tree is reparented. I ran into this while trying to do the same
> thing. Basing it on the ChangeSet ID is a waste, and it needs to be
> based on the ChangeSet key instead (the ChangeSet ID for a given key can
> change when a merge is done).
Good point. I'll need to look at this more closely...
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: september@surriel.com trac@trac.org
From: Ulrich Drepper
Subject: Re: New BK License Problem?
Date: Sat, 05 Oct 2002 12:24:12 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ben Collins wrote:
> Suddenly all the kernel developers who have staked their work in BK
> cannot work on a "competing" product to BK, without changing their
> development model.
Not only this, it gets worse.
In my case it is almost impossible to not get involved in many many free
software projects. gettext or i18n in general, of glibc related issues
pop up everywhere and often I contribute patches. Subversion is one of
the projects where this has been the case in the past.
According to my understanding this means I'm tainted (I've asked Larry
for confirmation).
Now the important part: I still have to work closely with kernel
developers. The npt work is one example: I had to check out Ingo latest
patches in the kernel every day. Now this isn't possible anymore without
a) me finding another route to get the latest kernel in realtime (which
still could be considered illegal since somebody else, for the expressed
purpose of making the result available to me, is using bk);
b) the kernel developers I work with not depending on bk anymore.
The second point is what is causing the trouble. Any team which wants
to use bk to synchronize the work is tainted by one single individual
being tainted.
I have never looked closer at bk than I had to be able to check out the
latest sources. I'm not doing any development with it and I'm not
checking in anything using bk.
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper ,-----------------' Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE9nzxc2ijCOnn/RHQRAkG5AKCUgMWoYGzb2Hb9kAMHntBLsLXu7ACgyNrA
f2LKpqNQu/nZn4COIBsLWm0=
=WQqn
-----END PGP SIGNATURE-----
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 12:43:21 -0700
> patches in the kernel every day. Now this isn't possible anymore without
Nonsense. There are all sorts of people who have taken the BK trees and
made the patch snapshots available on timely basis. Garzik's done it,
Woodhouse has done it, Rik has done it, I'm sure there are piles more.
The kernel is GPLed and we have no control of the kernel source. You
can get at the source just as easily as ever, in fact, I'm 99.9% sure
that your access is much better than it used to be because Linus makes
the changes available on bkbits much more often than he used to make
pre-patches and/or releases.
Yeah, if you want to try and make BK go away then the answer is that you
don't get the benefits of BK while you are trying to accomplish your goals.
That's not going to change, scream all you want. Those are the rules.
You have no grounds for complaint because anyone can do the bk export -tpatch
to get you the exact same patch you would have gotten if you had asked them
for it before they ever used BK. If you hate BK or the license or just want
to be traditional, our position is that you should be no worse off than you
would have been if the kernel wasn't in BK. What you are complaining about
is that you want access to the *improvements* in the development process
while you are working on tools which would damage the company who provided
those improvements. That's asking too much. You can live with what you
used to live with and work on competing products or you can benefit from the
new tools, but not both.
Our position is clear, it's not unreasonable, it affects very few kernel
developers, and it doesn't even make those developers any worse off than
they were before we showed up. All we are saying is that you don't get
to use our tools if you are trying to rewrite our tools. I don't care if
your name is Linus, Alan, or Ulrich, those rules are uniform for everyone.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Ulrich Drepper
Subject: Re: New BK License Problem?
Date: Sat, 05 Oct 2002 13:21:45 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Larry McVoy wrote:
>>patches in the kernel every day. Now this isn't possible anymore without
>
>
> Nonsense. There are all sorts of people who have taken the BK trees and
> made the patch snapshots available on timely basis.
That's not what I was talking about. It is not possible anymore to use
the same process we did. It is not possible anymore to react right away
on "Linus checked the patch in; try it.". It now requires serious
efforts. And it requires them repeatedly at various sites with people
who have the same problem. Requiring others to make patch I can apply
does not work since a) it would put extra burden on people who are
already overworked and b) the timezones make it often impossible to get
swift responses.
You mentioned rsync to replicate the archive and then use CSSC. Would
be fine with me. But: knowing how to set up rsync would probably
require me to look at all the bk infrastructure and mechanisms more than
I had to do in the whole time I was using bk the check out sources and
while doing this I probably once again violate your license.
And don't get me wrong: you have the right to use whatever license you
want. I don't complain about that. I just point out the problem so
that other don't run into the same problems after they started using bk
and in the hope that somebody sets up a service which allows checking
out the current sources in nearly the same time as they are available in
the bk repository without relying on bk (rsync, cvs, subversion, I don't
care how).
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper ,-----------------' Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE9n0nZ2ijCOnn/RHQRAvDpAJ0ZXkNJKMt+ExMUnwxbOOP9a3xAxgCgwiwX
U+zaoRwM9UVwsJedk/IysVg=
=RTrB
-----END PGP SIGNATURE-----
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 16:28:52 -0700
> That's not what I was talking about. It is not possible anymore to use
> the same process we did. It is not possible anymore to react right away
> on "Linus checked the patch in; try it.".
Because Linus is using BK it is easier for him to make his work in
progress available, so he does. Before he was using BK, you got a
snapshot when he put up for ftp. It is an absolute fact that Linus
tree is far more quickly available, via regular patches or BK, than
it was before he used BK.
If he stopped using BK then you'd be back to the old patch availablity.
If he used Subversion or CVS or Perforce or whatever, because of how
those systems work, I'm positive that you'd see his publish rate drop.
BK makes it really easy to do what Linus is doing. If he had to manage
the same set of things using traditional branching techniques then
he'd publish less because it would be harder to do so.
The bottom line is that the use of BK is giving you faster access to the
data you want, in whatever form you want. So I fail to see the problem.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Alan Cox
Subject: Re: New BK License Problem?
Date: 06 Oct 2002 00:50:27 +0100
On Sun, 2002-10-06 at 00:28, Larry McVoy wrote:
> Because Linus is using BK it is easier for him to make his work in
> progress available, so he does. Before he was using BK, you got a
> snapshot when he put up for ftp. It is an absolute fact that Linus
> tree is far more quickly available, via regular patches or BK, than
> it was before he used BK.
Linus used to do about a patch every 2 days. Nowdays its a lot slower. I
put that down to buttkeeper
From: Alexander Viro
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 19:44:22 -0400 (EDT)
On 6 Oct 2002, Alan Cox wrote:
> On Sun, 2002-10-06 at 00:28, Larry McVoy wrote:
> > Because Linus is using BK it is easier for him to make his work in
> > progress available, so he does. Before he was using BK, you got a
> > snapshot when he put up for ftp. It is an absolute fact that Linus
> > tree is far more quickly available, via regular patches or BK, than
> > it was before he used BK.
>
> Linus used to do about a patch every 2 days. Nowdays its a lot slower. I
> put that down to buttkeeper
Rik's snapshots are once every 2 hours, IIRC...
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 16:53:16 -0700
On Sun, Oct 06, 2002 at 12:50:27AM +0100, Alan Cox wrote:
> On Sun, 2002-10-06 at 00:28, Larry McVoy wrote:
> > Because Linus is using BK it is easier for him to make his work in
> > progress available, so he does. Before he was using BK, you got a
> > snapshot when he put up for ftp. It is an absolute fact that Linus
> > tree is far more quickly available, via regular patches or BK, than
> > it was before he used BK.
>
> Linus used to do about a patch every 2 days. Nowdays its a lot slower. I
> put that down to buttkeeper
He may put up a patch for ftp less frequently, I haven't watched that.
He is publishing an average of 39 changesets/day, 7 days a week,
365 days/year based on the number of changesets in the tree as of a
minute ago. Some percentage of those are merge changesets which you
would probably not count, I checked and it looks like about 15%, round
it up to 20%, that's still 31/day. If you assume he's working 5 days
a week, it's more like 44/day. That's a patch accepted every 11 minutes.
Let's say I've screwed up my math somewhere, I'll give you a factor of 3,
that's still a couple of patches an hour. 40 hours a week.
Anyway, we have the BK data, if you have data that says the rate of change
has gone down since he started using BK, let's see it. If all you are
saying is that he isn't publishing ftp-able snapshots every hour, that's
a problem that HPA or whoever could easily fix with a shell script.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Linus Torvalds
Subject: Re: New BK License Problem?
Date: Sun, 6 Oct 2002 05:50:50 +0000 (UTC)
In article Alan Cox wrote:
>
>Linus used to do about a patch every 2 days. Nowdays its a lot slower. I
>put that down to buttkeeper
Don't be silly, Alan.
I don't do any pre-patches or daily patches any more, because it's all
automated. There are several snapshot bots that give you patches a lot
more often than "every 2 days". You don't need BK to use it, it's there
in the good old diff format.
(I haven't checked whether the auto-patches do a good job of doing
changelogs too, but since all the changelogs I generate for the _real_
releases are also automated and I make the tools I use to generate them
available, that's certainly not anything fundamental).
So yes, you can "put it down to bitkeeper" in the sense that it's
because of the automation that BK allows that I don't _need_ to
personally do pre-patches any more.
"Big boo-hoo, bitkeeper is evil, and Linus doesn't manually do any more
what BK plus a few scripts does better for us automatically."
Linus
From: Rik van Riel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 21:49:55 -0300 (BRT)
On 6 Oct 2002, Alan Cox wrote:
> Linus used to do about a patch every 2 days. Nowdays its a lot slower. I
> put that down to buttkeeper
Linus snapshots are available on a 3-hourly basis from:
ftp://nl.linux.org/pub/linux/bk2patch/
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: september@surriel.com trac@trac.org
From: Ingo Molnar
Subject: Re: New BK License Problem?
Date: Sun, 6 Oct 2002 13:04:39 +0200 (CEST)
On 6 Oct 2002, Alan Cox wrote:
> Linus used to do about a patch every 2 days. Nowdays its a lot slower.
> [...]
it's actually much different, and the patch flux has not only became much
larger (compare the current _per day_ patch flux with the one from one
year ago), it has also become more consistent. The 'trivial' patches get
in much more consistently, many subsystems have become more uptodate than
in eg. the 2.3 kernel days. And for people to keep posting stuff they need
dependability. Also, it's easier to get core stuff in these days because
1) the kernel is 'frozen' much more rarely 2) it's much easier for Linus
to just unroll bad stuff. Plus the BK tools to look at a piece of source
code's evolution over time are really nice and useful when trying to sync
up with some code one has not seen for a couple of weeks.
but i share some of your fundamental concerns. As much as i like Larry the
person, Larry the businessman is apparently a distinct entity. I remember
when moving the kernel tree over to BK was raised first time (it was not
even called bitkeeper back in that time), Larry talked about some sort of
guarantees that involve GPL-ing of BK code 1-2 years after it's first used
by the kernel, to make sure the Linux kernel tree is not left in limbo.
Today we are _very_ far away from such guarantees - and in fact i was
Cc:-ed on a mail in where kernel.org's admin got flamed by Larry with "you
get what you pay for" when he simply asked for a .rpm version of the
binary-only bk stuff so that it becomes easier to maintain. Larry, do you
have any plans to GPL the BK code at any future date?
And i'm not sure what Larry the businessman would say to a $100m
acquisition offer today. Or a $200m one, or a $500m one. Based on Larry's
past comments we have to assume that "yes" would be the answer - because
he has employees who have kids to be fed, etc.
So i believe the hard point of no return is the day the commit metadata
becomes proprietary, either via using a proprietary format, or via getting
a patent awarded. (it isnt right now, despite increasing centralization.)
That would be the time Ingo the kernel hacker would definitely say 'no' to
BK. (despite of what Ingo the person thinks about Larry the person.)
i'm also a bit worried about the legal status of commit messages posted
via bkbits. Are they GPL-ed automatically, can we just take them and put
them into a free-BK type server? We already have one precedent of a
business entity abusing a free OS project and then suing it (and winning
the suit), hindering the free OS's development for years.
and frankly, i find it very sobering how Larry (the businessman?) plays
down the fundamental and valid worries of the Linux community with "well
you get what you pay for" type of arguments. There are tons of other
businesses in the world that would 'pay' alot more than a free server, a
T1 line, and "ask nicely enough and be prepared to be flamed when you are
asking for too much" kind of free support, for the big PR-advantage of
hosting the Linux kernel tree. Occasionally i ask myself whether the
significant de-loading of Linus' patch management work is worth the
increasing feeling of ... humiliation this causes.
Ingo
From: Nicolas Pitre
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 15:47:09 -0400 (EDT)
On Sat, 5 Oct 2002, Ulrich Drepper wrote:
> I have never looked closer at bk than I had to be able to check out the
> latest sources. I'm not doing any development with it and I'm not
> checking in anything using bk.
What about Larry making available a special version of BK that would only be
able to perform checkouts?
This special version could have a less controversial license, even be GPL
with source. This only to provide a tool to extract data out of public BK
repositories (like Linus' kernel repository) for people who don't intend or
aren't willing to actually use the real value of the full fledged BK.
Nicolas
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 12:54:12 -0700
On Sat, Oct 05, 2002 at 03:47:09PM -0400, Nicolas Pitre wrote:
> On Sat, 5 Oct 2002, Ulrich Drepper wrote:
>
> > I have never looked closer at bk than I had to be able to check out the
> > latest sources. I'm not doing any development with it and I'm not
> > checking in anything using bk.
>
> What about Larry making available a special version of BK that would only be
> able to perform checkouts?
>
> This special version could have a less controversial license, even be GPL
> with source. This only to provide a tool to extract data out of public BK
> repositories (like Linus' kernel repository) for people who don't intend or
> aren't willing to actually use the real value of the full fledged BK.
You can do this today. rsync a BK tree and use GNU CSSC to check out
the sources. We maintained SCCS compat for exactly that reason.
You've had the ability to ignore the BKL since day one if you aren't
running the BK binaries.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 12:56:24 -0700
On Sat, Oct 05, 2002 at 12:54:12PM -0700, Larry McVoy wrote:
> On Sat, Oct 05, 2002 at 03:47:09PM -0400, Nicolas Pitre wrote:
> > On Sat, 5 Oct 2002, Ulrich Drepper wrote:
> >
> > > I have never looked closer at bk than I had to be able to check out the
> > > latest sources. I'm not doing any development with it and I'm not
> > > checking in anything using bk.
> >
> > What about Larry making available a special version of BK that would only be
> > able to perform checkouts?
> >
> > This special version could have a less controversial license, even be GPL
> > with source. This only to provide a tool to extract data out of public BK
> > repositories (like Linus' kernel repository) for people who don't intend or
> > aren't willing to actually use the real value of the full fledged BK.
>
> You can do this today. rsync a BK tree and use GNU CSSC to check out
> the sources. We maintained SCCS compat for exactly that reason.
> You've had the ability to ignore the BKL since day one if you aren't
> running the BK binaries.
Whoops, forgot one thing. Take the GNU CSSC sources, they look for
^Ah%05un
at the top of the file. Make them accept both "h" and "H" and then it will
work. We changed it so that ATT SCCS would overwrite our metadata.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Rik van Riel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 21:34:18 -0300 (BRT)
On Sat, 5 Oct 2002, Ulrich Drepper wrote:
> a) me finding another route to get the latest kernel in realtime
ftp://nl.linux.org/pub/linux/bk2patch/
> (which still could be considered illegal since somebody else, for the
> expressed purpose of making the result available to me, is using bk);
Good question, does Larry have any objections to people
exporting stuff from bitkeeper as patches and making those
patches available for download ? ;)
I'm pretty sure he doesn't, since Linus and Marcelo are
doing exactly this.
> b) the kernel developers I work with not depending on bk anymore.
>
> The second point is what is causing the trouble. Any team which wants
> to use bk to synchronize the work is tainted by one single individual
> being tainted.
I haven't found this to be any problem at all with -rmap, I
happily accept patches from both bitkeeper users and non-users.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: september@surriel.com trac@trac.org
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 17:45:32 -0700
> Good question, does Larry have any objections to people
> exporting stuff from bitkeeper as patches and making those
> patches available for download ? ;)
>
> I'm pretty sure he doesn't, since Linus and Marcelo are
> doing exactly this.
Right. I'd make a fuss if it were someone who was also working on
Subversion, yeah, for the obvious reasons. That's why that clause
is in there. On the other hand, if Ben was ftping all the csets from
your machine and shoving them into Subversion there isn't a darn thing
I can do about it, it's not my data. So you're fine.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 12:15:27 -0700
> I'd suggest that you need to have an interoperability clause for Open Source
> software. Otherwise using BK for kernel development suddenly seems like a very
> bad idea, because the community has suddenly been locked out of developing a
> free SCM (ie, working on CVS, Subversion etc); he couldn't be an effective
> kernel developer today (ie, using BK) and also continue working on the other
> open source project...
>
> You know I am rather fond of BK and your goals in general, but that would just
> suck.
BitKeeper is a *business*. What you are saying is "it would suck if
you wouldn't allow the use of BitKeeper in the development of products
which would make that business die."
It may suck that Ben can't use BK to try and put BK out of business.
It would suck a whole lot worse, in our view, to allow him to do so.
I'm sympathetic to the fact that this means that people who are both
working on the kernel and competing with us can't use BK, that does suck.
But we thought of that, that's why BK is so friendly to external systems,
it's why BK is happy to both import and export regular patches. If you
think about it, Ben is absolutely no worse off than he was before BK
was used. He can get the same patches he always got. He can work the
same way he always did. The only thing that has changed from Ben's point
of view is that Linus is a little less stressed out and somewhat less
likely to drop a patch. It's a net positive for Ben. Not as big of
one as being able to use BK, perhaps, but it hasn't hurt Ben's ability
to contribute to the kernel one iota.
It's Ben's choice to compete with us. Yes, we're forcing you to choose
between competing with us or using BK as a way of contributing to
the kernel. I could see that that would suck if Linus refused to take
regular patches, or even if he slowed down on taking regular patches.
But he doesn't, he hasn't, he's actually sped up. And he's committed
to taking regular patches, there are people out there who oppose the
BKL on grounds that they want a completely free tool chain. Both
Linus and I respect that, take a look at bk-3.0 when it comes out,
it's got much improved (both performance and reliability) GNU patch
import abilities. We've spent money to support people who don't
want to use BK, it's not just lip service.
I'm not against people having a go at reimplementing BK. But you had
better believe that I'm against helping them, they are actively trying to
destroy our company. No company is under any obligation, moral, ethical,
or legal, to be self destructive when they are doing nothing wrong.
What you are saying is that it sucks that we don't want to help put
ourselves out of business. If that sucks, so be it.
I think some people here are under the mistaken impression that BK is
my hobby sort of like LMbench was my hobby. It's not a hobby. It's a
business. It would take medium sized bus to hold all the people who
depend on BK for their livelihood. What you are asking for is for us
to allow and aid in work which would materially damage our business.
That's nuts, it's absolutely out of the question, it's way past the
point of being a reasonable thing to expect. If you can't see that,
I'm sorry, but that's the way it is.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: jbradford
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 20:46:57 +0100 (BST)
> The only thing that has changed from Ben's point of view is that Linus
> is a little less stressed out and somewhat less likely to drop a patch.
#if defined(sense_of_humor)
Plus the fact that his inbox is probably overflowing because of this thread ;-).
Sorry, I couldn't resist that one :-).
#endif
John.
From: Hans Reiser
Subject: Re: New BK License Problem?
Date: Sat, 05 Oct 2002 17:10:33 +0400
tom_gall wrote:
> Greetings all,
>
> I noticed Larry recently changed the license on bk. Once clause in
> particular struck me and I thought I'd better point it out for your
> reactions...
>
> Specifically from Section 3:
>
> (d) Notwithstanding any other terms in this License, this
> License is not available to You if You and/or your
> employer develop, produce, sell, and/or resell a
> product which contains substantially similar capabil-
> ities of the BitKeeper Software, or, in the reason-
> able opinion of BitMover, competes with the BitKeeper
> Software.
>
Seems like a pretty straightforward violation of the anti-trust laws,
and a conspiracy to restrain trade. Hope Larry votes for Bush's
reelection, cause Bush judges will keep Larry safe from the law on this
for sure.
Hans
From: Murray J. Root
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 18:53:10 -0400
On Sat, Oct 05, 2002 at 05:10:33PM +0400, Hans Reiser wrote:
> tom_gall wrote:
>
> >Greetings all,
> >
> >I noticed Larry recently changed the license on bk. Once clause in
> >particular struck me and I thought I'd better point it out for your
> >reactions...
> >
> >Specifically from Section 3:
> >
> > (d) Notwithstanding any other terms in this License, this
> > License is not available to You if You and/or your
> > employer develop, produce, sell, and/or resell a
> > product which contains substantially similar capabil-
> > ities of the BitKeeper Software, or, in the reason-
> > able opinion of BitMover, competes with the BitKeeper
> > Software.
> >
> Seems like a pretty straightforward violation of the anti-trust laws,
> and a conspiracy to restrain trade. Hope Larry votes for Bush's
> reelection, cause Bush judges will keep Larry safe from the law on this
> for sure.
>
Yup - a blatant and outright violation.
Worse - it's also illegal to refuse to do business with someone
based on who their employer is, in most states.
Also - it's an attempt to restrict first-purchase rights. Most courts
have found such clauses to be unenforcable in standard contracts - I doubt
a shrink-wrap license is gonna fare any better.
--
Murray J. Root
------------------------------------------------
DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/
------------------------------------------------
Mandrake on irc.freenode.net:
#mandrake & #mandrake-linux = help for newbies
#mdk-cooker = Mandrake Cooker
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 16:21:44 -0700
On Sat, Oct 05, 2002 at 06:53:10PM -0400, Murray J. Root wrote:
> > Seems like a pretty straightforward violation of the anti-trust laws,
> > and a conspiracy to restrain trade. Hope Larry votes for Bush's
> > reelection, cause Bush judges will keep Larry safe from the law on this
> > for sure.
> >
> Yup - a blatant and outright violation.
Then by all means, file a lawsuit if that's what you feel.
> Worse - it's also illegal to refuse to do business with someone
> based on who their employer is, in most states.
Err, this is the BKL, no money is changing hands. I'm pretty sure that
the courts will let us decide under what terms we allow people to use
our software for free.
> Also - it's an attempt to restrict first-purchase rights.
No, this is the BKL. There is no such clause in the BKCL.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Murray J. Root
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 19:49:33 -0400
On Sat, Oct 05, 2002 at 04:21:44PM -0700, Larry McVoy wrote:
> On Sat, Oct 05, 2002 at 06:53:10PM -0400, Murray J. Root wrote:
> > > Seems like a pretty straightforward violation of the anti-trust laws,
> > > and a conspiracy to restrain trade. Hope Larry votes for Bush's
> > > reelection, cause Bush judges will keep Larry safe from the law on this
> > > for sure.
> > >
> > Yup - a blatant and outright violation.
>
> Then by all means, file a lawsuit if that's what you feel.
>
My only intent is to offer potential defenses should you choose to
go after any kernel hackers. Beyond that - I don't care. Put whatever
you want into the license.
--
Murray J. Root
------------------------------------------------
DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/
------------------------------------------------
Mandrake on irc.freenode.net:
#mandrake & #mandrake-linux = help for newbies
#mdk-cooker = Mandrake Cooker
From: Rik van Riel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 21:48:25 -0300 (BRT)
On Sat, 5 Oct 2002, Murray J. Root wrote:
> On Sat, Oct 05, 2002 at 05:10:33PM +0400, Hans Reiser wrote:
> > Seems like a pretty straightforward violation of the anti-trust laws,
> Worse - it's also illegal to refuse to do business with someone
> based on who their employer is, in most states.
Bitkeeper isn't refusing business. They just refuse to give away
their product for free to competitors, but these competitors can
still ask Bitkeeper for the normal commercial license ...
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: september@surriel.com trac@trac.org
From: walt
Subject: Re: New BK License Problem?
Date: Sat, 05 Oct 2002 07:30:17 -0700
Hans Reiser wrote:
> tom_gall wrote:
>
>> Greetings all,
>>
>> I noticed Larry recently changed the license on bk. Once clause in
>> particular struck me and I thought I'd better point it out for your
>> reactions...
>>
>> Specifically from Section 3:
>>
>> (d) Notwithstanding any other terms in this License, this
>> License is not available to You if You and/or your
>> employer develop, produce, sell, and/or resell a
>> product which contains substantially similar capabil-
>> ities of the BitKeeper Software, or, in the reason-
>> able opinion of BitMover, competes with the BitKeeper
>> Software.
>>
> Seems like a pretty straightforward violation of the anti-trust laws,
> and a conspiracy to restrain trade...
I Am Not A Lawyer, but AFAIK the anti-trust laws in no way obligate
a business to aid its own competitors.
Restraint of trade occurs when two competitors conspire to crush a
third competitor. Who is Larry's co-conspirator in your scenario?
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 08:10:39 -0700
I can tell that this issue isn't going away quickly so here are some
thoughts.
If the only thing that happens is a pile of complaints about how bad
the license is, the license isn't going to change.
Try and think about this from our point of view. We provide a complex
yet useful product for free. While doing so accomplishes our goal of
helping the kernel community, it also puts us at far greater risk that
someone will just reimplement the software. Creating this software
was quite difficult and we are not in the business of providing a
roadmap to our competitors, they get to find their own way.
If you want to suggest license changes do so showing that you understand
why we did what we did and show how your changes accomplish that in
a better way. Suggestions like "you guys are idiots, just GPL it and
you can make money from support" just get ignored. Suggestions which
increase, rather than decrease, our risk also get ignored.
If someone has a magic way of saying "you can use the software if and
only if your use of it does not put BitMover at financial risk" I'd
love to hear it. So far, however, what I'm hearing is "your license
screws me and I want you to change it". I hear your complaints,
but they are just noise because they are one-sided.
There are other ways to work out the problem. For example, the
openlogging stuff doesn't work for researchers. We make a standard
practice of providing waivers to institutions or groups who are doing
pure research (not work for hire for BigFatCompany, Inc). There is no
reason we can't do that for you for the non-compete clause. We're
in the process of developing that language for IBM's Linux Technology
Center, we can reuse it for anyone else.
Unless someone can come up with language which protects us, the license
stands as is. We'll do waivers for kernel developers who happen to
work at Rational or whatever as needed. It's no different than dealing
with patents by Red Hat or whoever, if you are concerned about it, you
can ask us to make our intentions clear to you personally in writing.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: tom_gall
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 10:57:57 -0500
On Saturday, October 5, 2002, at 10:10 AM, Larry McVoy wrote:
> I can tell that this issue isn't going away quickly so here are some
> thoughts.
I think it can go away quickly. It just a matter of how you want to
address it.
> If the only thing that happens is a pile of complaints about how bad
> the license is, the license isn't going to change.
The license on the whole is a good license. It's just that one claus
the gives me pause.
> Try and think about this from our point of view. We provide a complex
> yet useful product for free. While doing so accomplishes our goal of
> helping the kernel community, it also puts us at far greater risk that
> someone will just reimplement the software. Creating this software
> was quite difficult and we are not in the business of providing a
> roadmap to our competitors, they get to find their own way.
And that's perfectly fair. However as worded in your license today, the
individuals who work for those companies and have nothing to do with
the competitive software you are worried about can't use your product
to work on open source software.
If we can fix this problem somehow, I would be a very happy camper.
> If you want to suggest license changes do so showing that you
> understand
> why we did what we did and show how your changes accomplish that in
> a better way. Suggestions like "you guys are idiots, just GPL it and
> you can make money from support" just get ignored. Suggestions which
> increase, rather than decrease, our risk also get ignored.
How about this:
(d) Notwithstanding any other terms in this License, this License *MAY*
not
be available to you if you and / or your employer develop, produce,
sell,
and/or resell a product which contains substantially similar
capabilities
of the BitKeeper Software or in the reasonable opinion of BitMover,
competes
with the BitKeeper Software.
For those individuals who work on Open Source Software, that is software
as defined by being under a license meeting the Open Source Definition
as
defined on www.opensource.org, may apply for a waiver to
<someuserATbitmover.com>
stating
1) Which company they work for
2) Which Open Source Project(s) they are going to be using the
Bitkeeper software for
3) Identify if they are working on this project in their "free" time or
as part of their
job definition
If granted the waiver will only cover the stated Open Source project(s)
you have named. If you expand your use of the BitKeeper software to
other Open Source project(s) you will need to apply for a waiver for
those project(s) as well.
> There are other ways to work out the problem. For example, the
> openlogging stuff doesn't work for researchers. We make a standard
> practice of providing waivers to institutions or groups who are doing
> pure research (not work for hire for BigFatCompany, Inc). There is no
> reason we can't do that for you for the non-compete clause. We're
> in the process of developing that language for IBM's Linux Technology
> Center, we can reuse it for anyone else.
It is good to hear that you're open to being flexible. I hope that
might include
this case as well.
> Unless someone can come up with language which protects us, the license
> stands as is. We'll do waivers for kernel developers who happen to
> work at Rational or whatever as needed.
Well if you would, please have a read, Hopefully my idea sounds
reasonable to you.
Thanks
Tom
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 16:44:06 -0700
> And that's perfectly fair. However as worded in your license today, the
> individuals who work for those companies and have nothing to do with
> the competitive software you are worried about can't use your product
> to work on open source software.
Yes, that's true. But that doesn't mean we can't make exceptions, we can
and do.
> defined on www.opensource.org, may apply for a waiver to
>
> stating
> 1) Which company they work for
> 2) Which Open Source Project(s) they are going to be using the
> Bitkeeper software for
> 3) Identify if they are working on this project in their "free" time or
> as part of their
> job definition
>
> If granted the waiver will only cover the stated Open Source project(s)
> you have named. If you expand your use of the BitKeeper software to
> other Open Source project(s) you will need to apply for a waiver for
> those project(s) as well.
If *I* had suggested this language I would have been flamed off the face
of the earth. The people who are complaining the loudest are complaining
that BitKeeper limits their choices or takes their freedom away or whatever.
They absolutely *despise* any sort of authority figure and the idea of
coming begging to BitMover for a waiver each time just makes them crazy.
That said, what you outlined is more or less our current practice anyway.
It's not clear to me that changing the license in any way other than
GPLing it will shut up the whiners, so my preference is to leave it the
way it is and let you ask for a waiver. The effect is the same both ways.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Rik van Riel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 21:19:41 -0300 (BRT)
On Sat, 5 Oct 2002, Larry McVoy wrote:
> If someone has a magic way of saying "you can use the software if and
> only if your use of it does not put BitMover at financial risk"
The main complaint I've heard now is "if I develop a product
that competes with bitkeeper, won't I be able to grab any more ??"
A fix for this would be "make patches available from bkbits.net".
This way everybody can still get the free software, they just
won't have the benefits of bitkeeper's version control or other
nice luxuries.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: september@surriel.com trac@trac.org
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 17:30:57 -0700
On Sat, Oct 05, 2002 at 09:19:41PM -0300, Rik van Riel wrote:
> On Sat, 5 Oct 2002, Larry McVoy wrote:
> > If someone has a magic way of saying "you can use the software if and
> > only if your use of it does not put BitMover at financial risk"
>
> The main complaint I've heard now is "if I develop a product
> that competes with bitkeeper, won't I be able to grab software project available in BK> any more ??"
>
> A fix for this would be "make patches available from bkbits.net".
bkbits.net is a free service. It costs us about $1600/month in cash
to run it, that doesn't count any salaries, that's just fixed costs.
If rsync and/or ftp didn't use about 100x as much bandwidth to do what
BK does we'd have already done what you are asking. We simply can't
afford it.
But as I said to someone else, why doesn't someone register "nobkbits.net"
and use BK to mirror the repos and then provide the tarballs/patches as
you see fit.
I'm quite happy to help someone set this up, I'm just not willing to
foot the bill. The bandwidth costs will kill you. kernel.org could
do this and that would be fine with me.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Rik van Riel
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 21:51:58 -0300 (BRT)
On Sat, 5 Oct 2002, Larry McVoy wrote:
> On Sat, Oct 05, 2002 at 09:19:41PM -0300, Rik van Riel wrote:
> > The main complaint I've heard now is "if I develop a product
> > that competes with bitkeeper, won't I be able to grab > software project available in BK> any more ??"
> >
> > A fix for this would be "make patches available from bkbits.net".
>
> bkbits.net is a free service. [snip good arguments]
> But as I said to someone else, why doesn't someone register
> "nobkbits.net" and use BK to mirror the repos and then provide the
> tarballs/patches as you see fit.
I can do this on NL.linux.org. I'm already doing it for the
2.4 and 2.5 Linux kernel trees and am willing to run the script
for other bitkeeper trees too.
If people want it, just let me know.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: september@surriel.com trac@trac.org
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 17:53:49 -0700
> > > A fix for this would be "make patches available from bkbits.net".
> >
> > bkbits.net is a free service. [snip good arguments]
>
> > But as I said to someone else, why doesn't someone register
> > "nobkbits.net" and use BK to mirror the repos and then provide the
> > tarballs/patches as you see fit.
>
> I can do this on NL.linux.org. I'm already doing it for the
> 2.4 and 2.5 Linux kernel trees and am willing to run the script
> for other bitkeeper trees too.
>
> If people want it, just let me know.
If this turns into a serious thing we could polish up the bkbits.net
infrastructure and provide it with one extra URL that lets you get
gnu style patches. I already have the code for this, I just have it
disabled for bandwidth reasons.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Robert Love
Subject: Re: New BK License Problem?
Date: 05 Oct 2002 21:00:04 -0400
On Sat, 2002-10-05 at 20:53, Larry McVoy wrote:
> If this turns into a serious thing we could polish up the bkbits.net
> infrastructure and provide it with one extra URL that lets you get
> gnu style patches. I already have the code for this, I just have it
> disabled for bandwidth reasons.
So are you saying I could look at Linus's tree on bkbits.net and click
on a changeset and get a GNU diff?
That would be amazingly good of you, Larry.
Robert Love
From: Hans Reiser
Subject: Re: New BK License Problem?
Date: Sat, 05 Oct 2002 20:18:51 +0400
walt wrote:
> Hans Reiser wrote:
>
>> tom_gall wrote:
>>
>>> Greetings all,
>>>
>>> I noticed Larry recently changed the license on bk. Once clause in
>>> particular struck me and I thought I'd better point it out for your
>>> reactions...
>>>
>>> Specifically from Section 3:
>>>
>>> (d) Notwithstanding any other terms in this License, this
>>> License is not available to You if You and/or your
>>> employer develop, produce, sell, and/or resell a
>>> product which contains substantially similar capabil-
>>> ities of the BitKeeper Software, or, in the reason-
>>> able opinion of BitMover, competes with the BitKeeper
>>> Software.
>>>
>> Seems like a pretty straightforward violation of the anti-trust laws,
>> and a conspiracy to restrain trade...
>
>
> I Am Not A Lawyer, but AFAIK the anti-trust laws in no way obligate
> a business to aid its own competitors.
Read about the essential facilities doctrine.
>
>
> Restraint of trade occurs when two competitors conspire to crush a
> third competitor. Who is Larry's co-conspirator in your scenario?
>
>
> -
> 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/
>
>
A single company is considered a conspiracy under the anti-trust laws.
Hans
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 10:28:22 -0700
On Sat, Oct 05, 2002 at 08:18:51PM +0400, Hans Reiser wrote:
> >> Seems like a pretty straightforward violation of the anti-trust laws,
> >> and a conspiracy to restrain trade...
> >
> > I Am Not A Lawyer, but AFAIK the anti-trust laws in no way obligate
> > a business to aid its own competitors.
>
> Read about the essential facilities doctrine.
I'm not a lawyer either but I spend about 40% of my working hours on
legal issues, such as contracts and IP law. So I'm not uninformed
about the topic either.
In order for the essential facilities doctrine to apply, we have to
have control of some "essential facility". If anyone wants to bring
suit attempting to claim that we have control over such a facility, I
wish them luck. I'm pretty sure that if I claimed BK was such a thing
you'd all fall over laughing and so would a judge. That may change in
the future but for now, not a chance of a judge or a jury seeing it that
way, in my opinion. Feel free to sue if you feel differently.
It would be interesting case law since the suit would be over something
that we give away for free. Might not matter but then again it might.
I doubt the courts can compel a business to give away their products.
If we were a monopoly they could compel us to sell them but I really
don't see how a court could say "you have to give this away for free".
If anything, the courts seem to be going in the opposite direction.
There was an interesting case recently where the courts upheld that
it was illegal to take a competitor's product, play with it, and then
copy the features. It was an old case, the decision just came down,
but if we went to court over this stuff, that would be the first thing
we'd hold up as case law which supports our position.
Unlike the slashdot kiddies, the courts seem to recognize that the real
work is in the initial creation of a product, not in the replication of
that product. The courts are quite supportive of that point, as well
they should be. They tend to switch sides as one becomes a monopoly,
but as things stand to day, that is a problem that we'll worry about
if and when it happens. I have a feeling I'll be retired before then
so you can argue with someone else about it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Related Stories:
I like Linus's attitude
To these sorts of issues - making descisions on a purely technical note works well, makes him a pretty hard target for critisism and seems to keep a lid on the politics of kernel deveopment. You'll note Alan (and others) shoot off the mouth a bit because they are fanatics of GPL/opensource and it detracts from their image of course if everything stayed the same but the program was opensource then they'd be putting just as much time into defending it!
YALD - Yet ANOTHER License Dispute...
Microsoft may be an evil company, Linux is an evil product because it turns all of its users and developers into friggin lawyers.
Missing the point
After reading the above thread, I think that Larry is missing the point. Of course it is perfectly legitimate for Larry and BitMover to want to make money with BK, and of course it is also totally within their rights to add such clauses as the one being discussed to the BKL, but I think the initial question and many of the objections raised later on in the thread have to be examined from a different point of view.
Just like Larry and BitMover have certain interests, the kernel developers do have interests as well, and these interests do obviously conflict sometimes. From what I read, it seems that there are mainly two things that the kernel developers care about; on one hand, the ability to focus on actually coding the kernel and not having to deal with patch/release management any more than necessary (an interest which is certainly helped by sophisticated tools such as BK), and, on the other hand, to keep not only the kernel, but also its development free (as in freedom) - to allow anyone who's interested to participate in the development process, other things that person is doing nonwithstanding.
The problems with these conflicting interests become quite apparent in Larry's reply to one of the Subversion developers when that one asked whether his work on Subversion meant he was not allowed to use BK under the BKL anymore. While Larry does, at other times, argue that a) participating in kernel development has not become harder for those not allowed to use BK under the BKL since Linus (and others) began using BK for their repositories and b) that the possibility to sign a waiver to still be able to utilize BK for kernel development exists, his explanation that anyone who's working on Subversion (or, probably, any "competing" source management system) cannot use BK under the terms of the BKL illustrates that there is more to this whole issue than a company with a legitimate interest in staying in business and not helping out its competitors.
Finding a solution for this problem is not an easy task, obviously, and for now it seems to me that Linus' opinion (namely, that the benefits of using BK are worth making it more difficult for certain people to participate in kernel development) is a reasonable one, but it does leave a bad taste nonetheless. Excluding or at least making it harder for certain people to participate in kernel development simply because of the license of a proprietary tool used for said development can, in my opinion, not be acceptable in the long term.
--
schnee
Larry's point is that stoppi
Larry's point is that stopping some people from using BK doesn't make it harder for them, it just makes it 'not easier'. No one has said anything that I have seen to indicate that this is not the case.
How is using the traditional GNU tools harder or less effective now than it was pre-BK?
Making things not easier
Larry has stated that he doesn't have any issue with people exporting code from bitkeeper repositories in other repository formats.
There is no vendor lockin, people who don't want to use bitkeeper can still get access to the very latest source code. All they'll miss out on is the bitkeeper tool itself. This is fine with Larry, since there doesn't seem to be much competition to bitkeeper at the moment...
If bitkeeper was the only way to get the latest Linux kernel code there would be a problem, but there are many ways people can get the Linux kernel source without using bitkeeper.
For example, you can get the latest bitkeeper tree as a gnu patch since the latest tagged release, or rsync over the bitkeeper repository and access the files within using SCCS or CSSC. I'm running one of these "compatibility" repositories myself, at:
ftp://nl.linux.org/pub/linux/bk2patch/
BitKeeper Is A Commercial Product? But of course!
There is no doubt that BitKeeper is a commercial product; that is not what this dispute is about nor do I think anyone has a problem with that particular aspect of Bitkeeper per se. Rather, some people perceive BitKeeper as a proprietary product and all that that entails.
There are many commercial products which are also free software, among them GNU Privacy Guard. Please remember, the commercial software label does not preclude Free Software.
Neal
Re: BitKeeper Is A Commercial Product? But of course!
True, but only if you mean "free" as in "beer" - BK is definitely not free as in "freedom", and, what may be more important in this case, it cannot count as open source, either, because (apart from the obvious reasons, of course), the BKL violates terms 5 and 6 of the Open Source Definition, which prohibit discrimination against persons/groups or certain fields of endevaour, respectively.
Now, of course, I realize that noone really ever said BK was open source or even that it did not violate those terms; but simply being available for use without associated costs under terms of certain licenses does certainly not make software free, and I think BK is a prime example for this.
--
schnee
Re: BitKeeper Is A Commercial Product? But of course!
I never claimed that Bitkeeper is Free Software. My gripe is that the title of this article suggests that there is something inherently wrong with Commercial Software: there is none; the problem is with proprietary software, which Bitkeeper certainly is.
Neal
Re: BitKeeper Is A Commercial Product? But of course!
The title is self-proclaimed irony.
Call me slow
Sorry, I am a bit confused: where is the irony? Bitmover has always been commercial; this furor is about the proprietary nature of Bitkeeper. The two are completely different. Or is the irony in something else completely?
Thanks.
re: Call me slow
The title states the obvious, and at the same time it completely misses the point. Intentionally.
When I read the above thread this morning, it seemed to me there was a lot of noise in which many were missing the point.
However, there were also several interesting points raised. Actually, I recommend you read the thread beyond what is posted above, as in my opinion it becomes more interesting and useful. (Sorry, I don't have time right now to offer another summary)
All said and done, I believe that Larry has created an impressive (albiet proprietary) product and a sustainable business model, while at the same time offering this powerful tool free-of-charge to Linus and others working on Linux kernel development. Linus has chosen to use this tool, as have others, and watching 2.5 development it seems to me the use of this tool has benefited the development of the Linux kernel.
Beyond that, I also believe that Larry has demonstrated he is willing to work with someone offering constructive criticism and useful advice. Suggesting a modification to the BKL that changes his business model to no longer be sustainable is not useful. Finding a way to make the BKL work for the majority and still keep the business model sustainable is.
Finally, whether or not you choose to use BitKeeper, you have access to the latest kernel source trees. There is no and never has been any requirement to use BitKeeper.
Tieing it all together, perhaps you should suggest a better title... ;)
BK locks academia out
The same clause of the BK license that Larry is using to lock out Ben Collins (and IBM is worried locks them out) also locks out a large percentage of acadmics. I suspect the majority of kernel hackers are prohibited from using BK as the license is currently written.
For example, the State of California runs a huge university system and and several major research labs. While more famous for their BSD system, the State also has a number of employees working on the Linux kernel. (The University of California runs the world's largest Beowulf clusters on contract for the US Government.) I'd be surprised if there's nobody within the UC system doing source control research. Anybody within UC doing source-control research prohibits kernel hackers at a different campus from using BK. (Because IBM has people working on source control, they have to get a special exemption from Mcvoy for their kernel hackers.)
The same argument applies to any other large university system, as well as many private universities such as MIT. Even if you establish that nobody else in your university system is doing source-control research, that could change at any time if another campus hires a new junior faculty member.
It doesn't lock IBM out
You can choose which of the three BK licenses you want to use; one of them is the no-cost license; the two others aren't.
I don't see why IBM would need to get a special exemption from BitMover. They can just use the commercial licenses.
It does Lock some out
It does lock out IBMers from use especially in the case where those IBMers are working on the kernel in their own free time. Same goes for any other person working on the kernel in their own time for some other company. The assumption here is that IBM as well as other companies are not going to pay for BK licenses for employees where their job is other than a kernel engineer.
In essense, the people in these catagories are being penalized by Larry for picking up a paycheck. Now granted if the people in this catagory were creating software that compete's with larry that's probably a horse of a different color. Still usually that's covered by other parts of a traditional license, under that "thou shalt not reverse engineer..."
Nobody is locked out
At least, nobody is locked out from getting the very latest Linux kernel source code. Bitkeeper uses an open data format (SCCS) for its repository and various people (including myself) are exporting the latest kernel source in formats that can be handled by free tools.
The whole confusion seems to be caused by the fact that people perceive that bitkeeper is necessary for kernel development. Sure, it's an invaluable tool for people like Linus, Marcelo, and many other developers (including myself) and I am very thankful that Larry lets us use his product for free. However, people who can't or don't want to use bitkeeper still have access to the latest source code.
There is no vendor lock-in and conversely nobody is locked out.
Missing the point
The problem isn't that it's affecting the distribution of kernel sources -- this process is the same as it ever was.
The problem is that BitKeeper is effectively strangling off the accessibility of kernel development for newbies like me who've read the books, have dabbled with some kernel code and want to get more involved, but who don't have the resources to have the BitKeeper licensed reviewed to make sure that we comply.
It's easy if you're a company -- send the license to the legal department. But Linux is all about enthusiasts, and it's the newcomer enthusiasts who are being cut off by the use of BitKeeper. Sure, user can still send off traditional patches and of course "nobody is locked out from getting the very latest Linux kernel source code" -- nobody has ever disputed that. The issue is far more serious even than that.
Excuse me
If (1) the source code is accessible to people who don't use bitkeeper and (2) Linus accepts (encourages) normal patches over bitkeeper patches ... then how does not being able to use bitkeeper reduce your accessibility of kernel development ?
Andrew Morton and Al Viro don't seem to have any problems participating in Linux kernel development without the use of bitkeeper. The firewire people don't seem to have any problems either.
I don't see why you would be a special case here and require bitkeeper access to the source code, while other people manage just fine without it...
Academics are prevented from using Bitkeeper
Rik,
As you point out, nobody is locked out of getting the latest kernel source code, nor from contributing patches. However many academics ARE prevented from using Bitkeeper for kernel (or any other) development, solely because someone who works hundreds of miles away on a different campus of the same university system is hacking on Subversion or RCS or CVS. It was in this sense I meant we are locked out from BK. Likewise, people who work for IBM or HP can't use BK at home.
No, I can't get a commercial license
Larry won't sell me one. He doesn't work in lots of less than 15 users.
In related news...
Microsoft announce that since last "security update", all Windows licenses held by open source developers are null and void.
the BSA will be knocking on the door any minute... follow the white rabbit.
is the title fair?
Ok, I agree with most of the posters here, that most of the time the BK flame wars are pointless. But this thread shows clearly why this is an issue. First Larry states:
The clause is specifically designed to target those companies which
produce or sell commercial SCM systems. That's why we explicitly
left out "distribute". The open source developers have nothing to
worry about.
Ben Collins who also happens to spend some time working on a open source SCM (subversion) then asked if the clause applied to him. Note that he does not work for a company selling subversion, and he is a open source developer.
Larry informs him:
> Would it be your intention that your license disallow my type of work? I
> think it does.
You bet it does. The Subversion folks would like nothing better than
to displace BK. That's fine, but they don't get to use BK to do it.
You're absolutely correct that you could use BK to make Subversion better.
It is not our job to help you make Subversion better and we've made that
clear for a long time.
This seems to me to be a clear reversal of his stated position. To me this reversal is the central point of the thread, not people bemoaning that BK is propritary. Troy Benjegerdes crystalize this thread perfectly IMNHO:
But until Larry retires, I have found it much easier to think of the
Bitkeeper license as the "don't piss off Larry license". Don't antagonize
Larry, or directly mess up his business model, and you'll all get along
find ;P
Is that the kind of license you are ok with?
not to mention that it forbid
not to mention that it forbids having a SCM system in the kernel.
proprietary software sucks.
This could bite us in the future
Many of you might be familiar with ClearCase; certainly I'm sure that the BitKeeper developers are. ClearCase is typically implemented with a kernel module that implements a special filesystem. The user specifies his or her configuration, and this makes specified versions of files available. At some point, someone will want to clone ClearCase or do something similar, and will send Linus patches to implement part of
the revision control system in the kernel. It appears that Linus will either need to reject the patches, stop using BitKeeper, or buy the commercial version of BitKeeper and ask other kernel developers to do the same.
Of course, it could be argued by some that the ClearCase approach is a bad idea; it has performance problems, for example. The problem is that such arguments will appear tainted, when the issue becomes "reject the patches or stop using BitKeeper for free".
Such problems might be solvable, by maintaining the thing as kernel modules that would be distributed from a separate site. But it appears that if any Red Hat employee worked on such a project, then all Red Hat kernel developers would lose their licenses to use BitKeeper (other than, of course, the right to give Larry $$$ for
permission).
It seems that this will eventually work itself out. If the BitKeeper terms become too annoying, they become an itch, and open source developers are strongly motivated to scratch that itch. I'd be surprised if, two years from now, it will still be in use under the present licensing terms.
Future shock.
I think the question is. How much control (via licenses) should a tool maker exert over the one's using the tool? If say someone wishes to use a commercial compiler to created the code for a free compiler? Are there any terms like what Larry has, found in commercial compiler licenses?
Also I've heard the "use the commercial edition", aside from the fact that would be like an "entrance fee" for an aspiring kernel coder. There's the unstated that the commercial license will not change.
Apples to Apples
> Are there any terms like what Larry has, found in commercial
> compiler licenses?
Are there any terms like what Larry has in Larry's commerical license? You need to compare apples to apples. In short, how many
commerical compilers can you use for free? ( to the best of my knowledge the answer is zero unless they are "crippled" in some capacity. The free version BK happens to be "crippled" in licensing not in functionality. Those "freebie" compiler tend to also be crippled in a similar fashion; useful only for education purposes, not "commericial" development. ) Secondly, yes that sort of restriction appears in compliers of languages which are deeply interspective and dynamic (e.g., Common Lisp). Bascially, because you can implement the language by sucking in that language. An over simplification but
(loop (print ( eval ( read ) ) ) )
is a very simple implementation of Common Lisp. I'm pretty sure most
vendors preclude you from selling that as your own version of Common Lisp.
Furthermore, as with most CS terms, the term SCM is vague. I don't think Larry would view exact clones of RCS or SCCS as a "competitor" of Bitkeeper. Linus and every other distributed development teams I know seriously reject using these tools due to the lack of some "essential" features. There is a difference between a bicycle and a motorcycle. Just because it has two wheels doesn't particularly means they are direct competitors.
And I'm perplexed as to why some clearcase clone module would need to be part of standard kernel. Putting SCM into the canonnical kernel is bloat if there every was a case for it. The utility would be for exactly ONE program. Besides Larry has given every indication of the willingness to make reasonable compromises in such situations. [ Contracts should cover 90% of what can happen.
covering every nuance and corner case that could possibly appear is folly. It is suppose to be a "meeting of the minds" not a complete enumeration of all possible barquoe, corner cases. ]
[OT] MacDonalds
Just to shoot down Rob Langley's canard over MacDonalds ...
People who know the facts think that MacDonalds deserved everything they got ...
1) You don't normally get 3rd degree burns from a coffee spill.
2) The old lady concerned did not spill the coffee over herself - someone else did.
3) The MacDonalds concerned had received (and ignored) several official warnings that the coffee was being served at far too high a temperature.
(I know it's OT, but linuxers do tend to insist on the facts being accurate ...:-)
Cheers,
Wol
(Anthony dot Youngman at ECA dash International dot com)