Slashdot Mirror
BitKeeper EULA Forbids Working On Competition
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.'"
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.
Any sufficiently advanced technology is indistinguishable from a rigged demo.
Hi!
. html
You can find a probably biased comparison here:
http://www.bitkeeper.com/Products.Comparisons.CVS
-- kryps
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."
The Right Reverend K. Reid Wightman,
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.
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
Editor, A1-AAA AmeriCaptions
The BSA will be knocking on the door any minute... follow the white rabbit.
Author, Shell Scripting : Expert Re
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.
Be kind. There are too many mean people out there already.
- "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."
- "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...or
We feel this is necessary to ensure the viability of our business.
Unfortunately your hammer was a free sample you obtained from the International Hammer Show 2001, and not the full commercial version.
We do sell a commercial hammer with no restrictions for $99.95.
Sincerely,
Ron O'Nail, U.S. Hammer Corp.
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.
US Citizen living abroad? Register to vote!
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...
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.
aegis (aegis.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. Unfortunately the choice was made for non-free software. Maybe now it's time to look at that proposal again.
> he was under the perception that the so-called
> "community" would donate enough money to allow
> him to accomplish that.
No, I wasn't. The community did keep me afloat for longer than I otherwise would have been, while I worked on getting corporate funding for a small team to finish and polish the hell out of arch.
Now an interesting question becomes: what does the bitkeeper license imply to IBM, HP/Compaq, Red Hat, Suse, Mandrake, and other businesses that depend on the linux kernel?
This event points to a more general problem: the free software business world needs a better infrastructure for all projects, not just the kernel. Now they have one more reason to believe in the urgency of this need.
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.
The problem with licensed proprietary software is that you can never make more than a snapshot judgement on it. You do not have the data necessary to make a judgement than will be valid for more than a few seconds.
I see nothing where Larry McVoy swears the license will never be changed to exclude anyone providing non-BK repositories. I havent seen a mail where he swears that people working for for-profit corporations wont be excluded. I havent seen him promise that BK wont exclude anyone with a beard either in the future.
How do you make a judgement then? How well does it do what it's supposed to do? How well does it do what you need it to do? Well, how much does that matter when _you may not be allowed to use it at all tomorrow_? What value does it have for you then?
Software freedom isnt necessarily the deciding factor if your choice matters the next five minutes. But when you make a choice that must be valid over a decade youd better have a crystal ball to see how whoever decides the license is going to act for the next ten years.
Fine, but you don't seem to understand that if everybody did what you do, you wouldn't have free software to enjoy. So, in short, you adopt a comfortable "I use the right tool for the job" attitude, you "get sick" of people who really stand for free software and finally use their software when it is done. Brilliant.
I don't see why it would bother kernel developers.
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.
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.
I don't believe you understand what the issue is.
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.
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.
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.
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..
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. (The author is flat broke and has no web hosting unless someone gives him some, so that link may not work; also see here and here). 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.
"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. (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, 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 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:
- I can do anything I like.
- You have no power.
- You can't say anything bad about me.
- 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.