RMS Calls On Linux Developers To Replace BitKeeper 795
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."
unbelievable. (Score:4, Insightful)
Re:unbelievable. (Score:5, Insightful)
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 threadRe:unbelievable. (Score:3, Informative)
Re:unbelievable. (Score:4, Informative)
Re:unbelievable. (Score:5, Insightful)
That has little to do with the content of the thread. The LKML community long ago split into `Bitkeeper is evil' and `I don't want to know, just let me use it' camps, and if you read the thread, it's the same old people bitching at one another.
Re:unbelievable. (Score:5, Insightful)
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.
Re:unbelievable. (Score:3, Insightful)
Re:unbelievable. (Score:3, Insightful)
He always goes on about how he is doing Linux a huge favor, but his company is getting by far the better end of the deal.
When was the last time you heard BitKeeper mentioned on any article or site where Linux was not also mentioned? Linux is probably the reason the vast majority of Slashdot readers have even heard of BitKeeper. Go to the BitKeeper [bitmover.com] site and look how almost all of their news items are about Linux.
This guy is a complete asshole and almost a charicature of all the worst things about pr
Re:unbelievable. (Score:3, Informative)
Re:unbelievable. (Score:4, Informative)
Perforce [perforce.com] has had this for many years. (It too is not free, but it's not that huge an improvement; I am not familiar with the state-of-the-art in free software, but I would imagine at least one system has atomic checkins.)
Re:unbelievable. (Score:5, Informative)
Subversion also has atomic checkins, but it suffers from severe reliability and design issues (read the arch-users list archives for an analysis of the latter).
Allan is right (and FSF money will be there) (Score:3, Informative)
And FSF usually puts its money where RMS mouth is. Take Savannah [gnu.org], for instance. An open SourceForge clone (product, hosting, free public machines, suppor
Re:Allan is right (and FSF money will be there) (Score:5, Informative)
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?)
Re:Allan is right (and FSF money will be there) (Score:4, Informative)
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 [wipo.int] seems to be the most recent.)
So: patent law is indeed provided for by international treaties, as with copyright.
Re:Allan is right (and FSF money will be there) (Score:5, Insightful)
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.
Re:unbelievable. (Score:5, Interesting)
The BK license is a click-through EULA like any other. Just like all of them, it's not valid.
Unless your country decides to pass a law [loc.gov] making them binding, it won't effect you. (Even if your nation allows electronic contracts, the software vendor would have to take some steps to record the agreement in a valid manner. BitKeeper, like most publishers, does not do that)
If a person permits you to download his software without obtaining an agreement as to how you'll use it, you can do whatever you want (execute the code) so long as you don't violate copyright (make copies of the program, which is unnecessary if you've already got a copy from the publisher)
Re:unbelievable. (Score:5, Informative)
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.
Re:unbelievable. (Score:4, Insightful)
And if you don't agree, then you still have the right to do everything you're allowed to do by default, just like you are with any software accompanied by a EULA which you did not agree to.
bzzt, WRONG MORON (Score:5, Informative)
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.
The GPL is not an EULA (Score:4, Informative)
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..."
oh, go on. (Score:3, Insightful)
Who wants to do that? Copying Bitkeeper's feature set is all that's required. No one's dumb enough to say that can't be done are they?
If they want to make it hard to get current work out, it's all the more reason not to put work in. The Bitkeeper people should be happy that people admire the feature set and work to make it better than free versions or simply charge for the hosting they provide. S
Remember Connectix vs Sony? (Score:3, Interesting)
IANAL, but one of the issues is that copyrights protect expression but the actual useful ideas are not subject to copyrights but rather patents. So I see no reason to think this is a copyright issue per se.
The license however is one which contains restrictions which *may* be valid under contract law. So this may be an argument of "You agreed not to by using
Re:unbelievable. (Score:4, Insightful)
The conversation continued to the point where Larry (as usual) got exasperated and said (paraphrased) "We give free BitKeeper to the community for any use other than putting us out of business. We have made all DATA freely available, and you are free to use any tool, including CVS, to work with that data. Basically, if you want to use our tool you are doing so by our good graces, so quit complaining."
While maybe not the most politcally correct person out there, I see nothing in Larry's statements to disagree with. BitKeeper is in use because it's better than the available free tools. The use of BitKeeper has done wonders for Kernel development -- the changelogs are the most visible example, but ask Alan Cox (who doesn't use BitKeeper) if Linus has been easier to work with since adopting BitKeeper. And if Larry wants to make it difficult for people to copy his product, that's his business -- he has gone out of his way to make the data freely available, and he has also gone out of his way to clearly draw a line between what is BitKeeper (his) and what is owned by the community.
Re:unbelievable. (Score:3, Interesting)
Please somebody point out the weak link in my reasonning. I can feel it is warped but can't fail it.
Re:unbelievable. (Score:5, Informative)
Make no mistake, GNU doesn't like the LGPL, and they are attempting to do revisionist interpretations of what the LGPL says in order to make LGPL software unappealing to companies which make proprietary, closed source software with restrictive licenses.
Despite their apparent attempt to use ambiguous wording and specious re-interpretation, section 5 clearly states that no, BitKeeper is not subject to section 6.
Re:unbelievable. (Score:3, Interesting)
The GNU foundation's people? Are these the same people who have a strong dislike of LGPL? Are these the same people who have strong political feelings that all software should be free?
Here's the first paragraph of section 5:
BK - RMS was right again (Score:4, Insightful)
That sucks so hard. This is what you get for dancing with the Devil.
Re:BK - RMS was right again (Score:3, Insightful)
If the guy that spent money developing the product asks that you not make a direct, compatible, free software GPLd competitor then I think under the circumstances that that is only fair. I mean, he's trying to make some money here, and he's not making it from the Linux community. That's certainly not illegal, and it's not inherently immoral (unless you're Richard Stallman). I mean look at Red Hat, Mandrake or
Re:What happened earlier in the thread? (Score:5, Informative)
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.
Re:What happened earlier in the thread? (Score:3, Interesting)
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.
Th
Re:What happened earlier in the thread? (Score:3, Interesting)
Don't forget the youngsters to computers that don't recall a time when software or hardware came with a full, detailed manuals Normally a set of them that required a reinforced bookshelf to hold the weight of them. And detailed ment a lot of source code and schematics. You had to pay for it of course, but you got what you paid for: good stuff. Well not good in all senses, there were bugs in the software, but in general it was better than software from MS in the '90s. (MS has improved quality or so I
Re:What happened earlier in the thread? (Score:3, Insightful)
I can download a tarball of the kernel source, and I don't need BitKeeper to view it, edit it, redistribute it, etc. How are we being locked in?
Worst case scenario; Linus gets fed up with the license, checks his source out of BitKeeper and checks it into CVS or something else.
This is exactly what Alan was trying to point out (Score:4, Insightful)
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
Jesus (Score:4, Insightful)
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.
Re:Jesus (Score:5, Funny)
Naah. Microsoft would never SAY such thing. (they do this secretly)
Re:Jesus (Score:4, Insightful)
Although this would only be a problem if someone did try and replace BK with something BK-compatible... no reason for them to do it if they don't feel commercially threatened. But then I suppose having the Linux kernel use BK is a bit kudo to them, so they'd want to keep it.
I don't think Linus would stand for much of that though, somehow.
Re:Jesus (Score:5, Insightful)
What you fail to understand... (Score:4, Insightful)
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.
Re:Jesus (Score:5, Insightful)
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.
Re:Jesus (Score:3, Funny)
Proficient in the use of small arms.
Re:Jesus (Score:3, Insightful)
So why Subversion? Why not something like Arch, which handles this?
Re:Jesus (Score:3, Insightful)
There is always arch.
Re:Jesus (Score:3, Interesting)
He actually got a lot of sympathy on the LKML. One of the problems is that people hate RMS so much that they will rally around whomever RMS is debating, no matter the merits of the argument.
I find it funny that RMS often predicts doom and gloom, people call him an idiot, and a few years later something happens (like this) and he's proven right. RMS said BK
Re:Jesus (Score:5, Insightful)
Quit with the RMS bashing, you smelly AC troll.
Re:Jesus (Score:3, Interesting)
And apparently, some of them are are so mesmerized by RMS's charisma that they downplay their own contributions.
Why clone, when we can do better? (Score:5, Insightful)
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.)
Re:This is how evil is born (Score:3, Informative)
For a few months I have been feeling that a good rev
Re:This is how evil is born (Score:3, Insightful)
Enbracing and extending is good and healthy. It allows vendors to play with advanced features not part of standards. The problem is when it is used to lock other vendors out. THis is the fundamental problem with the way MS does it. Surely you aren't saying that every database manager should stick simply to the ANSI and ISO standards and not support any other features that may be useful (like extensibl
The BitKeeper company.... (Score:5, Insightful)
"Best tool for the job" (Score:5, Insightful)
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.
Re:"Best tool for the job" (Score:3, Interesting)
A proper comparison would be with Subversion [tigris.org]. CVS, while certainly not a POS, is showing its age. Subversion is supposedly "CVS brought up to date".
Why did Linus go to BitKeeper in the first place?
Re:"Best tool for the job" (Score:4, Insightful)
Because subversion wasn't anywhere near ready, CVS is broken by design, and the email/patch system that Linus previously used was wasting his time and harming the rapid development of Linux. A commercial SCM would have done the job but who can afford the exorbitant license fees of something like Clearcase? Larry offered a free license to use BK so Linus gratefully accepted it. It really was a no-brainer.
No matter what anybody says, Larry isn't the bad guy. His software isn't cheap yet he offered the gift of a free multi-user license to Linux developers. That's a pretty generous donation in itself, but Larry also wrote extensions that Linus requested, built a CVS gateway, and has been very responsive to the needs of Linux developers. Ok, so Larry has all the tact of an axe murderer but that's part of his charm. His blunt and abrasive nature doesn't detract from the quality of BK.
Just keep in mind that nobody is wrong here. There are no bad guys. There are just people who have different priorities. For Linus, Linux is #1 priority. For RMS, free software is #1 priority. For Larry, BK is #1 priority. Cue the thunder and lightning.
It was a mistake to miss Aegis (Score:5, Informative)
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?Re:It was a mistake to miss Aegis (Score:3, Informative)
Someone posted earlier in this article that one of the key things Linus wanted was the ability to run the project via e-mail, which BK allows. Does Aegis offer that?
Re:It was a mistake to miss Aegis (Score:3, Informative)
I have no idea if BK is any good, but I do know there are flaws with CVS and it's free kin. Arch hasn't caught on, and Subversion development has been painfully slow (first release was in 2000/10) and it seems like a very heavy installation. Features l
Re:"Best tool for the job" (Score:5, Interesting)
All these things, software included, share a fundamental characteristic: they are all forms of art - a personal expression of the author that can be appreciated and enjoyed by others for nothing more than what other people perceive that it adds to their own life.
I certainly wouldn't ever say that nobody has any rights to give away any their creations, but I don't think anybody has any rights to dictate whether or not someone else should be allowed to seek financial compensation for their endeavors. Stallman is perfectly within his rights, IMO, to encourage, however strongly, the creation of free alternatives to commercial software, but he doesn't have any business to keep telling particular commercial software authors to stop doing what they do after they've already told him thanks but no thanks.
Re:"Best tool for the job" (Score:3, Interesting)
Dude, quit with the purple prose. Software is not an extension of body or mind. It's some instructions to a CPU. That's very different.
I can type really pretty fast, but the keyboard is not an exension of my body, it's well, a lump of plastic with loads of buttons on.
Software may be a tool like Photoshop, or it may be art in itself, or it may be something really frigging boring like a printer driver.
It's just not special in a
Re:"Best tool for the job" (Score:3, Insightful)
One implies the other. If a program is freedom-free, it's already beer-free. (The reverse is not true)
99+% of all software sales depends on the fact that the product is not free (beer or speech). If customers are moderately well informed, the only time they'll pay for the software is when it's too inconvenient to find a friend to copy from. (Witness Red Hat's dropping out of
Re:"Best tool for the job" (Score:3, Interesting)
RMS (and alot of his followers, me included) seeks to make proprietary software obsolete and non-existent.
When you make something non-existant, you destroy or remove it. I stated this and you reaffirmed it.
Does mean that noone can charge for software? No, it simply means that all software would be free as in freedom, price is mostly irrelevant.
This is the single biggest lie in the GNU/Free Speech movement. As l
Re:"Best tool for the job" (Score:4, Informative)
The specific shortcomings of CVS in terms of the Linux kernel project is that the ability to write to the respository is all or nothing.
1. If you want a developers to be able to make changes, you basically have to give him 100% write access. (Yes, it's possible for others to back out his changes if he damages something, but this is messy.) (And yes, it's possible to create auxilliary scripts in the CVSROOT area to accept/reject individual parts of a checkin- but it would be a separate development project to write those scripts)
2. If you want developers to be able to make changes, you basically have to give them TCP/IP access to the repository 100% of the time. CVS doesn't contain "workflow" features, where a person submits a change and it is queued up for the maintainer to inspect and accept/reject.
With BK, Linus can be the only person able to change the actual source code. Everyone else mails him a "change set" file, which his local copy of BK helps him inspect and accept/reject it as he wishes. When the changes are accepted, BK handles the meta-data, automatically merging in the revision history of the edits.
Yes, it would be possible to implement something along those lines with CVS- Linus gets patches in his email (in Larry Wall format), applies them to his tree, and checks it into CVS if he approves. But BK provides many little helps to automate this.
There are other advantages to BK which you can find on LKML. All in all, BK and CVS are almost too different to be called competitors. It's like comparing rpm with apt-get.
Sound (Score:5, Insightful)
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.
Gonna have to side with RMS on this one... (Score:5, Interesting)
Oh, and LKML's web server isn't a very good advertisement for free software right now.
Filesystem SCM a la ClearCase (Score:5, Informative)
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.
Re:Filesystem SCM a la ClearCase (Score:3, Informative)
There is an open-source clone of ClearCase (my favorite SCM system), called Katie. You can search for it on Freshmeat.
I don't know what level of quality its at, but I believe the author is eating his own dog food and using Katie to develop Katie.
Personally, I would love nothing more than to see him adapt Katie as a front-end for SVN (Which has a good overall architecture).
Katie also uses PostgreSQL (ClearCase uses Raima's dbVista, btw). Subversion uses BDB and really needs a better back-end eng
A replacement is needed (Score:3, Interesting)
It's clear now that you want a real database in the back end. Every major app that had an ad-hoc database in the back end has eventually run into problems. Look at Sendmail, BIND, etc. The replacements that work well have a relational DBMS in back. SCCS, RCS, and CVS all had the same problem.
Now that we have several good open source databases available, there's no need for ad-hoc databases. This simplifies the application enormously - all you need is the logic for version management and monitoring.
One thing I'd suggest for a replacement is heavy use of message digests (MD5, etc.) as identifiers and checks. Everything should have an MD5 of its uncompressed version carried along. I'd go so far as to store files by MD5, not name, so that if two copies of identical bits are stored, they're not duplicated. This makes efficient renaming and sharing, the curse of version control systems, effective.
On the user interface side, take a look at Tortoise CVS. It's very convenient, although the integration with CVS is a bit painful, because the protocol (text messages from the server) is ill-defined.
Time for something altogether new. Darcs, perhaps? (Score:4, Interesting)
It's worth a look, if only for the ideas.
Aegis? (Score:3, Interesting)
First, it's very mature. Second... just check the feature list for yourslef.
People please read (Score:4, Informative)
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..
The article RMS responded to (Score:5, Informative)
Has some more interesting stuff in it.
Original message from Larry McVoy (Score:5, Informative)
---
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
for those of you who dont subscribe to the mailing (Score:3, Interesting)
Message: 16
Subject: Re: Bitkeeper
From: Alan Cox
To: Valdis.Kletnieks@vt.edu
Cc: Larry McVoy , Richard Stallman
Linux Kernel Mailing List
Organization:
Date: 18 Jul 2003 23:16:57 +0100
On Gwe, 2003-07-18 at 22:54, Valdis.Kletnieks@vt.edu wrote:
> Now what's this about the "simply irrelevant"?
"in most of the world"
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....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pleas
Open Source Development is Hard (Score:5, Insightful)
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.
Blown way out of proportion (Score:5, Interesting)
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.
"don't mess with our file-format lock-in" (Score:5, Insightful)
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.
McVoy a @$#%, Arch/tla a strong alternative. (Score:3, Insightful)
Even forgiving its author's antics, I'm still not fond of arch. Back at the time, its repositories tended to corrupt at the drop of a hat, and grow far larger than need be (particularly compared to the alternative I'll be introducing shortly).
TLA, the C version of Arch (a version control system by Tom Lord), has much more promise. It has the same distributed repository paradigm as BitKeeper, but is under a Free license. It doesn't have the graphical merge tools, but is written such that adding one would be very easy -- and it *does* have some nifty extra features such as the star merge algorithm (which prevents spurious conflicts in the case of multiple branches which are merged back and forth -- a common situation in open source development).
Ever wanted to make your own branch of a project but didn't have write access to the repository? Been annoyed by CVS's lack of support for versioning things like directory moves, file renames and the like? If files are given internal tags in arch, the VCS will even detect file renames *automatically*, without being told at all!
One final, strong, item in favor of arch: The repository format is simple and well-documented, and by its design unlikely to corrupt in ways that can't be fixed by hand. None of the crud like CVS's rewriting
So, to sum up: Arch is nifty. Arch is good. Arch is written by someone who is much less of a $@%#% rat bastard than Larry McVoy. You should try arch.
Oh, you want to know where? See the arch wiki [fifthvision.net] or Tom Lord's home page [quackerhead.com].
Have fun!
What does RMS have to do with it? (Score:3, Insightful)
McVoy is right -- that's why BitKeeper's wrong 4us (Score:5, Insightful)
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.
buying out BitKeeper vs. developing a replacement (Score:3, Interesting)
McVoy is giving the software away for free, as in no cost. Let's not confuse that with Free as in freedom.
As for buying out BitKeeper and GPL'ing it vs. developing a replacement, it's purely a strategic decision, based on -- I think -- two factors.
(1) Which will produce a GPL'ed product that Linus and other developers who like BitKeeper's features as fast as possible? Buying out BitKeeper may or may not be the choice. It might take longer to raise the money to buy out BitKeeper than it would to develop a Free alternative with comparable features that Linus and other's would switch to. There's no reason why both can't be done in parallel. Indeed, the best strategy is to do them in parallel, so that McVoy feels pressure -- once a Free alternative is developed that Linus and other's would switch to, the effort to buy out BitKeeper is off.
(2) Which will be cheaper? Financial considerations are important. It may or may not be cheaper to develop it ourselves.
McVoy's comments (Score:3, Interesting)
To which McVoy response:
Well, I believe that only your free (as in beer) license says that. And that may very well be upheld by a court, because you're giving it away for no money. However, a similar provision in your for-money BitKeepr license might not be held up. Court's have ruled that -- despite what licenses say -- reverse engineering is acceptable for the purposes of developing products with interoperability. It is highly unlikely that McVoy's license on the pay-for version of BitKeeper would hold up, as that grants no extra rights not given by law, and in fact tries to deny rights to reverse-engineering given by law.
And it is precisely for this reason that RMS wants people not to use BitKeeper. Just as MS has taken measures to lock people into using MS Office, so too can McVoy take measures -- both technological and licensing-wise -- to lock people into using BitKeeper.
RMS is an annoying SOB (Score:3, Insightful)
Alas, this still goes on... (Score:3, Interesting)
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.
This is a bit overly sensationalist. (Score:5, Insightful)
Re:whats the big deal? (Score:4, Informative)
McVoy seems to play this game even harder than Microsoft, seeing that Wine's been cloning Windows for about 10 years now.
Re:whats the big deal? (Score:5, Insightful)
Not necessarily true (Score:5, Insightful)
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?
Re:Not necessarily true (Score:5, Insightful)
Re:Not necessarily true (Score:5, Informative)
Re:Not necessarily true (Score:5, Interesting)
This is already the case in many non-US jurisdictions. German law, for example, does not allow you to sign away your copyright to anything you create. Copyrights are never transferrable but, of course, you can get a license to use the material. Similarly, you can't give away your right to a court hearing (making binding arbitration an impossibility in such a jurisdiction).
I think that some stuff you ought not be able to give away. Otherwise, you as an individual might find yourself at a disadvantage at the bargaining table. If, for example, software company A had a large market share and as part of its sales agreements stipulates that everything you create with that software automatically belongs to company A, you wouldn't have much power to bargain here. Either you accept the terms or your don't use the product. That kind of unfair advantags is what such legal restrictions are supposed to prevent.
Re:Not necessarily true (Score:5, Insightful)
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.
Re:Not necessarily true (Score:5, Informative)
I did not miss the point. The original poster failed to recognize that it *might* be possible for one to both have the right to do reverse engineer software *and* the power and ability to contractually waive or sell that right. I was simply recognizing a distinction he failed to note.
I'm not sure if it is in fact true that, "most countries 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." You haven't presented any evidence on that point. However, even it that is true for "most" countries, it very well might not be true in the United States. See
BOWERS v. BAYSTATE TECHNOLOGIES [findlaw.com]
Cyberspaces.org Article re: Bowers [cyberspaces.org]
IDG Article re: Bowers [idg.com.sg]
Info World Article re: Bowers [infoworld.com]
As indicated above, in Bowers the United States Court of Appeal for the Federal Circuit held that the defendant violated a shrink-wrap license agreement when it reverse-engineered a competitor's piece of software, and that said agreement was enforceable. The United States Supreme Court refused to hear the case.
I'm not saying whether this is good or bad. I'm not saying whether this "ought" to be the law. What I am saying is that it would dangerous to assume that the Bitkeeper license agreement provision re: reverse engineering is unenforceable. I'm not saying it *is* enforceable. I'm simply saying it is not safe to assume that it isn't enforceable. The recent decision in Bowers supports being careful.
Re:Not necessarily true (Score:3, Funny)
Re:I don't get it. (Score:5, Funny)
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.
Re:I don't get it. (Score:4, Insightful)
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.
Re:I don't get it. (Score:3, Informative)
(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.).
Re:I don't get it. (Score:3, Interesting)
Nonetheless, I have jack all sympathy for that. In most projects, sometimes you hit obstacles and have to take a detour for a bit in order to solve your long term goal. We're doing it in my project, because our goal is not to make a nice framework for writing installers and packages, it is to make software installation on Linux easy. That means we have to solve problems with
Re:I don't get it. (Score:3, Insightful)
The solution to this is quite simple. Free software needs to build a better SCM tool. It should not copy BitKeeper, though not for the reason McVoy gives. His reas
Re:Hey RMS!!! (Score:4, Insightful)
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.
Cox on the point of this troll. (Score:4, Funny)
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....
Re:What's wrong with CVS? (Score:3, Interesting)
1. No way to rename files without losing revision info.
2. Ditto for moving files.
3. Can't handle symlinks.
Re:Can someone explain what these programs DO? (Score:5, Informative)
> 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).