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."
We all knew this was going to happen , so we just write an open source clone of the client and server.
No-one soon, when open source programs are made which do the same job. RIP Bitkeeper.
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.
http://www.ussg.iu.edu/hypermail/linux/kernel/0307 .2/1054.html
-dk
Whoah. A whole 7 replies to this, before the site melted down. Fastest /. I've seen yet..
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.
Why are they using bitkeeper in the first place? From their home page it doesn't seem to be GPL/OpenSource but rather a propietary system.
/. tradition I didn't bother to research the beginings of this controversy. Maybe they did have some sort of agreement at first and now somebody is backtracking.
If that's so, why are they complaining about not being able to use their own clients? Surely they knew it could come to that when they started.
Of course, in true
No sig
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
The comments from McVoy are so asinine that one wonders how anyone could possibly have uttered them; in fact, are we sure that he did? Do we know that the message(s) aren't forgeries? Maybe RMS was the victim of a prank?
Cantankerous old coot since 1957.
RMS nailed this one.
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.
If these are fighting words, what prompted them? Surely this guy didn't suddenly make this threat out of boredom. Was he baited? Any links to earlier in the thread?
Toronto-area transit rider? Rate your ride.
Read the replies to the LKML post. It's RMS who is trolling, not McVoy. Most of the LKML posters saw it (used to frequent exposure to RMS no doubt), but the Slashdot crowd obviously doesn't, judging from the comments so far. How unusual.
The Free Software movement needs more people like Linus and fewer like RMS, this is yet another proof of that.
Quality, performance, value; you get only two, and you don't always get to pick.
Err, sorry :) Replace all "developers.slashdot.org with lkml.org :)
... Mike Fedyk Scott Robert Ladd "J.A. Magallon" Alan Cox James Simmons "David S. Miller" (Eric W. Biederman) Jeff Garzik Mark Mielke Loup
Possible replies by: Rik van Riel "Trever L. Adams" Michael Buesch Shawn Shawn Larry McVoy Shawn Larry McVoy Jrn Engel Alan Cox "Trever L. Adams" Svein Ove Aas "Trever L. Adams" Alan Cox Valdis.Kletnieks@vt
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
I haven't read a single message in that thread, and neither should you.
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.
"Next time, when RMS warns about things like this, I for sure am going to listen carefully."
The sad thing is that there has to be a "next time". Was anyone listening the "first time"? Why not?
Larry McVoy is always arguing with people on the LKML, big whoop. :).
Nothing ever seems to come of it, and BitKeeper is still the best tool for the job (or so i'm told
From Larry McVoy:
I'm trying hard to stay out of this, I think Richard may be trolling,
but I need to make sure that people understand that what Richard is
suggesting is violation of our license and copyright.
On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper. At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.
Our license states that you can't use BK if you are developing a similar
system, i.e., a clone. Without using BK it's impossible to reverse
engineer BK to create the clone. So your message seems to be saying
"it would be appropriate at this point to violate the BitKeeper license
in order to write a free client which talks with BitKeeper".
Are you really instructing people to go out and violate our license?
=========
And more:
=========
From Larry McVoy:
On Fri, Jul 18, 2003 at 02:08:32PM -0700, David Schwartz wrote:
> My understanding of the relevant case law in the United States is that
> these types of restrictions are not allowed under copyright law itself.
On Fri, Jul 18, 2003 at 10:23:30PM +0100, Alan Cox wrote:
> Actually your license is simply irrelevant in most of thre world. You
> aren't allowed to forbid reverse engineering for interoperability.
"Judge, I want to violate this license on this product that I got
for free because it's not free enough".
"Judge, we give it out for free and we also developed technology
to transfer the data out of our product and into a GPLed product,
we do that at our expense and even host the competing GPLed repos
for free and they still want to violate the license"
Who do you think is going to win that one?
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.
The license means we have a revenue stream. We use a significant portion
of that revenue stream to help Linux. If the revenue stream goes away
then so do the services we provide to you for free. They obviously
have value or you wouldn't be using them.
Even the best servers have only a finite amount of bandwidth. Pipes are only so big.
It ain't the bandwidth. Page loads are fine, but every other page gets me a MySQL/PHP error.
DUH.
--rhad
Slashdot needs to interview Natalie Portman.
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....
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.
It's worth a look, if only for the ideas.
Easy, automatic testing for Perl.
Didn't he mean a GNU/Linux developers?
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
Not only does Larry threaten to change the protocol willy-nilly and implement digital signatures in an attempt to prevent interoperability with free software, but he also claims that writing a free interoperable client is a violation of the license agreement. What a jerk! Read about it in his own words.
Here is the article that RMS responded to.
Has some more interesting stuff in it.
Brielle
Sure, that's a valuable feature that I've missed in CVS, but come on people, if that's the only thing missing from CVS, why not just add it? If there's some implementation reason that can't be done in the CVS/RCS framework, how big a deal is it to even rewrite CVS from the ground up, totaly abandoning the RCS underpinnings but keeping the same command set (write the new code to do what the old documentation says) and implementing change groups? Use a transactional SQL database to manage issues of concurrent access and what the heck is the rest of the problem? CVS isn't THAT complicated.
I don't doubt I'm missing something, but I wish someone would spell out precisely what it is.
why bother following bitkeeper's protocol? just make your own up and have a full drop in replacment.
I am the Alpha and the Omega-3
Although Linus chose BitKeeper because he thought it fit the need better then CVS, what's specifically are the problems with CVS that he didn't like?
I'm new to coding, and am just starting to tinker around with CVS (in fact, O'Reilly just published Essential CVS, which just came available under Safari). Since I am not competant enough of a coder yet to even justify using a Revision Control System, maybe some of the guru's here can translate for us neophites this main arguments.
Ruby on Rails Screencast
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)
Not another one of *those*. Please people, I read LKML daily for the *code* not the politics. The worst thing is when you can agree with *both* viewpoints, and I don't have enough time or ulcers for that.
C|N>K
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
I'm not saying that CVS is necessarily the be-all-and-end-all. I'm really curious here, and would very much appreciate a specific answer so that I can understand the motivation a little better.
File under 'M' for 'Manic ranting'
list..
,
e read the FAQ at http://www.tux.org/lkml/
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
Sigs are dangerous coy things
If you were reading the list yesterday, you'd know he didn't.
/var/tmp filled up and killed the mail server for a while.
Actually, it seems that some student wandered in and was fishing for clues about duplicating functionality with an open license. Most people tried to put him off, in order to avoid another flame war on the list. Last time that happened,
C|N>K
For those of us who know nothing about software development, what is BitKeeper?
Someone reverse engineer the protocol and create an open source bk clone (gk)! Their license cannot prevent you from doing this. But hurry -- once they add those cryto signatures, your reverse engineering won't be protected under the DMCA.
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."
McVoy once talked on lkml about alternatives and uttered sth. like "if any other system can ever come close in features then it will be arch". Afaik an upload of all kernel versions into an arch repository is under way already for 2-3 weeks as a test, so maybe with some heavy code-reviewing-and-feature-hacking a replacement for BK can be there in a month or so. Arch can be found here: arch</ a>
are you writing this open source program that will be as good as bitkeeper, or are you waiting for someone else to do it, or are you telling people that CVS is good enough?
Do you even lift?
These aren't the 'roids you're looking for.
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.
Why?
OT...
Since I am not competant enough of a coder yet to even justify using a Revision Control System, maybe some of the guru's here can translate for us neophites this main arguments.
Start using CVS NOW. Install it - there are plenty of howto's. Just do it. There are even a bunch of GUI tools to make it easier to use.
As a beginning coder, you owe it to yourself to not lose the good code to bad code; to be able to see the changes you've made; and to have a backup should you accidentally delete an entire code directory you didn't really mean to.
"now it seems many of the non-free concerns were warranted"
This seems to be the way these things usually work:
1) RMS issues a warning
2) He is immediately subjected to a massive number of vicious personal attacks, accusing him of being paranoid, being extreme, being ideological, etc.
3) Some time later, it becomes obvious his warning was correct
4) Few if any of his critics apologize or even acknowlege their error... they are too busy attacking RMS over his next warning.
As for McVoy, my first interaction with him was through MontaVista Software, my employer at the time. We were using BitKeeper for developing Free software, and took advantage of the no-cost license (letting our changelogs be published to BitMover's site). McVoy changed the license such that we, specifically, would be out of compliance -- and terms were such that we were obligated to upgrade to any newer beta and accept its license or cease using BitKeeper. Being much smaller than presently, MVista had to fold and go back to CVS -- and fun that was *not*.
,v files (and thus permitting opportunities for a power cycle to kill all of a file's history).
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 or Tom Lord's home page.
Have fun!
First, it's very mature. Second... just check the feature list for yourslef.
Less is more !
No.
GNU/Linux is the kernel with the GNU tools, together as a OS.
Linux is just the kernel.
This is a call to the kernel developers, not the whole GNU/Linux userbase.
Note that this post predates the slashdot post by two days.
---
From: Larry McVoy (lm@bitmover.com)
Subject: Re: BK Licence: Protocols and Research
Newsgroups: linux.kernel
Date: 2003-07-17 15:10:09 PST
On Thu, Jul 17, 2003 at 10:01:07PM +0100, Rory Browne wrote:
> [is unhappy about our license enforcement]
I'm sorry you feel that way. It's not personal. We'll protect our code just like you will protect yours. This community is very aggressive at protecting their work, look at the recent fuss over the Linksys device that was using Linux. Nobody got upset at the enforcement of the GPL and nobody should get upset at us enforcing our license.
It's not personal, don't take it that way, it wasn't intended that way.
---
-- thalakan
Most of the highly rated replies seem seriously out of touch. (I don't have any Karma so this non-PC clarification won't hurt much.) It's always amazed me how people can get so worked up over gifts. If you don't like it DON'T USE IT!!!
BitKeeper is released as a free version for people who want to _use_ it for open source development. But not for people who want to reverse engineer it.
If you want to reverse engineer it, you have to purchase a license. (which might attempt to prevent reverse engineering...don't know).
RMS proposed a project to reverse engineer BK, and since he doesn't purchase software...it an obvious license violation. And since he doesn't develop anymore, he's asking others to violate the license.
Aside from FSF philosopy, what's the problem? Larry's offering something useful for free. In return, he gets some free testing and advertising.
While it's true that linux depends on GNU, it's also true that GNU depends on Linux. Linux is "just" a kernel, but it's the most important part (besides the compiler). It's obviously burning up RMS that GNU depends on something which isn't GNU.
It also has to be frustrating when your baby, TURD (oops, HURD), is a wallflower to the darling Linux.
I think those people that hate bitkeeper, or make sure you GNUter Linux would be more productive if they worked on HURD instead. The acceptance of Darwin shows that people are interested in microkernels and alternative to alternative OSs.
Do you even lift?
These aren't the 'roids you're looking for.
The facts are that this McVoy fellow implied that anything even remotely resembling BK will invite "probable lawsuit" (if this is an appropriate phrase).. some may suggest that McVoy is merely restating his right to enforce his license, but he seems to be implying that anyone interested in this sort of programming.. code updates, etc.. who wants to write their own or update CVS, better not have evereverever worked with BK. If they have and they add similar functionality to another product, he will sue.
If BK is the bigdong in these sort of code update/modification scenarios.. then isn't there a highprobability that anyone who works on different code of a similar nature almost inevitably spent time working on BK stuff? Will he blindly say, "You worked on freeBK, I'm suing you for updating CVS." etc ?>?
e
Also, just because McVoy sarcastically offers the guy a job (give me a break) and RMS doesn't include the comment in his quote.. it doesn't mean RMS is taking everything out of context and misrepresenting what mcvoy was saying.
e
I suggest if someone wants to take the time to create a better program, go ahead. I don't see why they should do so now just because RMS has called for it. Let him spend his own time doing the work, if he's so hot for it.
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 !
There's a name for that. It's called Embrace and Extend and it's not the most ethical path to follow. Whereas Microsoft has the advantage of owning the platform for pursuing this kind of path, the GNU platform is owned by everyone who contributes. Do we really want to start following the example of Microsoft simply because it suits our aims? I thought the point of GNU was to promote a system where the platform can't screw with its users and developers.
-- thinkyhead software and media
Larry McVoy claims that the Bitkeeper licence agreement will prevent cloning of Bitkeeper, thanks to a clause that "states that you can't use BK if you are developing a similar system, i.e., a clone."
This clause sounds suspiciously unenforcable. Are licence agreements powerful enought to allow vendors to specify/limit product use in this way?
---
From: Larry McVoy
To: Richard Stallman
Subject: Re: Bitkeeper
Cc:
Date: Fri, 18 Jul 2003 13:44:05 -0700
I'm trying hard to stay out of this, I think Richard may be trolling,
but I need to make sure that people understand that what Richard is
suggesting is violation of our license and copyright.
On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper. At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.
Our license states that you can't use BK if you are developing a similar
system, i.e., a clone. Without using BK it's impossible to reverse
engineer BK to create the clone. So your message seems to be saying
"it would be appropriate at this point to violate the BitKeeper license
in order to write a free client which talks with BitKeeper".
Are you really instructing people to go out and violate our license?
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...
I never did understand how Linux can require the use of a proprietary application
It doesn't require any such thing. Some of the Linux developers user BitKeeper, but there are gateways to applications like CVS and SVN.
I was under the assumption that checkins had to be done via BitKeeper. Regardless, only a select few have access to commit to the respository and they can always do it via an x86 or powerpc machine; regardless, it doesn't make much sense.
The usual response to someone loudly complianing about a missing feature in a free software package or lack of free equivalent to a commercial feature...
WRITE IT YOURSELF.
There's actually very little of insight in the Theory of Patches. It's just taking some fairly obvious facts about functions on sets and rewriting it with the word "patches". Either that, or it's just taking some fairly obvious facts about patches and wrapping them in shiny formalisms. Regardless, it's trivial and should not be seen as an indication of the quality of darcs (of which I know nothing) but rather the background of the author. Mind you, it's nice that someone bothered to write it down, even if all SCM users already have the intuitive understanding.
"Call on." RMS is "calling on" Linus to drop bitkeeper. Ooooooo. Well, if he's "calling on" him, we'd better fuckin' pay attention -- you know what happens if RMS "calls on" someone to do something and you don't do it! Ooooooooo.
Quoting from Larry McVoy - Subject: Re: BK Licence: Protocols and Research
Date: 2003-07-17 15:10:09 PST
We'll protect our code
just like you will protect yours. This community is very aggressive at
protecting their work, look at the recent fuss over the Linksys device
that was using Linux. Nobody got upset at the enforcement of the GPL and
nobody should get upset at us enforcing our license.
I think that RMS is the troll here. Let's get the most important fact:
NOBODY forced Linus to user Bitkeeper, it was his choice. So, Linus was the first one to agree to Bitkeeper's Licence. If anyone does not it, let's get angry with Linus and not with McVoy.
I still can not understand why there MUST be a GPL Bitkeeper client. Bitkeeper does not hold a monopoly on versioning systems, so there is no reason to make a clone. If RMS does not like Linux to be hosted on a not free product, that's fine, but it is not a good reason to break a licence.
I think its hypocritical to break McVoy licence even if it is for a "noble" cause.
He is the Path, the Truth and the Life
People that do not innovate, stagnate.
The formal Theory of Patches is just a page of incoherent mumbo-jumbo using fancy words and phrases, and that with little understanding. The so-called "definitions" and "theorems" are ambigious, incomplete and in general incomprehensive. For a starter :
The proofs and theorems given here are what I would call ``physicist'' proofs and theorems, which is to say that while the proofs may not be rigorous, they are practical, and the theorems are intended to give physical insight.
This is an approach often taken by experimental physicists, and is often reasonable, it is an entirable wrong approach for modelling application of patches! This is evident by his statement that "The theory of patches is independent of the data which the patches manipulate".
An approach based upon Graph Theory (which he can read about in any book on Discrete Mathematics) would be much more fruitful. He could even pick up how to make definitions, theorems and proofs by reading the book by Grimaldi.
It would be great to have a mathematician work on this, but I am not a mathematician, and don't care for math.
It clearly shows! And if he doesn't care for math, why does he base his so-called theory on "theory of quantum mechanics"? He happily refers to the mathematics of Operator Theory, and "applies" it. Yuck!
It goes on and on. The guy can't possibly have passed freshman year.
If I misunderstand the problem, feel free to correct me.
If I wanted to contribute to kernel development, would I need to get a copy of Bit Keeper? My understanding is no. I can get a fully up to date version of Linus' kernel as a tarball and work from there.
All source control systems are transient actors. The code goes in, the source control systems keeps things in sync for a while while developers give and take, and the source comes out all nice and pretty (and publicly assessable).
There is no possibility of locking developers into a source control product. By the nature of the genre, the data the product uses (the source code) -must- come out on a regular basis. If the product gets too restrictive, or the users are unhappy with it for any reason, the source can easily be moved to some other product.
Assuming the above are all true, and I haven't missed something important, then this whole issue is a non-starter.
On the issue of changing the protocol to keep people from interoperating with Bit Keeper....so what? If you're going to put in the work to duplicate the functionality of Bit Keeper, don't waste your time trying to interoperate with it if McVoy wants to play whack-a-mole with the protocol. Create your own protocol to go along with your own source control system. If you can create the source control features, the protocol will come naturally. Then just import the kernel source into the new system.
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 civilised countries (and even in some not-so-civilised ones).
And FSF usually puts its money where RMS mouth is. Take Savannah, for instance. An open SourceForge clone (product, hosting, free public machines, support, all included).
Also, dealing with branches is really bad, from what I've heard. Basically, everyone that I know who's actually deal with branching in CVS says that it blows goats, hard. This is obviously not a good thing for kernel development given Linus' "Linux is really just a bunch of different code trees, and people happen to call the one I run official" view of devolopment.
Bitkeeper's entire world view has basically been set up to pander to Linus' multiple-trees view. I believe cloning a BK repo is the equivalent of a CVS branch, and merging changes from lots of different sources is done fairly well, from what I've heard.
Okay, first of all, the preferred Linux development method has always been "push patches to a maintainer, the maintainer will push patches to Linus". I don't imagine that many people had commit access to the main repo, though I obviously can't quote you a number. In any case, the preferred development method is still "push patches to a maintainer, the maintainer will push patches to Linus". So what platforms BK does and doesn't run on doesn't really matter one bit for the vast, vast majority of kernel developers.
Now, Linus is probably ALWAYS going to be running x86. I imagine the kernel developers will always be running one of: AIX >4.1.5, FreeBSD, HPUX >10, IRIX >6.5, Linux/Alpha, Linux/IA64, Linux/PARIST, Linux/MISP, Linux/PPC, Linux/SPARC, Linux/ARM, Linux/s390, Mac OS X, NetBSD, or Solaris, so platform compatibility (in practice) probably isn't an issue. (Unless you've written lots of software that runs reliably on that many platforms plus Windows, you really shouldn't be dissing the cross-platform nature of bitkeeper.)
Given his practices in the past, not his words recently, lm will probably be accomodating enough to try and port Bitkeeper to any platform someone Linus says needs commit access uses.
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. Surely, the things they provide of value will continue to have value and they can continue to do what they want with the revenue stream and other resources. A free version won't make any of that go away anymore than free mail transport agents killed email. It's incredible that anyone might waste time with protocal changes and then brag about it. There is NO context that's good in.
Friends don't help friends install M$ junk.
Programmers are essentially force multipliers. For example, I write web apps for customer oriented businesses that enable them to handle more customers with the same staff they currently have. If half their customers use web tools instead of phoning in questions, then the business can double it's customer base without doubling it's overhead(employees, office space, etc).
A good programmer can go into any business and write software that increases the ability of that business by 10, 20, etc percent.
If in 10 years all software is free, there will still be a need for programmers in business because each business has a custom workflow that can be enhanced beyond the stock software you can buy or get for free.
The comparison with artists doesn't hold up, because a pretty song or a painting doesn't increase the productivity of a company by 10%. The right piece of software can.
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
How about all of you take a much nicer tilt on this, and ask McVoy (who's already giveing you the software free) his price to GPL bitkeeper.
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.
social sciences can never use experience to verify their statemen
Those being questionale in my opinion with regards to BK and the Linux Kernel, one based on GPL code and the other not.
:-)
Long term these two cannot exist. Why?
1)
The primary reason why is that companies in what I call the old "established" economies of software manufacturing, insist they have complete control of the software.
2)
The second reason is due to the fact that as we transition, and leave these companies behind, to the new economic reality of "software commoditization", said companies will enact/engage DMCA/Copyright and IP laws to prevent competition or improvements to the process of building the Linux kernel.
1 is obvious. 2, not so obvious. I mean, what would happen if for some reason the Linux kernel couldn't be developed, or not easily developed, on something besides BK?
Furthermore, BK isn't the end all be all of software development methodologies to handle source.
You have to remember, that BK and the company that owns it is basically TELLING YOU this is how we will develop and manage software.
Which brings up my final point:
3)
All software in the proprietary space is being usurped gradually by engineers who are building better software, through a process that continues to evolve.
This process isn't tide to a particular piece of software that cannot easily be changed, to keep innovation of the basic practice of building said software from stopping due to a license restriction.
I think I have to disagree with Linux on my final point. The Linux kernel will soon reach an epiphany, probably around Version 3.0. Which will require some fairly advanced pieces of tools to be developed to keep development, and the community on track.
When we reach that place, we will need tools we can modify to bring the process of building the software, as well as the kernel technology itself, to new levels.
I don't see how that is going to be possible, if we continue to run BK.
If this continues, kernel timelines, and code quality will suffer. Already 2.6 is an immense challenge.
We should be looking at, quite perhaps, something like and Eclipse style plugin, or perhaps a seperate tool for KDevelope, to handle specific kernel versioning, and development issues in a standardized environment.
Right now you have to spend a good 30-40 days of continuous reading, kernel track, source code, and putsing around with building perhaps 1-2 machines to build anything serious for the Linux Kernel.
After 2.6, we will need some sort of IDE to get programmers up to speed faster, so they can learn more quickly, about the kernels innards, etc.
We don't need to rebuild an IDE, specific for kernel programming, we could design Plugins for Eclipse or KDevelope to further that task.
What could be included would be:
1) A current and relevant deprecated code completion aware editor. Perhaps, connected with a version control system that would keep developers aware of changes in the main development trunks.
2) A more complete robotic/remote host plugin for developing/stepping through those nasty sorts of device drivers you pretty much need two machines for: 1) Video Drivers and basically Network drivers, for an adequate building environment.
I mean, given the responses from the BK owners, imagine if Sun told the Eclipse team: Don't you dare build a remote debugger, we will reengineer the protocols the the JDA (Java Debugging Architecture) with ever jdk release so you can't debug code without our software.
You can bet Java code would suck even more than it does so today without an integrated debugging environment.
--
In conclusion, I think these sorts of things will be very difficult to create or build, if the very software that is holding the main development trunks of the kernel, cannot openly participate in the building of a continuously better approach, to creating/debugging/versioning/managing source code for the Linux Kern
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
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.
social sciences can never use experience to verify their statemen
Regardless, only a select few have access to commit to the respository
AFAIK that select few includes Linus, period.
There are maintainers for the 2.2 and 2.4 kernels as well, I imagine that they have commit access on their repositories.
Whether big files should be stored in the database itself is an interesting question. Databases are better at BLOBs than they used to be. I'd be tempted to store the permanent version in the database and front-end the system with a cache based on files named by MD5.
A friend of mine has written a large-scale file-backup application that's database-driven. The backups themselves aren't in the database, but all the control information is. That's more what I have in mind.
If that's the case, then he's missing the point.
Non-trivial software is a knowledge/information resource that requires originality and effort to create. In this respect it is no different to books, television programmes, paintings or musical recordings.
Copyright is designed to provide an incentive for skilled people to create such work and receive fair compensation for their labours, because otherwise it could be copied immediately and anyone who invested in creating it could get no return on their investment (be it time, money or whatever else).
This argument applies to software just as much as the other things I mentioned, and thus logically so should copyright.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
... So this reminds me of the kind of intensity between the ones who split from the MIT labs and formed a commercial company out of the fruits of the research. RMS began writing software which incorporated each new feature, but was in his free software.
One man, keeping up with--and surpassing--the programming of many others.
Larry added in the legal aspect because he knows that baiting RMS in that fashion will garner him a loss--it's happened before, and it can happen again.
I, for one, would love to see RMS piqued to the point where he's willing to write (in reasonable time) the BitKeeper-killer. Wouldn't that be a feat and a half, if even half of the effort that Larry says it took to develop BitKeeper was accurate.
I'll tell you one thing: It doesn't take millions of dollars to develop a versioning system. It takes one programmer about eight months to build something functional, and then another two years to shake the bugs out and make it perfect.
Is is true that there are probably less than 15 developers who have access to commit access for Linux in it's various forms via BitKeeper. This includes the different stable releases, the development release, the testing branches, and the platform-specific branches. I just find it unusual that BitKeeper cannot run on all of the platforms which linux runs on. If you were working on porting Linux to a new platform, you would have to maintain an x86 or ppc linux box to checkin your code which would require keeping the code on an NFS servers so that you could easily compile it and also commit it. It seems that it would be a real pain-in-the-butt for branch maintainers of new or unusual architecture support.
Man does that guy not know his history about the GNU/Linux Community. GNU/Linux hasnt become what it is today because millions of people believed in it from the start. For years(and now) people have been saying that Linux will eventually die, that it cant compete, can't scale, etc. Saying things like that just fuels people to come together, work hard, and prove them wrong. I mean Richard Stallman created GCC by himself, working on it for 2 years. He coded every moment he was awake. His motivation was to make something that was as good or better than the closed source implementation.
There is no room for "sort of" free software. It cant work. It has to be all or nothing because once you start letting little things slide you will lose control.
75% of all statistics are made up!
(Mod parent redundant)
No it won't get slashdotted, you moron.
jap - maintainer of lkml.org
Lets not forget that The FSF makes, and spends, quite a bit of money anyway. They spend quite a bit of money on running servers and stuff, probably more then bitkeeper.
autopr0n is like, down and stuff.
This is grossly off-topic, but it shocks me that a list admin would do such a thing. I've run mailing lists for years, and NOTHING gets deleted or modified in the archives. Period. It's a historical record, and I treat it as such.
Please help metamoderate.
At this point, neither can Linus nor any other kernel developer that used BK, ever, ever work on anything that even smells like it came from the same planet as BitKeeper. For the rest of their lives!
Thank you for stressing that point. That is the most alarming point I took from McVoy's comments as well. Who knows how far the ideas of versioning that BK uses can be extended to apply to all sorts of systems?... some of which might already be unknowingly implemented within the Linux kernel, which could someday be used to compete with BK.
If that is in fact what the license says, then it is also rather ridiculous. So much so, in fact, that I would suspect that it is not legally enforceable. IANAL, but as I understand it, many EULAs are not enforceable because they are unreasonable. e.g. Your reading of my post means that you can never write a differing post on this subject.
Now, while many may say "The License be damned." or "The license does not appy in my country.", polluting any portion of Linux with such greedy, anticompetitive hogwash bodes nothing but trouble in Linux's future.
I agree, it would have been best to stay away from BK entirely... but as you point out, there are many people which have already become "contaminated" by this license (who, e.g., might not even be able to submit patches to another rcs). Furthermore, in so much as the license might not legally enforceable, it is legal to disobey it... which is not to say that it is moral to ignore a reasonable contract, even if it is legal.
Sony was suing Connectix (now owned by M$) and Connectix won because the reverse engineering solely for the purpose of interop was considered legit.
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 our product and now you are violating your contract and hurting us." This is a completely different issue, and quite frankly I don't know who would win....
LedgerSMB: Open source Accounting/ERP
I completely agree that RMS predicted this and he's being proven correct. But I'm really surprised at this response by him. Free (and open source) software works because someone finds a problem and decides to solve it. Then that person licenses that solution in such a way that everyone else can share. So far as I'm aware, all free/open source software came about because someone who cared decided to write it. And not a single piece of that software came about just because someone said, "Hey, I want this."
If RMS thinks this code should be written, then by all means, he's free to write it. But until it's written, it's vaporware, and it does no good talking about what "should" or "shouldn't" happen. I'm surprised that someone who has written as much free software as he has doesn't get that. Maybe he just forgot.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
OK... Hands up those of us who had heard of BitKeeper before it was used for Linux kernel development... Anyone, anyone, anyone... Oh, one of you at the back, well done.
My point is that successful use for Linux kernel development is just about Bitkeepers only major sucess and, hence, their best form of advertisment.
There is surely no way any free software project can allow itself to be tied into the kind of trap that McVoy seems to be laying. Ok, I know Linus works _real_ hard but come on: is the loss of freedom that is apparently going to rear its ugly head through BitKeeper usage worth it? Please Linus: time to stop the BitKeeper thing and let them do their own marketing.
Full marks again to Mr Cox, incidentally.
Thanks,
Charlie
no i'm not. i use nano -w
Richard is as smart as a whip.
I agree. He is at least as intelligent as the average whip.
Whence? Hence. Whither? Thither.
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
BitKeeper is a profitable company that employs people and pays them good salaries. Why don't people think about them before they get all worked up about putting a legitimate and successful concern out of business?
I'm not sure whether this will make me pay more heed to RMS's warnings, but I do agree McVoy is being seriously stupid with this attitude. Statements like the above is pouring gasoline on the fire, and he's managing to make the hardcore Free Software folks _angry_ enough to put a serious, focused effort into creating an equal or better product than BitKeeper as fast as they can. When that happens, BitMover's business is going to take a serious hit.
But damned if he isn't right most of the time. He just has a habit of rubbing people the wrong way and letting his ego show, so many people reject what he has to say. But despite that, he is worth listening to.
My rights don't need management.
First, I thought a lot of patches were sent as BK links, not as email patches. Second, how can the revision history be extracted from the BK archives iif the BK archives are locked up? What happens if, say, Microsoft buys out BK?
Infuriate left and right
The name you want is McVoy. McVeigh was the OK city federal building bomber.
Infuriate left and right
No, unlike you RMS knows the difference between a kernel and an OS.
Analogies don't equal equalities, they are merely somewhat analogous.
Then why don't switch to Visual Source Safe?
Hell, I'D give them my companies copies for FREE.
http://jesus.everdense.com/
Does anyone else get the feeling that McVoy has most of the kernel developers wrapped around his little finger? Notice how so many post to defend McVoy after RMS makes a fairly benign statement about creating a free BK client. Notice McVoy's tone: "Fuck with me and I'll sink you all!" And the kernel developers (with the exception of Alan Cox) come rushing to his side!! Have they forgotten that they are working on a Free Software project??? Why are they so complacent with this kind of behavior??? When McVoy says jump, they don't even ask how high...they just jump as high as they can. Incredibly sad. I just hope this gets some people motivated to make something better than BK so McVoy can become irrelevant.
Desperate plea for money: While being horribly unemployed for a very long time, and not getting any support from IBM, RedHat, Suse, Mandrake, or Sun to work on arch, and living in the San Francisco Bay Area (where unemployment is through the roof), I've gone horribly, horribly into debt, just to keep alive. In spite of the stress of that: hey, look, here's arch. For roughly the past six months I've scraped by on individual contributions to my effort, mostly sent via Paypal or moneybookers. I don't think this is how free software R&D should really be funded -- but realistically, that's how it _is_ funded for now. So, if you'd like to see more software from me, I hope you'll consider tossing a few bucks my way. Thank you very much to all of those who have already done so.
The fact that some poor soul, living in the richest country in the world, who is prepared to 'do the right thing' by his fellow men is reduced to this in a 'civilised society' is just beyond my understanding of what I have thought civilisation to be.
On the other hand an author of a different SCCS who prefers to 'do the right thing' by his family has to write thus:-
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.
Neither author is wrong, but the situations into which both of them have been forced are both very wrong . What to do about it? Could the FSF be slightly less free in its licencing policy so that use of the GNU system required a tiny contribution to a fund to support the folks who produce the free goodies which we all use and enjoy so much? I'm on a pretty small pension, but don't mind paying a small fee for what I use and like -- see the * beside my name above. Neither should anybody else.
Anyone knows if BitKeeper holds any patents? I fear that if their first collection of attempts at lock-in doesn't succeed, they'll settle for creating a hastle for everyone else in moving on, even if it means that no-one in the free software world is using their tools. Again, we'll see patents not fostering "innovasion", but stifling it.
Belief is the currency of delusion.
So, what does BitKeeper have that Subversion doesn't yet? Is there some killer feature that would be worth implementing sooner rather than later that would make it a good replacement?
There is a better solution already out there. It's called arch, it's GPL'd, and it works great. We're using it on our software project already, and the only problems I've had with it relate to a shift in thought on my part away from CVS.
It's designed by Tom Lord, and he did a lot of thinking about it, and he has designed an incredible solution which you can download now.
A few of the advantages off the top of my head:
I have been extremely pleased with the system because of its simplicity yet power. In my mind that's the sign of the Right Solution. Arch is pretty much based upon an extension to diff and patch (to allow for file renaming and such things), tar, and touch.
If you want to check it out, there's a wiki at: http://arch.fifthvision.net , and the latest releases of tla (the C version of arch that is being actively developed now that things have settled down to a final state) http://regexps.srparish.net/src/tla/ .
I suggestion you check it out and at least read over the documentation. It's different. The commands are a bit verbose, but I expect someone will write at least a wrapper pretty soon that allows you to be terse.
Oops. Very fond of arch. Gah.
Larry,
As I told you before. Keep screwing with the community and we will screw you back. It's lovely to see such professional replies from you on the kernel list, such as "we'll change the protocol".
So what! We'll come up with a better protocol which isn't proprietary and works better than bitkeeper. This will eventually make bitkeeper a non-issue. It's nice to see that you're unwilling to compete on the merits of your software, whatever those are, and immediately start playing the lockout game!!! Great move, Larry!!
So, as I said once before (and I know it was you who replied) I say again: So long, Larry, and thanks for all the fish!
Later, GJC
Gregory Casamento
## Chief Maintainer for GNUstep
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.
Actually GNU/Linux refers to the kernel and the GNU userland.
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.
Since when was the GPL ever about freedom? It's as restrictive as proprietary licenses, if not more so. As far as I know, the only software license that endorses true freedom is the BSD license.
"We are all in the gutter, but some of us are looking at the stars." - Oscar Wilde
Mis-informed comments again. The GPL grants the user rights and freedoms not granted under copyright law. The EULA takes away rights and freedoms granted under copyright law. You don't have to accept the GPL to use GPL'ed software; you do have to accept EULA's.
Regarding BSD vs. GPL, it is true that the BSD grants absolute freedom. But is that what we really want? Or do we just want as much freedom as possible without giving other's the power to restrict other's freedom using our hard work? The BSD allows proprietary developers to incorporate the work of FS developers while contributing nothing back, allows them to use BSD'ed code to write new code that is under a license that restricts user-freedoms in draconian fashion. The GPL doesn't allow that.
The BSD grants everyone using BSD'd code near-absolute freedom (the original code must still be GPL'ed and credit must be given). This means that they have the freedom to restrict other's freedom. The GPL, forseeing this problem, specifically restricts anyone from denying the freedoms mentioned in the GPL.
social sciences can never use experience to verify their statemen
> 1. No way to rename files without losing revision info.
,v files in the repository as you see fit
> 2. Ditto for moving files.
Move and rename are the same operation under any non-stupid operating system (such as UNIX and workalikes).
These are difficult with CVS, but not impossible. Here's how:
1. Make sure EVERYBODY has released the directories you're renaming to/from (unless they like surprises)
2. Log in to the CVS server
3. Rename the
4. Checkout $CVSROOT/CVSROOT
5. Make the rename/etc changes in your modules, etc files
6. Check in $CVROOT/CVSROOT
7. Check out the tree you want to work on
8. ???
9. Profit!
(I admit, step one is difficult with a large number of developers. Good thing we laid a bunch off.)
> 3. Can't handle symlinks.
True, but you don't need 'em 99.9% of the time. Just have your Makefiles create them:
$(LINKED_SOURCES):
[ -f "$(MORESRCDIR)/$@" ] && ln -s "$(MORESRCDIR)/$@" "$@"
The quotes are important if you have stupid people in your organization who think spaces belong in filenames. (And why does that only EVER happen with VB files? Gee, I wonder)
Do daemons dream of electric sleep()?
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..."
That is an interesting thought: it would stuff Linux dev overnight...the moment they turned off the servers or added the rule that everything committed became MS property.
But look on the bright side, the world would be free of Source Safe, which is possibly the worst SCM tool on the planet, worse even than zipping your source up into archive files (which gives you implicit labels that are accurate), or not doing any backup at all (which makes it obvious that your work will vanish when the disk drive breaks -SourceSafe pretends things are safe till they go horribly wrong)
History disagrees with you. The OS created by combining the Linux kernel with a lot of other software was referred to as "Linux" from the early days of its inception. RMS would simply like to redefine the term Linux to only refer to the kernel. Since Linus himself has said that the OS is called "Linux", the best way to avoid confusion between the OS and the kernel is to refer to the kernel as "the Linux kernel".
The operating system is GNU.
GNU is a software project created and run by the FSF. It has very strict "free software" ideals that are laid out in the FSF literature. So, while the GNU project has certainly created and released an entire OS (e.g. Debian GNU/Linux), that doesn't mean that everything that makes use of the FSF software is called GNU, nor should it be. If the folks creating an OS have a more "open source" mindset, they should definitely avoid the GNU prefix, since the GNU project strongly objects to any use of closed-source software while the open source movement believes it is OK in certain circumstances.
..wayne..
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
There would be pretty big grounds for a lawsuit, I mean there is a huge difference between illegally pirating software and simply ignoring an unenforceable, and therefore invalid EULA clause.
autopr0n is like, down and stuff.
What's all that talk about Burger King? ;)
http://www.club977.com/ - The 80's Channel!
Your source for commercial free 80's music!
Under that logic, all open source is 'immoral'.
autopr0n is like, down and stuff.
Since they're only talking about the kernel, it's consistent with his wiews to only call it 'Linux'. It's when you use (GNU) programs with the kernel that you have to call it 'GNU/Linux'. I think he's too much of an idealist (or boneheaded) to get fed up with the typing... :-)
Meep.
please tell me! it's good enough for *BSD, mozilla and pretty much every other free project out there. as far as i see it, all linux needs is versioning, a history archive and different branches (linus', ac etc and a submissions tree). this is not a troll, i really do want to know what bitkeeper can do that CVS cannot!
It's pretty cool how they develop the kernel using nothing but the kernel itself, and none of the gnu tools.
RMS was up in Toronto once, and kept interrupting a speaker on "Linux" to say "GNU/Linux". He was informed that he should kindly keep quiet, and got pissy. Stallman's contributed a lot, but it doesn't excuse his being an ass. I mean, he managed to be rude enough to have the chair of the CS dept. at U of T get up from a free lunch and leave...
As to his post to the LKML, it was pure troll - but the RMS lapdogs here evidently didn't bother reading the thread before jumping in to support RMS.
--R.
Most of us would like to see more comercial software for Linux. The main reason being because Linux is a great OS. Don't get me wrong Linux itself and lots of the other free software apps are world class deserve support and recognition. I use them every day. There are however certain areas where there is a void that needs to be filled. Comercial ports could fill those voids but it is this kinda of behavior that scares them off. They know if they do anything good. RMS is gonna knock it off. BK is being used to develop the kernal for one reason and one reason only it is the best tool for the job. I always use free software as my first choice if there us a mature project out there but if there is not I still need to get work done so I will use a comerical product if I need to. We should not scare commercial developers away like this. If RMS thinks he can make a better BK now that is a different story all together but I get the impression form the way he worded it he really just entends to rip off the client. GNU tools have historicly been better then their comercial cousins, and won acceptance based on merit. Let's not change that by makeing cheap rip-offs
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
That is a tenuous argument at best.
The principle of copyright is simply that someone who spends time and/or money creating a work based on knowledge and information should be allowed a fair return on their investment.
Unfortunately, if you're going to require that people give away source code in order to secure that return on investment, you're shooting them in the foot. As numerous people have pointed out, open sourcing everything is simply not in the interests of businesses; trade secrets in software techniques would get to competitors, who would rapidly exploit them, thus unfairly disadvantaging whoever did the R&D in the first place.
Thus, unless you're proposing to allow software patents so that people who do invest in R&D can maintain a fair return on investment in spite of opening their source code and revealing their secrets, mandating the distribution of code as source and not executable is a dead idea.
And of course, even if you do, there are other problems with distribution via source alone: you require end users to build their own apps. Picture the support nightmare, if you will... (NB: You can't ship an executable with the source because then that would be redistributable for free and you've basically given up copyright under your scheme.)
So, if we accept that distribution of an executable file alone is the only plausible outcome for much software -- and if you don't accept that, you're living in RMS-Wonderland and not the real world -- then what is the point of having copyright protection over the source if you're going to call a compiled version of the code a "derivative work" and remove it from protection? You've still taken away the ability for the original creator of the work, the guy who put in the effort to make it happen, to gain from his endeavours.
I'm sorry, but I don't think you've thought this through fully, or you're failing to understand why copyright exists and the relationship between the roles of copyright and patents.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Excactly, all those emacs fans, should use visual editors :>
apart from that, do *you* have any other good suggestions?
It's a little stupid to stop using something that works perfectly, is free, is still rapidly evolving and you know very well, for something else that you don't know, costs more, is not free, and is not as good -- just for the sake of "progress".
as for the worshipping thing, you just get that, when something is so usefull ( ohmyvi, the mails got mixed up, vihelpus)
Washington bullets will simply be known as the "Bulle
Please, though, if I'm missing the point of bitkeeper, enlighten me.
This sig no verb.
support in CVS isn't as sophisticated as it is in alternative SCM solutions (Perforce is my fav). This makes it hard to use in multi-streamed development projects. There are whitepapers on the Perforce website about their branching & integration approach.
There are a few other reasons too: (forgive me if my memory here is rusty, I haven't used CVS in a bit) the distinction between tags for branches and tags as labels gets confusing at times. The version number system (1.1.1.1.1..... ad nauseum) is also difficult for human parsing (it's useful in a revision history to note explicit branch & integration points without having to parse out the version string)
Generally my feeling about CVS is that it does most jobs well, the real issue is the amount of human attention and discpline required to use it properly for large development projects.
-Stu
its really that simple. If you don't like BKs license or author or whatnot, don't use it.
As long as it makes patch sets available that don't require anything more than ftp and patch, linus can continue to use it without preventing anyone from getting at the code trees.
Claiming that you have a right to use it because you really really need it and it started out so close to open source is no better than a crack addict whining, "but the first one was free!"
no. the first one wasn't free. BK has never had an open source licese. Now there are tons of tainted people who are forbidden by Grand Moof McVoy from ever writing a SCM in their entire life. And you know what? It was their own stupid mistake to limit themselves as such.
as being a bit too hackish and randomly thrown together.
unfortunate in many ways but it wasn't ready for the task. BK was designed specifically with Linus's job in mind because Larry was smart enough to realize that there are 1000s of Linus's out there doing the same job on projects in the hidden commercial software world.
actually I believe Arch was the package i was thinking of as being dismissed. ignore the above post. nothing to read here. move along.
I know you're trolling, but that error has nothing to do with the OS. You can set the maximum number of DB connections in mySQL, and if that's exceeded, you get that error. So, nothing's broken, it's doing what it was told to.
-palp
because of what it says on the website:
Incomplete Implementations
At the moment, these implementations are very rough, and only useful to look at if you're a developer. http://arch.fifthvision.net/bin/view
While it sounds interesting, if you're choosing a version control software, "stable" and "well tested" are at the top of your list.
http://lists.fifthvision.net/pipermail/arch-users/ 2003-February/025283.html
well ? what then what ?
free dom(inion) - free energy - free your mind - whee!
I thought I'd let you know of a program which is perfectly workable under Linux, but which I do *not* think (even though it works fine from the CLI) is under the LGPL reverse-engineering clause.
.data .text
section
msg db "Hello World!",0x0a
len equ $-msg
section
global _start
_start:
mov eax, 0x04
mov ebx, 0x01
mov ecx, msg
mov edx, len
int 0x80
mov eax,0x1
int 0x80
If you have nasm (provided Slashdot doesn't screw up the formatting of my post) you can compile and run it with the following commands:
nasm -f elf t.s
ld -s -o t t.o
Now take a peek at the objdump output. Clean and free of all LGPL taint.
That, I consider to be free of the LGPL influence.
Never let it be said that I wasn't accommodating for you.
The guy clearly does not want his work to be copied. Instead of just --copying--- it, why not make something better!
This is my sig.
it was already slashdotted when I got there, luckily I "squeezed through" and got the text after hitting "reload" a few times, you moron.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Linux developers -- people who develop the Linux kernel regardless of platform and toolchain. You don't call tham Bitkeeper/Linux developers do you?
Analogies don't equal equalities, they are merely somewhat analogous.
So is it legal to um "describe" said application to non-users who might decide to code something else?
Also what pissed Lawwy off to have him bring in the threats?
The message on the other side of this sig is false.