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)
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.
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.
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.
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
It's worth a look, if only for the ideas.
Easy, automatic testing for Perl.
ah people do not make the saem mistake that RMS did in not reading MCVoy's org post..
He was asked by the community to do a protocol rev and he was commenting on someoen else volating the bitkeeper license and how his reeactions to community requests with new fixes in protocol and etc will always defeat someone wanting to violate the license..
Don't Tread on OpenSource
Here is the article that RMS responded to.
Has some more interesting stuff in it.
Brielle
It's true that FreeBSD uses CVS, but we also use Perforce for some out-of-tree work that later gets merged back into CVS. Our experience has been that CVS doesn't work real well for long-running development branches that need to get resynchronized periodically with the CVS HEAD.
(Examples of long-running branches in our Perforce tree are those for the SMPng project, and for works-in-progress for newer architectures such as ia64, amd64, etc.).
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...
> Personally, I think this is such an important issue, and I can't believe people are walking into this
They traded convenience for liberty. And the 'They' is Linus.
I followed the BK thing from the beginning. It is 100% certain that it will clash sometime in the future.
First because RMS is right (you should not use non-free software even if it is 'easier')
Second, because larry changed opinion a lot of time. He clearly cannot be trusted. He just want to use linux as a marketing tool for his product.
Third, because no onelooks at the long time implication. The development process is hugely important (aggraved by the fact that most kernel developers are not even aware of the existence of a process). And now, a commercial entity control the process.
BSD development is so much mature than linux development that it is not even funny anymore (how funny. [The irony is that the BSD folks are supposed to be less free(dom) than linux folks].
As a side point, I think that newscomers to Free software take freedom as granted. They don't recall time where you had to pay to get a compiler, to pay to get an operating system, to pay to get manuals. And sometimes, you were refused the access to the dev tools because you were not a professional. And when the tools were free, you could get them removed from you at anytime (ie: becoming obsolete). I learned to value my freedom. I suspect that most new hobbyist developers take the freedom of the tools as granted, so closed-source but free is free enought.
I only hope that when it'll clash (not *if*, but *when*), people have learned something. This is why I hope for a huge clash (like BK getting bought by microsoft, which is probably Larry business plan).
--fred
For a few months I have been feeling that a good revision control system is really needed for the open source community. CVS has numerous problems that I may describe later in some article. I've started looking at other systems out there and designing things. Thankfully, I've never used BitKeeper so I am not violating their license. I had no idea that they had that terrible clause in it. If Microsoft had it in Windows, no Linux kernel developers could use Windows! A "similar system" is a broader definition than "a clone".
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 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
Correct: the patent treaty was signed in Geneva (but not named after Geneva, for obvious reasons!)
And patent laws are national laws, IMHO there no international rules.
The delegates who met in Geneva on June 1, 2000 to sign the Patent Law Treaty would be surprised to learn that. (There are various other, prior treaties referred to by that treaty, but this seems to be the most recent.)
So: patent law is indeed provided for by international treaties, as with copyright.
In general, RMS's position with regard to "free software" (as in freedom) is RARELY off-target. This is because his motivations are simply an outcome of the reasoning that code, like any other form of expression, is crystallized thought, and as thought should be cherished and spread to as many as possible to share it's benefits (and, in some cases, drawbacks). The GPL is one tool that helps ensure the spread of thought in code form. It truly is a disease to think that thought products (affectionately known as "intellectual property") can truly be contained. So why not embrace the fact that we as human beings are tremendously adept at copying, processing and synthesizing thought products.
The other tool at his disposal is a relentless pursuit of the goal that all software should be "free" (again, as in freedom). Software that is not free is always suspect: the "owner" that reserves rights to restrict others in their ability to utilize "their" software is prone to an "absolute power" syndrome. Their intentions may start out noble, but that can change at any moment. Sad to say, but it appears the Mr. McVoy may be on the verge of this. I remember reading the mailing-list archives when this first blew up. Mr. McVoy really has drawn a mental line in the sand that he's not willing to cross. It is unclear if he has the strength of character to let go of his "closed-source" ways. It would really be nice if he did.
Unfortunately, in pursuit of his "free" software goal RMS is likely to piss people off, hence the established rancor at him. Fortunately, RMS has the resolve to see past this and move on. It will be a rocky road to enlightenment for most (it certainly is for me, and I can't even begin to claim any form of enlightenment), but it certainly is liberating.
A replacement for BitKeeper should be developed post-haste, subversion looks promising, but needs many features to completely replace BK. I personally use subversion in my own projects and found it to be quite workable.
Food for though (pun intended): Are your thoughts yours? Do you own your thoughts? If so, how do you exert thought ownership rights? If you never existed would your thoughts exist in others? Now, granted, there clearly are expressions of my thought process that others recognize as "me", but at work, if others were confronted with the problems you work to solve every day what is the likely-hood that others would produce the same or similar solutions as yours? I find it amazing looking at all of the various Web site building technologies out there built by many others how similar many of their solutions are to the ones I produce. The evidence that elements of "my" thoughts are going on in other people's heads oh so clearly demonstrates the fact that "intellectual property" are hollow words. Pursuing the task of squirreling away your thoughts and jealously guarding them is the labor of sick-minded people. Even writing what I writing now is not new. Most of you have read "drivel" like this before, but it is still worth mentioning. Just think about it.
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.
Agh! Not another person who thinks the GPL is anything at all like an EULA! That's the third one today! We should get a page on snopes debunking this myth. Or you can just search for it.
I suppose I should also make some boilerplate to explain the difference. Here's the short version:
The GPL permits you, at your option, to violate the copyright on a piece of software, which is otherwise against the law.
An EULA (attempts to) forbid you, without your consent, from re-selling software to another person, which is completely within the law. (Different EULAs may forbid many other things)
You are NOT required to agree to the GPL before using a program. (That's why you've never seen it- because you didn't have to agree to it, unless you were actually going to look at the source). According to the software publishing houses, you ARE required to agree to an EULA before using their programs.
I feel that if such a case were pushed to the Supreme court, however, EULAs would be invalidated. When you sell someone a box of software (or a book, or a music CD), you are giving him permission to use it normally in private. Once he's got that permission, you can't interpret his normal use as consenting to some extra contract. "By closing this web browser window, you are consenting to mail me $500". That's not a valid license, because you're allowed to close the window without permission from me. Once you buy software and have walked out of the store with the box, you're also allowed to use it without further permission, but that's not what software publishers claim.
PS. I've answered this question so much today, I can actually quote GPL section 9 verbatim: "You are not required to abide by this license, as you have not signed it. However, nothing else gives you permission to redistribute the software, which is a violation of international copyright law..."
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