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.
But then you'll get sued for violating BitKeeper's EULA, see this reply of Larry McVoy.
McVoy seems to play this game even harder than Microsoft, seeing that Wine's been cloning Windows for about 10 years now.
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
I didn't follow this controversy too closely when it came out (I could care less about kernels), but my impression then was that the best argument for moving away from BitKeeper was that Larry McVoy clearly had some personality issues. Now that he's promised to deliberately break interoperability with any compatible product, RMS looks reasonable in comparison. I know Linus is very agnostic about licenses, but it doesn't seem wise to collaborate with someone who has stated his opposition to one of the main reasons so many people use Linux in the first place. Is it really worth dealing with that asshole?
Oh, and LKML's web server isn't a very good advertisement for free software right now.
Unless you live in a country where reverse engineering for interop purposes is allowed, which makes Larrys EULA invalid. Like most countries, in fact.
BitKeeper, from what I understand, was the best alternative out there at the time. Unfortunately, the maintainer is proving buggy and may be unstable under certain conditions.
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)
ClearCase is a version database with a powerful query language. You can select file versions by label, date, owner, attributes, branch, etc. Because ClearCase is its own filesystem, it can (but doesn't have to) transparently update your view to the latest versions. (This feature is nice for server rollouts. If something is wrong, change the query and you're instantly back to the old.) Also because it is its own filesystem, ClearCase provides audit builds that tell you everything that was touched when creating a derived object.
Updates for your view are lightning fast. And it can version directory trees, which is sorely missing in most other products. It has a documented Perl API.
On the downside ClearCase is roughly as difficult to administer as Oracle. It is expensive in terms of dollars, server hardware, and network resources.
From: Alan Cox ...
...
To:
Subject: Re: Bitkeeper
If everyone spent the time replacing bitkeeper instead of beating up
Larry they'd get a lot further. I appreciate beating up Larry is more
fun but....
This 'discussion' has been going on months. Bit by bit, BK is becoming more and more like some kind of SCM version of MS Office.
A while ago another pact with BM was made - that they would change the native BK file format from an open, documented one to a proprietary one (for reasons of extra features, apparently). The quid pro quo for this was a CVS gateway.
Sounds like they are now going to start revving the network protocol as well as the file format, and you know, probably at some point other stuff will stop working so well. IIRC, the BK->CVS gateway isn't 100% perfect, and I could well imagine certain things having to be dropped "because CVS just can't handle it".
It's against the BK EULA to reverse-engineer it, even though the right to do that is enshrined in many laws (like in Europe). This actively bars people - not just from interoperating, but *any* developers of rival SCM systems. SVN developers are completely unable to use the 'free' BK to participate in kernel development, because it's against the licence. Even if they aren't trying to reverse engineer BK itself; just working on a competing system is enough.
And that's also the reason why Linux can no longer have a versioned file system built into it - it's against the licence of the 'free' BK users, like Linus.
This is so storing up problems for later. It's true - it doesn't cause a huge problem at the moment. But it will do in years to come. More and more of a problem as Linux development is locked into BK. Personally, I think this is such an important issue, and I can't believe people are walking into this. But, that's their call I guess. Time will tell who is right.
"Elmo knows where you live!" - The Simpsons
Here is the article that RMS responded to.
Has some more interesting stuff in it.
Brielle
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)
Everyone should probably read where the discussion came from (http://lkml.org/archive/2003/7/17/124/index.html) before commenting on it. Here's a copy.
---
With apologies to the list for the off topic post (I'm really trying to
not annoy you guys but some stuff we can't let slide due to legalities).
On Thu, Jul 17, 2003 at 01:05:05PM +0100, Rory Browne wrote:
> Would the conduction of research(and publication of results of same) on
> the bitkeeper formats/protocols, preclude users from using the Free version
> of Bitkeeper, for the research project?
Yes, for the research project and/or anything else.
> Would the carrying out of such research using the free version of
> Bitkeeper, prevent them from developing a product which contains
> substantially similar capabilities of the BitKeeper Software in the
> Future, assuming that all copies of Bitkeeper were destroyed before the
> development started?
Yes.
> Would previous activity in the area of developing a product which
> contains substantially similary features to Bitkeeper preclude users from
> using the Free Bitkeeper software?
Yes.
Each question above can be restated as "Would it be OK if we used BK
in violation of its license?". The answer is no and if you did that we
would be forced to come after you, if we don't and some large company did
the same thing we would have a much tougher time enforcing the license.
Trademarks and licenses tend to lose their value if you don't enforce
them.
Your questions indicate one of two things: you either have a burning
desire to work on BK itself or a burning desire to copy BK. If it's
the former, that's easy, send us a resume and if you are a good engineer
we'll hire you, we need good engineers with a solid understanding of file
systems, distributed systems, graphs and sets, and/or human interfaces.
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. Since you would be chasing us you can never
catch up. If you managed to stay close then we'd put digital signatures
into the protocol to prevent your clone from interoperating with BK.
Instead of trying to copy our work in violation of our license, you'd be
far better served by doing some new work. If you like SCM then either
work here, work on some other SCM unrelated to BK, or expect a costly
discussion with a lawyer. I realize this is an unpopular position but
that's tough, it's our code and our license and you obey the rules
or suffer the consequences. The license is a contract and it's an
enforceable contract, we have gone up against a company who spends more
on lawyers in a week than our annual gross revenues and successfully
enforced it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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."
> [why is hard to write a good revision
> control system?]
Many reasons. Here are a few.
1) precision. If your mp3-player crashes -- big whoop. You'll fix it, or report a bug, or try a different one. If you run your project on revision control system XYZZY for a year, and then discover that it has corrupted 6 month old data beyond repair, now you are really screwed. There are many features in revision control systems that aren't critical -- bugs can just be fixed. But there's a core part of revctl that has to be very robust.
2) balancing art and science. I suspect that most casual uses of, say, CVS are just thinking about checking out trees, maybe updating them, maybe checking stuff in. When projects are large and busy, though, suddenly branching and merging and history auditting and all the "obscure" features are very important. The problem for the designers/authors of revision control systems is that for those obscure-but-important features: There Are No Right Answers. If you were to try to develop a purely mathematical theory of what those features should do, the fundamental theorem of the theory would be "it is impossible to implement them." In practice, the best you can do is to implement _approximations_ of what those features would ideally do. And worse, there are gazillions of different approximations to choose from. So there's a serious challenge there: to pick a subset of the possible that adds up to the most useful approximation of the impossible.
4) making wise implementation decisions, especially regarding time and space performance characteristics. Revision control systems ultimately wind up managing a _lot_ of data, and keeping that data around for a _long_ time. In an implementation, you have to make decisions about how to store that data, trading off factors such as the complexity of the implementation, the amount of storage space you'll use, and the cost of retrieving data. Over the lifetime of a deployed revctl system, you can expect factors like CPU speed and disk economics to evolve profoundly far. As basic, text-book software implementation tasks go -- revctl is a fairly challenging one.
5) distribution. In terms of what users are starting to demand, distribution is a comparatively new thing in revision control. Remember, it wasn't _that_ long ago that CVS didn't even support remote access to a central repository, nevermind distribution across mulitple repositories. Taking distributed operation into account, the mix of slow, medium and fast network connectivity in the world, the economics and politics of administration -- distribution amplifies the challenges of (1)..(4).
I can't believe this wound up on Slashdot. First of all, the vger list admin already shitcanned the thread from LKML because it's just inappropriate there. Now it moves over here for further idiotic discussion.
If you read the original thread between McVoy and Rory Browne, you'll see that Rory started the whole thing by posting a BitKeeper licensing question to the LKML. I'd almost say Rory was just trolling. From there, McVoy's personality took over and he tossed out a worst-case scenario (rewriting the BK protocol to stay ahead of people trying to reverse-engineer it), and that's what spawned RMS's post.
Okay, so I won't disagree that having open protocols and open software is a good thing. But this is hardly a good example for RMS to pick on. There are completely open CVS and SVN gateways into BK, so at no point is the Linux Kernel code at risk. Major kernel hackers such as Alan Cox don't even use BK themselves - they use CVS or SVN to do all their kernel development.
If you read further down the thread, you'll find that even the most rabid of anti-BK people on the list concede McVoy's point - it's his product, protected by his license, and he can do anything he damn well pleases with it. There should be no more upset over this than when the Linux community went after Linksys to get them to obey the GPL for their router software.
The thread ends with a number of posts by people thanking Larry for what he's done by providing tools that make our kernel get better. That and a number of other "we don't need to rehash this again" messages. It's apparent that people are tired of this issue.
Just check this features:
- Aegis supports large teams and large projects.
- Aegis supports change sets.
- Aegis is designed around incremental development. It records these increments as file change sets, and can reproduce any historical increment.
- Aegis is designed for repository security (availability, integrity and confidentiality).
- Aegis supports distributed and multiple repositories.
- Aegis supports multiple lines of development and multiple simultaneous active branches.
- Aegis supports branching to any depth.
- Each project is a separate repository, with separately configurable policies.
- Aegis enforces a development process which requires that change sets ``work'' before they may be integrated into the project baseline. Works includes requiring that change sets build successfully, and (optionally) that they include and pass tests. It also ensures that code reviews have been performed.
- Aegis supports both push and pull distribution models, and many distribution topologies. Aegis' normal development process is used to validate received transactions before accepting them.
- Aegis supports long transactions, also known as ``branches'' or ``lines of development''. This allows appropriately created changes to be treated as if they were projects, and thus to have changes made to them. This allows a hierarchy of changes within changes, to any desired depth.
- Aegis runs on almost any flavor of UNIX (including even cygwin). Self configuring using a script generated by GNU Autoconf.
- The error messages of Aegis have been internationalized. This means that error messages can be in your native language, if a translation has been provided. More translations are welcome.
- There is an intranet Web interface, which is installed automatically when the install script discovers a web server. This interface allows browsing of much of the Aegis meta-data, of all publicly accessible projects.
- There is a script-based reporting facility, allowing many custom reports to be generated from the Aegis database. There are also many report scripts distributed with Aegis.
- Aegis is mature software - it was first released in 1991.
Now tell me, what are features of BK, that are missied in Aegis *AND* are essintial for Linux kernel development?Less is more !
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
Including the US, as it happens, which is how Compaq created the first clone of the PC BIOS. The DMCA bars breaking access control systems, not reverse-engineering software. In some cases (software DVD players) the two overlap, but usually it's clear: reverse-engineering Office to make it work properly under Wine is fine, cracking CSS to make a DVD player isn't (you need to license the relevant algorithm, not just copy it from someone who has). The one caveat is that reverse-engineering a patented system doesn't give you any right to copy it: you still need a patent license. That's not US law, though, it's international law (Berne convention?)
If you don't read (and thus don't agree to) the GPL, then standard copyright law applies to you with regard to using GPL'ed software. You can use it however you want for your own personal use, but you can't distribute the code or modified versions of it, or the binaries.
The GPL only grants extra rights that are *not* granted to you by copyright law. Thus, it is most definately enforcible. Furthermore, if you don't read it, then you have to assume that standard copyright law applies. If you assume that standard copyright law applies, you can't distribute it or modifications; thus, it will be impossible for you to violate the GPL.
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 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.