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.
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.
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.
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!
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. :-)
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.
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 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.
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.
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.
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.
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 the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
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.