Slashdot Mirror
RMS Weighs In On BitKeeper
An anonymous reader writes ". . . and boy, is he pissed! The BitKeeper license, he told the Linux kernel mailing list, is 'the whip hand' of proprietary software. His brief but pungent comment is carried by Linux and Main."
This is different because occasionally, a Chevy worker will drive a Ford to work; and a McDonalds worker will eat Burger King food. Neither activity is restricted by their job.
"Can of worms? The can is open... the worms are everywhere."
That is because he was talking about the Linux kernel... NOT the GNU/Linux system.
a ^= b; b ^= a; a ^= b;
Larry said in a previous thread that if the kernel developers wanted to contact bitkeeper and get dispensation on the stuff they were worried about (because it doesn't follow the spirit of the license even though it might fall under the wording) that they could do that.
Maybe post-1.0 they'll offer features that would bring it up to the level of bitkeeper, but right now, that isn't their main goal.
You're a suburbanite.
Actually, if you read the article, it says that the FREE version of BitKeeper cannot be used to work on its competition. i.e. You cannot use the FREE version of BitKeeper to develop CVS. HOWEVER, one can BUY a license from BitKeeper to do just that.
GNU/Linux only applies in those situations where you refer to the entire operating system. The kernel itself is pure Linux, and even RMS doesn't debate that issue.
:)
Since BK is purely a kernel development issue, his failure to prefix GNU isn't proof of his lack of sincerity.
-Restil
Play with my webcams and lights here
Which is a shame, because I'm sure the one person that doesn't need an article posted about his ranting is RMS. Is there anyone that was surprised by his response? Can you tell the difference between those people that read the article and those that didn't? If the story has both "RMS" and "proprietary", then you can be pretty confident on what his opinion is.
The problem with EULA's is that they can be changed at any time by the developer....
Except, no. When you enter into a license agreement with a licensor, the terms of the agreement are set in stone at the time that you and the licensor enter in to the agreement. It's not okay for one or the other party to make arbitrary changes to the license agreement after the fact.
Agreements governing a service are different; this is probably what you're thinking of. If you enter into a service agreement with a provider, sometimes that provider reserves the right to change the terms of service, with proper notification, whenever he likes. This makes sense because a service is an ongoing engagement, and it is unreasonable for a provider to be bound permanently by a set of terms when neither party can predict what circumstances might arise during the term of the agreement.
But software license agreements can't just be arbitrarily changed by either party.
I write in my journal
If you don't think his idealogy is extreme, then you havn't been to an event where he publicly speaks.
Here's the relevant part of the license:
I write in my journal
Here's a handful of links to kernel archive mirrors discussing subversion. There current attitude of kernel developers is that subversion is nowhere near mature enough to replace bk for kernel use yet. once it is, people will happily switch.
So, for the time being, live with them using BK, and know that you don't have to use it at all to help with kernel development.
get 0wned. irc.w30wnzj00.com
> I said Apple uses cvs and they use it for a large project Mac OS X.
Putting source available on CVS is much, much, different from actually using it for source control. Apple likely uses quite expensive SC software for internal use in actually developing OSX.
> Also gcc and it is large project uses cvs, there are currently 10 experimental branches plus 1 stable branch plus the head. Look at all the *BSD, they use cvs and they are the kernel plus userland even imports sources from else where too.
And none of these projects has the number of developers/hackers that Linux currently does. Anyways, with this logic, we should all be using Windows right now.
1)You CAN use BitKeeper to develop competing software. But instead of being a cheap bastard (or a Linux kernel developer), you have to buy a commercial license.
2)The Linux kernel is not competition to BitKeeper, and BitKeeper has features that free/open-source RCS systems do not have. Therefor, BitKeeper is the best tool for the job. Any Linux kernel developers who also do not work on projects such as CVS, Subversion, etc., don't have to worry. The ones that do will either just have to live without BitKeeper or (*GASP*) pay for a commercial license.
You, sir, are wrong. Linus decided to use BitKeeper for his own development only after just about the rest of the main contrubutors told them just how "great" it was. In fact, Linus was pretty weary of using any type of RCS for a very very long time, till he tried BitKeeper, and liked it.
Not that I agree with him on this point, but if anyone else would have said it they would have gotten a lot more positive reaction here. If his name is on the byline, most people here start screaming without even reading it...
There are plenty of huge open source projects, and they work fine with CVS. GNU Hurd is being developed with CVS. BSD is. To me, the real question is: what is going wrong with Linux kernel development that CVS is not sufficient?
Neither have the magnitude of Developers or incoming patches that the Linux kernel has- *BSD have very small development teams. HURD's developer team is slightly larger, but still nowhere as large.
Here's an archive of the recently-set-up bk-commits-head mailing list, which shows patchsets sent through the bk 2.5 development tree alone.
get 0wned. irc.w30wnzj00.com
"Many people don't seem to understand that many people who advocate free software consider this like a slap in the face."
Their problem, not mine. Deal with it.
"You might want to recall 150 yrs ago when some were saying "if you don't like slavery - don't own slaves, otherwise mind your own business. it's all up to whoever chooses" , there problem was that there was no equivalency relationship back then and there is none now."
OK, you just took "information wants to be free" to an undefensable extreme.
First off, until software starts contemplating "cognito ergo sum," it's just a bunch of 1's and 0's to me. Comparing it to slavery is not a proper metaphor.
Secondly, if you're trying to call those of us who choose to use "enslaved software" the slaves, guess what: I can wipe Windows off my hard drive and give Mandrake more room whenever I damned well please. My decision not to is not an invitation for you and your ilk to "liberate" me against my will.
At any rate, IMO the Confederacy was saying the right things in the wrong way for the wrong reasons. And, ultimately, you're not attacking the "Let me keep my slaves!" part of the argument as much as the "Leave me alone!" part.
"Copyrights are abusing peoples right to copy,"
As practiced in the United States today? Yes. As a concept? No. As a concept it is the fair exchange of rights between the producer and the consumer. It gives the producer compensation for their work wile ultimately giving the consumer new public domain works.
"Mixing, matching, and choosing is not the answer, because people are using copyrights to controll me even if I don't wish to exercise them myself."
WTF?! How is my decision to use non-GPL software infringe on your right to use GPL software? Should I also be prevented from writing this post lest I hurt your feelings?
"It is very harmfull to try and promote some type of equivalency relationship, and IMHO this is a great example of why."
The more vehemently you GPL sheep denounce the evils of EULA software the more you end up sounding like Steve Ballmer. Or do you enjoy becoming that which you claim you hate?
And how can you argue against equivalency? The BitKeeper license is over-broad in preventing you from using it to work on a competing product (you have to pay money to get out of that requirement). The GPL is over-broad in preventing you from using GPL software on a competing product (you have to agree to GPL your own code to get out of that requirement). Both of them serve to restrict the public domain by applying terms not only to their own works but to derivative works as well. Not even plain ol' vanilla copyrights do that ("Sorry Wierd Al, you can't release that parody unless you agree to publish through Sony.")
Want to write free software? Waive your Title 17 rights. You use what software you want, I'll use mine.
No, I believe this is incorrect. Actually the little known revolutionary John Hanson was the first president! Hancock was the fourth president from 1785-1786. George Washington was actually the 8th president. See the link below:
t m
http://www.snopes.com/history/american/hanson.h
isn't revisionist history so much fun!
Actually it is even if your company works on anything related. The main example being IBM - any IBM employee isn't allowed to use bitkeeper on the kernel project. Larry said he was fixing this, but it has been over 6 months now.
Now I don't have counted the developers of KDE and Linux, but I'd guesstimate that there are more on KDE.
I'm sorry, but this is just plain wrong - Linus will accept patches with as much alacrity as he'll accept URLs for a repository to pull from. As evidence of this, consider the number of patches he's merged from Andrew Morton and Al Viro, neither of whom use BitKeeper. Hell, Linus basically demanded excellent support for importing patches into a repository from Larry McVoy, and got it without the slightest argument.
All told, Linus using BitKeeper has noticeably sped up and smoothed out the development process - he's now merging more patches (particularly trivial patches that often got lost in the noise before), and thanks to his use of BitKeeper you can literally watch every single commit he makes, so you get a far better view of what he's doing. The development process has been helped by this, not suffered, and that's the consensus of all the core people (including ones like akpm who doesn't use bk for philosophical reasons).
Go and actually
himi
My very own DeCSS mirror.
I think the website was having troubles. Try again. I just did and it worked fine.
But even better, here is the kernel archives URL for RMS' comments and the response.
Kirk
How can you even argue this?
Given that the Linux kernel is much newer than the Hurd yet has matured faster don't you think Linus got something RIGHT in his development process?
The Linux tree is actually very organised but that doesn't solve all of the problems.
Hmm lets take a recent scenario: Combine an interface change with the maintainer adding functionality while a kernel janitor cleanes up random portions of code? In each case the code changes are only on a single driver yet you have 3 people making changes.
http://www.uwsg.iu.edu/hypermail/linux/kernel/021
In case this get slashdotted, here is RMS' post (and I quote):
The new restrictions on Bitkeeper, saying that people who contribute
to CVS or Subversion and even companies that distribute them cannot
even run Bitkeeper, have sparked outrage. While these specific
restrictions are new, their spirit fits perfectly with the previous
Bitkeeper license.
The spirit of the Bitkeeper license is the spirit of the whip hand.
It is the spirit that says, "You have no right to use Bitkeeper, only
temporary privileges that we can revoke. Be grateful that we allow
you to use Bitkeeper. Be grateful, and don't do anything we dislike,
or we may revoke those privileges." It is the spirit of proprietary
software. Every non-free license is designed to control the users
more or less. Outrage at this spirit is the reason for the free
software movement. (By contrast, the open source movement prefers to
play down this same outrage.)
If the latest outrage brings the spirit of the non-free Bitkeeper
license into clear view, perhaps that will be enough to convince the
developers of Linux to stop using Bitkeeper for Linux development.
- Vincit qui patitur.
> Did you mean, a "Brave GNU World"? I'm sorry Mr. Huxley, but it's just so appropriate.
GNU's monthly e-zine is, in fact, named Brave GNU World
I've finally had it: until slashdot gets article moderation, I am not coming back.
> GNU Hurd is being developed with CVS.
It's being developed?
> BSD is.
They gave up on the client end and created cvsup for distribution instead (which was meant to replace sup, but turns out to beat cvs in terms of reliability). Many private branches use Perforce
> To me, the real question is: what is going wrong with Linux kernel development that CVS is not sufficient?
Why don't you ask Linus? He's tired of answering, but now and then, he will give you a *big* rant on what he hates about CVS. Let's start with the fact that you can't even rename a file in CVS without losing its history. Or the fact that you can't make one changeset (in CVS terms, a tag) depend on another. Or that you can't even back out individual changesets -- history in CVS is entirely linear when going backward. The reason this worked for Linux before was because Linus did it all by hand, and now he's tired of it.
But seriously, don't take it from me, ask Linus.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Whilst it's true we manage ok with CVS, it's certainly not without its problems. We've discussed changing to something else several times, and I suspect when subversion is sufficiently developed we'll change to that.
Rich.
Metal Gear Solid 2 used CVS on a Linux system. I wouldn't call that small. Check out the PS2 DVD "The Document of Metal Gear Solid 2" for more interesting info on the development of the game, it's got some pretty sweet info.
Upgrade your grey matter, cause one day it may matter