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."
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.
Here is the article that RMS responded to.
Has some more interesting stuff in it.
Brielle
As usual, people have not taken the time to read the whole thread. Here is one post by McVoy that sheads a bit more light on the subject. Please note that I am not trying to pass judgement one way or the other, but rather adding more information, since too few of the posters here have bothered to read more than Stallman's post.
Below is one of Larry McVoy's comments in the BK thread"Those who make peaceful revolution impossible, make violent revolution inevitable" - JFK
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
Yes, we really do want it to be illegal to sell our rights. Should you allow that you would see public slavery quite fast(underground it happens still, mainly with sex trade and immigrants). Basic rights aren't rights if you can give the key to them away.
world was created 5 seconds before this post as it is.
"Judge, I want to violate this license on this product that I got for free because it's not free enough".
Except, as Alan just pointed out, in the part that Larry has quoted, that the part of the license which forbids reverse engineering for the sake of interoperability is not enforcable in most of the world. If it isn't enforcable then you can't actually violate it.
Besides, have you considered that it is that license you appear to dislike so much which provides for the product, the hosting, the free public machines, the support, all of that? It's a pile of money and time and I don't see RMS steppng forward with an open checkbook.
Maybe someone should clue Larry in, but GNU have servers around the world hosting both the GNU project itself, the FSF and GNU Savanah. They manage to keep them running, I fail to see how keeping a few extra source control servers running would be an issue for GNU.
Bitkeeper may be better than the current Free alternatives, but it isn't Free software. Larry seems to be of the attitude that a freebee licence and a couple of servers somehow means we should be building golden idols in his image. I don't buy it, sorry.
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).
Richard is as smart as a whip. If he groomed himself like a blue suit IBM type of yore, he would be unstoppable. The only excuse some individuals have for not listening to Richard is personal prejudice against Richard's way of life. Whatever you think of the way Richard lives, there is no denying his brilliance. He called it right on Bit Keeper from the start.
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.
I think the world will be surprised at how many of the "extremist", "paranoid", "ideological", "smelly hippy" ideas that Stallman has put forth will come true just as he has predicted them.
the guy's a visionary on a level that even much of today's technical crowd can't fully grasp.
pr0n - keeping monitor glass spotless since 1981.
You entirely miss the point. Most countries in the world have laws that explicitly make reverse engineering for the purpose of interoperability legal and make any license provisions or contract clauses stating otherwise null and void.
This includes most of Europe - In almost any European country you can not be forced to sign away your right to reverse engineer a product for the purpose of interoperability.
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?
Because some rights are so fundamental and important that they need particular protection. By making it impossible to sign them away, there is nothing to be gained from trying to trick or coerce you into signing them away.
Your freedom has that status in any country on earth: You can't sign yourself into slavery. The reason is that if it were possible, your freedom would be weakened - you could be coerced or tricked into signing it away, and could never change your mind.
Many less vital rights are also protected in the same way: In most countries you can't sign away certain health and safety protections for the workplace, and can't sign away protections against unfair dismissal and similar rights, because the difference in strength between employee and employer in many cases would render the protections worthless if you could sign them away, in particular for the employees with least leverage who would be most likely to suffer from it.
Similarly, reverse engineering is protected in most countries because the right to compete in the marketplace is seen as paramount to a free market in most of the world, and preventing reverse engineering would create massive barriers to entry, and massive potential for consumer lock in.
There are literally hundreds or thousands of rights you have that you can't sign away, or can't sign away without getting specific concessions in return. They are usually there because you would have LESS freedom without them.
Exactly. You do not have to follow the GPL.
It's not an EULA. EULAs try to forbid you from doing things which are legal. The GPL allows you to (optionally) do things which are illegal.
Read section 9 of the GPL:
9. You are not required to accept this License, since you have not signed it.