| |||||||||||||
Linus on the BK withdrawalLinus on the BK withdrawalPosted Apr 6, 2005 16:07 UTC (Wed) by gowen (guest, #23914)Parent article: Linus on the BK withdrawal
Larry in particular really did try to make things work outRight, except for dropping his insistence that he's allowed to dictate what other software projects BK users work on in their spare time.
(Log in to post comments)
Linus on the BK withdrawal Posted Apr 6, 2005 16:25 UTC (Wed) by philips (guest, #937) [Link] Flames, flames and flames.
Most imporatantly I haven't seen among anti-BK flamers for example Tom Lord - who is silently continues his work on GNU/Arch.
And other SCM developers too. They were silent. Most kernel developers were silent too. (Andrea Arcangeli's position is well known - but he is rather exception.)
So who was flaming them? Zealots, who had time to flame - but no capabilities to develop competitor?
Larry did his best. As always. I've seen most BK flames on LKML. Larry has more patience than me - that's for sure.
Linus on the BK withdrawal Posted Apr 6, 2005 20:06 UTC (Wed) by ballombe (subscriber, #9523) [Link] You should be more observant.
Ben Collins is both a kernel developer and a subversion developer, and has
Linus on the BK withdrawal Posted Apr 7, 2005 9:08 UTC (Thu) by gvy (guest, #11981) [Link] ...and then svn doesn't fit anyways, although the main point for him might be prohibitive clause (don't follow lkml in any ways -- moctly KT -- for quite a time, may just err).
Yep, people who yell and people who implement usually are just different...
Linus on the BK withdrawal Posted Apr 6, 2005 16:26 UTC (Wed) by pizza (subscriber, #46) [Link] > Right, except for dropping his insistence that he's allowed to dictate what other software projects BK users work on in their spare time.
Note, that's not "BK users", that's "People using the BK client they didn't pay a dime for." You can't get something for nothing. If you coughed up $$ for a full licence of BK, there are no restrictions on what software you develop using it.
It's his (company's) software, so they can set whatever terms they want. If you don't like those terms, then don't use BK. Simple, mmmm? It's not like you have to use BK in order to participate in kernel development.
I love McVoy's general attitude -- "If you don't like it, develop something better." And you know what? Rather than whining about it, some people are. Thus we have subversion, arch, darcs, codeville, monotone, etc attempting to do just that.
Linus on the BK withdrawal Posted Apr 6, 2005 16:40 UTC (Wed) by gowen (guest, #23914) [Link] It's his (company's) software, so they can set whatever terms they wantNo one's denying that. Larry is completely within his rights. The comedic cognitive dissonance arises because the descriptions of his actions
Or, of course, when he does something insanely moronic, like suggest kernel developers should "Code Red" one of their members, like the Marine Corps.
Linus on the BK withdrawal Posted Apr 7, 2005 9:16 UTC (Thu) by gvy (guest, #11981) [Link] Gowen, please stop bragging this BS here.
They ARE (at least were) OS-friendly. They DIDN'T claim to compare with Novell TTBOMK. Whom are you arguing with, or just a troll?
Linus on the BK withdrawal Posted Apr 7, 2005 13:22 UTC (Thu) by gowen (guest, #23914) [Link] They DIDN'T claim to compare with NovellThey described themselves as "as open-source friendly a commercial organization as you are *ever* going to see." Sorry kiddo, but that's a superlative, and that means they're comparing themself with everyone.
Linus on the BK withdrawal Posted Apr 12, 2005 19:11 UTC (Tue) by zander76 (guest, #6889) [Link] Hmm, Interesting point.
Well the fact is that they may or may not release there software opensource. They released a commercial product to a group of opensource developers for free. That does sound like an opensource frendly commercial company. They decided to help when there were no other alternatives (aside from cvs of course).
As far as Novel, perhaps you have not been reading but they have released a lot of tech from both Suse and Ximian that were originally closed source. So they are releasing. Perhaps not as quick as you would like but Novel was a completely closed company and Suse was open source yet suse ended up with closed source tech that was later released by Novel. So positions are changing.
Later
Linus on the BK withdrawal Posted Apr 6, 2005 16:52 UTC (Wed) by jamesh (guest, #1159) [Link] > If you coughed up $$ for a full licence of BK, there are no restrictions on what software you develop using it.
It is not quite that simple. There has been a documented occasion where BitMover has refused to let a company buy a BK commercial license on the basis of an employee's actions:
http://lwn.net/Articles/103727/
So there are cases where an individual or company can be left in a position where they couldn't use BK, even if they could afford a commercial license.
Come back to earth, please. Posted Apr 6, 2005 16:53 UTC (Wed) by GreyWizard (guest, #1026) [Link] Hello? McVoy stated in no uncertain terms that his main motivation for the license restriction was to make it more difficult for anyone to create a BitKeeper competitor. Do you really think he would tolerate reverse engineering from a paying customer? Think again. Even if he has explicitly said he would allow it (I've never read anything to that effect) that would just be spin until a paying customer actually contributed to a free software revision control system. Rest assured if that ever happens the fur will fly.
While I'm on the subject, why is it that when Bill Gates gives software away without charge and puts create terms in its EULA to control the behavior of people who agree there is an uproar but when Larry McVoy does the same people declare him some kind of unappreciated folk hero? Microsoft ought to hire this guy for their public relations department.
Actually, yes Posted Apr 6, 2005 17:04 UTC (Wed) by bos (guest, #6154) [Link] Larry has explicitly said, in public and in private, that paying customers are not prevented from working on open or closed source SCM tools. As a paying customer, I've seen and signed off on the commercial BK license, and there are no clauses to that effect in there.
Actually, yes Posted Apr 6, 2005 17:48 UTC (Wed) by GreyWizard (guest, #1026) [Link] Well, that's interesting. One of three things is necessarily true here: either you're full of beans (I have no reason to doubt you), McVoy's claims are merely opportunistic spin that would be retracted the moment he discovered a paying customer contributing to a competing system or McVoy is a moron. Placing restrictions on what people who download the free tool can do with it is, as has been clearly demonstrated and easily proven with McVoy's own words, a public relations problem. That has some cost, at least in emotional terms. But if you don't also constrain the paying customers it is also a pointless exercise.
Suppose I'm an evil developer with the skills to reverse engineer protocols who wants nothing more than to "steal" McVoy's precious intellectual property. All I have to do is buy a license. Suppose I don't have the cash. No problem! I'll just get a job with a company that has a BitKeeper site license. Of course, I could probably raise the money in hours if I solicited donations from the hordes of grumpy kernel hackers who flame about the BitKeeper license in the first place, but I'd probably have to use a psuedonym to throw off the sales people. Either way the restrictions in the no charge license are not a significant obstacle to me. All they do is create grief for McVoy.
I remain convinced of what I said in my original post: once this happens the fur will fly. McVoy is more rabid about protecting his secret sauce than just about anyone and while he might be a jerk he is anything but stupid. The claim that he would tolerate competition from paying customers while spending his time threatening legal action on the Linux kernel mailing list seems to me deeply disingenuous.
Actually, no Posted Apr 7, 2005 16:42 UTC (Thu) by GreyWizard (guest, #1026) [Link] http://lwn.net/Articles/103727/
BitMover has actually refused to sell someone a license because they suspected that a developer employed by the prospective customer would contribute to a free software source control system. Maybe paying customers are not prevented from working on source code management tools, but if so that is only because BitMover does a background check to decide whether someone is likely to do so before allowing them to become a paying customer in the first place. Do you really mean to suggest that McVoy would ignore the situation if he discovered a paying customer who had passed this screening process later decided to work on a competing project?
If not then my comments in the grandparent post are exactly correct.
Actually, no Posted Apr 7, 2005 16:55 UTC (Thu) by bos (guest, #6154) [Link] The guy in question (a) was obnoxious and (b) had said in advance that he wanted to clone BK, so of course they didn't sell him a license. People like that can be a major support burden, and often cost a lot more to deal with than one can make off licensing and support fees.
What occurs *after* someone buys a license is an entirely different thing, because there's then a well-defined legal agreement in place that puts specific obligations on both parties.
As to whether Larry would ignore it if he discovered that a paying customer was working on cloning BK, I'd expect that to depend on the circumstances (surprise, surprise). I do know that a number of companies have bought BK licenses, with Larry's foreknowledge and assent, explicitly so that their employees could continue to work on competing open source SCM tools.
Having it both ways? Posted Apr 7, 2005 17:47 UTC (Thu) by GreyWizard (guest, #1026) [Link] On the one hand, we have a clearly documented case where McVoy will refused to sell licenses to someone who declared, in advance, that he intended to work on a competing source control system (I'm not convinced that obnoxiousness and support costs were the reasons because McVoy himself emphasized the competitive issue exclusively in his first comment). On the other, you seem to claim that McVoy happily sold licenses to other companies who claimed, in advance, that some of their developers were currently working on competing source control systems -- all under license terms that place no restrictions on what those developers are able to do with BitKeeper.
Sorry, but this time I actually *do* think you're full of beans. Maybe you could name these companies and provide some sort of linkable evidence?
Having it both ways? Posted Apr 7, 2005 18:11 UTC (Thu) by bos (guest, #6154) [Link] Sure. Red Hat has some commercial BK licenses; this has been public knowledge for a while. My recollection is fuzzy, but I believe that David Miller refused to use BK without a commercial license because of the restrictions in the free license.
I also know that at least one much larger company has bought commercial BK licenses for somewhat similar reasons, but I'd rather not say who.
Are we discussing the same thing? Posted Apr 7, 2005 20:50 UTC (Thu) by GreyWizard (guest, #1026) [Link] Each of your examples is problematic. RedHat is not well known for their work on source control products. They do quite a lot of kernel development, and if they have a license it is probably intended to resolve cases like this one. That is hardly a reasonable example of competition. David Miller does not directly contribute to any project that competes with BitKeeper, so his purchase is irrelevant. Meanwhile, I'd rather not argue about this mysterious larger company you'd rather not name. Are we even discussing the same thing? My point is that is that Larry McVoy is zealous about preventing anyone who contributes to a project he considers competitive from using BitKeeper. This is supported by his own statements, such as: He does not say they don't get to use BK "unless they pay for it." Clearly he doesn't want them to use it at all. To the extent the paid license doesn't explicitly enforce this it's either an oversight or a lazy attempt at spin that would be immediately reversed if it ever became relevant. (I'm not sure exactly how this reversal would be implemented, but a simple license change would probably work because customers like you will eventually need updates, support or both. There may even be a clause allowing BitMover to alter the license unilaterally.) I find it unimaginable that McVoy would not take immediate action in response to competition from a customer.
Are we discussing the same thing? Posted Apr 7, 2005 21:05 UTC (Thu) by bos (guest, #6154) [Link] Sure, Red Hat isn't interested in SCM; they still use CVS to do most of their work, for example. The mysterious larger company actively works on SCM, but I doubt there's any overlap between their BK users and their SCM developers.
Certainly, Larry has been pretty vigorous about preventing naked competitors from using BK when he's had foreknowledge.
Are we discussing the same thing? Posted Apr 12, 2005 19:20 UTC (Tue) by zander76 (guest, #6889) [Link] Well, I don't know if I would say that RedHat is not a treat. RedHat is a commercial organization and if at anypoint they saw profit in SCM then they would be in there.
And your point is...? Posted Apr 12, 2005 19:35 UTC (Tue) by GreyWizard (guest, #1026) [Link] RedHat does not compete with BitMover today. That they could do so at some point in the future is irrelevant because the same can be said for any company that might consider purchasing BitKeeper. Refusing to sell on this basis would mean refusing to sell at all.
Linus on the BK withdrawal Posted Apr 6, 2005 22:47 UTC (Wed) by kasperd (guest, #11842) [Link] > It's his (company's) software, so they can set whatever terms they want.
This is not true. In many countries these terms are in conflict with the law. Had I downloaded the client in order to access the kernel sources, I would also have been allowed to reverse engineer it. It doesn't matter what the license says, because the law clearly says I cannot give up my right to reverse engineer software.
Linus on the BK withdrawal Posted Apr 7, 2005 1:22 UTC (Thu) by hppnq (guest, #14462) [Link] Actually, this whole reverse engineering debate is not at all about your right as a person to reverse engineer whatever software. (You don't really think that Larry and his legal counsil would have overseen this, do you?)It's about how much information Larry has to release in order for other developers to use that in their own software. Which is an entirely different discussion and one you are not likely to win in court. Since Larry is not at all obliged to release *any* information.
Linus on the BK withdrawal Posted Apr 7, 2005 2:02 UTC (Thu) by hppnq (guest, #14462) [Link] s/overseen/missed, sorry, its' getting late here. Or early, rather. ;-)
Linus on the BK withdrawal Posted Apr 7, 2005 6:43 UTC (Thu) by kasperd (guest, #11842) [Link] I don't think their lawyers knows the law in every country. This license might very well comply with American law. But did they actually take a look on the law in every European country? I don't think they did.
You say they are not obliged to release any information about their protocol. While that might be true, releasing the information would change the reverse engineering situation. In the Danish law, the right to reverse engineer only applies if you don't have easy access to this information. By giving everybody access to format and protocol specifications, they could actually make the reverse engineering illegal.
What the law says in other countries I won't say much about, since I haven't read it. I have read on the internet, that multiple European countries have laws similar to the Danish on this area, but American law is different.
Linus on the BK withdrawal Posted Apr 7, 2005 8:33 UTC (Thu) by hppnq (guest, #14462) [Link] At least they have most likely thought about it quite a bit harder than most of us here. IANALOT either, I just want to point out that it seems to me that this particular aspect of the debate doesn't get a lot of airplay.Your example of the Danish law would be perfectly aligned with what Larry has been saying quite consistently: he won't do anything to actively help anyone reverse engineer the inner magic of BitKeeper. (Note, by the way, the contradictio in terminis that is hidden in here. It's not all wordplay, it reflects the absurdity of the demands that some people think they can lay on Larry.)
Linus on the BK withdrawal Posted Apr 7, 2005 20:31 UTC (Thu) by kasperd (guest, #11842) [Link] > he won't do anything to actively help anyone reverse engineer the inner magic of BitKeeper.
What is this inner magic of which he talks? Good heuristics to merge branches and avoid conflicts? I don't think there is much magic in software. Good heuristics is what looks most like magic to me.
Reverse engineering the formats and protocols isn't necesarilly the same as reverse engineering the heuristics. But of course when you do reverse engineering it may not be possible to reverse engineer exactly the right corner of the code, and you may end find out a lot more than what you really needed.
Had formats and protocols been published the reverse engineering rights had no longer applied. And maybe that way BitMover could have forbidden me to reverse engineer the code.
So in some sense publishing more information could have made it harder to (legally) reverse engineer the inner magic of BitKeeper.
Linus on the BK withdrawal Posted Apr 7, 2005 22:06 UTC (Thu) by hppnq (guest, #14462) [Link] I can't really follow you here, I'm afraid. Maybe it's because I'm much too lazy to reverse engineer a program, I'd much rather spend my time trying to reverse engineer the programmer who wrote the program, for instance, and start from there (not that I am particularly good at it ;-). Or is that what you call "reverse engineering heuristics"?You seem to suggest that it can't be that hard to write a non-trivial piece of software. I'm quite sure any kernel hacker would agree with me that, looking at random bits and pieces of an OS kernel, none would look too complicated. The general operation of an OS kernel is no rocket science either. Getting everything right all the time, however, that's much more like black magic. (Funnily enough, in physics the exact same problem is related to "degrees of freedom". The similarity doesn't end there, but I won't bore you with that. ;-) (The term "inner magic", by the way, is not Larry's, as far as I know, if that is of some importance to you.)
Linus on the BK withdrawal Posted Apr 7, 2005 14:23 UTC (Thu) by harcho (guest, #29107) [Link] Personally I also wouldn't be all too suprised to find that a certain company in Redmond has quietly passed something under the table to our man of the moment Larry to persuade him that it is not in his best interest to continue supporting a free BK for the Linux Kernel.
What better way to chop the legs out of Linux Development than to target the tools used to support that development. It makes simple sense to me and it explains better why using closed source tools to support Great Open Source Software will always be a dangerous exercise.
It always leaves you open to Subversion without you even knowing that it is happening.
All in all a useful learning experience I would say and one I certainly hope people are paying attention to.
Linus on the BK withdrawal Posted Apr 7, 2005 22:18 UTC (Thu) by hppnq (guest, #14462) [Link] Nice one. ;-)Without any evidence it seems a bit too far fetched for me, at least in this case, but it is not unimaginable...
|
|||||||||||||