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.
Brief and to the point. This is the RMS I want hanging around. Go RMS!
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.
From: Richard Stallman
e read the FAQ at http://www.tux.org/lkml/
To:
Subject: Bitkeeper
Cc:
Date: Fri, 18 Jul 2003 15:51:36 -0400
View all headers/Unparsed body/
Forward this mail to
> 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.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pleas
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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
The site was hosed with MySQL connection limit errors before 4 posts were on the article.
> 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.
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.
here's what I get from the article link:
/home/sites/lkml.org/scripts/lkml-mail.php on line 37
/home/sites/lkml.org/scripts/lkml-mail.php on line 38
/home/sites/lkml.org/scripts/lkml-mail.php on line 38
/home/sites/lkml.org/scripts/lkml-mail.php on line 38
/home/sites/lkml.org/scripts/lkml-mail.php on line 42
/home/sites/lkml.org/scripts/lkml-mail.php on line 42
/home/sites/lkml.org/scripts/lkml-mail.php on line 42
/home/sites/lkml.org/scripts/lkml-mail.php on line 43
/home/sites/lkml.org/scripts/lkml-mail.php on line 49
Warning: Too many connections in
Warning: Access denied for user: 'www-data@localhost' (Using password: NO) in
Warning: MySQL Connection Failed: Access denied for user: 'www-data@localhost' (Using password: NO) in
Warning: MySQL: A link to the server could not be established in
Warning: Access denied for user: 'www-data@localhost' (Using password: NO) in
Warning: MySQL Connection Failed: Access denied for user: 'www-data@localhost' (Using password: NO) in
Warning: MySQL: A link to the server could not be established in
Warning: Supplied argument is not a valid MySQL result resource in
Warning: Supplied argument is not a valid MySQL result resource in
Message not found, please try again at the main index o
Administrator: Jasper Spaans
pretty f'n pathetic.
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)
Kernel.org has been down for what, two days now? Is this why?
... 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 other news, SharpFang is a worthless karma-whore and should be executed by a firing squad!
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.
Whatever you think about RMS ranting and raving, or how you believe proprietary software fits into a capitalist economy, one thing is clear:
There is a constantly-present risk involved with using non-Free software. When you use this kind of software, you hand over a piece of your business or your projects to the people who write the software.
Right now the Linux source code is inside of a version control system. It will take a good deal of time and/or money to switch to another system. The cost of the switch represents the risk associated with using BitKeeper.
Over and over folks get burned by this, yet they never learn. They standardize on Microsoft, and once they they are locked in, they complain and complain about security problems, license changes, cost increases, but they rarely switch. How can they? It would cost too much.
Free software programs (and perhaps more importantly, free *file formats* and *standards*) are the only way to avoid this risk.
Linus is respected by us because of his easy-going nature and because he's not RMS (admit it, Linus and RMS can say the exact same thing and it just sounds more reasonable when Linus says it).
But he made a mistake here. It is a mistake to ignore the "politics" of these situations. Imagine if microsoft switched all development to Subversion and publically announced it, saying "it's the best tool for the job". People wouldn't care about that. They would ask microsoft over and over, why the hell did you use an outside product? Can't microsoft come up with something better? etc.
You could argue technical points all day, but saying "the best tool for the job" doesn't fly much in the computer world, where we are using shitty tools day in and day out. A good shovel isn't so good if the handle gives you splinters.
Get Linux out of BitKeeper. Take a stand against software lock-in, changing licenses, and closed formats. You don't have to blame the closed-source writers like McVoy. They are within their rights. Just don't use their products if you can't assume the risk.
Just in case it gets slashdotted:
> 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.
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.
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
Even the best servers have only a finite amount of bandwidth. Pipes are only so big.
Maybe this is a bit off-topic, but ...
I have to question RMS's priorities a bit. I think RMS has got a point about Bitkeeper, but I think Free Software has a threat that is 100x larger than bitkeeper:
SCO.
So how about taking the SCO support out of gcc 3.3.1 and gdb 6.0, for starters? That's more important than replacing Bitkeeper.
Not only that, he's one fuckin zoophilic troll! (just check the links ;)
...is always to take a swipe at HURD.
DUH.
--rhad
Slashdot needs to interview Natalie Portman.
For a project like Linux, dependance on a closed product like BitKeeper is detrimental to the community as it is supposed to be community developed, allowing another COMPANY to leverage their might over linux developers is not fair. Hopefully this spurs on better tools than bitkeeper in the open source arena. Open source developers should also look to the academics in software engineering as they are developing many solutions but often just need someone to take them to production.
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....
Doesn't it seem to you that RMS in this case probably started the entire thing on purpose by suggesting that compatible products be developed? He knew the personalities involved and what would happen.
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.
Or is RMS taking a page out of MS's book?
"Do what we want, or we'll copy your product and squish you."
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.
Its called KitBeeper by a lot of the developers because people fucking hate it.
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.
STFU, Stallman.
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
Doesn't help much, huh?
Even if he did, what would it matter? Either way, there is a problem with becoming on Bitkeeper--the developers could hold Linux kernel development ransom. There is a real problem here, and whether RMS provoked the guy to point that out, or whether it just happened, the problem needs to be understood and solved.
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
Please replace UNIX. Thank you.
He merely gave his opinion on what should happen.
Note that he did not say "We must immediately abandon bitkeeper", but rather "I think it would be appropriate" if we developed an alternative.
Certainly, having a free alternative that was competitive feature-for-feature with bitkeeper would be an advantage for all of us, in the same way that having a free web browser or shell is.
And to the dipshit that said the Free Software movement needs more people like Linus and less like RMS... try to keep the Free Software and Open Source movements separate. RMS founded the Free Software movemement, and wrote a great deal of the code we all use every day. The world is a better place for having had him.
I never did understand how Linux can require the use of a proprietary application which doesn't even run on all of the platforms on which Linux will run..
All your BitKeeper are belong to us.
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
stallman has RSI and can't type. I can't imagine
someone taking that long rant as dictation.
It sure is long though -- sort of like watching fireworks.
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.
The guy is totally in his rights, and RMS is trying to manipulate the text, or at least it seems that way if the person reading his message hadn't read the previous post.
1. No sig. 2. ???? 3. Profit!!!
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
The more I read, the more I value the efforts of the GNU project and the FSF. At the very least, GNU/FSF offers a wedge against crap like this.
If you find value in the work of the GNU project and FSF, please consider offering your support in the form of your
All one has to do is hit the right keys at the right time and the instrument plays itself. - Johann Sebastian Bach
For those of us who know nothing about software development, what is BitKeeper?
get your facts straight. McVoy is merely backing up the license that all bitkeeper users have agreed to. He clearly means to say that don't bother playing catch up, because 1) the license prohibits it, and 2) you time would be better spend superceeding bitkeeper than copying it.
By the way, Alan Cox, kernel maintainer extrordinaire, does NOT use bitkeeper, and seems to be unhindered by the fact bitkeeper is at the core. Ergo, if you don't like bitkeeper, dont use it. If you think Linus shouldn't use bitkeeper, fine.
It is not your decision. BitKeeper is used because it works, and when something better comes along, they are free to use it.
It is very clear that when something better does come along, it cannot be a rehash of BitKeeper. (for reasons stated above)
-
Another AC
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.
Proprietary software is better. Open-source garbage simply can't compete with the work of paid programmers. But thats why I think Linux developers should stop using BitKeeper now. There's a much better proprietary alternative -- Microsoft Visual SourceSafe. Its backed not by a dubious crew of former open-source hackers, but by the worlds largest and most trusted software company. And it integrates well with what everybody agrees is the finest IDE in the world, Visual Studio .NET. Why Linux developers aren't using VS.NET to begin with boggles the mind...I think using superior development solutions such as those offered by Microsoft could speed up the integration of new features vastly. Of course, this would make Linux development dependent on Windows, but thats not a problem is it -- Windows is easier to use and has more software on the desktop anyway, so why not use it?
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."
Mate, your suggestion about throwing in a RDBMS is clueless religion.
In a 'filesystem' you're dealing with large quantities of heiarchical data that has very high locality and needs incredibly quick access (no one wants to wait for the equivalent of 'ls'). These constraints usually cause developers to design a custom metadata scheme that takes advantage of the data locality. Data blobs in hierarchies are what filesystems do best, not dbms'.
Trying to 'serialize' the heirarchy into a RDBMS and then back out of it is slow and unnecessary, and you end up loosing all the advantages of the locality of access in the first place.
You don't have to believe me - go build a central RDBMS backed change control system and see how performant it is under high user load. I believe you'll walk away quite frustrated in the end.
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>
Doesn't it seem a bit wierd that the worst impact McVoy could have on kernel development would be the same as the best proposed solution: move to something else? If you look at it in this light, they might as well ride things out until/unless BitKeeper becomes too difficult to use in order to maximize their efficiency.
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.
What about SourceSafe?
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.
Looks like they should have used FreeBSD !!!!
"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 !
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
I have no moderation points, but this an insightful response.
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.
RMS's old man is a member of the GNAA.
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
Bathe her, and bring her to me.
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?
Yeah! Let's screw everyone that doesn't provide a GPL version to satisfy RMS and the rest
Keep it up and NO commercial companies are going to support Linux with ANY free services.
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...
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.
If the kernel devs were migrated to a free source mangement system system, then companies SCO could monitor the code more easily, and it will make finding out who the offenders were more easy and SCO would not have to "blame everyone"
discuss.
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.
he refers to 'linux', not 'GNU/Linux'
I don't think this thread is credible.
Use Microsoft Visual SourceSafe! It's the greatest versioning system ever
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.
I think larry should pick up his marbles and go home, lets see how long it is before the kernel devolpers ask for him to come back. His software is used because it's the best no-cost option for linux and the kernel devolpers. I wonder how linus will fill about going back to diff's for 100% of his work.
I think larry is right, i don't understand why he puts up with this mess... He should shut down the servers, tar up kernel source and complete with the latest changes and send them to linus, say sorry, and no longer offer it for free use, he's getting the raw end of this deal... always giving software, servers, bandwidth, catering to kernel developers giving them everything there want. Yet he is considered the bad guy.
Maybe larry should give Linus his own exclusive license to use BK on his own machines, and not allow others to use the product. Then he can sit back and watch as others complain that they can't access linus BK stored information. Remember Linux Kernel Development is not a democracy it's a dictatorship, Long Live Linus.
So his use is consistent with his own position. Don't confuse his position with the GNU/Troll GNU/Position GNU/Held to GNU/Piss GNU/People GNU/off.
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.
in theory, it's such a simple solution. everyone knows CVS falls short in so many places, yet so few have even attempted to replace it. everyone talks shit about non-free revision systems but no one in the community has stepped up yet to write one.
yes for every 'flaw' mentioned with CVS someone will counter it and attempt to hack it, but that takes time and for each amount of time you wait for that it could potentially hold back releases. you can always find someone to argue both ways, but someone has to take these complaints to heart, even if they don't agree with them. someone needs to address them.
folks, someone needs to put their money where their mouth is.
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.
Stallman has often invoked the free license for other copyrighted works related to himself (such as his biography). Now, maybe he limits such to just works about Richard m. Stallman, but perhaps his ideals are more expansive. He has never clarified.
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
Most of the replies which favored the person who threatened to change his product constantly so it would remain incompatible with a free software product were by nobodies sucking up. Couldn't remember when I'd seen their patches accepted or even submitted. Couldn't even find any factual content from those messages.
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
Mod parent up!
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.
3) Profit?
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
If you care to check the facts, RMS is about as responsible for EMACS as Microsoft was for MS-DOS.
Or CVS .. all the BSD's use CVS. I say SVN and buzilla by gum!!
... or at least to the future non-free version of the Linux kernel.
Of course one could put the kernel on savannah.gnu.org but that would be admitting defeat!
The kernel is licensed under GPL/LGPL but we must not let it fall into the evil hands of the FSF!!
The comments from Bitkeeper (about fudging Bitkeeper to undermine the success of any free alternative) sound very amenable to open source and free software
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.
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!
So how much of a kickback does linus get for using bitkeeper?
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.
No, start using Subversion (SVN) now. Don't let alpha status fool you; it's very stable. While I wouldn't recommend it yet for very large projects (that do alot of merging of branches), it's fine for the single developer.
SVN is both more powerful and simpler to use than CVS. It's very easy to learn, especially if you haven't been "polluted" with alot of CVS'isms.
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.
No. RMS is not wrong.
Where did the project to access _your own data_ from
a bk repository _without_ bk itself go? It used to be
at http://bitbucket.sf.net and it seems there was a
mirror at savannah.
RMS is right as usual. I used to think he was just too
extreme, but history shows what happens when you
are not protected by the law. SCO is a good example
of what happens when a company changes management
of changes it's decision to co-operate with anyone,
never mind the Free Software Community. Walk softly
and protect yourself. It's a must to have the ability to
get at what is yours even if the company you lent the
keys to goes away. Having source tarballs is not enough,
the Changesets and revision history is required too.
Look at the SCO situation for proof of that one also!
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
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
McVoy is making money off the fact that Linus uses BK. He in fact is not giving his product away for free, but for an extremely valuable marketing resource. How much do you think it would be worth it to IBM -- or Microsoft? To say the Linus uses their product?
Second, RedHat doesn't make their money by developing proprietary products and threatening to change protocols every six months just to confound copycats.
Infuriate left and right
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.
Fucker, if you really want to know what communism is look around you... unless you don't want to open your eyes in the feminist utopia /men evile/ USA
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.
they could not use good old CVS, it's not freakish enough...
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.
Why didn't they take subversion ?
It's free, much better than CVS and it is stable
enough for large scale projects.
http://subversion.tigris.org/
[Aegis]Re: source mgt. requirements solicitation Mon Dec 9, 2002 10:24 pm
g e/ 2997
http://groups.yahoo.com/group/aegis-users/messa
Go there and read all of the thread. He just went in there cause a stink with no damned good reason for it.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
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!
He just said he doesn't have to follow the GPL, which it true. He didn't say anything about copyright. Why do you have to call him a moron? You're a jerk.
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.
Look at his resume:
http://www.bitmover.com/lm/resume.html
He used to work at SCO!
...is an relic; a Judas once a good software engineer and a great philosopher, now nothing more than the millstone hanging from the leg of the Open Source community; like a modern Newton or Einstein, inventing a whole new world and then denouncing any implications derived from that.
RMS just shut up, or write something yourself -- oh, I forgot, you always have other people write stuff for you, and then you disown it and claim it is a GNU project.
Succer!
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.
I see the Ayatollah RMS is declaring more edicts....
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
Why does this matter to an everyday Linux user, and how will this impact him or her?
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.
Both are much bigger projects than the Linux kernel (double emphasis on the last word).
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.
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.