If the next kernel takes over three years to release, then the linux movement is dead.
Don't see how that follows. The only reason the 2.4/2.6 releases were especially significant was the flood of new features that had previously been held up in the unstable line. We don't have separate stable and unstable lines anymore, just unstable 2.x.y Linus releases and a stable 2.x.y.z line off of that.
Will we have to go back to that post-BK? I'll pay for a beverage of your choice (limit: US $20) if we do, or if Linus doesn't get out another 2.x.y release within six months (the interval with BK has been about three).
[ My email address is in my/. profile if you want to accept. ]
WHERE IS THIS GPL SCM that supports the kind of features that BitKeeper does?!?!?
You seem to be under the impression that this sort of thing could happen on an ongoing basis. I was just pointing out that that was a one-off effect of the BK license and Larry's ability to revoke it in this fashion. This kind of disruption is unlikely to happen again.
This reduces to one thing: Linus can make whatever agreement he wants, and use whatever software he wants, but if he tries to exceed his authority and make a binding agreement to which the other developers (not to reverse-engineer BitKeeper) are held WITHOUT THEIR CONSENT, they aren't obligated to follow him.
Take OSS versus proprietary out of the picture for a moment. Why do you think it's okay for him to do that? With anything?
Who is Linus to impose his tool preference on kernel developers? He's the guy who started this whole ball of wax. He's the guy developers are sending their modifications to his creation. He's the guy who has a track record for making decisions that has gotten the kernel to this point today. I trust *his* track record.
Who is Linus to dictate what people do outside of kernel development? He set up an agreement that affected such people without their consent, and then you're horrified they didn't comply and the agreement caved in?
I agree this sucked for kernel development and will slow things down for a while. I've seen what drags down Debian and HURD firsthand. This isn't that. HURD tanked because of a really crappy technical foundation, and Debian is slow to release not because of licensing issues, but because they insist on getting everything in the distro ported to all their architectures before release, which is an unrealistic goal. Look at their perpetual list of release-blocking portability bugs.
It'd be nice to blame this on F/OSS zealotry, but Linus took a risk making this untenable agreement. Maybe it was stupid, or maybe it was smart -- ultimately it caught up with him, even though he got some benefit in the meantime.
The consequence of not abiding that agreement was that he would remove the right to use his product and his support for no monetary compensation. That is carrot, not stick.
Uh, what? That's a stick (negative reinforcement), by definition. The carrot (positive reinforcement) would be the benefits of using BitKeeper.
Tridgell decided Linux must not be developed with proprietary tools, and actively chose to pursue his legal right to reverse engineer BK, against the agreement Linus and Larry made. Tridgell, who is not a kernel maintainer or defacto leader of kernel development
Maybe that touches the root of the problem.
IMO, the kernel development organization is informal enough that Linus didn't have the authority to make that kind of agreement on behalf of everyone. There's no clear boundary between kernel developers and non-kernel developers -- what minimum level of kernel involvement would cause someone to be bound by the agreement?
For example, I have never touched kernel code (other than some KGI twiddling many years ago that never made it into Linus' kernel). Do I fall under Linus' authority, and should I be bound by an agreement he enters into? Why or why not?
How about you? Should you be bound by it? Why or why not?
If you aren't a party to the agreement (nor to the BK license), is it just for the agreement's negative consequences to still be applied to your actions?
You could make a good case that Andrew lies above some arbitrary line of organizational involvement, but according to the one KernelTrap article, Andrew wasn't the only one reverse-engineering BitKeeper. This has apparently been going on under the radar for a while.
What you're seeing is a (limited) rebellion against Linus because he has hit the limit of the authority conferred on him by the community. John Locke would have been proud.
I'm not saying Trigdell was unethical because he committed an act of reverse-engineering.
Ok. I think that's finally sunk in now. I guess part of what has me and others upset is that Larry _is_ apparently arguing that (articulating it in the form of a "no-coat-tails" moral principle)... and that Linus appears to be buying into the argument. That is a totally unrelated issue though. I was too upset earlier and having a hard time separating your argument in my mind.
Why should businesses adopt Linux if it can't competently act upon meeting its production timetable?
...Linux has a production timetable? From what I've read of his posts on the subject, Linus might disagree...
[note: the following is based on an incomplete understanding of what transpired; if you can correct me with a reference please do so]
You know, all this aside, it's not clear that Tridge had planned to announce his work at this time, and he has never released any code. We might not be having this conversation if the news hadn't reached Larry by social word-of-mouth or Larry hadn't responded so publically and explosively, doing things like demanding Andrew be fired.
Once Larry blew up like that in public, Andrew might well have been motivated to continue out of stubbornness, unwilling to let Larry dictate his private development activities. I'm similarly pigheaded and I know I'd be tempted.
That is purporting an intention which hasn't been backed up with evidence (i.e. - Larry gloating in a post that it was part of his evil master plan).
Actually I think that was an instance of Larry trying to be genuinely helpful while still maintaining control. But I can't really speak to his internal motivations, only analyze his public actions.
You presume Larry conspired to create this situation.
Actually I presume (and it is a presumption) that a well-meaning Larry succumbed to a fairly natural desire for control.
I'm also making assumptions about Tridge's motivations though. I am assuming that his reverse-engineering was more concerned with providing free access to the repository that wasn't dependent on Larry's good will, rather than first and foremost an attempt to force the issue with Larry.
Although I'm relieved the issue is now put to rest (although the circumstances suck), even I would be unhappy if it turned out to be the result of Tridge just deciding to force things.
[ BTW, you're right -- while I do have some experience as a project leader, I am "armchair quarterbacking" here. ]
Larry's the owner, he's entitled to set whatever conditions he choses to set.
Within the limits of law. He has no right to set conditions on someone (i.e. Tridgell) who is has not entered into an agreement with him and is otherwise operating in obedience to the spirit and letter of relevent laws.
Don't go sabotaging trucks at the border because you can.
Sabotaging trucks is both illegal and immoral. I don't think that's an appropriate comparison to reverse-engineering for interoperability, which is at least legal (a right enshrined in even the hated DMCA). Moral? Given Larry's attempts to unjustly manipulate the situation to limit a legal freedom of developers in ways that the law doesn't allow, I would say yes.
I don't care so much what restrictions he places on licensees, but when he tries to use his BK userbase as a wedge to exert control over non-licensees who are not party to an agreement with him, that's another thing entirely...
An agreement in which the participants would abide because they respect the decision making ability of its leader?
Linus is the nominal project leader and organizer for the main branch of the Linux kernel. He's not the leader of the "open source community" (remember that other projects use BitKeeper too), and not even really the leader of the "linux community".
Apparently I am horribly mistaken to think the linux community was capable of such discretion.
I'm not sure it's realistic to think of it as a unified organization. At best it's a pretty loose confederation. You have folks like Linus, and folks like RMS (or worse), and everyone in between.
Is Linus now required to consult every user on the internet on every operational decision he wished to embark on?
Of course not. Except... if Linus makes a promise to Larry that is contingent upon the cooperation of the entire internet community, I guess he really should have gotten their assent first, yes. Hence "impossible".
BTW, agreements are a form of contract, and that can be binding under law.
...and you need to be party to an agreement to be bound by it.
Tridgell was incapable of expressing his opinion to Linus, or the community?
IIRC he dissented from the decision to use BK for Linux way back in the beginning, along with Cox, RMS, et al. I'm a bit surprised nobody did it sooner, but I guess like myself most people at least tolerated things as long as Larry
It's not as if he ever wrote McVoy an email saying "nyah, nyah, I'm going to clone BK so suck it up!" or anything. McVoy heard about it third-hand and started demanding that Linus and OSDL shut him down.
and for no benefit that I can see;
Maybe Andrew was giving him too much credit. If Larry could have responded maturely, that would have been great, we could be assured of the freedom to move away from BitKeeper if needed, and many of the criticisms of BitKeeper would have died down. We'd probably still be using it for the forseeable future.
As it was, Larry spitefully exercised the "nuclear option", confirming everyone's worst fears.
Given this, disentangling projects from Larry's increasing domination seems a major long-term benefit to me.
I'll grant that Larry's terms are weird and probably counterproductive, but Linus thought they were, for the moment, acceptable.
The initial terms didn't seem so bad, but Larry has slowly made them more restrictive over time. Frog, meet slowly heated pot of water.
Linus was a fool, and is apparently now too blinded by buyer's remorse to think through the implications of the position he is now advocating.
He is, in effect, now advocating against Samba, against OpenOffice, against so much of the software developed using reverse-engineering due to uncooperative vendors.
If reverse-engineering against a vendor's wishes is really immoral, then so was developing that software, including many Linux device drivers.
Hopefully Linus will eventually work his way through the cognitive dissonance, as he could do some serious damage to the continued viability of Free Software (vis a vis interoperability) if he continues this line of advocacy. Heaven save us if Microsoft really picks up on this and runs with it.
Linus got McVoy to export the kernel tree without using Tridgell's work.
...but not via a method that was free of McVoy's attempts at manipulation through onerous licensing terms.
Also remember that the Linux kernel isn't the only Open Source project hosted on bkbits.net.
I'm not denying Tridgell's legal right to reverse-engineer the protocol, but I think doing it in a way that got McVoy to cancel the free BitKeeper product and to get Linus's and OSDL's licenced cancelled to boot was a lame thing to do to Linus.
How could Andrew have done it in a way that wouldn't have angered Larry? Larry said that he didn't want it reverse-engineered at all.
Question -- if one accepts that Larry is has a right to prohibit any reverse-engineering by fiat, isn't that denying Andrew's right to reverse-engineer?
It just doesn't work to say "if you'd just kept him happy, everything would have been okay!" It wouldn't have been. Appeasement never, never works. Domineering personalities just take further advantage.
Things weren't standing still; the BK license was getting increasingly more restrictive in ways that made migration increasingly difficult. Something had to give eventually, and I'm glad it wasn't our freedom as developers.
Looks like Linus is very carefully skirting the line and not implementing any actual SCM features in git himself, rather dropping hints and letting others do the actual work.
Which is a plausible theory, but it's not clear to me why it's Tridge's place to override Linus's decision about what SCM system Linus uses.
Again, that was Larry's doing, not Tridge's. Larry is the one who chose to employ collective punishment.
It's not clear to me why it's Linus' or Larry's place to dictate what projects Tridge can work on, if he is working within the bounds of the law and is not restricted by any legal agreements with them.
[ By the way, you do realize that Linux isn't the only Free Software project that was using BitKeeper at this point? This is bigger than Linus. ]
I'm sure Larry thought he was giving everyone a good deal, but a deal is something you are allowed to refuse. Obviously Tridge wasn't allowed to.
Ultimately, what this degenerated into was Larry trying to unilaterally impose his will on the entire development community by using the projects hosted on bkbits.net as hostages -- don't do anything he doesn't like (whether or not he has a right to demand it), or he'll take BitKeeper away!
Larry tried to maintain his company's position through backhanded manipulation rather than honest dealing, and I'm glad he failed.
The way you explain it, apparently Tridge felt a calling to save the Linux kernel from that poor dupe of McVoy's, Linus Torvalds.
That's the way _I_ see it, from a long-term strategic point of view. I think Tridge was just trying to ensure that it was actually possible to migrate the change history and metadata to another SCM without going through the lossy CVS gateway.
I imagine Larry's own offering of a special export feature in BK didn't satisfy Tridge, since that would have barred anyone using it (or as recent events illustrate, given Larry's bizzare theory of license contagion, anyone even remotely associated with them) from working on a competing SCM.
That Larry's increasingly onerous license provisions were slowly setting up a "if anyone tries to escape I'll shoot the rest of the hostages" situation was all the more reason to take the risk now rather than later.
I don't think that was necessarily McVoy's conscious intent, but he was acting out of fear of losing control. Which became a self-fulfilling prophecy really.
That may be true of Tridge as well; the difference in Tridge's case being that he could justify his position in terms of preserving everyone's control over their own development activities, whereas Larry was effectively insisting on control of other people's, including situations where there were no voluntary contractual agreements nor rights under the law involved.
It's a shame he gave out such a lame statement.
It looks like he was threatened with legal action and lawyered up, hence he isn't able to talk about it in detail yet. I'd expect him to be able to win, but that doesn't preclude him from having to prove his case in court if a civil suit is in fact brought against him.
Uh, yeah. The situations are completely equivalent. We all saw Linus's bruises, and we never realized. "I just bumped into a door," he told us. That bastard McVoy!
That was obvious hyperbole on my part, but if you replace "Linus' bruises" with "increasingly onerous licence restrictions imposed on free BK licensees like Linus", and "I just bumped into a door" with "I'm just using the most practical tool at the moment," that is a bit closer to the reality.
An interesting question is whether Larry will choose to sue Linus for breaking the BK license by working on a competing SCM ("git") within the one-year non-compete window. As far as I know Linus wasn't under a special arrangement which would excempt him from that.
Larry was providing an up-to-date CVS server. Non-BitKeeper users could still obtain the code and participate in kernel development.
CVS loses some of the metadata -- and it's the metadata/change histories that you want to export when you switch revision control systems -- not just the raw code.
Even Larry realized that CVS wasn't sufficient, or he wouldn't have offered the direct-from-bk export functionality that Tridge turned down (since it would still require accepting a bk license to use).
That wouldn't be so onerous if the BK license didn't prohibit working on SCM code for a year after last use.
McVoy would have to abandon his position on protecting his intellectual property.
What intellectual property under the law would he have failed to protect? Copyrights? Patents? Trademarks? Or are you employing some sweeping extra-legal definition of "intellectual property"?
But his action results in a cessation in the use of BitKeeper, makes it impossible for Linus and Larry to operate under their voluntary, agreed arrangement, which was their preference, and now kernel development progress reverts to the rate at pre-BK adoption.
Larry made that impossible by setting impossible conditions. Or are you seriously suggesting that Linus could make a good-faith agreement that was binding on the entire world (including Tridge), without consulting them?
If Tridgell and F/OSS zealots are incorrect, and there isn't a tool comparable to BK, it will be a year before Linus will be able to START new kernel development.
I thought the consensus was that there wasn't a tool comparable to BK yet. OTOH, according to Linus most of the improvements weren't BK-specific, but organizational and procedural changes that came out of experimenting with the additional flexibility BK gave.
So the situation is not quite so grave, and the state of free SCM tools will improve quickly out of necessity now that we're not stuck in this propreitary cul-de-sac (though we will feel the lingering effects of the BK "non-compete" clause for another year...). BK doesn't incorporate any radical new technologies in the SCM field; its primary advantage is a thoughtfully-tweaked interface that matched the way Linus likes to work.
Linus picked the tool, and could have unpicked it at any time.
Unpicking it requires an export tool, and frankly, like Tridge, I wouldn't personally want to rely wholly on Larry's good graces for one as Linus seemed willing to do.
So, is Larry providing one now? Tridge's was just a proof-of-concept.
(Admittedly that's kind of moot as it sounds like Linus did extract his own BK repository already. But what if he hadn't?)
Now if Tridge just wanted to improve the state of kernel development, he did a pretty poor job of it. And if he didn't care about the kernel and just wanted to reverse engineer BitKeeper, then perhaps he could have picked somewhere other than OSDL to do it.
This was on his own time, not when he was billing OSDL contract hours (he's a contractor, not an employee).
But forcing Linus off of his chosen SCM system... was either amazingly jerky or a huge miscalculation.
Larry did that, not Tridge.
Frankly, the more I read about the situation, the more this sounds like one of those situations where a controlling and jealous husband beats his wife because he doesn't like what some of her friends are doing. Then some people take the side of the husband and blame the friends for everything.
They insist how good he was was to her, and that he wasn't really TOO controlling, really. He PROVIDED for her. Where would she have been without him? Is it too much to ask if she and her friends could just show gratitude and respect his wishes?
The two are kinda friends at the moment; probably not.
Here's an interesting question... will Larry sue Linus for violating the one-year blackout period (after cessation of use) for SCM development that was stipulated in the free BitKeeper license?
So, basically Tridge should be grateful to his propreitary overlords for their product, rather than getting uppity and attempting to write compatible free software?
I realize that's not the way you're thinking of it -- I doubt that's even the way Larry thinks about it -- but those are the ultimate implications, and what that line of argument reduces to.
As it is, the state of free software SCM has been set back quite a bit, as the people in the position to do the most (e.g. Linus) have been distracted with a "good enough" propreitary tool, and subsequently restricted from participation by the "non-compete" clause Larry introduced in newer versions once Linus et al had adopted it.
Aside from finding that situation unacceptable on the face of it, I imagine Tridge also worried that Larry would continue to tighten the noose over time. From what I've heard from other people who have actually had to deal with him, it's not an unfounded concern.
The problem with relying on support for the neutral export format in BitKeeper is that you're still at Larry's mercy.
Based on Larry's past (e.g. lmbench!) and present behavior, that would be extremely unwise. In this instance, IMO, Linus is being a profound fool.
I don't blame Tridge for insisting on a method that doesn't continue to put everyone at the mercy of Larry's whims. Frankly, he's done Linus a favor, at least in the long-term.
I can't help but be reminded the venom we received when we forked Sodipodi; people castigating us for ruining things by forking, and berating us as if we'd done something criminal... "stealing" (that word was used) all the hard work that had gone into Sodipodi.
Heaven forbid we upset the apple cart by using legal and ethical means to ensure the freedom of users and developers...
There are groups of people ideologically at odds with one another on our planet, fighting for power and control of a variety of things - there is no way to win, and the only way to avoid losing is to not play their game.
There's a prisoner's dilemma involved, though. Unless you can guarantee that the other party won't continue to play, you still lose.
I think people are aware of the possibility already; my personal experience is that there are very immense social pressures against forking that increase with the scale and relative fame of the project.
That, combined with the GIMP project leadership not being dysfunctional enough to force the issue, is the only reason the GIMP hasn't seriously forked already (aside from CinePaint [nee FilmGimp]). Scott's effort looks like the first serious rumblings, however...
(This isn't to denigrate the contributions of the other three co-founders, of course, but I was the one who started the ball rolling; I came up with the name, bought the domain, convinced the other folks to come on board, set up the project (bryce might have been the one to set up the SF project actually), and IIRC personally did much of your step #2...)
I've already done that once, with the vector graphics application Sodipodi (the name I chose was "Inkscape" -- heard of it?).
Of course, Sodipodi was an easier fork to sell than the GIMP, because the problems were much deeper than naming and UI issues.
I don't have the energy to do that again for the Gimp, so someone else will have to carry that particular flag... (Scott, maybe?)
[ Btw, speaking as someone who's actually done it, step 2 isn't really automatable; certainly not on an ongoing basis. You may as well fork properly like Inkscape chose to do. ]
Slashdot Mirror
Don't see how that follows. The only reason the 2.4/2.6 releases were especially significant was the flood of new features that had previously been held up in the unstable line. We don't have separate stable and unstable lines anymore, just unstable 2.x.y Linus releases and a stable 2.x.y.z line off of that.
Will we have to go back to that post-BK? I'll pay for a beverage of your choice (limit: US $20) if we do, or if Linus doesn't get out another 2.x.y release within six months (the interval with BK has been about three).
[ My email address is in my /. profile if you want to accept. ]
You seem to be under the impression that this sort of thing could happen on an ongoing basis. I was just pointing out that that was a one-off effect of the BK license and Larry's ability to revoke it in this fashion. This kind of disruption is unlikely to happen again.
This reduces to one thing: Linus can make whatever agreement he wants, and use whatever software he wants, but if he tries to exceed his authority and make a binding agreement to which the other developers (not to reverse-engineer BitKeeper) are held WITHOUT THEIR CONSENT, they aren't obligated to follow him.
Take OSS versus proprietary out of the picture for a moment. Why do you think it's okay for him to do that? With anything?
Who is Linus to dictate what people do outside of kernel development? He set up an agreement that affected such people without their consent, and then you're horrified they didn't comply and the agreement caved in?
I agree this sucked for kernel development and will slow things down for a while. I've seen what drags down Debian and HURD firsthand. This isn't that. HURD tanked because of a really crappy technical foundation, and Debian is slow to release not because of licensing issues, but because they insist on getting everything in the distro ported to all their architectures before release, which is an unrealistic goal. Look at their perpetual list of release-blocking portability bugs.
It'd be nice to blame this on F/OSS zealotry, but Linus took a risk making this untenable agreement. Maybe it was stupid, or maybe it was smart -- ultimately it caught up with him, even though he got some benefit in the meantime.
Thinking more about this... could a similar scenario occur if Linus were using e.g. a GPLed SCM instead?
I think this was a vulnerability introduced by Larry's licensing arrangement...
Uh, what? That's a stick (negative reinforcement), by definition. The carrot (positive reinforcement) would be the benefits of using BitKeeper.
Maybe that touches the root of the problem.
IMO, the kernel development organization is informal enough that Linus didn't have the authority to make that kind of agreement on behalf of everyone. There's no clear boundary between kernel developers and non-kernel developers -- what minimum level of kernel involvement would cause someone to be bound by the agreement?
For example, I have never touched kernel code (other than some KGI twiddling many years ago that never made it into Linus' kernel). Do I fall under Linus' authority, and should I be bound by an agreement he enters into? Why or why not?
How about you? Should you be bound by it? Why or why not?
If you aren't a party to the agreement (nor to the BK license), is it just for the agreement's negative consequences to still be applied to your actions?
You could make a good case that Andrew lies above some arbitrary line of organizational involvement, but according to the one KernelTrap article, Andrew wasn't the only one reverse-engineering BitKeeper. This has apparently been going on under the radar for a while.
What you're seeing is a (limited) rebellion against Linus because he has hit the limit of the authority conferred on him by the community. John Locke would have been proud.
Ok. I think that's finally sunk in now. I guess part of what has me and others upset is that Larry _is_ apparently arguing that (articulating it in the form of a "no-coat-tails" moral principle)... and that Linus appears to be buying into the argument. That is a totally unrelated issue though. I was too upset earlier and having a hard time separating your argument in my mind.
...Linux has a production timetable? From what I've read of his posts on the subject, Linus might disagree...
[note: the following is based on an incomplete understanding of what transpired; if you can correct me with a reference please do so]
You know, all this aside, it's not clear that Tridge had planned to announce his work at this time, and he has never released any code. We might not be having this conversation if the news hadn't reached Larry by social word-of-mouth or Larry hadn't responded so publically and explosively, doing things like demanding Andrew be fired.
Once Larry blew up like that in public, Andrew might well have been motivated to continue out of stubbornness, unwilling to let Larry dictate his private development activities. I'm similarly pigheaded and I know I'd be tempted.
Actually I think that was an instance of Larry trying to be genuinely helpful while still maintaining control. But I can't really speak to his internal motivations, only analyze his public actions.
Actually I presume (and it is a presumption) that a well-meaning Larry succumbed to a fairly natural desire for control.
I'm also making assumptions about Tridge's motivations though. I am assuming that his reverse-engineering was more concerned with providing free access to the repository that wasn't dependent on Larry's good will, rather than first and foremost an attempt to force the issue with Larry.
Although I'm relieved the issue is now put to rest (although the circumstances suck), even I would be unhappy if it turned out to be the result of Tridge just deciding to force things.
[ BTW, you're right -- while I do have some experience as a project leader, I am "armchair quarterbacking" here. ]
Within the limits of law. He has no right to set conditions on someone (i.e. Tridgell) who is has not entered into an agreement with him and is otherwise operating in obedience to the spirit and letter of relevent laws.
Sabotaging trucks is both illegal and immoral. I don't think that's an appropriate comparison to reverse-engineering for interoperability, which is at least legal (a right enshrined in even the hated DMCA). Moral? Given Larry's attempts to unjustly manipulate the situation to limit a legal freedom of developers in ways that the law doesn't allow, I would say yes.
I don't care so much what restrictions he places on licensees, but when he tries to use his BK userbase as a wedge to exert control over non-licensees who are not party to an agreement with him, that's another thing entirely...
Linus is the nominal project leader and organizer for the main branch of the Linux kernel. He's not the leader of the "open source community" (remember that other projects use BitKeeper too), and not even really the leader of the "linux community".
I'm not sure it's realistic to think of it as a unified organization. At best it's a pretty loose confederation. You have folks like Linus, and folks like RMS (or worse), and everyone in between.
Of course not. Except ... if Linus makes a promise to Larry that is contingent upon the cooperation of the entire internet community, I guess he really should have gotten their assent first, yes. Hence "impossible".
...and you need to be party to an agreement to be bound by it.
IIRC he dissented from the decision to use BK for Linux way back in the beginning, along with Cox, RMS, et al. I'm a bit surprised nobody did it sooner, but I guess like myself most people at least tolerated things as long as Larry
Provoke McVoy how? By disobeying him?
It's not as if he ever wrote McVoy an email saying "nyah, nyah, I'm going to clone BK so suck it up!" or anything. McVoy heard about it third-hand and started demanding that Linus and OSDL shut him down.
Maybe Andrew was giving him too much credit. If Larry could have responded maturely, that would have been great, we could be assured of the freedom to move away from BitKeeper if needed, and many of the criticisms of BitKeeper would have died down. We'd probably still be using it for the forseeable future.
As it was, Larry spitefully exercised the "nuclear option", confirming everyone's worst fears.
Given this, disentangling projects from Larry's increasing domination seems a major long-term benefit to me.
The initial terms didn't seem so bad, but Larry has slowly made them more restrictive over time. Frog, meet slowly heated pot of water.
Linus was a fool, and is apparently now too blinded by buyer's remorse to think through the implications of the position he is now advocating.
He is, in effect, now advocating against Samba, against OpenOffice, against so much of the software developed using reverse-engineering due to uncooperative vendors.
If reverse-engineering against a vendor's wishes is really immoral, then so was developing that software, including many Linux device drivers.
Hopefully Linus will eventually work his way through the cognitive dissonance, as he could do some serious damage to the continued viability of Free Software (vis a vis interoperability) if he continues this line of advocacy. Heaven save us if Microsoft really picks up on this and runs with it.
...but not via a method that was free of McVoy's attempts at manipulation through onerous licensing terms.
Also remember that the Linux kernel isn't the only Open Source project hosted on bkbits.net.
How could Andrew have done it in a way that wouldn't have angered Larry? Larry said that he didn't want it reverse-engineered at all.
Question -- if one accepts that Larry is has a right to prohibit any reverse-engineering by fiat, isn't that denying Andrew's right to reverse-engineer?
It just doesn't work to say "if you'd just kept him happy, everything would have been okay!" It wouldn't have been. Appeasement never, never works. Domineering personalities just take further advantage.
Things weren't standing still; the BK license was getting increasingly more restrictive in ways that made migration increasingly difficult. Something had to give eventually, and I'm glad it wasn't our freedom as developers.
Looks like Linus is very carefully skirting the line and not implementing any actual SCM features in git himself, rather dropping hints and letting others do the actual work.
Again, that was Larry's doing, not Tridge's. Larry is the one who chose to employ collective punishment.
It's not clear to me why it's Linus' or Larry's place to dictate what projects Tridge can work on, if he is working within the bounds of the law and is not restricted by any legal agreements with them.
[ By the way, you do realize that Linux isn't the only Free Software project that was using BitKeeper at this point? This is bigger than Linus. ]
I'm sure Larry thought he was giving everyone a good deal, but a deal is something you are allowed to refuse. Obviously Tridge wasn't allowed to.
Ultimately, what this degenerated into was Larry trying to unilaterally impose his will on the entire development community by using the projects hosted on bkbits.net as hostages -- don't do anything he doesn't like (whether or not he has a right to demand it), or he'll take BitKeeper away!
Larry tried to maintain his company's position through backhanded manipulation rather than honest dealing, and I'm glad he failed.
gamma rays = high-energy photons
So, roughly none.
That's the way _I_ see it, from a long-term strategic point of view. I think Tridge was just trying to ensure that it was actually possible to migrate the change history and metadata to another SCM without going through the lossy CVS gateway.
I imagine Larry's own offering of a special export feature in BK didn't satisfy Tridge, since that would have barred anyone using it (or as recent events illustrate, given Larry's bizzare theory of license contagion, anyone even remotely associated with them) from working on a competing SCM.
That Larry's increasingly onerous license provisions were slowly setting up a "if anyone tries to escape I'll shoot the rest of the hostages" situation was all the more reason to take the risk now rather than later.
I don't think that was necessarily McVoy's conscious intent, but he was acting out of fear of losing control. Which became a self-fulfilling prophecy really.
That may be true of Tridge as well; the difference in Tridge's case being that he could justify his position in terms of preserving everyone's control over their own development activities, whereas Larry was effectively insisting on control of other people's, including situations where there were no voluntary contractual agreements nor rights under the law involved.
It looks like he was threatened with legal action and lawyered up, hence he isn't able to talk about it in detail yet. I'd expect him to be able to win, but that doesn't preclude him from having to prove his case in court if a civil suit is in fact brought against him.
That was obvious hyperbole on my part, but if you replace "Linus' bruises" with "increasingly onerous licence restrictions imposed on free BK licensees like Linus", and "I just bumped into a door" with "I'm just using the most practical tool at the moment," that is a bit closer to the reality.
An interesting question is whether Larry will choose to sue Linus for breaking the BK license by working on a competing SCM ("git") within the one-year non-compete window. As far as I know Linus wasn't under a special arrangement which would excempt him from that.
CVS loses some of the metadata -- and it's the metadata/change histories that you want to export when you switch revision control systems -- not just the raw code.
Even Larry realized that CVS wasn't sufficient, or he wouldn't have offered the direct-from-bk export functionality that Tridge turned down (since it would still require accepting a bk license to use).
That wouldn't be so onerous if the BK license didn't prohibit working on SCM code for a year after last use.
What intellectual property under the law would he have failed to protect? Copyrights? Patents? Trademarks? Or are you employing some sweeping extra-legal definition of "intellectual property"?
Larry made that impossible by setting impossible conditions. Or are you seriously suggesting that Linus could make a good-faith agreement that was binding on the entire world (including Tridge), without consulting them?
I thought the consensus was that there wasn't a tool comparable to BK yet. OTOH, according to Linus most of the improvements weren't BK-specific, but organizational and procedural changes that came out of experimenting with the additional flexibility BK gave.
So the situation is not quite so grave, and the state of free SCM tools will improve quickly out of necessity now that we're not stuck in this propreitary cul-de-sac (though we will feel the lingering effects of the BK "non-compete" clause for another year...). BK doesn't incorporate any radical new technologies in the SCM field; its primary advantage is a thoughtfully-tweaked interface that matched the way Linus likes to work.
Unpicking it requires an export tool, and frankly, like Tridge, I wouldn't personally want to rely wholly on Larry's good graces for one as Linus seemed willing to do.
So, is Larry providing one now? Tridge's was just a proof-of-concept.
(Admittedly that's kind of moot as it sounds like Linus did extract his own BK repository already. But what if he hadn't?)
This was on his own time, not when he was billing OSDL contract hours (he's a contractor, not an employee).
Larry did that, not Tridge.
Frankly, the more I read about the situation, the more this sounds like one of those situations where a controlling and jealous husband beats his wife because he doesn't like what some of her friends are doing. Then some people take the side of the husband and blame the friends for everything.
They insist how good he was was to her, and that he wasn't really TOO controlling, really. He PROVIDED for her. Where would she have been without him? Is it too much to ask if she and her friends could just show gratitude and respect his wishes?
The two are kinda friends at the moment; probably not.
Here's an interesting question... will Larry sue Linus for violating the one-year blackout period (after cessation of use) for SCM development that was stipulated in the free BitKeeper license?
So, basically Tridge should be grateful to his propreitary overlords for their product, rather than getting uppity and attempting to write compatible free software?
I realize that's not the way you're thinking of it -- I doubt that's even the way Larry thinks about it -- but those are the ultimate implications, and what that line of argument reduces to.
As it is, the state of free software SCM has been set back quite a bit, as the people in the position to do the most (e.g. Linus) have been distracted with a "good enough" propreitary tool, and subsequently restricted from participation by the "non-compete" clause Larry introduced in newer versions once Linus et al had adopted it.
Aside from finding that situation unacceptable on the face of it, I imagine Tridge also worried that Larry would continue to tighten the noose over time. From what I've heard from other people who have actually had to deal with him, it's not an unfounded concern.
The problem with relying on support for the neutral export format in BitKeeper is that you're still at Larry's mercy.
Based on Larry's past (e.g. lmbench!) and present behavior, that would be extremely unwise. In this instance, IMO, Linus is being a profound fool.
I don't blame Tridge for insisting on a method that doesn't continue to put everyone at the mercy of Larry's whims. Frankly, he's done Linus a favor, at least in the long-term.
Well, the basic problem is that you're either:
a) using a knife softer than the board -- in which case the knife will become dull quickly
or
b) using a knife harder than the board -- in which case the knife will leave grooves in the surface for bacteria to hide in
Why don't you just go tell that to Larry, then? It was his decision to yank BK, not Tridge's.
I can't help but be reminded the venom we received when we forked Sodipodi; people castigating us for ruining things by forking, and berating us as if we'd done something criminal ... "stealing" (that word was used) all the hard work that had gone into Sodipodi.
Heaven forbid we upset the apple cart by using legal and ethical means to ensure the freedom of users and developers...
MP3 is patent-encumbered, however.
OTOH, the Flash format is more or less openly documented, and there are OSS viewers.
Homestar. Runner.
There's a prisoner's dilemma involved, though. Unless you can guarantee that the other party won't continue to play, you still lose.
I think people are aware of the possibility already; my personal experience is that there are very immense social pressures against forking that increase with the scale and relative fame of the project.
That, combined with the GIMP project leadership not being dysfunctional enough to force the issue, is the only reason the GIMP hasn't seriously forked already (aside from CinePaint [nee FilmGimp]). Scott's effort looks like the first serious rumblings, however...
(This isn't to denigrate the contributions of the other three co-founders, of course, but I was the one who started the ball rolling; I came up with the name, bought the domain, convinced the other folks to come on board, set up the project (bryce might have been the one to set up the SF project actually), and IIRC personally did much of your step #2...)
I've already done that once, with the vector graphics application Sodipodi (the name I chose was "Inkscape" -- heard of it?).
Of course, Sodipodi was an easier fork to sell than the GIMP, because the problems were much deeper than naming and UI issues.
I don't have the energy to do that again for the Gimp, so someone else will have to carry that particular flag... (Scott, maybe?)
[ Btw, speaking as someone who's actually done it, step 2 isn't really automatable; certainly not on an ongoing basis. You may as well fork properly like Inkscape chose to do. ]