Slashdot Log In
BitKeeper EULA Forbids Working On Competition
Posted by
timothy
on Sun Oct 06, 2002 04:17 AM
from the that-isn't-the-santa-clause dept.
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
|
Log In/Create an Account
| Top
| 694 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Only the gratis license is affected (Score:5, Insightful)
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.
Re:Only the gratis license is affected (Score:5, Funny)
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-go
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
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
Re:Only the gratis license is affected (Score:4, Insightful)
I can understand (to a degree) preventing someone from using BK for free to develop a competing product, but to rule out working on competing software period is somewhat more destructive.
Necessity truly is the mother of invention. We invent because of some dissatisfaction with the present way of doing things. To make something that is necessary (or even quite helpful) more expensive for anyone who wants to invent a better replacement is to deliberatly kill innovation.
I imagine that Edison used either oil or gas lights while working on the light bulb. Henry ford probably used some form of transportation other than his feet while preparing to make automobiles. Imagine if they had been unable to afford the increased cost?
I suppose next, we will see OS licenses that disallow use of a computer to develop a better OS, or chipsets that don't allow the development of a new chipset.
"If I have seen further it is by standing on the shoulders of Giants". The BK EULA is like the 'giants' forbidding Newton from standing on their shoulders. Perhaps the oil companies would like to charge $100/gallon if you work on electric cars?
Re:What does BitKeeper exactly do? (Score:5, Informative)
You can find a probably biased comparison here:
http://www.bitkeeper.com/Products.Comparisons.CVS
-- kryps
Sure are full of themselves! (Score:5, Interesting)
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...
Re:What does BitKeeper exactly do? (Score:5, Interesting)
> "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.
For what a EULA is worth (Score:4, Informative)
It's a New EULA, so the old one did not mention it?
The solution is simple: continue to use your existing version.
Re:For what a EULA is worth (Score:5, Informative)
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.
Re:For what a EULA is worth (Score:5, Insightful)
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.
They can... if they purchase it! (Score:4, Informative)
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
Re:Consider ethics and software freedom. (Score:5, Insightful)
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.
Re:Consider ethics and software freedom. (Score:5, Insightful)
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.
Re:Consider ethics and software freedom. (Score:5, Funny)
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.
the path of least resistance (Score:3, Interesting)
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
Re:Why don't they use standard CVS? (Score:5, Informative)
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
Re:Why don't they use standard CVS? (Score:5, Insightful)
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.
Too bad. (Score:3, Interesting)
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)
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."
Bait-and-switch will get them what they deserve. (Score:5, Interesting)
"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:
- 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.RMS was right (Score:5, Insightful)
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.
Free tools, Free chips, RMS and LGPL (Score:4, Insightful)
You need to understand that it is exactly this issue that causes a lot of the problems. It is really worth reading all of the talk transcript [eurorights.org] from the guy who is going to debate the RIAA VP next week. It is exactly because of the desire to extract every dime available under the utility curve that leads to the desire to create non-transferable licensing (restrict right of first sale) and a host of other evils that almost everyone objects to.
How awful is it if you actually PAID MONEY for the software? Face it, if your boss doesn't have bucks, you don't have a job. Somebody's paying for the Linux kernel to be developed - if it costs 1% more, is that a big deal?
It isn't that simple. If a commercial tool is needed to participate, it limits the scope. Not everyone working on any given free source project is getting paid. Ok, so you can grab bitkeeper for free to work on the Linux kernel, that's sort of ok, but now they say you can't work on some projects if you do that. Sort of silly if you ask me, since it just gives them (BitMover) a black eye in the community and it won't slow down the development of the free alternative. It is, in fact, pretty easy to argue the opposite based on discussion of the issue here. Lots of people who were on the fence for this issue are going to move away from their product.
The transcript that I linked above makes the point that we don't actually know if BitMover is hurting or helping themselves. If they just GPLed their tool, and charged for support, commercial licenses, and other stuff, they might do better in the long run. It is a leap of faith, but you gotta ask how much the change of EULA language will hurt them in the long run. It will encourage more people to push the free alternative, and work to make that tool competetive. If it was GPLed, they would have the whole community behind them, and a lot of people would buy their books and support in gratitute for the gift of their software.
These issues are even more stark if you want to work on free hardware. The free tools are in a primitive state, so you are in a bind of choosing a less desirable tool vs something free. The producers of the commercial tools are afraid of their business drying up, so they won't do anything if it might help the free tools compete with them. You say, ok, so I'll find a tool I can use for free on free hardware even if it is closed source, but that slows down the free alternatives.
This is where you start to get just how important GPL is and why it is such an important innovation. One of the big problems in the sub-chip level hardware design is that the big tool makers have everything locked up and they don't talk to each other very well.
There are some open standards, but the whole mentality of closed intellectual property creates this situation where the best minds are all working to recreate the same tools and chip functions in each closed universe. This is even worse than it is for software because there aren't nearly as many people working in hardware as with software, and it is getting more complex just as fast.
My gut tells me that any company that makes the leap of faith and frees their intellectual property under GPL or similar terms will get back much more than they give up. It's hard, if not impossible to prove this, but instictively we know this when we look deeply at the issues.
On a side note, RMS doesn't think that the GPL is appropriate for hardware. It's bits all the way down until you start replicating the physical parts, and unlike software, it isn't possible to actually use it until you physically replicate it.
Nothing stops me from downloading the ISO images of RedHat's latest release cutting as many one-offs as I want on my CDR, or even making a run of CDs, and cutting them out of the loop completely. I can even offer my own support services to compete with RH. Doing this with chip or board level fabrication has considerably higher entry barriers, so potential "Red Hat Hardware" vendors would have less to worry about.
As long as I've come this far, I want to finish with a comment about the LGPL. From where I stand, RMS's stance on the LGPL is a take-back that is just as damaging, if not more so, as the EULA change being discussed. LGPL gives you a lot more choice in terms of integrating free and proprietary subsystems and components. Where free libraries have significantly extended functionality, he explicitly recomends GPL over LGPL. As an example if you want all the GNU goodies that make command line work so nice in bash, you have to either write your own or be ready to release your entire project under GPL. I might even agree with his goal of all software being free, but my choice is limited. What if I'm doing this work for an employer who is not ready to release the whole thing? I can't choose GPL, but I could choose LGPL.
This is the one case where I would claim that it goes beyond style, and the message itself actually hurts the movement.
Re:RMS was right (Score:5, Interesting)
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:5, Funny)