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."
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
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.
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.
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
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.).
Don't mean to reply to myself, but I forgot to add that most of the replies in the LKML are favorable to BK and Larry.
"Those who make peaceful revolution impossible, make violent revolution inevitable" - JFK
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
> [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).
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
At least in many parts of the EU, the ability to reverse engineer for interop IS a part of the law, and contractual agreements cannot override the law in that way.
Not really tho, But you can keep telling the /. morons that don't read the article that...
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
"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)."
Law > EULA.
You can reverse-engineer BK or anything else in Europe for interoperatibility or personal use.
Thank you Alan Cox.
----
From: Alan Cox
To: Larry McVoy
Subject: Re: Bitkeeper
Cc: Richard Stallman , Linux Kernel Mailing List
Date: 18 Jul 2003 22:23:30 +0100
On Gwe, 2003-07-18 at 21:44, Larry McVoy wrote:
> 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.
Actually your license is simply irrelevant in most of thre world. You
aren't allowed to forbid reverse engineering for interoperability.
Those projects are not bigger than Linux. They might be if you count number of files- but that's not what matters. The number of developers is what's important. The *BSD projects are famous for having a rather small set of persons modifying the code repository.
The specific shortcomings of CVS in terms of the Linux kernel project is that the ability to write to the respository is all or nothing.
1. If you want a developers to be able to make changes, you basically have to give him 100% write access. (Yes, it's possible for others to back out his changes if he damages something, but this is messy.) (And yes, it's possible to create auxilliary scripts in the CVSROOT area to accept/reject individual parts of a checkin- but it would be a separate development project to write those scripts)
2. If you want developers to be able to make changes, you basically have to give them TCP/IP access to the repository 100% of the time. CVS doesn't contain "workflow" features, where a person submits a change and it is queued up for the maintainer to inspect and accept/reject.
With BK, Linus can be the only person able to change the actual source code. Everyone else mails him a "change set" file, which his local copy of BK helps him inspect and accept/reject it as he wishes. When the changes are accepted, BK handles the meta-data, automatically merging in the revision history of the edits.
Yes, it would be possible to implement something along those lines with CVS- Linus gets patches in his email (in Larry Wall format), applies them to his tree, and checks it into CVS if he approves. But BK provides many little helps to automate this.
There are other advantages to BK which you can find on LKML. All in all, BK and CVS are almost too different to be called competitors. It's like comparing rpm with apt-get.
- You cannot rename files or directories.
- You cannot move files or directories.
- Support of binary files is very bad (yes it exists, but it is very crude and almost worthless)
-
It is very inefficient on the server side.
-
It has a steep learning curve.
Did I miss any?Work bio at MMWD
You've allowed David Turner to skew your understanding of LGPL. Section 6 only applies if you distribute something statically linked against glibc.
Make no mistake, GNU doesn't like the LGPL, and they are attempting to do revisionist interpretations of what the LGPL says in order to make LGPL software unappealing to companies which make proprietary, closed source software with restrictive licenses.
Despite their apparent attempt to use ambiguous wording and specious re-interpretation, section 5 clearly states that no, BitKeeper is not subject to section 6.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
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).
Exactly. You do not have to follow the GPL.
It's not an EULA. EULAs try to forbid you from doing things which are legal. The GPL allows you to (optionally) do things which are illegal.
Read section 9 of the GPL:
9. You are not required to accept this License, since you have not signed it.
I did not miss the point. The original poster failed to recognize that it *might* be possible for one to both have the right to do reverse engineer software *and* the power and ability to contractually waive or sell that right. I was simply recognizing a distinction he failed to note.
I'm not sure if it is in fact true that, "most countries have laws that explicitly make reverse engineering for the purpose of interoperability legal and make any license provisions or contract clauses stating otherwise null and void." You haven't presented any evidence on that point. However, even it that is true for "most" countries, it very well might not be true in the United States. See
BOWERS v. BAYSTATE TECHNOLOGIES
Cyberspaces.org Article re: Bowers
IDG Article re: Bowers
Info World Article re: Bowers
As indicated above, in Bowers the United States Court of Appeal for the Federal Circuit held that the defendant violated a shrink-wrap license agreement when it reverse-engineered a competitor's piece of software, and that said agreement was enforceable. The United States Supreme Court refused to hear the case.
I'm not saying whether this is good or bad. I'm not saying whether this "ought" to be the law. What I am saying is that it would dangerous to assume that the Bitkeeper license agreement provision re: reverse engineering is unenforceable. I'm not saying it *is* enforceable. I'm simply saying it is not safe to assume that it isn't enforceable. The recent decision in Bowers supports being careful.
Only Women Bleed (Sex, Sharia remix)
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
BitKeeper does a *lot* of things that CVS can't. Probably the single biggest improvement is something that we call a "mod" and I think BitKeeper calls a "changeset". It's a collection of files that you check in all at once and can track as a single entity. You can create multiple lines of development and merge changesets between them. On the surface this doesn't sound very useful but when you have a large development group, trying to figure out "what else changed when this file changed" is very nice. We use a system with similar features to BitKeeper and those capabilities are invaluable debugging tools. Our system, and I'm pretty sure BitKeeper as well, can update local workareas much faster than CVS which can be glacial.
Go Badgers! -- #include "std/disclaimer.h"
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.
What the hell crack are you smoking? I've already written David Turner and his answer to me was far more explicit than your reference:
My turn: This'll be my last response. Corporate lawyer's opinion trumps whatever you think you know about the matter, but let's go from there shall we?
I wrote a note to the FSF and got the following response back:
> If so, then wouldn't all executables linked with the
> GNU/Linux LGPL'd GLIBC suddenly be open to reverse engineering and
> modification for the customer's own purposes, and that if a proprietary
> vendor tried to take away the right to reverse engineer their product that
> they would lose the right to link with GLIBC?
Yes, this is all correct.
--
-Dave Turner
Free Software Licensing Guru
This is not legal advice. If you need legal advice, see a lawyer.
This is a message directly from Dave Turner. If you want the full source, I'd be happy to supply it.
Secondly, after receiving this, I had to take it to a corporate lawyer to get advice. Without it being commutative to any situation you think you're on top of (but apparently aren't,) the corporate lawyer agreed with Mr. Turner's email to me: There is substantial reason to believe that the LGPL guarantees the right to reverse engineer any executable linked with an LGPL'd library.
This is how it should be, and it's a good thing, except for those commercial customers who are concerned that someone has the motivation to write a free alternative to their software.
But you're wrong. Dave Turner, plus a corporate lawyer, plus common sense reading (ie: not stretching it to fit what you think it should) all equal LGPL protecting reverse engineering on all proprietary software that doesn't link with a proprietary or BSD-style replacement for libc.
Ta.
Perforce has had this for many years. (It too is not free, but it's not that huge an improvement; I am not familiar with the state-of-the-art in free software, but I would imagine at least one system has atomic checkins.)
I feel fantastic, and I'm still alive.
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..."
Arch has changeset support as well, *and* the same distributed repository support as BitKeeper, *and* a dumb server model (keep your repository on any unmodified WebDAV/SFTP/FTP/whatever server), *and* far better platform support, *and* is available under a Free license.
Subversion also has atomic checkins, but it suffers from severe reliability and design issues (read the arch-users list archives for an analysis of the latter).
Symbolics died years after that (technically, it is even still alive. You can still buy OpenGenera for the Alpha from them, for example, and they even have some LispMs in stock), because of a mixture of bad management decisions, their target market disappearing in the "AI winter" and stock hardware becoming more competetive with their special-purpose one. There is no single person to blame for their demise.
Programming can be fun again. Film at 11.