Forgot your password?
typodupeerror
Linux Software Your Rights Online

BitKeeper EULA Forbids Working On Competition 694

Posted by timothy
from the that-isn't-the-santa-clause dept.
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:
  • I don't feel like reading a EULA tonight...by "working on" I assume that means contributing code. Is that correct? It doesn't mean using the program, right?
    • Since Bitkeeper is a development package, "using" equals "contributing code" for all meaningful cases.
      • "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 Bartab (233395) on Sunday October 06, 2002 @05:21AM (#4396199)
    Note that only the use of Bitkeeper for free is affected by this clause. It still seems like this was a bait-and-switch maneuver on the part of BitKeeper, also there seems to be some personal animosity with the Subversion crew.

    Subversion isn't quite up to par, yet, but it does seem like the switch to 2.6/3.0 "soon" would be a good time to switch revision control systems to something less... counter productive.
    • by gladiator72 (614077) on Sunday October 06, 2002 @07:19AM (#4396407)
      An excellent time to quote President Zaphod Beeblebrox: "WOW!"

      It makes me quiver with abject glee to know with relative certainty that authors of printed publications will never resort to individual licenses (rather than the kind of license that is required to, for instance, make a movie or adapt the story to the stage) that would abjectly forbid any other author or potential author of a book in a similar genre from reading!

      Imagine if H.G. Wells would have declared that anyone reading his books would be strictly forbidden from publishing a novel in the genre that would become known as science-fiction.

      Imagine if chip manufacturer X were to forbid other chip manufacturers from using their(X) chips or any product that uses their chips in the design or fabrication of the competing chips.

      Imagine if you were forbidden from using ketchup in your meatloaf!! AAAAHHHHH!!!!! Hrm... okay. I'm slipping. Heh. Yeah. Anyway.

      Regardless of how simple and striaght-forward the BitKeeper product may be, I think Mr. McVoy is forgetting that folks that do kernel development have been using tools such as gcc, as, emacs, vi, lint, m4 thingies, troff, make, info... XWindows (for the love of God!) Needless to say, your average kernel developer is probably not the typical oh-my-i-just-cant-figure-this-out-when-is-bill-goi ng-to-come-and-save-me-with-another-bug-ridden-blo ated-version-of-his-operating-system-so-I-can-get- on-with-what-I-really-want-do
      sort of end user. If he really thinks he can bully the egg-head* community in such a fashion, he's either much more brilliant than he's coming off as or his visions of becoming a respected revision control system author are going to intersect quite abruptly with the particular variety of fate known as limited-lifespan (at least as it pertains to projects that have large groups of developers that just might actually work for a competitor).

      On a different angle, if the kernel community does not decide to ditch BK for some reason, it will make for entertaining legal stories if/when Mr. McVoy starts having people hauled in. Can you imagine the kinds of goodies that will be drifting through the minds of those junior-assistant-undersecretary-to-the-person-who- brings-water-to-the-one-who-gets-to-deal-with-the- silly-things officer at foreign state departments?

      Mr. McVoy, please. I beg of you. Our glorious leader is already making us look extremely silly and annoying to the rest of the planet! Please do not exaserbate the situation.

      Praise Cheezewiz...

      * this adjective used out of respect
  • Could someone please post a feature list of what BitKeeper does that comparable free programs don't? There may be such a list already, so a url would be fine. It's time for free source control programs to get whatever capabilities that they're missing. Since I've never seen BitKeeper myself, I'd like to know what new stuff needs to be implemented.
    • by kryps (321347) on Sunday October 06, 2002 @05:26AM (#4396208)
      Hi!

      You can find a probably biased comparison here:
      http://www.bitkeeper.com/Products.Comparisons.CVS. html [bitkeeper.com]

      -- kryps
      • by ebyrob (165903) on Sunday October 06, 2002 @07:03AM (#4396379) Homepage
        From the site:

        If you can't afford a good source management product, use CVS, we'll help you migrate off of it when the time comes.

        Wow... We use CVS at work and certainly haven't felt it isn't "industrial enough" to handle what we're after. Quite the opposite in fact.

        Broken builds?? What do they think the last tagged version of the stable branch is supposed to be for?

        "plain text" a bad thing? I find I can usually trust products that keep plain things plain, much more than ones that try to over-complexify everything. If a developer can't handle managing several checkouts of a repository in his/her own work area, he/she probably doesn't deserve the title.

        RCS limitations? Be nice to see some of the most prominent listed if they are such a big deal.

        The multiple repository thing does seem interesting, but I'd think if it came to where you really needed it, something could be worked out using CVS without too much work... Actually, in practice it would seem better to get everything into the main repository as quickly as possible so everyone else can start testing on the code sooner, even if there was a bit more overhead associated with doing that.

        Course, maybe this BitKeeper appeals to managers more than actual developers...
    • CVS is quite powerful and fast. I think just about any project for which CVS is not powerful enough probably needs to be broken up into larger numbers of independent source trees and groups of developers. And, yes, I include the Linux kernel in that assessment.
      • 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 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.

    • Not possible (Score:2, Informative)

      by Anonymous Coward
      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 Florian Weimer (88405) <fw@deneb.enyo.de> 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 cduffy (652) <charles+slashdot@dyfis.net> on Sunday October 06, 2002 @01:31PM (#4397538)
        BitKeeper, back when I used it (2-3 years ago) had some nifty features, yes -- but was prone to corrupting the repository on a regular basis. What's more, Larry deliberately changed the license so that my then-current employer was no longer in compliance. Suffice to say that more than a few people there still consider him an asshole for that.

        If Red Hat is going to put money into a better version control system, I'd hope that that would be either Subversion or arch [regexps.com]. (The author is flat broke and has no web hosting unless someone gives him some, so that link may not work; also see here [gnu.org] and here [linuxjournal.com]). Arch is brilliant, functional, much more reliable than BitKeeper (at least, much more reliable than BitKeeper was when I used it)... and for someone as utterly friggin' brilliant as Tom Lord to be utterly penniless (as in, unable to buy beer, much less pay rent) is just wrong.
  • by kryps (321347) on Sunday October 06, 2002 @05:24AM (#4396202)
    Hi!

    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
  • Since when? (Score:2, Funny)

    by Eudial (590661)
    Since when does ppl acutally read the EULA?
  • by patSPLAT (14441) on Sunday October 06, 2002 @05:29AM (#4396210) Homepage
    The Subversion folks would like nothing better than to displace BK.


    Larry McVoy has an entirely reasonable business concern. He has also now provided the momentum for that concern to materialize. This may provide the motivation for Subversion to produce the cvs.succ that we all wish for late at nights, writing posts such as this one.

    ~ pS
    • Larry McVoy has an entirely reasonable business concern.

      Yes, but it is just as reasonable for open source users to reject such software. Merely making software available for free under some license does not obligate anybody to use it or open source advocates to defend it.

  • What was the reason behind not using standard CVS like other OSS projects?

    Is the kernel just too big for it?

    P.S. I don't have an opinion as to which oen they use - as long as the one they do use gets the job done, and is secure.
    • 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.

      Schwab

      • 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 [tigris.org] 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 !
      • by kevin lyda (4803) on Sunday October 06, 2002 @06:46AM (#4396351) Homepage
        you made a lot of good points until the small projects with a small number of people bit. that's crap. free and open bsd use cvs for one thing; they are not small.

        cvs works for developers with a clue about cvs. that's not to say that a better version control system couldn't be developed - one can and should. but saying cvs is crap for large projects is demonstrably false.
        • free and open bsd use cvs for one thing; they are not small.

          Actually, most of the interesting, complicated, and/or highly distributed work in FreeBSD happens in Perforce. The only thing that CVS gives us that Perforce doesn't have is the ability to replicate the repository. Unfortunately, that's also 90% of the reason why haven't fully switched over to Perforce.
  • Too bad. (Score:3, Interesting)

    by 7-Vodka (195504) on Sunday October 06, 2002 @05:30AM (#4396213) Journal
    It seemed like bitkeeper was working out quite well for the linux kernel. I liked the detailed changelogs that started apearing after the switch.

    Hopefully one of the teams working on Free alternatives will get it to a stage suitable for maintaining the kernel.

    I wonder what they'll be using when linux 4.x rolls around? Maybe linux will still be using bitkeeper and the HURD will be using something like subversion (assuming the HURD becomes easy enough for us mortals to use by then :)

    I'm hoping that by the time I wake up this afternoon there will be interesting comments by the top kernel hackers, the FSF and Linus about this.

  • Illegal (Score:5, Insightful)

    by giminy (94188) on Sunday October 06, 2002 @05:35AM (#4396223) Homepage Journal
    Forgive me if I'm stupid, but doesn't an EULA say what you can and can't do with respect to the product that the EULA covers? Reverse engineering and stuff like that are, grudgingly, acceptable terms of an EULA, but saying you can't do something that is not directly related to the software program covered by the EULA seems a tad on the side of illegality.

    I have a feeling that if anyone challenged the agreement, the law would force it to change. Granted you have to accept the EULA in order to use the software...but if I made a EULA that said you were no longer allowed to own a firearm if you used my product, it would be tossed to the wind in a second. In a sense, Bitmover's EULA infringes on my right to compete, yes/no? If Bitmover doesn't want people to use an idea they have, they should file a patent for that idea, or otherwise rely on copyright/trademark law to prevent people from "stealing."
    • Re:Illegal (Score:3, Insightful)

      by a_n_d_e_r_s (136412)
      The sad part is that many software companies tries to control HOW you use the program, WHO uses it and WHAT they use it for.

      The gargantual licenses used by software companies nowadays are taking ridiculous proportions.

      We are all lucky that RMS once upon a time came up with the GNU GPL to ensure end users rights and that at least some software gives you a lot more freedom that restrictions.

      • "The sad part is that many software companies tries to control HOW you use the program, WHO uses it and WHAT they use it for."

        Yes, and changing the license AFTER you have already started using the software is bait-and-switch.

        Thanks to this abusive policy, Bitkeeper now has tons and tons of bad publicity. With certainty, the bad publicity will cost them more than any extra money they would have made from the bait-and-switch. Incidentally, did I mention bait-and-switch?

        Every company that would have paid for the Bitkeeper product interprets this sneaky activity very clearly: If they can do sneaky things to Linus, they can do this to our company, too. We should stay away from them. They are not trustworthy.

        This is typical of technically capable people who know nothing about marketing and think there is nothing to know: Work for years to build the product, and sink the company in an afternoon.

        Truly innovative industry leaders like Microsoft would never do something so low and mean as change the contract after companies have already decided to use the product: EULA (End User License Agreement) for a security bug fix [bsdvault.net]. (Don't croak, it's a joke. Don't blink, read the link.)

        VA Software, owner of Slashdot, uses a sneaky tactic, also. As you can see from the stock price [yahoo.com], the VA Software executives are people of great business insight. At the top of every Slashdot article, it says, "The Fine Print: The following comments are owned by whoever posted them." This sounds like you own your comments, doesn't it? However, the OSDN Terms of Service [osdn.com] says at section 4, CONTENT, paragraph 6, that they own your comments, too. It's as though Chevy sold you a car, but gave its executives the right to come around and use it, also. (I don't like sneakiness. All my comments belong solely to me. Slashdot would not have the importance it has now if the members knew that they were losing control over their writing.)

        It's no fun to work at an abusive company. We are seeing a rise in the number of sneaky contracts. This seems due to, not only technically capable people who are ignorant of marketing, but also the presence of people with no technical knowledge at technically oriented companies. These people cannot contribute to the real work of the companies; all they can do is invent ways to abuse the customer.

        As companies become more abusive, it becomes more miserable to work there. If you are good at what you do, quit and get a job somewhere where people are treated like people.

        The final EULA: EULAs are becoming more and more abusive. I decided to jump several steps ahead and write the final EULA:
        1. I can do anything I like.
        2. You have no power.
        3. You can't say anything bad about me.
        4. Everything belongs to me.
        I knew a 3-year-old who said this. He has since become an adult, which is more than I can say for some executives.
    • Well, basically, what they're saying is: "We made this neat program, which you can use, but in return, you have to promise you won't compete with us."

      If this clause had always been in the EULA, there would have been no problem: people would've known what they were getting into.

      But now, apparently, the clause has appeared in a revised version of the EULA, which would now force users to switch if they find the new terms unacceptable. This is obviously not a nice practice.
      • Yeah, it's the whole bait and switch aspect of this that's worrisome to me. As much as I disagree with the idea that any company should be able to tell me what I can do with something not related _directly_ to their product, I could accept that if they had said "this is the deal" right at the start, and let people make an informed decision about whether they were willing to be bound by that. But they've clearly just done this to lock people in and then try to squash competition. A very Redmondian tactic if you ask me.

        Whatever happened to the idea that software should compete on its merits rather than by trying to hobble its competitors? I say, the sooner we have a functional replacement for this, the sooner we will be free of onerous and unfair practices like what's going on here.

        Reading the LKML thread, the recurring theme was "we just don't want to help our competition for free". But the misleading, deliberately or not, thing about saying that is that the actual clause goes far beyond just prohibiting the use of BK for direct use in developing Subversion, for instance. It actually stops you from using it when you are simply working on an *unrelated* competing project that does *not* use BK. Frankly, that's not their business to decide and is designed as a way to siphon off developer support for these other projects by forcing a choice between say the kernel and Subversion.

        I think the best legal attack on this clause would be to say that they are being discriminatory in who they license to since first-sale probably doesn't apply when they give it away.
    • Re:Illegal (Score:3, Insightful)

      by Bartab (233395)
      As has been pointed out, non compete licenses are illegal. Refusing to do business with competitors is illegal, etc, etc.

      However, BitKeeper isn't saying they won't -sell- licenses to competitors. Just that competitors can't use the free license. The Commerical license does not have the problem clause.
    • Re:Illegal (Score:3, Insightful)

      by standards (461431)
      if I made a EULA that said you were no longer allowed to own a firearm if you used my product, it would be tossed to the wind in a second.

      How so? I will contract with you if you do not own a firearm. If you do own a firearm, I will not contract with you.

      What's so illegal about that? I am not the US government, but a private person. Unless the discriminatory action is clearly specified in law, I can discriminate against you all I wish.

      I don't think there is a law that says I, as a private individual, can't discriminate against gun owners. If there is, please let me know. And please don't bother to quote the constitution - that's for discrimination by the Federal gov't.
      • Re:Illegal (Score:3, Insightful)

        by Reziac (43301)
        But this sounds more like "If I contract with you, I'll wait til you are thoroughly dependent on our product, then at some arbitrary time I will suddenly change the contract so that you must throw away all your existing firearms, even if you need them."

        You can't unilaterally and retroactively change the terms of a contract -- if you do, that gives the other party the right to vacate the contract, because it is no longer what they agreed to. IF an EULA is an enforceable contract, then it falls under normal contract law -- and that cuts both ways.

        I'm not being very clear here, but you get the idea.

  • ... saying "told ya so!"
  • RMS was right (Score:5, Insightful)

    by raahul_da_man (469058) on Sunday October 06, 2002 @05:41AM (#4396230)
    Many slashdot posters seem to think Richard is just a voice crying out in the wilderness, but increasingly he seems to be a prophet.

    Many years before this happened Richard pointed out the flaws of relying on non free software. Will any of the slashdot posters who called him crazy then apologize now?

    Linus is wrong and Richard was right. You can't be "pragmatic" and use the best tool for the job if you want to keep your freedom.
    • You can... (Score:3, Insightful)

      by Sunnan (466558)
      "You can't be "pragmatic" and use the best tool for the job if you want to keep your freedom."

      You can, but non-free software can't be the best tool for the job.
    • Linus is wrong and Richard was right. You can't be "pragmatic" and use the best tool for the job if you want to keep your freedom.

      Pragmatic, according to Linus, means freedom to choose the best tool for the job from the available alternatives.

      Adhering strictly to the free software ideology limits your freedom to do so. Which is fine, as long as you recognize that this limitation to your freedom is self-imposed and that others may not be bound by the same limitations.
      • raahul_da_man's point was that Linus did not make the right choice. He thought he did, but he was wrong then. That's right - Linus Torvalds was wrong to choose BitKeeper when he did. He should never have chosen it. Why? Because the fact that the license could have changed to something this onerous means that you could not rely on the product over the long term, and choosing something like BitKeeper requires you to make a long-term commitment to the product. What good is a version control system if you have to throw it out six months later? What are you supposed to do with the versioning information when you abandon BitKeeper for some other product?

        Not only that, but Linus may not even be able to test Subversion while using BitKeeper, because the BK people may consider testing to be the same thing as "working on".

    • Re:RMS was right (Score:5, Interesting)

      by albalbo (33890) on Sunday October 06, 2002 @06:03AM (#4396265) Homepage
      Many slashdot posters seem to think Richard is just a voice crying out in the wilderness, but increasingly he seems to be a prophet.

      Absolutely right. Lest we forget, EULA clauses not allowing people to develop competitive (esp. Free Software) products is something Microsoft does [slashdot.org]. And they were rightly derided for that. Are we saying just because Bitmover are giving away free stuff that we're not going to apply the same standards?

    • Re:RMS was right (Score:3, Insightful)

      by nagora (177841)
      Many slashdot posters seem to think Richard is just a voice crying out in the wilderness, but increasingly he seems to be a prophet.

      The real problem is that RMS may or may not be a prophet but he insists on acting like god and pissing off people just by his tone. The real message gets lost in the ensuing flamewar. Overall he has become counter-productive to his own aims

      TWW

    • Re:RMS was right (Score:3, Insightful)

      by nathanh (1214)
      Many years before this happened Richard pointed out the flaws of relying on non free software. Will any of the slashdot posters who called him crazy then apologize now?

      No, they won't.

      Hating RMS is a religion. Facts don't faze the fanatics.

    • Well... the fully free alternative definitely must exist, and I'm grateful that Mr. Stallman saw fit to undertake that task. It also shows great foresight (or stubborness) that the GNU project continues to work on their own kernel even with Linux getting such acclaim these days. I applaud them for it!

      However, non-free alternatives and mixed alternatives simply existing is not necessarily a problem. What is good for the prophet is not always good for the people.
  • Put yourself in their shoes.

    Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

    What if you knew that they were using it in production with in house changes and additions with out releasing source code?

    This is where BitMover is sitting. Developers are using their software to assist in developing their competition and doing it in violation of their licensing agreement.

    BitMover is just doing what we would do if the shoe was on the other foot. This issue will be solved in the same way the open source community always deals with challenges.

    The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

    • If you actually read the link in the story, you will see that it prevents you from using it if you are developping (or aiding development) of an alternative.

      This actually means that if I am both a subversion hacker and a kernel hacker, I can't use BitKeeper anymore for my kernel hacking....

      Anything good (or sane) about that?

      And by the way, the GPL clearly gives the right to microsoft to use linux, even modify it, if they aren't distributing it... I think most conscious kernel hackers already know that.

      So that really makes them the bad guys (I didn't see any anti-Microsoft clause in the GPL)

      So that really makes them the bad guys ;)
    • The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

      This isn't the issue, however.

      The problem was that the developer of Subversion was also a kernel developer. I don't think that they were using Bitkeeper for developing Subversion - but the developer used Bitkeeper to check patches into the kernel. Now he cannot use Bitkeeper at all, and hence it is more difficult for him to work on Linux

      No, it's not Bitmover who is at fault here - it's a problem caused by using non-free software to develop Linux.

    • Yeah, Mod that Perdo guy down. He almost made us think for a minute. We just want to follow the party line. The party line says BitMover is bad! ...

      Meta might catch it.
    • Put yourself in their shoes.

      I... uh... can't. I understand the concept of trying to sell software to make a living, but I don't support it. I sell my services as a programmer to make a living and give away the code. This is not to say people who sell code are 'bad guys' but I fail to understand how they hope to compete with those commie open source hackers. Sure your start out with an edge and a superior product, but how long are you going to stay that way?

      Which, of course, you sum up nicely: The open source community will produce a better alternative under the GPL without using their software. That being said, do they really think they stand to make more money by pushing away the Subversion team? In the short term, maybe, but I think in the long run they just killed themselves. I think the wineX crew handles their PR much better.

    • by MobyTurbo (537363) on Sunday October 06, 2002 @08:24AM (#4396485) Homepage
      BitMover is just doing what we would do if the shoe was on the other foot.[...] Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.
      I have moderator points today, but I guess I'll give them up for this article because I don't see anyone else bringing up the most common useage in the legal field of this particular form of license agreement.Of course, IANAL. :-)

      I'd agree with your perspective concerning Bitkeepers IP rights if this was the only way this clause is used in a shrink-wrap license. However, it is more often used in court in a semi-fraudulent manner. More often than not, Bitkeeper could claim that a developer was "contaminated", and unless it was *very carefully* documented otherwise, with the sort of documentation rarely available in an open-source project, it can shut down the competitition. I'd hate to think that Bitkeeper's lawyers would do something so cynical, but its a common practice with this sort of contract. About the only remedy is to start the entire project over from scratch and work in "double-clean" rooms, but that's practically impossible in an open source project.

      Kudos to Bitkeeper's lawyers for proving that fascism is alive and well in the commercial software industry when it comes to competing with open source projects. Until they drop this clause open-source developers should boycott their tools, because doing otherwise is too great a risk. Maybe they'll get the message, if not, Bitkeeper will go the way of gopher, another product which got a license like this and was dropped like a hot potato by developers in favor of www, and of course the competition ended up being better. :-)

    • Put yourself in their shoes. Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

      Yes.

      What if you knew that they were using it in production with in house changes and additions with out releasing source code?

      No problem. Distribution requires source changes to be available, not use.

      The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

      You're right, it's called OpenCM [slashdot.org]

    • by fwr (69372) on Sunday October 06, 2002 @10:40AM (#4396848)

      Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?


      I don't see why it would bother kernel developers.


      What if you knew that they were using it in production with in house changes and additions with out releasing source code?


      This is explicitly allowed by the GPL, so for any kernel developers to have a problem with this would be hypocritical. Anyone can use any GPL software in house in a production environment with as many custom changes they want without releasing those changes to everyone in the world as long as they do not distribute their custom version outside their organization. Perhaps you meant something else than what your words clearly say? That you mean an "in house" "production" environment is somehow equivalent to distributing a version of a GPL software package outside (not in house) your organization with custom changes and not releasing the source code? That would be illegal, but that's not what you said.


      This is where BitMover is sitting. Developers are using their software to assist in developing their competition and doing it in violation of their licensing agreement.


      Not it is not. Their new license apparently goes well beyond that. It says that developers using (the free license version of) their software for a non-competing product, such as the kernel, can not work on a competing product, regardless of what other revision control software they use to build the competing product. So, no Linux kernel developers, or anyone else that uses the "free" version of BK, can contribute to some competing products. This is quite different than you portray.


      BitMover is just doing what we would do if the shoe was on the other foot. This issue will be solved in the same way the open source community always deals with challenges.


      I don't believe you understand what the issue is.


      The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.


      One would hope that the community produces a better alternative under the GPL. If BM wants to limit the use of their software to create a competing product then I don't see a problem with this as much as what they are doing, which is described above.
    • Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

      If I were a Linux kernel developer, how people would use my kernel is none of my business.

      What if you knew that they were using it in production with in house changes and additions with out releasing source code?

      If I knew they were distributing binaries to Linux without accompanying source code, I would insist that they rectify their apparent violations of the GPL.

      This is where BitMover is sitting. Developers are using their software to assist in developing their competition and doing it in violation of their licensing agreement.

      Actually, BM is restricting the license to BK, not based on how it's used, but on who uses it. If you're a competitor to BM, you do not qualify to use the Gratis version.

      It's not open source software. It's commercial software. This may be ultimately incompatible with its use by open source developers. This is no surprise, right? Linus seems to make choices based on the merits of technology and practicality, not politics. If too many barriers to the use of BK emerge, I have a feeling he could make a different decision.

      BitMover is just doing what we would do if the shoe was on the other foot. This issue will be solved in the same way the open source community always deals with challenges.

      Placing restrictions on how a piece of software is used violates the "free speech" elements of any open source software license. It would stop being open source software. How people use the Linux kernel is none of the developers' business. How they redistribute it, however, differs with certain licenses.

      The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

      I don't think the SV folks ever considered using BK as their revision control system. I think the issue is, a SV developer could not accept the Gratis license to BK to work on the Kernel, because he was excluded because he works on a competitive project.
  • So many people here are getting all upset because BitKeeper is not free. Well, there's nothing wrong with trying to make money off of some software, while helping the community at the same time.

    No business in their right mind is going to help a competetor take their market share. Maybe BitKeeper can't help if Subversion takes that market on its own, but they are not going to help them do it.

    Disclaimer: I have a huge interest in Subversion, and I've been contributing to their mailing list for almost a year. I love Subversion. But I still implore all you Slashdot hippies: do not assume that all non-free software is evil, and do not make BitKeeper the bad guy just because they want to make money.

    Free software depends on a few companies' ability to actually make money developing and using free software. Without industry support, free software will never make it past a select few geeks' basement computers. If you like free software, then you should support BitKeeper's decision. BitKeeper has helped the FS community in the past, and their support for the kernel project has been wonderful. Support them, help the FS industry grow, and everyone benefits.
    • 'So many people here are getting all upset because BitKeeper is not free'

      No, I am upset because it is used to develop Linux (which is free) and because is the only non free tool used to do it.

      I think Linus is wrong on this, because by using it, in a way, he is forcing it upon other people involved in kernel development.

      If BK where used to develop windows I wouldn't have any problem with it.
    • Free software depends on a few companies' ability to actually make money developing and using free software.

      Ya, and commercial software relies on free software to keep it honest enough that computers can actually remain a useful tool to the human race...

      We all need each other, lets have a group hug.

      P.S - I don't think most of the point is that bitkeeper is bad, just that it was a bad idea for the kernel to rely so heavily on a commercial product in the first place. From some posts, it even sounds like the development team could have licenses to bitkeeper that wouldn't limit what they can work on if they're ready to shell out the bucks...
  • by sparkz (146432) on Sunday October 06, 2002 @05:58AM (#4396253) Homepage
    Microsoft announce that 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.

  • Alan Cox? (Score:4, Interesting)

    by vsync64 (155958) <vsync@quadium.net> on Sunday October 06, 2002 @06:04AM (#4396268) Homepage
    Does Alan Cox use BitKeeper, and if so, does he pay for his copy? I would imagine not, given his stances on free software and intellectual property.

    I'd like to point out that Alan Cox works for RedHat, whose operating system includes CVS. I would venture to guess that RedHat hackers have contributed to CVS, at the very least with a 1-line diff here or there. This makes RedHat both a reseller and a developer of CVS, and even if he doesn't personally have anything to do with CVS (doubtful) he is forbidden from using the openlogging version.

    I find it ironic that at a time when BitKeeper is trying to sway developers toward their product, they create onerous conditions which prevent a prominent developer and political spokesman from using said product on any sort of trial basis.

    Technically, I suppose I'm not allowed to use BitKeeper either, since I've written (and released, I think; I'll have to double-check) an add-on to CVS which parses and cross-references checkin logs.

    The really funny thing is that CVS is quite prevalent in the free software world, where it is extremely common to create patches and add-ons. The most effective referrals to BitKeeper would be from CVS hackers or those otherwise extremely experienced with it, but by preventing precisely these people from trying BitKeeper out, the one thing that could help BitKeeper the most -- a public defection from a "pet project" -- is verboten.

    It's rare that we get to see such an obvious case of shooting oneself in the foot.

    • This makes RedHat both a reseller and a developer of CVS, and even if he doesn't personally have anything to do with CVS (doubtful) he is forbidden from using the openlogging version.

      Nope. You entire argument rest on the premise that CVS "contains substantially similar capabilities" to BitKeeper. It doesn't... not just in my eyes, but in the eyes of Larry McVoy and BitMover. Larry has repeatedly stated that if CVS was good enough, he'd never have had to start developing BK in the first place. CVS is fundamentally flawed in its design, and doesn't come close to BK in terms of capabilities. By far the biggest one is its lack of changesets, but there are others, too. Hence, RedHat shipping CVS has no bearing on use of BK by any RH employees. Now if Red Hat shipped TrueChange, Perforce, or (more relevant in this case) Subversion, then it would be a different matter. And even if they did, I'm sure Larry would make an exception, or modify the license slightly. He's a reasonable guy, and wants to do the right thing, but at the same time, he has a business to run, and staff to pay, and it's perfectly reasonable for him to take steps to protect that.

  • by crimsun (4771) <crimsun@@@ubuntu...com> on Sunday October 06, 2002 @06:23AM (#4396305) Homepage
    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 [theaimsgroup.com], here [theaimsgroup.com], and here [theaimsgroup.com].

    3) This is hardly a "new EULA."

    Please see the thread at http://marc.theaimsgroup.com/?l=linux-kernel&m=103 389686711292&w=2 [theaimsgroup.com], or subscribe to linux-kernel at vger.kernel.org for updates.
  • by Nerant (71826) on Sunday October 06, 2002 @06:24AM (#4396309)
    Kerneltrap.org 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 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.
    "

    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.
    • by XaXXon (202882) <xaxxon&gmail,com> 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 testuser58 (552737) on Sunday October 06, 2002 @06:26AM (#4396313)
    Just make me feel like a sucker for choosing the "hip" GPL for my software. To think that I could have included a license that says something like:
    • "by using this software, you agree to give me your car and talk to a jar of pickels at work for the first five minutes of every day."
    • "by using this software, you agree to agree to the previous agreement, section D, which can be found in records department 41, level 9, building B. Yeah, see them to find out what you just agreed to, sucker."

      or

    • "by using this software, you agree to tell me when you encounter bugs instead of emailing me I'll never use your software because it doesn't work good!"
    Sigh... the fun I could've had...
  • Read the thread (Score:2, Insightful)

    by blender98 (258057)
    If anyone bothers on read the whole thread (ha!), they'll find that this only affects the free use of BK.

    Larry's main concern is that someone who wants to implement a competing version control system does not use a free version of BK to do so. He is not attempting to prevent the subversion people from using bitkeeper; he just doesn't want them using it for free.

    Before people start jumping up and down and screaming "antitrust", let me just state again that he is simply insisting that people who work on competing products but BK, rather than using it for free. He is by no means restricting anyone's trade.

    Furthermore, BK is not required to checkout source code from a BK repository -- SCCS suffices, and Rik van Riel, Jeff Garzik and others make snapshots available every couple of hours.

    The long and short is that nobody need use bitkeeper for kernel development (the source code may be obtained in a timely fashion using existing tools). If you don't like the BK license, don't use BK!

    Larry has a responsibility to BitMover and its employees. He has salaries to pay, and making it easier for competitors to duplicate BK does not make that any easier. By providing BK and bkbits.net for free, he is doing the kernel community a service -- how about we cut him some slack?
    • Re:Read the thread (Score:2, Insightful)

      by jrfonseca (575890)
      I've read carefully all the thread on http://kerneltrap.org/node.php?id=444 but I don't share your opinion.

      Larry first presented BitKeeper designed to both aid the kernel development and to be comercially viable. So far these two goals haven't collided: people could use freely BitKeeper for kernel development and BitKeeper has been growing as a comercial product.

      But this changes does affect everything: it prevents people that (even if just remotely) contribute somehow to different SCM products and which were using BitKeeper freely has they were incentivated to revert their habits. The problem is not that they can't find a way around, but that Larry is taking away a present which had been given away freely.

      The worst is that this change does not seem to be made to protect BitKeeper business model but seems instead a act of bad faith against a particural set of people.

      This radically change my opinion about the usage of BitKeeper and the trust on the people behind it, and from I've read Debian maintainers feel the same.
  • 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.
  • arch (Score:3, Insightful)

    by chris_sawtell (10326) on Sunday October 06, 2002 @06:56AM (#4396367) Journal
    It looks to me as if arch [gnu.org] is a pretty good alternative yo Bit-Keeper.

    Anybody used it for a big project?

  • by Anonymous Coward on Sunday October 06, 2002 @07:04AM (#4396382)
    aegis (aegis.sourceforge.net [sourceforge.net]) 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 [lwn.net]. Unfortunately the choice was made for non-free software. Maybe now it's time to look at that proposal again.
    • by Florian Weimer (88405) <fw@deneb.enyo.de> 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.
  • Then you should really consider starting a "free the source" fund to collect enough money for the required number of licenses needed to work on subversion.
  • BK Summary (Score:5, Insightful)

    by mysticalreaper (93971) on Sunday October 06, 2002 @08:29AM (#4396493)
    What's the short version?

    A) The license forbids you to use BK to further a direct competitor to BK. Distributing a competitor, while using BK, like Red Hat does, is allowed.

    B) This license is the FREE license. Remember the saying, "Beggars can't be choosers?" They can't. Are you using BK for free? Then you can't expect to choose the license. If you buy the program, you can develop whatever you like with it.

    C) Anyone still has the ability to be a kernel hacker without using BK whatsoever. The old tools still work, Linus and everyone else still accepts standard patches. It's just the old tools are actually worse than BK. BK was chosen purely on technical merits, it's only the license that's raising questions.

    Point B) is important. Because this is the FREE license, it means that BM is not violating anti-trust laws by forbidding competition, because you can purchase the product, and get unrestricted use. Companies are not required to provide free samples of their products to competitors to help them out. Also, it means that BM is NOT acting like MS when they pulled the same stunt in their EULA. (Adding a clause stating that you cannot use MS products to harm MS in any way).

    Summary: Bit Mover is acting reasonably, and completely within their rights as a company to define the acceptable uses of their free gift to users. The issue should is not whether or not Bit Mover is 'cheating' people. The issue now is whether or not to use Bit Keeper personally.
  • hmm (Score:3, Interesting)

    by Raven42rac (448205) on Sunday October 06, 2002 @09:08AM (#4396597)
    well that is just incredibly stupid and immature, that would be like an eula in phoenix or mozilla telling you that you can not use IE, not that you would want to anyway, but still, is this even legal?
    I thought EULAs were unenforcable, and usually get laughed out of court. I am no expert, so help me out on this one.
  • by MBCook (132727) <foobarsoft@foobarsoft.com> on Sunday October 06, 2002 @11:07AM (#4396920) Homepage
    One question: if you're making some kind of version controll system, why whould you use BK to develop it? Once it's working, wouldn't you use itself? Before it's working well enough, just do it by hand or with CVS or something.
    • From the Subversion FAQ [tigris.org]

      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

    • Ben Collins works on Subversion, and packages glibc for Debian, and does work on the Linux kernel. And he didn't send a Netwinder to Larry McVoy.

      He was using BitKeeper to work on the Linux kernel, as requested by Linus; now it is impossible for him to do so because of his work on the Subversion project. A number of people feel that the development of an important Free Software project should not depend on a non-Free version management system, especially one where the rules as to who is allowed to use it keep on changing.

      I wonder if it's the work on Subversion or the missing Netwinder that caused all this...

  • by XaXXon (202882) <xaxxon&gmail,com> on Sunday October 06, 2002 @11:18AM (#4396950) Homepage
    Here's the actual prices for BitKeeper [slackworks.com] 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) <xaxxon&gmail,com> 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) <xaxxon&gmail,com> 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..
      • 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.

        The text of the price list can be copyrighted. The fact that company X offered to sell you product Y for price Z cannot, as it is expressions and not facts or ideas that are copyrighted. IANAL, but unless you're under an NDA or another contract not to disclose the prices you were offered, I think you can safely tell someone else what those prices were. Copyright on the price list just means you have to express those facts in your own words.

  • by Ektanoor (9949) on Sunday October 06, 2002 @11:35AM (#4397015) Journal
    Sorry to those who buz talk about "beggars cannot be choosers". The philosophy of Open Source and Free Software is not about begging and getting for gratis. It is an exchange, someone offers a service and ethically I have a duty to offer some feedback. It worked very well while we were a few tens of thousands. Today the masses came in and we have lots of seemingly "beggars" around. But this is not the hear of the movement and we shall keep our efforts to show people how things really develope. The problem of having supposedly "beggars" is similar to the problem of Anonymous Cowards in /.. If we take them away, we jeopardise our ideals. "Beggars" and ACs are a side effect of a world that is not perfect and which we should fight for being a little more correct. Not marginalising the masses but bringing to them the real meaning of the Open Source, Free Software and Free Speech is the real duty we shall not ever ever forget.

    Now about this blatant monopolistic and ridiculous license. I may understand a commercial interest when someone declares a agreement void because I work on something that may hinder my partner. Development, production are things that are interim to a work where I and my partners should trust each other ofr a common cause. Using or developing some product while I do the same thing "on the side" for a concurrent product, is somehow a dubious behaviour from my side.

    However sell/resell? Who's the jerk that wrote this license? Who's the stupid lawyer that forgets centuries of commercial ethics and practices? Who is he to hinder my right of choice and the right of choice of my clients? Any exclusivety on distributing, selling or lending anything is a conception that immediately forces a special agreement of rights and duties between two partners, sharing a common profit. Not something that "I should do or else". This is monopolism and it is ethicaly criminal to state such things in this way. No matter I get this thing for free or under a fee, claiming that I have not a right to choose what is best for me is the worst of dictatorships ever. They hinder the very principal of market with this.

    Imagine this situation. I have a market. I try to find the best product so that this market lives on. Under this agreement either I cannot test their product if I sell something similar, I am forced to stop selling it to test their stuff or I have to pay them a fee to test their product. This, I would just call blackmail. If everyone starts doing it, it would be much worse than Windows EULAs.
  • by lpontiac (173839) on Sunday October 06, 2002 @11:36AM (#4397018)

    A lot of people seem to commenting that there's nothing wrong with BitKeeper being licensed as it is. This isn't really being argued ..

    The argument is that because BitKeeper's license is as it is, that the Linux kernel developers shouldn't be using it.

  • by gotan (60103) on Sunday October 06, 2002 @11:43AM (#4397038) Homepage
    This example illustrates a more general problem:
    Lately we see more and more license changes for existing software, BitKeeper and various Microsoft products are only the most notable cases. License changes accompany updates and patches, or it's just a document on some website that changes.

    Most Software isn't ever a `finished' product, it's subject to changes called `new version', `upgrade' or `patch'. Often the customers depend on having the latest version of a software, be it for security reasons, compatibility issues, or just part of a leasing contract for the software. The software makers use these changes in the software to change the license terms in the software. In the BitKeeper example, someone using BitKeeper in a large project probably depends on it, or it would at least cause a lot of additional work and delay the project to switch from BK to something else.

    This means, that even subtle license changes may have a huge effect on anyone depending on that software, done right such a license change might even ruin someones business (imagine someone using free BK on some project competing with BK, and imagine BK had gone one step further and made their "no competition" clause mandatory on all new licenses. Done just a few months before some critical timeline this might have killed the whole project. Even so any project using BK for a competing open-source product would probably have a hard time or even falter).

    To protect businesses from being at the whim of software-makers there should be some regulations in place, that only allow license changes within reasonable limits, and demand that such changes are announced some time beforehand, so the customers have time to react. Most companies protect their business by making sure that they can't be cut of from any resource they depend on, they should realize that software is just such a resource and enforce license terms that don't allow for ugly surprises due to one-sided changes. But since few companies have the leverage to change Microsofts license terms i think there's a need for legislation considering software license changes.
  • by dh003i (203189) <.dh003i. .at. .gmail.com.> on Sunday October 06, 2002 @12:12PM (#4397161) Homepage Journal
    No court in the nation is going to enforce those kind of EULA terms.

    It would be like MS saying you can't use MS Word if your using it to write up a document critical of MS, or to write up source code for something competing with an MS product.

    Most of these EULA terms are either unenforcible practically, or simply would not be upheld in a court of law. I believe the anti-competitive terms in this EULA are both. Firstly, as I said before, no court is going to enforce such non-sense. To do so would usher forth an era where every product includes a license forbidding you to use it if you work for or help a competitor. Secondly, this is simply unenforcible, or largely so. Why should anyone abide by this? There are no consequences if they don't, except perhaps being forced to stop using it. This is not a case where any financial damage enters the picture, so there's no potential cost to violating the license. Third, even if it is enforcible within the US, that can easily be side-stepped by hosting one's project outside of the US, where the US has no jurisdiction.

    What really annoys me about this BitKeeper people is their audacity to say that they are actually trying to help the community. No, they are not. They are doing this to make money, not to help the community. Its fine that they want to make money, but its not fine that they try to say that a Free Software project isn't trying to help the community, and that they are. The Ben Collins was right not to help BitKeeper, as BitKeeper has now proven by these draconian licensing terms. Helping non-free projects will invariably harm the Open Source (OSI-compliant) and Free Software (FSF-compliant) communities, in several regards. Firstly, it will encourage people to use non-free software. Secondly, as non-free software will become more popular and universal, the community will become more vulnerable to draconian EULA licenses like BitKeeper's.

    That aside, this is just proof that Stallman was right. You can't rely on a product with a EULA. They will always include draconian licensing terms. We should be switching over to Subversion and supporting that.

    Supporting non-free software will always hurt the cause of Free Software, and will ultimately hurt development of Free Software (which includes the GNU/Hurd; GNU/Linux; and the Free-, Open-, and Net -BSDs.
  • by Uggy (99326) on Sunday October 06, 2002 @04:06PM (#4398256) Homepage
    In my company (Free software based) we get our investors always talking about competition and patenting the living shit out of everything we can get our hands on. They talk about NDA's, closing stuff, hiding stuff, denying access to etc.

    My response has been and will always be: "What are you afraid of? Our clear objective is to do it better, keep our lead, solve customers' problems, give good service, and not sit on our asses and collect checks."

    Just do it better. There are enough incompetent people in the world. We shouldn't have such a weak view of ourselves that we fear THEM, should we?

    Investors don't like to hear that, but then I suppose, it's hard to keep fear from the equation.

    If Bitkeeper really wants to be around they should just make sure their product is better than the competition's. If there exists someday a free software alternative that is as good, they they had better make sure they excel in the service area, that they respond quickly and promptly to their clients' needs.

    If the free software alternative exceeds their closed source version, then they should switch to it. They could lay off part of their developers, save a bundle, and hire more service folks. They can then happily maintain their extraordinaryily content clients with the high level of support and care to which they have become acustomed.

    It's really simple, IMHO. Your fear will end up consuming you until such a time as you end up nothing but an insane reactionary, screaming and hurling insults at your last loyal client.

There's a whole WORLD in a mud puddle! -- Doug Clifford

Working...