|
|
Subscribe / Log in / New account

The BitKeeper non-compete clause

Certain subjects return to these pages over and over again; one of those, certainly, is the BitKeeper source management system. Despite concerns about its proprietary nature, BitKeeper has become the tool of choice for many Linux kernel developers. Those who are concerned about BitKeeper use for kernel development found new flame fuel in a previously unnoticed clause in the BitKeeper license, version 1.38, which reads:

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 capabilities of the BitKeeper Software, or, in the reasonable opinion of BitMover, competes with the BitKeeper Software.

The purpose of this clause is to say "you can use BitKeeper free of charge, but only if you are not using it to develop a competitor to BitKeeper." It is arguably a reasonable licensing clause; regardless of what one thinks of BitKeeper or proprietary software in general, BitMover can not be expected to willingly provide its tools for the purpose of creating new competition.

And BitMover does fear this competition. Many years of effort went into the development of BitKeeper and the associated business; the creation of a suitably capable free replacement could wipe out that investment in a short time. BitMover founder Larry McVoy believes that the free software community is not capable of creating from scratch a source management system of BitKeeper's quality and with BitKeeper's innovations. He does, however, think it could produce a clone that, while inferior, is good enough to cost BitMover a lot of business. Coming up with ideas in the first place is expensive; copying them is far easier. BitMover wants the space to earn something from its (expensive) efforts to create BitKeeper; it also wants to be able to develop the product into a far more capable tool, a task requiring, they think, about four years. They have stated their intention to fight back with every weapon at their disposal - including copyright and patents - against anybody who threatens their ability to carry out that plan.

Is all this a problem for free software and the Linux kernel? It could be, but probably not on the scale that some people fear. The immediate concern with the clause quoted above is that a number of free software developers and companies do deal with other source management systems. In the case of developers, the situation is fairly clear: if you work on a free source management system, BitKeeper is not available to you. To emphasize the point, Larry McVoy publicly told Ben Collins, a kernel FireWire driver developer (and Subversion hacker) that he could not use BitKeeper:

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.

Ben's kernel work will not be affected, since he was not using BitKeeper for that project. Other kernel developers could eventually run afoul of this rule as well, however. For example, the ReiserFS team has no end of ambitious plans for its filesystem; some of them, such as version management, begin to push into BitKeeper's turf. Larry told us that, in his opinion, it was "very likely" that ReiserFS would eventually cross the line and become a BitKeeper competitor; at that point its developers would be unable to use BitKeeper.

That is about as far as it goes, however. The license, says Larry, went too far by excluding anybody whose employer works on source management systems. The next "debugging" release of the license will tighten that term so that it only affects developers working directly on source management, and, perhaps, those very close to them. Thus, for example, Red Hat developers will not lose their access to BitKeeper just because Red Hat puts some patches into CVS. It is also BitMover's position the Linux kernel developers as a whole will not lose their BitKeeper access even if Linus merges a version of ReiserFS which costs the ReiserFS team its access.

In evaluating the whole BitKeeper controversy, it is worth remembering a few things. One is that BitMover could have avoided all this pain simply by never giving gratis access to its product. Other vendors of commercial source management systems do not make their products available for free-of-charge use, and they are not routinely flamed the way BitMover is. BitMover, instead, has chosen to make its product freely available to groups developing free software. Kernel development has benefitted from this gift in a number of ways:

  • The capabilities of BitKeeper are much appreciated by developers who choose to use it. BitKeeper really does make a lot of things easier, especially in a distributed, multi-developer environment.

  • Linus is merging patches at a tremendous rate, and appears to be far less stressed than before. Patches still get dropped, but on a much smaller scale. The process, by all appearances, is working more smoothly than it has in a long time.

  • Anybody who is interested can see the state of Linus's development tree in near real time. There is no longer any need to wait for prepatches or full releases. Thanks to BitKeeper, a new development kernel is released many times a day. As an added bonus, Linus is now able to post automatic changelogs as well, eliminating the need to read through each release to see what patches were included.

It is also worth pointing out that nobody has been forced to use BitKeeper. Many top-tier kernel developers have chosen not to use it, and they have not had to change their ways of working. Getting repositories and patches into and out of BitKeeper is easy by design; BitKeeper has a stated "no lockin" policy. It is not even necessary to use BitKeeper to keep track of Linus; several sites (like this one) provide frequent access to the updates in his tree.

