Slashdot Mirror
RMS Calls On Linux Developers To Replace BitKeeper
JakusMinimus writes "The developer of BitKeeper has issued fighting words to RMS and he has responded on the LKML,. I remember the flap about this way back when Linus decided on BitKeeper, now it seems many of the non-free concerns were warranted."
It's hard to fathom anyone being so stupid as to make a threat like that, "the protocol every 6 months", to maintian incompatibility with a free version. With an "owner" like that, Bit Keeper needs replacement.
Friends don't help friends install M$ junk.
So, the threat is now that BK will have a locked-down encrypted protocol if any Free Software gets anywhere close to talking the protocol nicely?
That sucks so hard. This is what you get for dancing with the Devil.
"Elmo knows where you live!" - The Simpsons
That sounds waaaaaaaaay too much like Microsoft for me. I vote for Subversion. I guess the distributed repository things would be a problem though.
I mean, damn. That is openly hostile. I don't CARE if people are trying to write a competitor that can interoperate with out, those sorts of tactics simply aren't honourable.
Next time, when RMS warns about things like this, I for sure am going to listen carefully.
The bottom line is that if we work to simply play follow-up, we'll ALWAYS be behind, and BK will ALWAYS be seen as the superior choice.
If, on the other hand, we design a system that is intended to super-set BK from the word "go", then BK is the one playing follow-up, because there would be no advantage in using them if they didn't match the software we had.
One feature that would be nice would be the ability to "version" sections of an update. That way, you could test version X.Y.Z of a driver with version A.B.C of the kernel. (Useful, for example, if you distribute the driver seperately but want to test in-situ.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
... certainly need an upgraded PR department. At least the developer of BK is honest. It's seldom that we in writing sees such a clear committment to vendor lock-in.
In some cases, a proprietary tool is the best for the job. The most popular free software source management tool (CVS) is a complete p-o-s in many respects and unsuitable for large projects and for those with automated builds.
That said, a proprietary tool can never be the best for the job if the author/copyright holder is a complete dick. If it was known that the author of BitKeeper was a dick before Linus started using it, then the tool should not have been introduced; regardless, it is clear now that the guy IS a dick, and therefore RMS is absolutely correct in urging the kernel developers to play chicken and either force BK to play nicely with others or shoot the moon and wind up losing its free advertising.
[ home ]
Actually Mr. Stallmans opinion is quite a sound one. There's a very fine line when you're commercializing in the free software space (mind you, not that it's necessarily morally wrong or violates licenses). Red Hat for example must also be very, very careful not to piss off the community, but
If you are trying to copy BK, give it up. We'll simply follow in the footsteps of every other company faced with this sort of thing and change the protocol every 6 months.
This statement just about pisses on every value, which RMS represents and despite his personality - his achievements are beyond dispute.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Unless you live in a country where reverse engineering for interop purposes is allowed, which makes Larrys EULA invalid. Like most countries, in fact.
Now, CVS is less than perfect, but considering the entirety of FreeBSD is developed using it, as are many other HUGE projects, I think that's a bit rich. Certainly, if they needed the tools, then improving subv to the level where it worked for them would have been a good idea.
Sorry, kiddo, but Linux can no longer be considered "Linus's kernel," what with it being developed by hundreds of people at any given time. While RMS does often spout a lot of hyperbole, this time he's responding to M$-like threats, and he's calling for a solution that seems pretty proportionate.
And as for the flaming about HURD: suck though it may, it has a pretty intelligent design. While it wouldn't bet on it ever seeing production use, a lot of its ideas will no doubt filter into other systems.
This is not necessarily true.
A country or other jurisdiction (e.g., state, province, etc.) may either: (a) not have either statutory or case law that makes reverse engineering illegal, in which case it would be legal (i.e., that which is not legally forbidden is permitted); or (b) have either statutory or case law that affirmatively states reverse engineering is permitted.
However, in either case (a) or (b) above, that would not necessarily mean that one could not contractually (e.g., via agreeing to a license agreement) give up one's right to reverse engineer. In other words, in neither case (a) nor (b) above is it necessarly true that a contractual or license clause preventing reverse engineering is against public policy and is therefore void and unenforceable.
The fact that something is permitted does not mean it is required. The fact that you have a right to engage in an activity does not mean that you can't contractually give up your right to do so, or that the contract is unenforceable
My guess is that, as a practical matter, it is probably more likely that a contracual or license provision against reverse engineering will be upheld in case (a), where there is merely an absence of statutory or case law making reverse engineering illegal. The fact that you are permitted to do something (i.e., because there is no statutory or case law making it illegal) is by itself poor evidence that you should not be held to your voluntary, contractual promise not to do it, or that the inforcement of said promise would be against public policy.
In case (b), where there is affirmative statutory or case law recognizing a right to reverse engineer, a court *might* be more likely to find that a contractual agreement not to do so is void and unenforceable because it is against public policy, but I have my doubts even in this situation.
The key questions are as follows. Why should you not be forced to abide by your voluntary, contractual promise? Do we really want the government to say that we don't have the *freedom* to make such binding contracts and promises?
Only Women Bleed (Sex, Sharia remix)
The right way to do open source development is to add real value to your freely-released product.
The difficulty is that if your project is popular and successful, then other open source developers may release open code that moves in the same direction as what you're doing. Your special super-duper improvement to foo, foobar may be rendered obsolete by foobaz in a few short months.
That's a brutally competitive position to be in. The challenge to making money then is to develop lots of really good code add-ons or plug-ins more quickly and better than the buzzing swarm of random open source developers.
This kind of competitive landscape is absolutely fantastic for consumers, but can make life for the developer trying to make a living difficult. The only room I see is for services: configuration, mainenance, custom-patches for special customer orders. A genuinely useful, general purpose add-on to a piece of free software will be replicated freely in some given amount of time, particularly if it's not difficult to do and/or you charge too much for your add-on.
Strictly, Richard Stallman is right and correct. That if you give in on your principles about free software, then you cannot complain if the software owner suddenly locks up the work and suddenly starts charging you an arm and a leg for the product. But though Richard is right, has high principles and thinks everyone ought to be similarly principled, generous, cooperative, etc., this leaves festering the practical issue of earning a livelihood doing something related to computer programming.
Richard never provides a comforting answer to all the good-hearted programmers thinking "Yes, I'd like to be a generous individual and give away my software and prevent anyone else from caging it by stapling it with the GPL."
"Now that I've done this nice generous thing, how do I live nicely and not like a pauper?"
Good idealistic programmers should love programming so much they do it for the love of it in their spare time, like artists. From what I know of artists, 99.8% of them work at something else that doesn't pay too well. Few get to earn a decent living doing what they love to do. That's a hard reality to face for a budding programmer.
I'd be really curious to hear what Peter Deutch (Aladdin Ghostscript) and the commercial SSH developers have to say about idealism, commercialism, earning a living, competing against their own earlier free software, etc.
"Provided by the management for your protection."
Here's the problem:
McVoy's answer to the proprietariness problem has always been "there's no equivalent free program - if you want one write your own, but we're not GPL'ing bitkeeper." (Note, I'm paraphrasing)
The problem here is that he's saying not only can you not use the bitkeeper code, and not only can you not work on a competing project, but you can't even publish information about what bitkeeper does (i.e., reverse engineer the protocols). This is not "don't use our code", it's Don't mess with our file-format lockin.
Let me repeat that. He's saying "Don't mess with our file format lock-in."
That's what's wrong with Microsoft Word, that's what's wrong with proprietary software in general. He's crossed the line from not sharing with his competitors to actively trying to thwart them from competing with him at all by locking his customers into his secret format. Not sharing is grudgingly acceptable to most; secret file format lock-in is immoral.
microsoftword.mp3 - it doesn't care that they're not words...
It's his (McVoy's) license, and he can do any damn thing he wants with it that will be enforced by the courts. Period. He can update it rapidly, to prevent interoperability, he can use digital watermarks to prevent interoperability, and do any number of other things to stiffle BK-compatible projects. Indeed, McVoy can partake on a scheme to try to lock developers into BitKeeper as much as he can possibly do using both his license and various schemes with the software.
And, quite frankly, I don't think RMS is challenging McVoy's right to do that. It's exactly because of McVoy's right to do that that RMS is worried. Because BK is proprietary, it is very possible that McVoy could pull such a move. And, ya know what, I don't think that RMS is saying that he can't do that, or that if he does we should violate his license. Of course, he might advocate that in so-far as the courts won't enforce McVoy's anti-reverse-engineering strategies, we should reverse engineer for compatability.
Now, whether or not RMS read back through the thread -- and whether or not /.ers did -- is irrelevant. Perhaps McVoy was only saying that as an example of a worst-case scenario, but the point is that he could do it. In that case, the only thing off the ball about RMS' comment is the "at this point". From the beginning, a Free client that talks with BitKeeper with similar capabilities should have been in development. I do agree with subsequent posters that a Free alternative with similar capabilities has to exist first; RMS is simply suggesting that we mobilize an effort to do so.
social sciences can never use experience to verify their statemen
Believe it or not, the American laws, the DMCA included, and the American Courts interpretation of those laws does not apply to the rest of world yet. Bush may eventually change that with his army, but for the time being, as Allan says, "reverse engineering for interoperability" is legal is most civilized countries (and even in some not-so-civilised ones).
Actually, it's not illegal in the US either. In fact, the DMCA explicitly allows reverse engineering of copyright controls for interoperability and cryptographic research. The DMCA doesn't say anything about things that don't have anything to do with copyright controls, but reverse engineering has always been legal in general.
autopr0n is like, down and stuff.
The original poster here is falling into the trap, which the software companies want you to fall into, of believing that the license legally determines the terms of use and that the copyright holder has complete control over the code.
This simply isn't true. The terms of a license are written under the contract, business and even criminal laws of a particular jurisdiction. Any license term in violation of such laws is void and not part of the license agreement.
The people who write EULAs throw in everything they want under every possible jurisdiction. You aren't bound by it if it contravenes law in your jurisdiction.
The writers of EULAs also often throw in things that aren't valid in any jurisdiction and rely on your impression that you have to follow that term.
My advice? Don't be a rube.
You know that bit at the end of nearly every civil legal document that says "if any part of this contract is invalid the other terms remain valid"? This is what that term is about. Without it one contralegal term could invalidate the entire contract and not just the illegal componant.
Dear copyright holders. You have the right of copy,, not the right of total control.
Dear copyright licensees. If the copyright holder claims he has bound you to a non or contra legal contract tell him to get bent.
That's what Alan just did.
KFG
The slashdot article makes RMS look like a crackpot. He may be, but the detail is that he's not saying "replace BitKeeper! replace BitKeeper!". He's saying "if Larry McVoy (CEO of BitKeeper) threatens to change the protocol every 6 months, thereby making it hard for free software to be compatible with it, then BitKeeper needs to be replaced." This is a reasonable thing to say. RMS is only saying to replace BitKeeper if the developers become unfriendly to the free software community.
Is that RMS has a far greater grasp on the real world than most people.
That is evidenced by almost everything he warns against usually coming true...
The predictions he makes ARE based on human nature. That's what he understands very well, and why his predictions are so accurate - when someone takes the first step down a slippery slope, it does not take a genius to recognize they are going to fall. Only someone who is capable of seeing the slope in the first place.
"There is more worth loving than we have strength to love." - Brian Jay Stanley