Slashdot Mirror
RMS Calls On Linux Developers To Replace BitKeeper
JakusMinimus writes "The developer of BitKeeper has issued fighting words to RMS and he has responded on the LKML,. I remember the flap about this way back when Linus decided on BitKeeper, now it seems many of the non-free concerns were warranted."
It's hard to fathom anyone being so stupid as to make a threat like that, "the protocol every 6 months", to maintian incompatibility with a free version. With an "owner" like that, Bit Keeper needs replacement.
Friends don't help friends install M$ junk.
So, the threat is now that BK will have a locked-down encrypted protocol if any Free Software gets anywhere close to talking the protocol nicely?
That sucks so hard. This is what you get for dancing with the Devil.
"Elmo knows where you live!" - The Simpsons
That sounds waaaaaaaaay too much like Microsoft for me. I vote for Subversion. I guess the distributed repository things would be a problem though.
I mean, damn. That is openly hostile. I don't CARE if people are trying to write a competitor that can interoperate with out, those sorts of tactics simply aren't honourable.
Next time, when RMS warns about things like this, I for sure am going to listen carefully.
The bottom line is that if we work to simply play follow-up, we'll ALWAYS be behind, and BK will ALWAYS be seen as the superior choice.
If, on the other hand, we design a system that is intended to super-set BK from the word "go", then BK is the one playing follow-up, because there would be no advantage in using them if they didn't match the software we had.
One feature that would be nice would be the ability to "version" sections of an update. That way, you could test version X.Y.Z of a driver with version A.B.C of the kernel. (Useful, for example, if you distribute the driver seperately but want to test in-situ.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
... certainly need an upgraded PR department. At least the developer of BK is honest. It's seldom that we in writing sees such a clear committment to vendor lock-in.
But then you'll get sued for violating BitKeeper's EULA, see this reply of Larry McVoy.
McVoy seems to play this game even harder than Microsoft, seeing that Wine's been cloning Windows for about 10 years now.
In some cases, a proprietary tool is the best for the job. The most popular free software source management tool (CVS) is a complete p-o-s in many respects and unsuitable for large projects and for those with automated builds.
That said, a proprietary tool can never be the best for the job if the author/copyright holder is a complete dick. If it was known that the author of BitKeeper was a dick before Linus started using it, then the tool should not have been introduced; regardless, it is clear now that the guy IS a dick, and therefore RMS is absolutely correct in urging the kernel developers to play chicken and either force BK to play nicely with others or shoot the moon and wind up losing its free advertising.
[ home ]
Actually Mr. Stallmans opinion is quite a sound one. There's a very fine line when you're commercializing in the free software space (mind you, not that it's necessarily morally wrong or violates licenses). Red Hat for example must also be very, very careful not to piss off the community, but
If you are trying to copy BK, give it up. We'll simply follow in the footsteps of every other company faced with this sort of thing and change the protocol every 6 months.
This statement just about pisses on every value, which RMS represents and despite his personality - his achievements are beyond dispute.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
I didn't follow this controversy too closely when it came out (I could care less about kernels), but my impression then was that the best argument for moving away from BitKeeper was that Larry McVoy clearly had some personality issues. Now that he's promised to deliberately break interoperability with any compatible product, RMS looks reasonable in comparison. I know Linus is very agnostic about licenses, but it doesn't seem wise to collaborate with someone who has stated his opposition to one of the main reasons so many people use Linux in the first place. Is it really worth dealing with that asshole?
Oh, and LKML's web server isn't a very good advertisement for free software right now.
Unless you live in a country where reverse engineering for interop purposes is allowed, which makes Larrys EULA invalid. Like most countries, in fact.
BitKeeper, from what I understand, was the best alternative out there at the time. Unfortunately, the maintainer is proving buggy and may be unstable under certain conditions.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Now, CVS is less than perfect, but considering the entirety of FreeBSD is developed using it, as are many other HUGE projects, I think that's a bit rich. Certainly, if they needed the tools, then improving subv to the level where it worked for them would have been a good idea.
ClearCase is a version database with a powerful query language. You can select file versions by label, date, owner, attributes, branch, etc. Because ClearCase is its own filesystem, it can (but doesn't have to) transparently update your view to the latest versions. (This feature is nice for server rollouts. If something is wrong, change the query and you're instantly back to the old.) Also because it is its own filesystem, ClearCase provides audit builds that tell you everything that was touched when creating a derived object.
Updates for your view are lightning fast. And it can version directory trees, which is sorely missing in most other products. It has a documented Perl API.
On the downside ClearCase is roughly as difficult to administer as Oracle. It is expensive in terms of dollars, server hardware, and network resources.
Sorry, kiddo, but Linux can no longer be considered "Linus's kernel," what with it being developed by hundreds of people at any given time. While RMS does often spout a lot of hyperbole, this time he's responding to M$-like threats, and he's calling for a solution that seems pretty proportionate.
And as for the flaming about HURD: suck though it may, it has a pretty intelligent design. While it wouldn't bet on it ever seeing production use, a lot of its ideas will no doubt filter into other systems.
From: Alan Cox ...
...
To:
Subject: Re: Bitkeeper
If everyone spent the time replacing bitkeeper instead of beating up
Larry they'd get a lot further. I appreciate beating up Larry is more
fun but....
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.
This 'discussion' has been going on months. Bit by bit, BK is becoming more and more like some kind of SCM version of MS Office.
A while ago another pact with BM was made - that they would change the native BK file format from an open, documented one to a proprietary one (for reasons of extra features, apparently). The quid pro quo for this was a CVS gateway.
Sounds like they are now going to start revving the network protocol as well as the file format, and you know, probably at some point other stuff will stop working so well. IIRC, the BK->CVS gateway isn't 100% perfect, and I could well imagine certain things having to be dropped "because CVS just can't handle it".
It's against the BK EULA to reverse-engineer it, even though the right to do that is enshrined in many laws (like in Europe). This actively bars people - not just from interoperating, but *any* developers of rival SCM systems. SVN developers are completely unable to use the 'free' BK to participate in kernel development, because it's against the licence. Even if they aren't trying to reverse engineer BK itself; just working on a competing system is enough.
And that's also the reason why Linux can no longer have a versioned file system built into it - it's against the licence of the 'free' BK users, like Linus.
This is so storing up problems for later. It's true - it doesn't cause a huge problem at the moment. But it will do in years to come. More and more of a problem as Linux development is locked into BK. Personally, I think this is such an important issue, and I can't believe people are walking into this. But, that's their call I guess. Time will tell who is right.
"Elmo knows where you live!" - The Simpsons
It's worth a look, if only for the ideas.
Easy, automatic testing for Perl.
ah people do not make the saem mistake that RMS did in not reading MCVoy's org post..
He was asked by the community to do a protocol rev and he was commenting on someoen else volating the bitkeeper license and how his reeactions to community requests with new fixes in protocol and etc will always defeat someone wanting to violate the license..
Don't Tread on OpenSource
Here is the article that RMS responded to.
Has some more interesting stuff in it.
Brielle
It's true that FreeBSD uses CVS, but we also use Perforce for some out-of-tree work that later gets merged back into CVS. Our experience has been that CVS doesn't work real well for long-running development branches that need to get resynchronized periodically with the CVS HEAD.
(Examples of long-running branches in our Perforce tree are those for the SMPng project, and for works-in-progress for newer architectures such as ia64, amd64, etc.).
This is not necessarily true.
A country or other jurisdiction (e.g., state, province, etc.) may either: (a) not have either statutory or case law that makes reverse engineering illegal, in which case it would be legal (i.e., that which is not legally forbidden is permitted); or (b) have either statutory or case law that affirmatively states reverse engineering is permitted.
However, in either case (a) or (b) above, that would not necessarily mean that one could not contractually (e.g., via agreeing to a license agreement) give up one's right to reverse engineer. In other words, in neither case (a) nor (b) above is it necessarly true that a contractual or license clause preventing reverse engineering is against public policy and is therefore void and unenforceable.
The fact that something is permitted does not mean it is required. The fact that you have a right to engage in an activity does not mean that you can't contractually give up your right to do so, or that the contract is unenforceable
My guess is that, as a practical matter, it is probably more likely that a contracual or license provision against reverse engineering will be upheld in case (a), where there is merely an absence of statutory or case law making reverse engineering illegal. The fact that you are permitted to do something (i.e., because there is no statutory or case law making it illegal) is by itself poor evidence that you should not be held to your voluntary, contractual promise not to do it, or that the inforcement of said promise would be against public policy.
In case (b), where there is affirmative statutory or case law recognizing a right to reverse engineer, a court *might* be more likely to find that a contractual agreement not to do so is void and unenforceable because it is against public policy, but I have my doubts even in this situation.
The key questions are as follows. Why should you not be forced to abide by your voluntary, contractual promise? Do we really want the government to say that we don't have the *freedom* to make such binding contracts and promises?
Only Women Bleed (Sex, Sharia remix)
I don't know about Linux but these are the problems I've encountered:
1. No way to rename files without losing revision info.
2. Ditto for moving files.
3. Can't handle symlinks.
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
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
The right way to do open source development is to add real value to your freely-released product.
The difficulty is that if your project is popular and successful, then other open source developers may release open code that moves in the same direction as what you're doing. Your special super-duper improvement to foo, foobar may be rendered obsolete by foobaz in a few short months.
That's a brutally competitive position to be in. The challenge to making money then is to develop lots of really good code add-ons or plug-ins more quickly and better than the buzzing swarm of random open source developers.
This kind of competitive landscape is absolutely fantastic for consumers, but can make life for the developer trying to make a living difficult. The only room I see is for services: configuration, mainenance, custom-patches for special customer orders. A genuinely useful, general purpose add-on to a piece of free software will be replicated freely in some given amount of time, particularly if it's not difficult to do and/or you charge too much for your add-on.
Strictly, Richard Stallman is right and correct. That if you give in on your principles about free software, then you cannot complain if the software owner suddenly locks up the work and suddenly starts charging you an arm and a leg for the product. But though Richard is right, has high principles and thinks everyone ought to be similarly principled, generous, cooperative, etc., this leaves festering the practical issue of earning a livelihood doing something related to computer programming.
Richard never provides a comforting answer to all the good-hearted programmers thinking "Yes, I'd like to be a generous individual and give away my software and prevent anyone else from caging it by stapling it with the GPL."
"Now that I've done this nice generous thing, how do I live nicely and not like a pauper?"
Good idealistic programmers should love programming so much they do it for the love of it in their spare time, like artists. From what I know of artists, 99.8% of them work at something else that doesn't pay too well. Few get to earn a decent living doing what they love to do. That's a hard reality to face for a budding programmer.
I'd be really curious to hear what Peter Deutch (Aladdin Ghostscript) and the commercial SSH developers have to say about idealism, commercialism, earning a living, competing against their own earlier free software, etc.
"Provided by the management for your protection."
> [why is hard to write a good revision
> control system?]
Many reasons. Here are a few.
1) precision. If your mp3-player crashes -- big whoop. You'll fix it, or report a bug, or try a different one. If you run your project on revision control system XYZZY for a year, and then discover that it has corrupted 6 month old data beyond repair, now you are really screwed. There are many features in revision control systems that aren't critical -- bugs can just be fixed. But there's a core part of revctl that has to be very robust.
2) balancing art and science. I suspect that most casual uses of, say, CVS are just thinking about checking out trees, maybe updating them, maybe checking stuff in. When projects are large and busy, though, suddenly branching and merging and history auditting and all the "obscure" features are very important. The problem for the designers/authors of revision control systems is that for those obscure-but-important features: There Are No Right Answers. If you were to try to develop a purely mathematical theory of what those features should do, the fundamental theorem of the theory would be "it is impossible to implement them." In practice, the best you can do is to implement _approximations_ of what those features would ideally do. And worse, there are gazillions of different approximations to choose from. So there's a serious challenge there: to pick a subset of the possible that adds up to the most useful approximation of the impossible.
4) making wise implementation decisions, especially regarding time and space performance characteristics. Revision control systems ultimately wind up managing a _lot_ of data, and keeping that data around for a _long_ time. In an implementation, you have to make decisions about how to store that data, trading off factors such as the complexity of the implementation, the amount of storage space you'll use, and the cost of retrieving data. Over the lifetime of a deployed revctl system, you can expect factors like CPU speed and disk economics to evolve profoundly far. As basic, text-book software implementation tasks go -- revctl is a fairly challenging one.
5) distribution. In terms of what users are starting to demand, distribution is a comparatively new thing in revision control. Remember, it wasn't _that_ long ago that CVS didn't even support remote access to a central repository, nevermind distribution across mulitple repositories. Taking distributed operation into account, the mix of slow, medium and fast network connectivity in the world, the economics and politics of administration -- distribution amplifies the challenges of (1)..(4).
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>
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.
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 !
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 !
Nonetheless, I have jack all sympathy for that. In most projects, sometimes you hit obstacles and have to take a detour for a bit in order to solve your long term goal. We're doing it in my project, because our goal is not to make a nice framework for writing installers and packages, it is to make software installation on Linux easy. That means we have to solve problems with symbol version locking, desktop integration and so on.
When the Gnome and KDE projects decided they were going to write a desktop, they took detours into writing component technology infrastructure. It's not directly related, but it was a problem they needed to solve in order to write a good desktop.
So, the kernel developers need to look at what their goals are. Are they simply to write some nifty kernel components, or are they trying to produce something useful to the free software community as a wider whole. Which is more important, a slight increase in productivity today and getting screwed tomorrow, or long term stability?
If I was Linus, the answer would be obvious, and yes I absolutely would be willing to work on the tools I needed to do my job, if no suitable ones were available. If people didn't like the fact that kernel development slowed down during this period, then they had better damn help me, or take responsibility for the project so I could get on with something else.
In this case, the easy way out was chosen - we'll let this nice man give us his product for free, and that means we can carry on doing what we enjoy. They just forgot to think about the consequences of using this particular tool, and now things have gone pear shaped.
Well, I can't say I have much sympathy. You've got to keep the long view.
Larry McVoy claims that the Bitkeeper licence agreement will prevent cloning of Bitkeeper, thanks to a clause that "states that you can't use BK if you are developing a similar system, i.e., a clone."
This clause sounds suspiciously unenforcable. Are licence agreements powerful enought to allow vendors to specify/limit product use in this way?
---
From: Larry McVoy
To: Richard Stallman
Subject: Re: Bitkeeper
Cc:
Date: Fri, 18 Jul 2003 13:44:05 -0700
I'm trying hard to stay out of this, I think Richard may be trolling,
but I need to make sure that people understand that what Richard is
suggesting is violation of our license and copyright.
On Fri, Jul 18, 2003 at 03:51:36PM -0400, Richard Stallman wrote:
> I think it would be appropriate at this point to write a free client
> that talks with Bitkeeper, and for Linux developers to start switching
> to that from Bitkeeper. At that point, McVoy will face a hard choice:
> if he carries out these threats, he risks alienating the community
> that he hopes will market Bitkeeper for him.
Our license states that you can't use BK if you are developing a similar
system, i.e., a clone. Without using BK it's impossible to reverse
engineer BK to create the clone. So your message seems to be saying
"it would be appropriate at this point to violate the BitKeeper license
in order to write a free client which talks with BitKeeper".
Are you really instructing people to go out and violate our license?
Here's the problem:
McVoy's answer to the proprietariness problem has always been "there's no equivalent free program - if you want one write your own, but we're not GPL'ing bitkeeper." (Note, I'm paraphrasing)
The problem here is that he's saying not only can you not use the bitkeeper code, and not only can you not work on a competing project, but you can't even publish information about what bitkeeper does (i.e., reverse engineer the protocols). This is not "don't use our code", it's Don't mess with our file-format lockin.
Let me repeat that. He's saying "Don't mess with our file format lock-in."
That's what's wrong with Microsoft Word, that's what's wrong with proprietary software in general. He's crossed the line from not sharing with his competitors to actively trying to thwart them from competing with him at all by locking his customers into his secret format. Not sharing is grudgingly acceptable to most; secret file format lock-in is immoral.
microsoftword.mp3 - it doesn't care that they're not words...
> Personally, I think this is such an important issue, and I can't believe people are walking into this
They traded convenience for liberty. And the 'They' is Linus.
I followed the BK thing from the beginning. It is 100% certain that it will clash sometime in the future.
First because RMS is right (you should not use non-free software even if it is 'easier')
Second, because larry changed opinion a lot of time. He clearly cannot be trusted. He just want to use linux as a marketing tool for his product.
Third, because no onelooks at the long time implication. The development process is hugely important (aggraved by the fact that most kernel developers are not even aware of the existence of a process). And now, a commercial entity control the process.
BSD development is so much mature than linux development that it is not even funny anymore (how funny. [The irony is that the BSD folks are supposed to be less free(dom) than linux folks].
As a side point, I think that newscomers to Free software take freedom as granted. They don't recall time where you had to pay to get a compiler, to pay to get an operating system, to pay to get manuals. And sometimes, you were refused the access to the dev tools because you were not a professional. And when the tools were free, you could get them removed from you at anytime (ie: becoming obsolete). I learned to value my freedom. I suspect that most new hobbyist developers take the freedom of the tools as granted, so closed-source but free is free enought.
I only hope that when it'll clash (not *if*, but *when*), people have learned something. This is why I hope for a huge clash (like BK getting bought by microsoft, which is probably Larry business plan).
--fred
Sympathy for McVoy is irrelevent. Free software is trying to defeat the proprietary software model by being more efficient. If you think its important to feed his family, send him a check, but don't perpetuate a software model you believe is inferior based on sympathy. His customers need the money they would save just as much as his company does.
The solution to this is quite simple. Free software needs to build a better SCM tool. It should not copy BitKeeper, though not for the reason McVoy gives. His reasoning is wrong -- nothing forces a particular deployment to upgrade to the new protocols, so if you become compatible with any particular version, you've achieved what you need to switch. The real reason not to copy BitKeeper is because you cannot be the best by being second. Although, if McVoy spends all his resources on gimmicks like breaking API's, maybe you can catch and pass.
For a few months I have been feeling that a good revision control system is really needed for the open source community. CVS has numerous problems that I may describe later in some article. I've started looking at other systems out there and designing things. Thankfully, I've never used BitKeeper so I am not violating their license. I had no idea that they had that terrible clause in it. If Microsoft had it in Windows, no Linux kernel developers could use Windows! A "similar system" is a broader definition than "a clone".
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).
More and more of a problem as Linux development is locked into BK.
I can download a tarball of the kernel source, and I don't need BitKeeper to view it, edit it, redistribute it, etc. How are we being locked in?
Worst case scenario; Linus gets fed up with the license, checks his source out of BitKeeper and checks it into CVS or something else.
Don't forget the youngsters to computers that don't recall a time when software or hardware came with a full, detailed manuals Normally a set of them that required a reinforced bookshelf to hold the weight of them. And detailed ment a lot of source code and schematics. You had to pay for it of course, but you got what you paid for: good stuff. Well not good in all senses, there were bugs in the software, but in general it was better than software from MS in the '90s. (MS has improved quality or so I hear)
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.
It's his (McVoy's) license, and he can do any damn thing he wants with it that will be enforced by the courts. Period. He can update it rapidly, to prevent interoperability, he can use digital watermarks to prevent interoperability, and do any number of other things to stiffle BK-compatible projects. Indeed, McVoy can partake on a scheme to try to lock developers into BitKeeper as much as he can possibly do using both his license and various schemes with the software.
And, quite frankly, I don't think RMS is challenging McVoy's right to do that. It's exactly because of McVoy's right to do that that RMS is worried. Because BK is proprietary, it is very possible that McVoy could pull such a move. And, ya know what, I don't think that RMS is saying that he can't do that, or that if he does we should violate his license. Of course, he might advocate that in so-far as the courts won't enforce McVoy's anti-reverse-engineering strategies, we should reverse engineer for compatability.
Now, whether or not RMS read back through the thread -- and whether or not /.ers did -- is irrelevant. Perhaps McVoy was only saying that as an example of a worst-case scenario, but the point is that he could do it. In that case, the only thing off the ball about RMS' comment is the "at this point". From the beginning, a Free client that talks with BitKeeper with similar capabilities should have been in development. I do agree with subsequent posters that a Free alternative with similar capabilities has to exist first; RMS is simply suggesting that we mobilize an effort to do so.
social sciences can never use experience to verify their statemen
How about all of you take a much nicer tilt on this, and ask McVoy (who's already giveing you the software free) his price to GPL bitkeeper.
McVoy is giving the software away for free, as in no cost. Let's not confuse that with Free as in freedom.
As for buying out BitKeeper and GPL'ing it vs. developing a replacement, it's purely a strategic decision, based on -- I think -- two factors.
(1) Which will produce a GPL'ed product that Linus and other developers who like BitKeeper's features as fast as possible? Buying out BitKeeper may or may not be the choice. It might take longer to raise the money to buy out BitKeeper than it would to develop a Free alternative with comparable features that Linus and other's would switch to. There's no reason why both can't be done in parallel. Indeed, the best strategy is to do them in parallel, so that McVoy feels pressure -- once a Free alternative is developed that Linus and other's would switch to, the effort to buy out BitKeeper is off.
(2) Which will be cheaper? Financial considerations are important. It may or may not be cheaper to develop it ourselves.
social sciences can never use experience to verify their statemen
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 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
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
There's a name for that. It's called Embrace and Extend and it's not the most ethical path to follow.
Enbracing and extending is good and healthy. It allows vendors to play with advanced features not part of standards. The problem is when it is used to lock other vendors out. THis is the fundamental problem with the way MS does it. Surely you aren't saying that every database manager should stick simply to the ANSI and ISO standards and not support any other features that may be useful (like extensible types in PostgreSQL)? Or do you think that performance should be the only difference between them?
I see nothing inherently evil in building the best software you can. It is just unethical to use overwhelming market share *and* your extensions to lock other people out.
Of course, with open source software, lockouts are impossible.
LedgerSMB: Open source Accounting/ERP
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
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
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.
In general, RMS's position with regard to "free software" (as in freedom) is RARELY off-target. This is because his motivations are simply an outcome of the reasoning that code, like any other form of expression, is crystallized thought, and as thought should be cherished and spread to as many as possible to share it's benefits (and, in some cases, drawbacks). The GPL is one tool that helps ensure the spread of thought in code form. It truly is a disease to think that thought products (affectionately known as "intellectual property") can truly be contained. So why not embrace the fact that we as human beings are tremendously adept at copying, processing and synthesizing thought products.
The other tool at his disposal is a relentless pursuit of the goal that all software should be "free" (again, as in freedom). Software that is not free is always suspect: the "owner" that reserves rights to restrict others in their ability to utilize "their" software is prone to an "absolute power" syndrome. Their intentions may start out noble, but that can change at any moment. Sad to say, but it appears the Mr. McVoy may be on the verge of this. I remember reading the mailing-list archives when this first blew up. Mr. McVoy really has drawn a mental line in the sand that he's not willing to cross. It is unclear if he has the strength of character to let go of his "closed-source" ways. It would really be nice if he did.
Unfortunately, in pursuit of his "free" software goal RMS is likely to piss people off, hence the established rancor at him. Fortunately, RMS has the resolve to see past this and move on. It will be a rocky road to enlightenment for most (it certainly is for me, and I can't even begin to claim any form of enlightenment), but it certainly is liberating.
A replacement for BitKeeper should be developed post-haste, subversion looks promising, but needs many features to completely replace BK. I personally use subversion in my own projects and found it to be quite workable.
Food for though (pun intended): Are your thoughts yours? Do you own your thoughts? If so, how do you exert thought ownership rights? If you never existed would your thoughts exist in others? Now, granted, there clearly are expressions of my thought process that others recognize as "me", but at work, if others were confronted with the problems you work to solve every day what is the likely-hood that others would produce the same or similar solutions as yours? I find it amazing looking at all of the various Web site building technologies out there built by many others how similar many of their solutions are to the ones I produce. The evidence that elements of "my" thoughts are going on in other people's heads oh so clearly demonstrates the fact that "intellectual property" are hollow words. Pursuing the task of squirreling away your thoughts and jealously guarding them is the labor of sick-minded people. Even writing what I writing now is not new. Most of you have read "drivel" like this before, but it is still worth mentioning. Just think about it.
The slashdot article makes RMS look like a crackpot. He may be, but the detail is that he's not saying "replace BitKeeper! replace BitKeeper!". He's saying "if Larry McVoy (CEO of BitKeeper) threatens to change the protocol every 6 months, thereby making it hard for free software to be compatible with it, then BitKeeper needs to be replaced." This is a reasonable thing to say. RMS is only saying to replace BitKeeper if the developers become unfriendly to the free software community.
If Microsoft buys Bitmover, nothing changes. They can't force Linus et al to upgrade to a "secured" version (i.e. they can't take the tools away) and they can't lock up the data that's already there (this is covered in the license - the data you put into BK is yours, Bitmover has no rights to it).
Agh! Not another person who thinks the GPL is anything at all like an EULA! That's the third one today! We should get a page on snopes debunking this myth. Or you can just search for it.
I suppose I should also make some boilerplate to explain the difference. Here's the short version:
The GPL permits you, at your option, to violate the copyright on a piece of software, which is otherwise against the law.
An EULA (attempts to) forbid you, without your consent, from re-selling software to another person, which is completely within the law. (Different EULAs may forbid many other things)
You are NOT required to agree to the GPL before using a program. (That's why you've never seen it- because you didn't have to agree to it, unless you were actually going to look at the source). According to the software publishing houses, you ARE required to agree to an EULA before using their programs.
I feel that if such a case were pushed to the Supreme court, however, EULAs would be invalidated. When you sell someone a box of software (or a book, or a music CD), you are giving him permission to use it normally in private. Once he's got that permission, you can't interpret his normal use as consenting to some extra contract. "By closing this web browser window, you are consenting to mail me $500". That's not a valid license, because you're allowed to close the window without permission from me. Once you buy software and have walked out of the store with the box, you're also allowed to use it without further permission, but that's not what software publishers claim.
PS. I've answered this question so much today, I can actually quote GPL section 9 verbatim: "You are not required to abide by this license, as you have not signed it. However, nothing else gives you permission to redistribute the software, which is a violation of international copyright law..."
Is that RMS has a far greater grasp on the real world than most people.
That is evidenced by almost everything he warns against usually coming true...
The predictions he makes ARE based on human nature. That's what he understands very well, and why his predictions are so accurate - when someone takes the first step down a slippery slope, it does not take a genius to recognize they are going to fall. Only someone who is capable of seeing the slope in the first place.
"There is more worth loving than we have strength to love." - Brian Jay Stanley