Become a fan of Slashdot on Facebook


Forgot your password?
Linux Software Your Rights Online

BitKeeper EULA Forbids Working On Competition 694

Col. Klink (retired) writes "BitKeeper's new EULA forbids working on the competition. Larry McVoy has told Ben Collins that he can't use BK because he works on subversion (a free revision control program). In fact, you can't use BitKeeper if you OR your company have anything to do with competing software. Free Software advocates who were upset when Linus decided to use non-Free software now have the opportunity to say 'I told you so.'"
This discussion has been archived. No new comments can be posted.

BitKeeper EULA Forbids Working On Competition

Comments Filter:
  • by Teun ( 17872 ) on Sunday October 06, 2002 @05:23AM (#4396201) Homepage
    (without having read the "New EULA")

    It's a New EULA, so the old one did not mention it?
    The solution is simple: continue to use your existing version.

  • by kryps ( 321347 ) on Sunday October 06, 2002 @05:24AM (#4396202)

    If the submitter had followed the thread on LKML more closely he would have realized that it is only forbidden to use the *free* (i.e. openlogging) version of BK to develop a competing product. They can still *purchase* a commercial license and develop whatever they want with it.

    -- kryps
  • by kryps ( 321347 ) on Sunday October 06, 2002 @05:26AM (#4396208)

    You can find a probably biased comparison here: html []

    -- kryps
  • Not possible (Score:2, Informative)

    by Anonymous Coward on Sunday October 06, 2002 @05:29AM (#4396211)
    AFAIK, free users have to always use the latest version since they are beta testers at the same time. It should be in the license (I haven't read it though). At least Larry explained it like that in l-k mailing list.
  • by Anonymous Coward on Sunday October 06, 2002 @05:38AM (#4396227)
    > What was the reason behind not using standard CVS like other OSS projects?
    > Is the kernel just too big for it?

    CVS is far from being perfect, but it's not the matter of the project size.
    For example, NetBSD, FreeBSD and OpenBSD all use cvs for the whole source tree and it's way bigger than Linux kernel.
  • by kryps ( 321347 ) on Sunday October 06, 2002 @05:41AM (#4396229)

    Well this is quoted from the free license. The commercial license does not include this section.

    -- kryps
  • by ewhac ( 5844 ) on Sunday October 06, 2002 @05:58AM (#4396252) Homepage Journal

    CVS has too many inherent limitations to make it a good choice for large-scale projects. Although it's been around for just ever and is fairly solid, there are a couple of issues that make CVS a sub-optimal choice.

    First, CVS is built on top of RCS and, as such, doesn't handle binary files. Okay, that's a fib; it sorta kinda does, but it's very klunky, and easily prone to errors. Further, it's easy for the "binary-ness" of a file to be lost (i.e. be treated as text), resulting in all kinds of nasty corruption. Best Practices will avoid this, but everyone has to be on their toes all the time.

    Second, CVS has no notion of "transactions". Let's say you check in a bugfix/new feature to the kernel. The change involves modifying six different files. CVS does not see this checkin as a single transaction, but six completely separate ones. So a lot of information about the scope of a given change is not easily found. The only way you can know a particular change affected multiple files is by noticing that their checkin comments are identical. Further, if you perform a checkin against multiple files and one or more of them has a conflict (someone else checked in a change before you did), CVS will simply halt at the conflicting file; earlier files successfully checked in up to that point are not backed out. Thus, the repository is left in an inconsistent state. Best Practices can avoid this but, again, everyone has to be on their toes.

    Other source control systems don't have these problems. In particular, Subversion is transaction-based, so groups of files checked in at once either all get checked in, or none of them do, keeping the repository consistent. Also, Subversion handles arbitrary meta-data for each file, including its MIME type, so the "binary-ness" of a file cannot be lost or modified unless you expressly change its MIME type. Even better, Subversion will automatically perform newline translation to/from your local platform when checking out/in text files.

    For small projects with small numbers of people, CVS is perfectly okay. But beyond a certain scale, CVS's limitations start to get in the way, and you need something better.


  • Yes CVS is powerful and fast, but anyone who uses it long enough knows there are just some CVS features that are hacks. Binary file support for one example, renaming files, and the biggest of all, renaming directories. If you can make a project that never has to reorganize in its history, then you are some kind of diety.

    The reason Subversion, BitKeeper, and a whole host of other next-generation SCM products are being developed is because CVS just plain doesn't cut it for most serious development. It works, but not nicely.

    Subversion is not distributed, so while having independent, distributed source trees is a nice feature of BitKeeper that some projects require, it is not the only reason to switch.
  • by theefer ( 467185 ) on Sunday October 06, 2002 @06:13AM (#4396284) Homepage
    Yes, and there are others points :

    - CVS cannot move files and keep a track of the log.
    - CVS directory handling is quite horrible

    Now, I use CVS as everybody else here does, it works, sure. But there are some problems that should be fixed (and cannot be because of the CVS base), that's why I'll probably switch to Subversion [] soon. It's still under heavy development, but it gets better from day to day.

    Let's support some free software instead of proprietary ones !
  • I believe the intent of "Col. Klink (retired)" was to bring this to a wider audience, but there are several points that need to be reiterated.

    1) "In fact you can't use BitKeeper if you OR your company have anything to do with competing software."

    The above applies to /free/ use only. You are still welcome to purchase a commercial license from BitMover. What Larry has said "makes sense" from a survival/profit (i.e. capitalist) point of view: "you simply don't get to use our product -- which we provide for free -- to put our company out of business."

    Furthermore, Larry has demonstrated that even if you /don't/ use BK, accessing changes and patches should be no more difficult than prior to Linus's trial/adoption of BK.

    2) It has been made very clear by several of the core developers that accessibility to Linus's merges has been made much easier since his trial/adoption of BK. See here [], here [], and here [].

    3) This is hardly a "new EULA."

    Please see the thread at 389686711292&w=2 [], or subscribe to linux-kernel at for updates.
  • by Nerant ( 71826 ) on Sunday October 06, 2002 @06:24AM (#4396309) covered all of this. for those too lazy to read through the whole exchange, i'll extract the best part (emphasis in bold is mine):
    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, 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.

    In short?
    If you want to use Bitkeeper for the development of something to replace it, you have to purchase a commercial license. Otherwise, you can use the "gratis" license.
  • McVoy just killed BK (Score:2, Informative)

    by Performer Guy ( 69820 ) on Sunday October 06, 2002 @06:35AM (#4396329)
    Face it, after this EULA and the email this guy just sent out bit keeper is dead. R.I.P. Who knows where their business dealings will take them and what use it will be in their interests to curtail in future. If you're using BK for source management you have to be looking over your sholder and worrying what proclamation McVoy will issue next that might force you to throw out all versions in your tree currently and move to an alternative product.
  • by Florian Weimer ( 88405 ) <> on Sunday October 06, 2002 @07:04AM (#4396381) Homepage
    It's a New EULA, so the old one did not mention it?
    The solution is simple: continue to use your existing version.

    The old EULA is revoked automatically as soon as Bitmover changes the Bitkeeper test suite so that the old version no longer passes it. In essence, this means that Bitmover can revoke old licenses at any time.

    IANAL, but I know I can't rely on Bitkeeper (the vendor doesn't want me to, obviously). Maybe the commercially sold version is different, I don't know.

    Bitkeeper is probably really nice software, so we can only hope that Red Hat (or someone else) buys Bitmover one day and licenses Bitkeeper under the GPL.
  • by Anonymous Coward on Sunday October 06, 2002 @07:04AM (#4396382)
    aegis ( []) is a mature source code management solution much better than CVS and offers the same core functionality of BitKeeper (transactions, changesets) plus a lot more. Heck, there was even a proposal to use aegis to manage the Linux kernel source code, way back in 1999! See this article []. Unfortunately the choice was made for non-free software. Maybe now it's time to look at that proposal again.
  • by kasperd ( 592156 ) on Sunday October 06, 2002 @07:08AM (#4396389) Homepage Journal
    "using" equals "contributing code"

    Yes using BitKeeper equals contributing code to some project . But using BitKeeper does not equal contributing code to a project competing with BitKeeper .

    You can use BitKeeper and other version control software for developing software for a completely different purpose (like for instance Linux), the question was what the EULA has to say about that.

    I actually doubt this statement in the BitKeeper EULA has any relevance for European users. I guess it is only in America you can legally make such ridiculous claims.
  • by kryps ( 321347 ) on Sunday October 06, 2002 @08:59AM (#4396569)
    >>> As other posters have pointed out, BitKeeper's licence is the same paid or free. You may not use BitKeeper to assist in developing a competitive product.

    This is just not true. There is the commercial license (the BKCL) and there is the free license (the BKL). Both differ in many points and there is no clause about development of competing products in the BKCL. Check your sources.

    -- kryps
  • by Florian Weimer ( 88405 ) <> on Sunday October 06, 2002 @11:07AM (#4396918) Homepage
    Aegis implements a process, not just version control, and many people are cautious about software which forces them to work in a certain way (until they have been using it for years, then it becomes The One True Way). Most Aegis newcomers who are forced to use it by the project maintainer will detest it because it encourages (forces?) them to write test cases along their changes...

    However, the process implemented by Aegis closely mirrors the Linux development process: a developer makes changes, some subsystem maintainer reviews it, and Linus integrates it into the official tree. But there's a drawback: this only works if all developers have access to the same repository, on the same filesystem. :-(

    Aegis has got a distributed development model, but it doesn't offer the same repository tracking features as Bitkeeper. I don't know if this is relevant in the kernel context, IIRC Linus has complained more than once that the repository tracking (which links changesets to particular repositories/revisions) prevents him from automatically applying patches to the master repository.
  • by XaXXon ( 202882 ) <> on Sunday October 06, 2002 @11:09AM (#4396923) Homepage

    In short?
    If you want to use Bitkeeper for the development of something to replace it, you have to purchase a commercial license. Otherwise, you can use the "gratis" license.

    This isn't an accurate statement, or at best it's misleading. Say you want to work on two projects -- one a version control program, the other the Linux kernel. For the version control stuff, you use your own software (or CVS or anything not BK), and for Linux you use BK (which apparently you don't have to do, but it integrates best). Nope, can't do it. Because you work on a competing project, you can't use BK for free for anything. I think this is the biggest problem.

    Apparently you're allowed to buy your own license, but most people don't have $5,000 to shell out (I've seen the price list) for a single copy.
  • by XaXXon ( 202882 ) <> on Sunday October 06, 2002 @11:18AM (#4396950) Homepage
    Here's the actual prices for BitKeeper [] in PDF as they were sent to me from BitKeeper. I was interested in using it for my personal projects until this licensing garbage came along, and I had inquired on the pricing model..

    If you want the short version, it's $5,800 for a single license, and then $1,200 / year starting the second year (the first year's included in the base price) for service and upgrades (and you have to keep it current. You can't just pay $1,200 3 years down and try and get upgrades).

    So anyone who says that an Open Source developer should just "buy themselves a copy", isn't really understanding that you don't go to Best Buy and plunk down $50.
  • by XaXXon ( 202882 ) <> on Sunday October 06, 2002 @12:03PM (#4397111) Homepage
    I just got this email from Larry McVoy informing me I had to take down the price listing. Here's the email I received:

    That was clearly marked as confidential not to be disclosed. See page 7
    right above the price list. Posting it is a blatent violation of our
    copyright and causes our company material damage. If our lawyers find
    that link still working tomorrow morning at 8am, you'll be the first
    entity we have sued for copyright violation. Ask around, what you are
    doing is serious with serious legal exposure for you.

    I'm not exactly sure why I'm not allowed to post it, as nothing says "you may not post this", but it is copyrighted to them, but I don't really know what that means. They're probably just using the fact that they have more lawyers than me (greater than zero vs. zero) to bully me around.. but ah well. I suppose I don't really care about BK anymore.
  • by XaXXon ( 202882 ) <> on Sunday October 06, 2002 @12:18PM (#4397187) Homepage
    So, I sent Mr McVoy an email back stating that wasn't sure exactly why I couldn't post his pricelist. He responded that it was on the price sheet and that I had missed it. He was correct about that. I had checked the top and bottom of the price listing and seen nothing regarding redistribution.

    This is one of the emails I got back:

    [my email quoted]
    > But I suppose I'll take it down. And you're causing your company more
    > material damages in what you're doing than what I'm doing.
    [his email]
    Actually, every time you slashdot kiddies get your undies in a bundie our
    sales go up. Thanks.

    Just thought I'd share that..
  • by CaptainZapp ( 182233 ) on Sunday October 06, 2002 @12:23PM (#4397205) Homepage
    From the Subversion FAQ []

    Is Subversion stable enough for me to use for my own projects?

    We believe that Subversion is stable and have confidence in our code, in fact, we've been self-hosting since September of 2001--eating our own caviar so to speak. We declared alpha because we're ready for the world to try Subversion.

    After 10 months of self-hosting, we haven't lost any data at all.

    Hope this helps

  • Re:moot point (Score:3, Informative)

    by MenTaLguY ( 5483 ) on Sunday October 06, 2002 @03:27PM (#4398093) Homepage
    Subversion started using CVS and then went self-hosting -- they're not using BK for Subversion development, nor did they ever.

    What Larry's upset about is that the Subversion developers made a BK gateway so that Subversion could be used in Linux kernel development more easily.

    Presumably that's a threat to his business -- it could be the first step in moving kernel development off of BK and onto Subversion.

    So he changed the license to (effectively) prevent this.
  • by tomlord ( 473109 ) on Sunday October 06, 2002 @09:05PM (#4399554)
    > and for someone as utterly friggin' brilliant as
    > Tom Lord to be utterly penniless [...] is just
    > wrong

    Of course, I strongly agree.

    > (as in, unable to buy beer, much less pay rent)

    I am as happy as one can be under these circumstances to report that, much to my surprise, I was able to buy both this month's rent and this week's beer on the last dribs and drabs of a friend's credit. But, yeah, it's pretty bleak.

    But, hey ... I've got this kick-ass business and technology plan here for companies like Red Hat and all the unix vendors.... free software is _good_ for business, and I'm doing my damndest to make things work. (Hey, Scott McNealy, let's do lunch (you're buying):-)

As of next Tuesday, C will be flushed in favor of COBOL. Please update your programs.