In other words, the adoption of BitKeeper has brought good things to anybody who uses the Linux kernel. This has happened free of charge, with no visible costs of any significance. Except, perhaps, for the time lost in flame wars. Access to BitKeeper is a gift that its creator was under no obligation to make. It is unfortunate that some members of the community expend so much effort criticising those who have made that gift. It is hard to see how the free software community would be better off if BitKeeper were withdrawn.

All this is not to say that there is no reason for vigilance and concern. The denial of access to some developers is a discriminatory action, to say the least. If Larry McVoy (or his board of directors) wakes up hung over one morning and decides to end free access to BitKeeper, the show is over. Larry is uninclined to do that - he has maintained free access despite the constant flames because he wants to support the kernel project. But Larry could have an unfortunate encounter with a bus (though, as Linus has pointed out, buses are rare in California), or BitMover could be acquired by another company; in either case, the new management could make changes to the license. The BitKeeper binary does not come with source; it could be doing no end of evil things and it would be difficult for people to know. Currently, BitKeeper makes it easy to extract all data and metadata from a repository; moving an entire repository into a different source management system is an easy task. Linus also uses the BitKeeper interfaces to export patches and tarballs in the same way he always has. Future versions of BitKeeper, however, could quietly shift over to a closed format that is harder to escape from.

And so on. These are issues that come up with any proprietary package, and they are certainly no worse than the issues raised by that other proprietary source management platform which is even more heavily used in the free software community: SourceForge. In the end, people who use software should always look at the license, and not use a particular package if the license is not to their taste. In the case of BitKeeper, those who chose not to use it are no worse off than they were before, and an easy path is open should a quick evacuation to another source management system be required. BitKeeper is worth watching; one never knows where a company might decide to go tomorrow. But the situation at the moment is not that bad.


to post comments

The BitKeeper non-compete clause

Posted Oct 10, 2002 1:58 UTC (Thu) by lordsutch (guest, #53) [Link] (8 responses)

I think this episode underlines the need for a truly free SCM system that Linus is comfortable with using. The developers of arch, Subversion and other advanced SCM systems need support to make that happen.

While I respect that Larry has a business to run, and perhaps even agree that GPL-licensed software is hardly a fountain of innovation, as opposed to duplication, he's the one who chose to build up his business by portraying himself as a friend of free software, as embodied in the Linux kernel. He shouldn't be surprised that when he publicly goes after important members of the developer community (BenC is not only a 1394 developer and Subversion hacker; he's a former Debian Project Leader too) it's gonna get him bad publicity.

Arch

Posted Oct 10, 2002 3:53 UTC (Thu) by BrucePerens (guest, #2510) [Link] (2 responses)

I'm afraid that the originator of "arch", Tom Lord, is unable to work on it any longer due to personal issues. So don't count on it. I'm disappointed, I did all I could to help, it didn't work. I know that there were other people working on it, and there was at least one full rewrite in progress (to Perl), but I'm not currently in touch with any of the other developers. I'd like to hear from them. Email to bruce@perens.com please .

Bruce

Arch

Posted Oct 10, 2002 16:21 UTC (Thu) by lordsutch (guest, #53) [Link]

I believe Walter Landry is one of the guys working on arch at the moment (he's posted some about it on debian-devel); try wlandry -at- ucsd.edu.

Arch

Posted Oct 17, 2002 10:22 UTC (Thu) by job (guest, #670) [Link]

There are a few things brewing in the Arch community. The new central place seem to be this one: Arch

That site lists a few exciting contribution from Walter Landry, who calls his creation larch.

It's only going to get worse

Posted Oct 10, 2002 4:53 UTC (Thu) by BrucePerens (guest, #2510) [Link] (4 responses)

Sorry if this ends up a duplicate. My original posting on this topic seems to have gotten lost.

Don't think the situation will remain the same. Larry's business barely makes payroll. He's not getting more investment. He knows that it would take a very little push to get him to the point that he can't make payroll. Subversion is going to give that push. Especially since anger is a great motivator in the free software community, and now there are a lot of angry people who want subversion to do just that. What Larry is doing with the pernicious license terms is attempting to hold off the inevitable for a little longer. But Bitmover will be sold or will have a new investor who changes the management. The best scenario is that the new investor is "one of us" and takes the thing free. But that's not the likely scenario - the likely one is that we lose the current free beer rights. We'd better make sure that subversion is ready for Linus (or whoever) to use, because a day will dawn when we suddenly need it.

Bruce

It's only going to get worse

Posted Oct 10, 2002 16:52 UTC (Thu) by lm (guest, #6402) [Link] (2 responses)

> Larry's business barely makes payroll.

We have 3 months of payroll in cash today. We have 5 months of payroll
coming in within the next 20 days. Most of our customers are lease based
which means we have a steady revenue stream, one which covers our costs.
We've been profitable for 4 years, which is saying a lot.

I don't know kind of smoke you're crackin but we're nowhere near being
"pushed over the edge".

I do not hate to burst your bubble at all, Bruce, since you are spreading
categorically false information about us, but the only way we'll withdraw
the free use product is if we let people like you annoy us. Since you
don't use BK and you don't do any kernel development, you don't rise
to the level of annoyance.

1 down, 10000 to go :)

It's only going to get worse

Posted Oct 21, 2002 21:33 UTC (Mon) by wolfrider (guest, #3105) [Link]

Larry, I respect your work and your efforts to help out Linus et al.

I can tell that you are sincerely trying to be a "good guy" and then you get flamed for your efforts by ppl who don't know any better.

Don't let the bastards grind ya down.

--Wolfrider

Why I said that you had trouble making payroll

Posted Jan 27, 2003 21:27 UTC (Mon) by BrucePerens (guest, #2510) [Link]

Larry,

You are correct that I know nothing about your business internals...
except what you tell me. I based my feeling about how hard it was for
you to make payroll, and how you felt about Open Sourcing his product,
on the following email, which appeared on at least one public list,
in which you very clearly wrote that it was a pull making payroll.

Regarding your propensity to threaten lawsuits, I only remember our
last two phone conversations, which I think both ended unpleasantly.
I have no wish to goad you, but I don't want to seem as if I'm making
things up.

Thanks

Bruce

From lm@bitmover.com  Sat Aug 10 17:57:35 2002
Return-Path: ⟨lm@bitmover.com&rang
Delivered-To: bruce@perens.com
Received: from bitmover.com (bitmover.com [192.132.92.2])
	by perens.com (Postfix) with ESMTP id 6A9DD228A0
	for ⟨bruce@perens.com⟩ Sat, 10 Aug 2002 17:57:35 -0700 (PDT)
Received: from work.bitmover.com (work.bitmover.com [10.3.9.1])
	by bitmover.com (8.11.6/8.11.2) with ESMTP id g7B0vRE27017;
	Sat, 10 Aug 2002 17:57:27 -0700
Received: from work.bitmover.com (localhost.localdomain [127.0.0.1])
	by work.bitmover.com (8.12.4/8.9.3) with ESMTP id g7B0vROe004201;
	Sat, 10 Aug 2002 17:57:27 -0700
Received: (from lm@localhost)
	by work.bitmover.com (8.12.4/8.12.4/Submit) id g7B0vQDq004199;
	Sat, 10 Aug 2002 17:57:26 -0700
Date: Sat, 10 Aug 2002 17:57:26 -0700
From: Larry McVoy ⟨lm@bitmover.com&rang
To: Tom Lord ⟨lord@regexps.com&rang
Cc: lm@bitmover.com, lord@morrowfield.regexps.com,
	arch-dev@regexps.com, ghudson@MIT.EDU, dev@subversion.tigris.org,
	tiemann@redhat.com, poole@affero.com, bruce@perens.com,
	dev@bitmover.com
Subject: Re: what proofs look like
Message-ID: ⟨20020810175726.A2468@work.bitmover.com&rang
Mail-Followup-To: Larry McVoy ⟨lm@work.bitmover.com&rang,
	Tom Lord ⟨lord@regexps.com&rang, lm@bitmover.com,
	lord@morrowfield.regexps.com, arch-dev@regexps.com, ghudson@MIT.EDU,
	dev@subversion.tigris.org, tiemann@redhat.com, poole@affero.com,
	bruce@perens.com, dev@work.bitmover.com
References: ⟨58C671173DB6174A93E9ED88DCB0883D04760B50@red-msg-07.redmond.corp.microsoft.com&rang ⟨200208101855.LAA09281@morrowfield.regexps.com&rang ⟨20020810115423.A2031@work.bitmover.com&rang ⟨200208101923.MAA09649@morrowfield.regexps.com&rang
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: ⟨200208101923.MAA09649@morrowfield.regexps.com⟩ from lord@regexps.com on Sat, Aug 10, 2002 at 12:23:10PM -0700
X-Spam-Status: No, hits=-2.1 required=5.0
	tests=IN_REP_TO,FOR_FREE,US_DOLLARS_2
	version=2.31
X-Spam-Level: 
Status: O

On Sat, Aug 10, 2002 at 12:23:10PM -0700, Tom Lord wrote:
&rang 	I had hoped to reply to your earlier note in as positive and
&rang 	constructive a mode as possible, to get past the difficult
&rang 	garbage, and into the space of making improvements of mutual
&rang 	benefit.
&rang 
&rang Do you think that's possible?

No.  Please take me off the CC list of this thread.  As gently as 
possible, with no ill will intended, I want you to hear that I can't
help you.  I don't have the extra money that you need and I doubt 
that anyone else does.  

[ Delete now if you don't want to know why we didn't take Tom's path ]

It's perhaps worth pointing out that I've been running a company doing
SCM type stuff for 5 years.  We own our IP and we use legal means
to force people to pay us for it.  And we have a good product, many
people think it is better than clearcase. 

Even with all that, the last 5 years have been a non-stop struggle to
scrap together payroll every 2 weeks.  It's a constant source of stress,
there are houses, families, kids, all of whom depend on me finding the
money to keep things going.  It's incredibly hard.  My health sucks
as a result of doing this, you have no idea of the toll it has taken.
And the part that you just can't seem to hear is that there is ABSOLUTELY
NO CHANCE that we would have made 1/100th of the money we have made if
we gave away our software for free.  And there is ABSOLUTELY NO CHANCE
that we would have made 1/100th of the money we have made even if we had
all the good parts of arch, BK, subversion, and clearcase put together
in a GPLed package.  The market simply will not pay for obscure products
unless they have to do so.

You may have a different opinion but what you are finding out is that
your opinion is wrong and that's a painful process.  I'm sorry for you,
I tried to warn you but it's understandable that you didn't listen,
we don't produce anything remotely approximating free software so we're
automatically in the "evil corporate" camp.  What you didn't get is that
I'm you.  I have the same ideals, the same goals, the same dedication,
the same drive to help the world.  I can just hear you saying "if that's
true then BitKeeper would be GPLed, you self serving bastard".  Not so.
My goal was, is, and will remain a goal of providing support for Linus
and Linux.  The difference between me and you is that I have realized 
what it really costs to produce a decent SCM system and then continue
to support and evolve it.  It's a HUGE cost.  Given that my goal was to
help Linus and that I believed that he needed a production quality system,
my choices were to get on the dot com wagon and get VC and/or make it
commercial.  Otherwise it was never going to get finished.  GPL was not
an option.

I choose not to go the VC route because the VC guys don't share my goals.
Their only goal is to make more money.  Which means as soon as they
thought that giving BK away to the open source crowd didn't help them
make more money, they'd put a stop to that.  So I passed on that, turned
down $6M from a top 3 VC firm,  just wasn't worth the risk.

We went it alone, but we had to make it a for profit concern or we'd 
never have gotten to where we are.  And we're nowhere near done.

Yeah, yeah, I can hear you saying "thanks for the BK advertisement"
but that's not the point.  The point is that the goal of helping out the
portion of free software community with difficult SCM problems FORCED us
into a corporate model.  You can whine all you like about how evil that
is, how I've sold out, whatever, but the reality is that you are begging
for money so you can get to a 1.0 release and we are shipping a tool that
2000+ Linux kernel developers use world wide.  For free.  And it has met
the goal of helping Linus.  BK still sucks, it has tons of problems, but
those problems will get solved precisely because we have a business model.
You don't.  Your business model is charity.  That's not going to work.

I'd be far more impressed with you if you were demonstrating that I
was wrong by showing me how to develop a system that works, in all the
corner cases, and is self supporting through a business model that
somehow works with an open source product.  I'd LOVE to see that.
I hate the idea of not shipping source, it pisses me off to no end.
But it is a fact of life that if we ship it, people abuse it.  And then
we go out of business.  And then the product doesn't get finished.

At any rate, I don't think you are listening to any of this, so just
listen to this one thing: please stop mailing me about this.  Feel 
free to flame me a few more times if that makes you feel good but 
don't expect a response, I've procmailed you into /dev/null.  Sorry,
but I have work to do and this is too much additional stress.  Good
luck, I'd love nothing more than to have you show me a business model
which proves me completely wrong, but until you do, I don't want to 
hear about your problems.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

It's only going to get worse

Posted Oct 17, 2002 10:27 UTC (Thu) by job (guest, #670) [Link]

If that would happend, I hope we as a community could "buy" BitKeeper (exatcly what was done for Blender). Perhaps that is something that could be appropritate to Bitmover? If the large players could cough up their share of money right away to free Bitkeeper? That would be a great contribution. Come on, it can't be impossible they've wasted more money than that on really lousy projects.

The BitKeeper non-compete clause

Posted Oct 10, 2002 2:39 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

One correction is that Bitkeeper source is available (remeber the flame wars over the fact that bitkeeper required the modified versions to still pass the regression tests that among other things verified that you didn't remove the openlogging portion)

There are restrictions on what you can do with the modified version so it's not 'Open Source' by the legal definition, but you can look at the source and verify what it is doing.

David Lang

The BitKeeper non-compete clause

Posted Oct 10, 2002 3:00 UTC (Thu) by corbet (editor, #1) [Link]

Actually, it's been some time since source for BK has been posted. They quietly withdrew that a while ago. BK is a true closed-source application these days.

The BitKeeper non-compete clause

Posted Oct 10, 2002 2:49 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

Also the non-compete clause only applies to the FREE use of bitkeeper, if you pay for a licence this doesn't apply to you at all (although if you purchase a licence and then write a program that works very like bitkeeper you can probably expect a lawsuit about copying it's look-and-feel)

In addition Larry has stated that he has already issued some waivers to kernel developers who work for companies that develop SCM systems to allow them to continue useing bitkeeper for kernel development.

The BitKeeper non-compete clause

Posted Oct 10, 2002 4:17 UTC (Thu) by Ross (guest, #4065) [Link]

Larry seems to be quite reasonable on granting exceptions
to this clause in the license for those who aren't working
on version control software. So pragmatically, this isn't a
problem right now.

But we should all realize we are relying on BM's good will
and that is less than optimal. I would suggest that the
kernel developers should avoid becoming overly dependent
on BK or any other product outside of our control.

In fact, this whole thing reminds me of another problem:
Putting way too many open source eggs in SourceForge's basket.

The BitKeeper non-compete clause

Posted Oct 10, 2002 5:56 UTC (Thu) by fyodor (guest, #3481) [Link] (1 responses)

Yes, this restriction supposedly only applies to the free version. But Larry can easily exclude people he doesn't like from the paid version via discriminatory pricing. Note how he immediately threatens lawsuits when someone posts the BK pricelist. Even if the pricing was not discriminatory, few open source hackers have an extra $5,800 lying around for a single-user Bitkeeper license. So if you are or ever want to be a kernel hacker, Larry wants you to think long and hard before contributing that little Subversion or CVS patch. It is true that you can still "work around" using Bitkeeper for kernel development, but Linus seems to be encouraging its use more and more.

I for one plan to resist this bogus, anticompetitive license. I am surprised the LWN article treaded so lightly. I wonder what they would have written if the MS EULA was changed to exclude developers of competing operating systems? I am currently developing the Nmap Security Scanner[plug], but I hope to find time to help with Subversion as well. The best way to fight BK is to write a compelling replacement. My best wishes go out to those who are already doing such admirable work!

-Fyodor

The BitKeeper non-compete clause

Posted Oct 10, 2002 6:50 UTC (Thu) by alan (guest, #4018) [Link]


From the link you gave, Linus was not encouraging BK's use at all. In fact he mentioned that the ACPI team was trying to use it and didn't quite get it right, ( and says that the ALSA patch was even more difficult to deal with).
He seems to be concerned about technical excellence, not licensing issues.
That's fine with me.

As for the price of licensing, I once sat down with Oracle in a series of meetings and asked for a price quote. I got $800,000 quoted for the project I was working on. My coworkers and I sat down and reviewed everything in detail, and when we were finished, the quote was $200,000. I can understand why Larry wouldn't like his prices spread about. Every negotiation is a consists of haggling out a deal. Posting his numbers will just scare off potential customers that he may be able to give discounts to in exchange for the probable future customers.

Fyodor, thank you for your work on nmap. It is unquestionably the best.

The BitKeeper non-compete clause

Posted Oct 10, 2002 6:39 UTC (Thu) by alan (guest, #4018) [Link]

Larry has notably poor customer service skills. This is forgivable, as he is an engineer, not a customer service rep.
What about the other side, the businesses that are looking in on BM, as a test case. They want to know, 'Can we work with the open source community?'. Yes, there are nasty licensing tricks BM *could do in the future, but focus on what it's track record is now, in generously supporting the kernel development team. If BM, a reasonably benevolent company with real innovations that are making a tangible difference, has a difficult time in pleasing the community with a very reasonable licensing scheme, it may discourage others from releasing software for open systems, as a futile effort not worth trying.

I agree that the dependence on closed software for kernel development is a situation that needs rectifying. However, BitMover only needs a slight innovative edge, to appease the demanding high-end customers from whom they intend to make a living. They will move on to bigger and better features, and customers, and they'll be able to say that their software dramatically improved the quality of a popular and large open source kernel, Linux. Features that give BK it's current edge will find their way into arch and subversion. I'm sure that is how this series of events will come to pass.

In the meantime though, the ability of a company to work with the community and make a living will be gauged by the many present and future businesses who are silently observing, looking for a successful model that is both profitable and opensource friendly. There are those who really want this to work, so how beneficial is it to abuse the first wave of those who are really trying?

The BitKeeper non-compete clause

Posted Oct 10, 2002 7:34 UTC (Thu) by lacostej (guest, #2760) [Link] (1 responses)

Something I don't understand is that people get scared wih a 'what if BK is removed from us?' question. The answer is: we will go back to CVS (or any other open source tool that has matured enough to replace it). That's all. No loss of productivity compared to what we used to have. The loss of migrating back will, as I understand it, probably be less important than the gain we had using BK during the last months.

So stop complaining. Say thanks to Larry who gives us some help, even if temporary, for free. That's his own contribution do Open Source. And it is a much bigger one than spending time complaining on mailing lists. If you are afraid that this gool tool is to be removed from you, then go and spend as much time as you can using it!

The BitKeeper non-compete clause

Posted Oct 21, 2002 21:44 UTC (Mon) by wolfrider (guest, #3105) [Link]

"we will go back to CVS" -- WRONG. Linus never used CVS for kernel development, that was one of the reasons why BK was so desperately needed.

Free software to the rescue.

Posted Oct 10, 2002 11:07 UTC (Thu) by leandro (guest, #1460) [Link] (3 responses)

Now we see RMS wisdom in action.

I never understood why Linus never evaluated Aegis, and why Subversion is being pushed so hard. AFAICS, Aegis does most or all of what BitKeeper claims to do and Subversion targets, and could be used by Linus with similar results and less controversy.

Also I am amazed to see that, if Linus had applied to Linux the reasoning he uses to justify BitKeeper usage, Linux would never have seen light. The better tools to the task at the time Linux got started were the BSD Unices...

Free software to the rescue.

Posted Oct 10, 2002 12:07 UTC (Thu) by massimiliano (subscriber, #3048) [Link]

> Also I am amazed to see that, if Linus had applied to Linux the reasoning
> he uses to justify BitKeeper usage, Linux would never have seen light.
> The better tools to the task at the time Linux got started were the BSD
> Unices...

While I agree on many worries about the bitkeeper license... I think that
at the time he started (with his brand new 386) Linus didn't want to use
"the best tool for the job": he was interested in developing such a tool
(operating system) himself.

Now, with a SCM, his position is different: he is not interested in writing
one (he is still busy with his OS), so he just looks for "the best tool for
the job".

Of course, I wish we had a free SCM with all the features BitKeeper has,
and I will take a look at Aegis soon... for now, I stick with CVS, keeping
an eye on Subversion.

Ciao,
Massimiliano

Free software to the rescue.

Posted Oct 10, 2002 17:36 UTC (Thu) by rfunk (subscriber, #4054) [Link] (1 responses)

Also I am amazed to see that, if Linus had applied to Linux the reasoning he uses to justify BitKeeper usage, Linux would never have seen light. The better tools to the task at the time Linux got started were the BSD Unices...

At the time, BSD was under a legal cloud, so he couldn't use it.

Free software to the rescue.

Posted Oct 17, 2002 8:32 UTC (Thu) by leandro (guest, #1460) [Link]

> BSD was under a legal cloud, so he couldn't use it.

He could, just as the GNU people used. He couldn't be sure of his legal status, so he perhaps would have to analyse his own patches to BSD before deciding if he could share them or not, or even refrain from publishing them at all.

Remember, copyright is not about usage, but copying.

Correction: Perforce is FREE for OpenSource use

Posted Oct 10, 2002 13:11 UTC (Thu) by faramir (subscriber, #2327) [Link]

This article states that no commercial source management system
is available for free use. In fact, Perforce has had an offer
on their web site for free licenses for OpenSource projects for
some time now. The offer is still on their web site on the page:

http://www.perforce.com/perforce/price.html

Reading the license document that is linked off of the page,
it seems that there might be issues because the software is
written to be licensed on a per user basis, but the offer is
still there...

And what about the non-free licenses?

Posted Oct 10, 2002 13:27 UTC (Thu) by emk (subscriber, #1128) [Link]

Does Larry allow developers of version control software to use BitKeeper under his proprietary license, without severe price discrimintation? If not, his attempts to penalize kernel contributors who work on version control software is fairly sketchy.

I'm surprised LWN took such a soft position on this license. I know that I'd get grumpy if any of my development tool vendors (free or proprietary) started taking an interest in what kind of software I was writing. Microsoft's done this a few times, and the Linux community has soundly condemned them each time.

Larry keeps changing his licensing terms after many users have become committed to his system, and his licensing terms place unusual and difficult burdens on some of his users. That's not nice.

One point to Richard Stallman, for predicting trouble. I'll be looking into Aegis.

The BitKeeper non-compete clause

Posted Oct 10, 2002 16:17 UTC (Thu) by dkite (guest, #4577) [Link] (1 responses)

I find this whole thing unfortunate. Mr. McVoy has very generously contributed to the kernel development in a very useful way, as the article mentioned. The free software developers have a habit though of looking the proverbial gift horse in the mouth.

I think the current economic situation has pushed Bitkeeper into a corner. The 'normal' response is to tighten up, get defensive. All this is doing is making the teeth look alot worse.

I suspect there will be a replacement soon. I was even tempted to sit down and figure out a way, something way beyond my skill or time availability. I am sure a number of hackers have been equally piqued.

I think the flame wars on the linux kernel forums will seem mild mannered compared to the ugliness that is going to come with this issue.

Derek

The BitKeeper non-compete clause

Posted Oct 16, 2002 20:47 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

BM is not giving a gift to the Linux kernel development community. It is making a wise business decision. The only reason you and most other people have heard of BitKeeper is because Linus uses it. That publicity has translated into tons of free advertising, and reviews from publications that otherwise never would have heard of the product.

It is costing BM money to support the kernel hackers who use BK, but again, that's merely a wise investment. Any successful software product needs a set of skilled beta customers to bang on it and help get the bugs out.

Given that the free BK license is not a gift, it makes sense to evaluate its consequences. It's been valuable to Linus, although that value looks greater because before BitKeeper Linus wasn't using any SCM system. However, there are down sides as well, as more and more kernel hackers find themselves either disqualified from using it or prevented from doing other work that interests them.

Accordingly, it should be seen as only an interim solution. In the long term, as ESR says, open source software gets written to scratch an itch; it would be in Larry and BM's interest to try to make BitKeeper itch as little as possible, otherwise they will only accelerate its eventual replacement.

For example, earlier reports suggested that BM would disqualify all (for example) Red Hat employees from using BK for free if any Red Hat employee worked on any competing SCM project. If they are backing off of that extreme position, it's a wise move.

OpenCM

Posted Oct 10, 2002 23:09 UTC (Thu) by zooko (guest, #2589) [Link]

There's also OpenCM. It is immature, but is directed by Jonathan Shapiro, who has done excellent research on capability security theory.

The BitKeeper non-compete clause

Posted Oct 11, 2002 14:54 UTC (Fri) by kunitz (subscriber, #3965) [Link]

It's not helpfull in the long term, that the development on the Linux kernel is depending on the success of Lary McVoy's company. I find it more and more dangerous, that open-source starts to depend on centralized infrastructure like Source Forge or the Bitkeeper open-logging server. I wait for the day this infrastructure will be ICANNized.

I would argue for a formal contract between the Linux community (Linux International) and BitMover Inc. This contract should define, what happens if "free" Bitkeeper-Licensing will be terminated or changed and how interoperability with current and future open-source SCM projects can be supported. This contract should be based on the fact, that BitMover wins high product awareness and market penetration by the application of BitKeeper for Linux kernel development.


Copyright © 2002, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds