* New BK License Problem? @ 2002-10-04 20:55 tom_gall 2002-10-04 21:08 ` Larry McVoy ` (2 more replies) 0 siblings, 3 replies; 223+ messages in thread From: tom_gall @ 2002-10-04 20:55 UTC (permalink / raw) To: linux-kernel Greetings all, I noticed Larry recently changed the license on bk. Once clause in particular struck me and I thought I'd better point it out for your reactions... Specifically from Section 3: (d) Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capabil- ities of the BitKeeper Software, or, in the reason- able opinion of BitMover, competes with the BitKeeper Software. Doesn't this affect maintainers all across the map that work for distros such as RedHat, SuSE, Connectiva, etc? Obviously these distros SELL as part of their respective products CVS and similar tools. Or even non-distro open source shops, you even resell CVS or the like in some way and you'd be in trouble. While I am all for Larry having a profitable business, this would seem to be a change which is not Open Source developer friendly. Regards, Tom ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 20:55 New BK License Problem? tom_gall @ 2002-10-04 21:08 ` Larry McVoy 2002-10-04 21:33 ` tom_gall ` (2 more replies) 2002-10-05 13:10 ` Hans Reiser 2002-10-05 13:17 ` Hans Reiser 2 siblings, 3 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-04 21:08 UTC (permalink / raw) To: tom_gall; +Cc: linux-kernel > I noticed Larry recently changed the license on bk. Once clause in This isn't a recent change at all, I know it is at least 6 months old because it was included in BitKeeper version is bk-2.1.6-pre5 20020330075529 for x86-glibc22-linux Built by: lm@redhat71.bitmover.com in /build/bk-2.1.x-lm/src Built on: Sat Mar 30 00:14:45 PST 2002 > (d) Notwithstanding any other terms in this License, this > License is not available to You if You and/or your > employer develop, produce, sell, and/or resell a > product which contains substantially similar capabil- > ities of the BitKeeper Software, or, in the reason- > able opinion of BitMover, competes with the BitKeeper > Software. > > Doesn't this affect maintainers all across the map that work for > distros such as RedHat, SuSE, Connectiva, etc? Obviously these distros > SELL as part of their respective products CVS and similar tools. Or > even non-distro open source shops, you even resell CVS or the like in > some way and you'd be in trouble. Distributions do not *SELL* CVS, they distribute CVS. We choose those words with care for exactly that reason. All the clause is saying is that if you are a competitor you don't get to use our product for free. That it, in our opinion, a perfectly reasonable position to take. > While I am all for Larry having a profitable business, this would seem > to be a change which is not Open Source developer friendly. The clause is specifically designed to target those companies which produce or sell commercial SCM systems. That's why we explicitly left out "distribute". The open source developers have nothing to worry about. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 21:08 ` Larry McVoy @ 2002-10-04 21:33 ` tom_gall 2002-10-04 21:38 ` Larry McVoy 2002-10-05 0:50 ` Rob Landley 2002-10-04 23:02 ` David S. Miller 2002-10-05 17:54 ` Ben Collins 2 siblings, 2 replies; 223+ messages in thread From: tom_gall @ 2002-10-04 21:33 UTC (permalink / raw) To: Larry McVoy; +Cc: linux-kernel On Friday, October 4, 2002, at 04:08 PM, Larry McVoy wrote: >> (d) Notwithstanding any other terms in this License, this >> License is not available to You if You and/or your >> employer develop, produce, sell, and/or resell a >> product which contains substantially similar capabil- >> ities of the BitKeeper Software, or, in the reason- >> able opinion of BitMover, competes with the BitKeeper >> Software. >> >> Doesn't this affect maintainers all across the map that work for >> distros such as RedHat, SuSE, Connectiva, etc? Obviously these >> distros >> SELL as part of their respective products CVS and similar tools. Or >> even non-distro open source shops, you even resell CVS or the like in >> some way and you'd be in trouble. > > Distributions do not *SELL* CVS, they distribute CVS. Of course they sell CVS. I give them money, they give me a CD, that CD has CVS on it. If I have a support contract with that distro and CVS breaks they will fix it. I don't doubt if I went to the various distros with money in hand for extra features for CVS they would put them in. > We choose those > words with care for exactly that reason. All the clause is saying is > that if you are a competitor you don't get to use our product for free. > That it, in our opinion, a perfectly reasonable position to take. Yeah I understand what your intent is and I'm not flaming you. I have a problem with the wording in that claus. Unfortunately you're not a lawyer so your stated intent means little, it's the language in the license that has meaning. Regards, Tom ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 21:33 ` tom_gall @ 2002-10-04 21:38 ` Larry McVoy 2002-10-04 22:16 ` Dr. David Alan Gilbert 2002-10-05 0:50 ` Rob Landley 1 sibling, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-04 21:38 UTC (permalink / raw) To: tom_gall; +Cc: Larry McVoy, linux-kernel > > Distributions do not *SELL* CVS, they distribute CVS. > > Of course they sell CVS. I give them money, they give me a CD, that CD > has CVS on it. That's your opinion. That's not our opinion. > Yeah I understand what your intent is and I'm not flaming you. I have a > problem with the wording in that claus. Unfortunately you're not a > lawyer so your stated intent means little, it's the language in the > license that has meaning. We're not changing the wording in the license just because you have a problem with it. Unless some lawyer wants to explain to me why this wording doesn't do what I want it to do, and unless I actually believe they are operating in the best interests of BitMover, the language stands as it is. Unless you are competing with us you have no reason to be worried. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 21:38 ` Larry McVoy @ 2002-10-04 22:16 ` Dr. David Alan Gilbert 2002-10-04 22:36 ` Roman Zippel 0 siblings, 1 reply; 223+ messages in thread From: Dr. David Alan Gilbert @ 2002-10-04 22:16 UTC (permalink / raw) To: Larry McVoy, tom_gall, linux-kernel * Larry McVoy (lm@bitmover.com) wrote: > We're not changing the wording in the license just because you have a > problem with it. Unless some lawyer wants to explain to me why this > wording doesn't do what I want it to do, and unless I actually believe > they are operating in the best interests of BitMover, the language > stands as it is. Just to be clear; does that term in the license affect a company, or its employees, that is a competitor of yours if they use bitkeeper in a way unrelated to the competition aspect? So for example is an employee of a competitor or the competitor itself allowed to download the linux kernel source using bitkeeper? Lets take that previous question and split it into 2: a) If they use the kernel source for something irrelevent to the competing product. b) If they use the kernel source for something relevent to the competing product (e.g. if they were to take the kernel and produce a proprietary module for accessing their system, or even just just use the kernel on the server they happen to store their products source on). I'd definitly find it objectionable if (a) came under the license conditions and a bit disturbing for (b). Anyway, wouldn't you be flattered if a competitor decided to use bitkeeper to store their code in? Dave ---------------- Have a happy GNU millennium! ---------------------- / Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 22:16 ` Dr. David Alan Gilbert @ 2002-10-04 22:36 ` Roman Zippel 2002-10-05 0:04 ` David S. Miller 0 siblings, 1 reply; 223+ messages in thread From: Roman Zippel @ 2002-10-04 22:36 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: Larry McVoy, tom_gall, linux-kernel Hi, On Fri, 4 Oct 2002, Dr. David Alan Gilbert wrote: > Just to be clear; ... this is completely offtopic, can this _please_ be moved to a bk list? Thanks. bye, Roman ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 22:36 ` Roman Zippel @ 2002-10-05 0:04 ` David S. Miller 2002-10-05 0:32 ` Larry McVoy 2002-10-05 10:26 ` Roman Zippel 0 siblings, 2 replies; 223+ messages in thread From: David S. Miller @ 2002-10-05 0:04 UTC (permalink / raw) To: zippel; +Cc: gilbertd, lm, tom_gall, linux-kernel From: Roman Zippel <zippel@linux-m68k.org> Date: Sat, 5 Oct 2002 00:36:16 +0200 (CEST) On Fri, 4 Oct 2002, Dr. David Alan Gilbert wrote: > Just to be clear; ... this is completely offtopic, can this _please_ be moved to a bk list? Thanks. It is very ontopic because it affects a number of kernel developers. Whether you like BK or not, it is the primary source management tool used by Linus and others, it is even documented in the source tree as such. Therefore, such a license change could change that, so it's a relavant topic. And finally, as the person who has to maintain this list and deal with the daily bounce pool this list generates every day, I declare it as ontopic so :-P~~~~~~ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 0:04 ` David S. Miller @ 2002-10-05 0:32 ` Larry McVoy 2002-10-05 1:54 ` John Levon 2002-10-05 10:26 ` Roman Zippel 1 sibling, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-05 0:32 UTC (permalink / raw) To: David S. Miller; +Cc: zippel, gilbertd, lm, tom_gall, linux-kernel > Whether you like BK or not, it is the primary source management tool > used by Linus and others, it is even documented in the source tree as > such. > > Therefore, such a license change could change that, so it's a relavant > topic. And in the "for what it is worth" department, when we contemplate changes to the BKL, we've made a practice of discussing them here first. We try and keep it to a minimum, it's not exactly a popular topic, but we also make sure that we don't surprise anyone who is paying attention. I know that some of our license decisions have been, err, less than warmly received, but we are operating in good faith, we want to help the kernel folks, and that policy hasn't changed and won't change as long as I own more than 50% of BitMover stock (still do, working hard to keep it so). IBM recently became worried that they were violating the license and we are working out a waiver for them because it is obvious that their work is valued by the kernel community. It's a little weird because I frequently argue against the SMP/NUMA stuff that IBM does, but that's technical and BK licenses are business and I don't mix the two, that would be both insane and unethical. So rest assured, all you IBMers and anyone else who cares, IBM and BitMover are figuring out a way that all the IBM hackers can keep on using BK if that's what they want. One hacker, when told that they might not be able to use BK anymore, asked if she could buy a copy with her own money. I haven't been told who that was but when I find out, she gets a BK t-shirt and our undieing support. That's what we like to see :) -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 0:32 ` Larry McVoy @ 2002-10-05 1:54 ` John Levon 0 siblings, 0 replies; 223+ messages in thread From: John Levon @ 2002-10-05 1:54 UTC (permalink / raw) To: linux-kernel; +Cc: Larry McVoy On Fri, Oct 04, 2002 at 05:32:16PM -0700, Larry McVoy wrote: > And in the "for what it is worth" department, when we contemplate changes > to the BKL, To be frank, I could not imagine a more appropriate list for discussion of changes to lock_kernel() ! </misunderstanding> regards john -- "Me and my friends are so smart, we invented this new kind of art: Post-modernist throwing darts" - the Moldy Peaches ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 0:04 ` David S. Miller 2002-10-05 0:32 ` Larry McVoy @ 2002-10-05 10:26 ` Roman Zippel 2002-10-05 10:23 ` David S. Miller 1 sibling, 1 reply; 223+ messages in thread From: Roman Zippel @ 2002-10-05 10:26 UTC (permalink / raw) To: David S. Miller; +Cc: gilbertd, lm, tom_gall, linux-kernel Hi, On Fri, 4 Oct 2002, David S. Miller wrote: > It is very ontopic because it affects a number of kernel developers. Does it? So far it was only a question and there are better places than lkml to research it. > Whether you like BK or not, it is the primary source management tool > used by Linus and others, it is even documented in the source tree as > such. I don't care about bk and I wouldn't care about such questions either, if Larry wouldn't use every such opportunity to publicly jerk off about bk. bye, Roman ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 10:26 ` Roman Zippel @ 2002-10-05 10:23 ` David S. Miller 0 siblings, 0 replies; 223+ messages in thread From: David S. Miller @ 2002-10-05 10:23 UTC (permalink / raw) To: zippel; +Cc: gilbertd, lm, tom_gall, linux-kernel From: Roman Zippel <zippel@linux-m68k.org> Date: Sat, 5 Oct 2002 12:26:49 +0200 (CEST) I don't care about bk and I wouldn't care about such questions either, if Larry wouldn't use every such opportunity to publicly jerk off about bk. Pure comedy :-) ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 21:33 ` tom_gall 2002-10-04 21:38 ` Larry McVoy @ 2002-10-05 0:50 ` Rob Landley 2002-10-06 2:17 ` Daniel Berlin 1 sibling, 1 reply; 223+ messages in thread From: Rob Landley @ 2002-10-05 0:50 UTC (permalink / raw) To: tom_gall, Larry McVoy; +Cc: linux-kernel On Friday 04 October 2002 05:33 pm, tom_gall@mac.com wrote: > Yeah I understand what your intent is and I'm not flaming you. I have a > problem with the wording in that claus. Unfortunately you're not a > lawyer so your stated intent means little, it's the language in the > license that has meaning. Actually, his stated intent means an awful lot, if you can get it in writing. Which, thanks to the archived nature of this list, you have. (Remember, the legal basis for contract law is just informed consent and the recording thereof. The license itself is merely a formal and carefully worded version of "what he said".) A verbal contract may only be worth the paper it's printed on, but it IS legally binding if you can prove it. And even relatively casual statements, if recorded, can show up to haunt you in court later on. Larry said who he wouldn't sue. If he then goes and sues them, these old emails show in court and undercut his case in a big way. That's not a guarantee in any judicial system that could let OJ off and give a million dollars to a woman who spills McDonalds coffee on herself, but it's probably about as good as you're going to get. > Regards, > > Tom Rob ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 0:50 ` Rob Landley @ 2002-10-06 2:17 ` Daniel Berlin 0 siblings, 0 replies; 223+ messages in thread From: Daniel Berlin @ 2002-10-06 2:17 UTC (permalink / raw) To: Rob Landley; +Cc: tom_gall, Larry McVoy, linux-kernel On Fri, 4 Oct 2002, Rob Landley wrote: > On Friday 04 October 2002 05:33 pm, tom_gall@mac.com wrote: > > > Yeah I understand what your intent is and I'm not flaming you. I have a > > problem with the wording in that claus. Unfortunately you're not a > > lawyer so your stated intent means little, it's the language in the > > license that has meaning. > > Actually, his stated intent means an awful lot, if you can get it in > writing. Not in the case of this license. > Which, thanks to the archived nature of this list, you have. (Remember, the > legal basis for contract law is just informed consent and the recording > thereof. The license itself is merely a formal and carefully worded version > of "what he said".) > > A verbal contract may only be worth the paper it's printed on, but it IS > legally binding if you can prove it. Do a google search on "fully integrated agreement" and "parol evidence rule". > And even relatively casual statements, > if recorded, can show up to haunt you in court later on. Only if you haven't got a fully integrated agreement. If you do, they'd never appear in court. If you look at the license, you'll note it has a merger clause ("This License represents the complete agreement between You and BitMover regarding the BitKeeper Software covered by this License."). I'm sure it's there specifically so the parol evidence rule applies completely. --Dan ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 21:08 ` Larry McVoy 2002-10-04 21:33 ` tom_gall @ 2002-10-04 23:02 ` David S. Miller 2002-10-04 23:33 ` Larry McVoy 2002-10-05 17:54 ` Ben Collins 2 siblings, 1 reply; 223+ messages in thread From: David S. Miller @ 2002-10-04 23:02 UTC (permalink / raw) To: lm; +Cc: tom_gall, linux-kernel From: Larry McVoy <lm@bitmover.com> Date: Fri, 4 Oct 2002 14:08:02 -0700 The clause is specifically designed to target those companies which produce or sell commercial SCM systems. That's why we explicitly left out "distribute". The open source developers have nothing to worry about. I don't have any problems with what you're trying to achieve, but my fear is that it doesn't even do that. Nothing in your license changes stops someone from dark-room duplicating bitkeeper. Just as clone Intel processors are sold quite legally today. Intel lost their attempts to stop that and my current guess is that you have a smaller legal representation than Intel has :-) ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 23:02 ` David S. Miller @ 2002-10-04 23:33 ` Larry McVoy 2002-10-04 23:28 ` David S. Miller [not found] ` <20021005003840.GQ710@gallifrey> 0 siblings, 2 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-04 23:33 UTC (permalink / raw) To: David S. Miller; +Cc: lm, tom_gall, linux-kernel On Fri, Oct 04, 2002 at 04:02:16PM -0700, David S. Miller wrote: > From: Larry McVoy <lm@bitmover.com> > Date: Fri, 4 Oct 2002 14:08:02 -0700 > > The clause is specifically designed to target those companies which > produce or sell commercial SCM systems. That's why we explicitly > left out "distribute". The open source developers have nothing to > worry about. > > I don't have any problems with what you're trying to achieve, but my > fear is that it doesn't even do that. > > Nothing in your license changes stops someone from dark-room > duplicating bitkeeper. That's fine, if someone wants to redo it without using it, that's fair, at least to the extent that it doesn't violate any IP rights. That's not the problem we're solving. What we are saying is "If you make or sell a competing product, you don't get to use ours for free". That's all. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 23:33 ` Larry McVoy @ 2002-10-04 23:28 ` David S. Miller [not found] ` <20021005003840.GQ710@gallifrey> 1 sibling, 0 replies; 223+ messages in thread From: David S. Miller @ 2002-10-04 23:28 UTC (permalink / raw) To: lm; +Cc: tom_gall, linux-kernel From: Larry McVoy <lm@bitmover.com> Date: Fri, 4 Oct 2002 16:33:35 -0700 What we are saying is "If you make or sell a competing product, you don't get to use ours for free". That's all. Ok, thanks for the clarification. ^ permalink raw reply [flat|nested] 223+ messages in thread
[parent not found: <20021005003840.GQ710@gallifrey>]
[parent not found: <20021004174501.Q835@work.bitmover.com>]
[parent not found: <20021005005344.GR710@gallifrey>]
[parent not found: <20021004180600.R835@work.bitmover.com>]
[parent not found: <20021005011706.GU710@gallifrey>]
[parent not found: <20021004185325.V835@work.bitmover.com>]
* Re: New BK License Problem? [not found] ` <20021004185325.V835@work.bitmover.com> @ 2002-10-05 11:54 ` Dr. David Alan Gilbert 0 siblings, 0 replies; 223+ messages in thread From: Dr. David Alan Gilbert @ 2002-10-05 11:54 UTC (permalink / raw) To: Larry McVoy; +Cc: linux-kernel In private email with Larry I asked him to clarify the question to the list; he didn't want to; but he did clarify to me the following and said I could pass it on. Here is my understanding of what he said. It really does appear that if you happen to be employed by a rival of Larry's then you aren't allowed to use it, even to check out free software unless you talk to Larry first. He seems to be open to working out exemptions/work arounds for particular organisations. I was worried that this meant that some people didn't have access to free software stored with bk; he pointed out that he has gone to great lengths to make the file formats fully compatible with SCCS (which answered my question of why something in this day and age had messages about SCCS appearing). So it should be possible to access the software using software other than bitkeeper. Now while I happen to not to like the idea of a license that restricts usage based on who you happen to work for, my main fear (of people being unable to get to hosted software) seems to be irrelevent due to this SCCS compatibility. So how does one use SCCS/CSSC to get the bk kernel repositories? That is my last message on this subject. Dave ---------------- Have a happy GNU millennium! ---------------------- / Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 21:08 ` Larry McVoy 2002-10-04 21:33 ` tom_gall 2002-10-04 23:02 ` David S. Miller @ 2002-10-05 17:54 ` Ben Collins 2002-10-05 18:25 ` Larry McVoy 2002-10-06 0:27 ` New BK License Problem? Rik van Riel 2 siblings, 2 replies; 223+ messages in thread From: Ben Collins @ 2002-10-05 17:54 UTC (permalink / raw) To: Larry McVoy, linux-kernel > > (d) Notwithstanding any other terms in this License, this > > License is not available to You if You and/or your > > employer develop, produce, sell, and/or resell a > > product which contains substantially similar capabil- > > ities of the BitKeeper Software, or, in the reason- > > able opinion of BitMover, competes with the BitKeeper > > Software. > > > > Doesn't this affect maintainers all across the map that work for > > distros such as RedHat, SuSE, Connectiva, etc? Obviously these distros > > SELL as part of their respective products CVS and similar tools. Or > > even non-distro open source shops, you even resell CVS or the like in > > some way and you'd be in trouble. > > Distributions do not *SELL* CVS, they distribute CVS. We choose those > words with care for exactly that reason. All the clause is saying is > that if you are a competitor you don't get to use our product for free. > That it, in our opinion, a perfectly reasonable position to take. Larry, I develop for the Subversion project. Does that mean my license to use bitkeeper is revoked? I've also been wanting to use bitkeeper to create a Subversion mirror of the kernel repository, but I suspect that my usage falls seriously into this category, as my reasons for doing so are three-fold; allow access to the bkbits repo to folks who don't want to use bk, but with all the joys of an SCM (history, changesets, etc.); stress test Subversion against a real-world high-activity repo; promote Subversion. Would it be your intention that your license disallow my type of work? I think it does. Ben -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 17:54 ` Ben Collins @ 2002-10-05 18:25 ` Larry McVoy 2002-10-05 18:35 ` Ben Collins ` (3 more replies) 2002-10-06 0:27 ` New BK License Problem? Rik van Riel 1 sibling, 4 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-05 18:25 UTC (permalink / raw) To: Ben Collins; +Cc: Larry McVoy, linux-kernel On Sat, Oct 05, 2002 at 01:54:37PM -0400, Ben Collins wrote: > Larry, I develop for the Subversion project. Does that mean my license > to use bitkeeper is revoked? Yes. It has been since we shipped that license or when you started working on Subversion, whichever came last. > I've also been wanting to use bitkeeper to create a Subversion mirror of > the kernel repository, but I suspect that my usage falls seriously into > this category, as my reasons for doing so are three-fold; allow access > to the bkbits repo to folks who don't want to use bk, but with all the > joys of an SCM (history, changesets, etc.); stress test Subversion > against a real-world high-activity repo; promote Subversion. > > Would it be your intention that your license disallow my type of work? I > think it does. You bet it does. The Subversion folks would like nothing better than to displace BK. That's fine, but they don't get to use BK to do it. You're absolutely correct that you could use BK to make Subversion better. It is not our job to help you make Subversion better and we've made that clear for a long time. We're a business. We're a business which happens to be committed to helping the kernel team because we think that the kernel is vital to the world at large. Helping the kernel absolutely does not translate to helping people who happen to be our competitors. By your own description and by our experience with you, you would be a competitor. And since we're here, I'll take this opportunity to remind you that when I asked about getting a netwinder so I could support the ARM folks, you were the guy who sent me mail saying you had some that you weren't using and that we couldn't have one because you didn't like our license. If I recall it was either that mail exchange or a subsequent one in which you made it clear that you were working on Subversion so Subversion could replace BK. You're the guy that refused to help us help the community. And you made it clear that you'd be delighted if Subversion was made good enough to replace BK and you were working towards that goal. I can't imagine a better example of someone who we absolutely do not want to support and do not want using BK. I am explicitly stating that it is our view that your use of BK is violation of our license. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 18:25 ` Larry McVoy @ 2002-10-05 18:35 ` Ben Collins 2002-10-05 18:41 ` Lars Marowsky-Bree ` (2 subsequent siblings) 3 siblings, 0 replies; 223+ messages in thread From: Ben Collins @ 2002-10-05 18:35 UTC (permalink / raw) To: Larry McVoy, Larry McVoy, linux-kernel On Sat, Oct 05, 2002 at 11:25:52AM -0700, Larry McVoy wrote: > On Sat, Oct 05, 2002 at 01:54:37PM -0400, Ben Collins wrote: > > Larry, I develop for the Subversion project. Does that mean my license > > to use bitkeeper is revoked? > > Yes. It has been since we shipped that license or when you started working > on Subversion, whichever came last. > > > I've also been wanting to use bitkeeper to create a Subversion mirror of > > the kernel repository, but I suspect that my usage falls seriously into > > this category, as my reasons for doing so are three-fold; allow access > > to the bkbits repo to folks who don't want to use bk, but with all the > > joys of an SCM (history, changesets, etc.); stress test Subversion > > against a real-world high-activity repo; promote Subversion. > > > > Would it be your intention that your license disallow my type of work? I > > think it does. > > You bet it does. The Subversion folks would like nothing better than > to displace BK. That's fine, but they don't get to use BK to do it. > You're absolutely correct that you could use BK to make Subversion better. > It is not our job to help you make Subversion better and we've made that > clear for a long time. Wow. You've got some bad memory, and some bad prejudice. Fact is, I've heard many Subversion core developers say, and I quote, "If BK were open-sourced, we'd just pack up and go home". Fact is, Subversion is not geared to replace BK, nor has the Subversion team ever claimed it as such. Fact is, the website clearly states it is a CVS replacement, which is not on par with what BK does else BK would never have come into existence. Sure, let's dig up the old ARM thread we had almost a year ago in private email and use it to fuel flames in a legitimate thread. Of course I thought you were about business, yet suddenly this has turned personal. Let's also not forget some of the helpful emails I've sent you in private. You've clearly made your point. I'll delete my copy of BK since I have no legal license to use it. That's all I wanted to know. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 18:25 ` Larry McVoy 2002-10-05 18:35 ` Ben Collins @ 2002-10-05 18:41 ` Lars Marowsky-Bree 2002-10-05 19:06 ` Ben Collins 2002-10-05 19:15 ` Larry McVoy 2002-10-06 13:46 ` Ingo Molnar 2002-10-06 22:11 ` BK is *evil* corporate software [was Re: New BK License Problem?] Pavel Machek 3 siblings, 2 replies; 223+ messages in thread From: Lars Marowsky-Bree @ 2002-10-05 18:41 UTC (permalink / raw) To: linux-kernel On 2002-10-05T11:25:52, Larry McVoy <lm@bitmover.com> said: > > I've also been wanting to use bitkeeper to create a Subversion mirror of > > the kernel repository, but I suspect that my usage falls seriously into > > this category, as my reasons for doing so are three-fold; allow access > > to the bkbits repo to folks who don't want to use bk, but with all the > > joys of an SCM (history, changesets, etc.); Larry, could you please explain whether _this_ part is fine doing (even if not by a subversion developer as per your license). Then someone (who wasn't involved in building the gateway) can run it and not break your license. I'd suggest that you need to have an interoperability clause for Open Source software. Otherwise using BK for kernel development suddenly seems like a very bad idea, because the community has suddenly been locked out of developing a free SCM (ie, working on CVS, Subversion etc); he couldn't be an effective kernel developer today (ie, using BK) and also continue working on the other open source project... You know I am rather fond of BK and your goals in general, but that would just suck. Sincerely, Lars Marowsky-Brée <lmb@suse.de> -- Principal Squirrel Research and Development, SuSE Linux AG ``Immortality is an adequate definition of high availability for me.'' --- Gregory F. Pfister ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 18:41 ` Lars Marowsky-Bree @ 2002-10-05 19:06 ` Ben Collins 2002-10-05 19:24 ` Ulrich Drepper 2002-10-05 19:15 ` Larry McVoy 1 sibling, 1 reply; 223+ messages in thread From: Ben Collins @ 2002-10-05 19:06 UTC (permalink / raw) To: Lars Marowsky-Bree; +Cc: linux-kernel > free SCM (ie, working on CVS, Subversion etc); he couldn't be an effective > kernel developer today (ie, using BK) and also continue working on the other > open source project... I don't want to get the wrong point across. I don't use BK to do kernel development. I live just fine without it, and my patches get accepted just fine by Linus, Marcelo and DaveM. The Linux1394 project survives using Subversion for our repository. Now, other more serious kernel developers who have been using BK for some time, may one day find they'd like to help a competing project. They have to make a choice between the means that they develop for the linux kernel and helping a project they have become interested in. Suddenly all the kernel developers who have staked their work in BK cannot work on a "competing" product to BK, without changing their development model. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:06 ` Ben Collins @ 2002-10-05 19:24 ` Ulrich Drepper 2002-10-05 19:43 ` Larry McVoy ` (2 more replies) 0 siblings, 3 replies; 223+ messages in thread From: Ulrich Drepper @ 2002-10-05 19:24 UTC (permalink / raw) To: Ben Collins; +Cc: linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ben Collins wrote: > Suddenly all the kernel developers who have staked their work in BK > cannot work on a "competing" product to BK, without changing their > development model. Not only this, it gets worse. In my case it is almost impossible to not get involved in many many free software projects. gettext or i18n in general, of glibc related issues pop up everywhere and often I contribute patches. Subversion is one of the projects where this has been the case in the past. According to my understanding this means I'm tainted (I've asked Larry for confirmation). Now the important part: I still have to work closely with kernel developers. The npt work is one example: I had to check out Ingo latest patches in the kernel every day. Now this isn't possible anymore without a) me finding another route to get the latest kernel in realtime (which still could be considered illegal since somebody else, for the expressed purpose of making the result available to me, is using bk); b) the kernel developers I work with not depending on bk anymore. The second point is what is causing the trouble. Any team which wants to use bk to synchronize the work is tainted by one single individual being tainted. I have never looked closer at bk than I had to be able to check out the latest sources. I'm not doing any development with it and I'm not checking in anything using bk. - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9nzxc2ijCOnn/RHQRAkG5AKCUgMWoYGzb2Hb9kAMHntBLsLXu7ACgyNrA f2LKpqNQu/nZn4COIBsLWm0= =WQqn -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:24 ` Ulrich Drepper @ 2002-10-05 19:43 ` Larry McVoy 2002-10-05 19:51 ` Nicolas Pitre ` (2 more replies) 2002-10-05 19:47 ` Nicolas Pitre 2002-10-06 0:34 ` Rik van Riel 2 siblings, 3 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-05 19:43 UTC (permalink / raw) To: Ulrich Drepper; +Cc: Ben Collins, linux-kernel > patches in the kernel every day. Now this isn't possible anymore without Nonsense. There are all sorts of people who have taken the BK trees and made the patch snapshots available on timely basis. Garzik's done it, Woodhouse has done it, Rik has done it, I'm sure there are piles more. The kernel is GPLed and we have no control of the kernel source. You can get at the source just as easily as ever, in fact, I'm 99.9% sure that your access is much better than it used to be because Linus makes the changes available on bkbits much more often than he used to make pre-patches and/or releases. Yeah, if you want to try and make BK go away then the answer is that you don't get the benefits of BK while you are trying to accomplish your goals. That's not going to change, scream all you want. Those are the rules. You have no grounds for complaint because anyone can do the bk export -tpatch to get you the exact same patch you would have gotten if you had asked them for it before they ever used BK. If you hate BK or the license or just want to be traditional, our position is that you should be no worse off than you would have been if the kernel wasn't in BK. What you are complaining about is that you want access to the *improvements* in the development process while you are working on tools which would damage the company who provided those improvements. That's asking too much. You can live with what you used to live with and work on competing products or you can benefit from the new tools, but not both. Our position is clear, it's not unreasonable, it affects very few kernel developers, and it doesn't even make those developers any worse off than they were before we showed up. All we are saying is that you don't get to use our tools if you are trying to rewrite our tools. I don't care if your name is Linus, Alan, or Ulrich, those rules are uniform for everyone. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:43 ` Larry McVoy @ 2002-10-05 19:51 ` Nicolas Pitre 2002-10-06 0:42 ` Rik van Riel 2002-10-05 20:21 ` Ulrich Drepper 2002-10-06 3:35 ` Jan Harkes 2 siblings, 1 reply; 223+ messages in thread From: Nicolas Pitre @ 2002-10-05 19:51 UTC (permalink / raw) To: Larry McVoy; +Cc: Ulrich Drepper, Ben Collins, linux-kernel On Sat, 5 Oct 2002, Larry McVoy wrote: > > patches in the kernel every day. Now this isn't possible anymore without > > Nonsense. There are all sorts of people who have taken the BK trees and > made the patch snapshots available on timely basis. Timely != real time. See my previous suggestion as a sensible compromise. Nicolas ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:51 ` Nicolas Pitre @ 2002-10-06 0:42 ` Rik van Riel 0 siblings, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-06 0:42 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Larry McVoy, Ulrich Drepper, Ben Collins, linux-kernel On Sat, 5 Oct 2002, Nicolas Pitre wrote: > On Sat, 5 Oct 2002, Larry McVoy wrote: > > > > patches in the kernel every day. Now this isn't possible anymore without > > > > Nonsense. There are all sorts of people who have taken the BK trees and > > made the patch snapshots available on timely basis. > > Timely != real time. That can be fixed, except for the fact that my script can't pull changesets before they've been pushed to the place I pull them from ;)) Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:43 ` Larry McVoy 2002-10-05 19:51 ` Nicolas Pitre @ 2002-10-05 20:21 ` Ulrich Drepper 2002-10-05 23:28 ` Larry McVoy ` (2 more replies) 2002-10-06 3:35 ` Jan Harkes 2 siblings, 3 replies; 223+ messages in thread From: Ulrich Drepper @ 2002-10-05 20:21 UTC (permalink / raw) To: Larry McVoy; +Cc: Ben Collins, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry McVoy wrote: >>patches in the kernel every day. Now this isn't possible anymore without > > > Nonsense. There are all sorts of people who have taken the BK trees and > made the patch snapshots available on timely basis. That's not what I was talking about. It is not possible anymore to use the same process we did. It is not possible anymore to react right away on "Linus checked the patch in; try it.". It now requires serious efforts. And it requires them repeatedly at various sites with people who have the same problem. Requiring others to make patch I can apply does not work since a) it would put extra burden on people who are already overworked and b) the timezones make it often impossible to get swift responses. You mentioned rsync to replicate the archive and then use CSSC. Would be fine with me. But: knowing how to set up rsync would probably require me to look at all the bk infrastructure and mechanisms more than I had to do in the whole time I was using bk the check out sources and while doing this I probably once again violate your license. And don't get me wrong: you have the right to use whatever license you want. I don't complain about that. I just point out the problem so that other don't run into the same problems after they started using bk and in the hope that somebody sets up a service which allows checking out the current sources in nearly the same time as they are available in the bk repository without relying on bk (rsync, cvs, subversion, I don't care how). - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9n0nZ2ijCOnn/RHQRAvDpAJ0ZXkNJKMt+ExMUnwxbOOP9a3xAxgCgwiwX U+zaoRwM9UVwsJedk/IysVg= =RTrB -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 20:21 ` Ulrich Drepper @ 2002-10-05 23:28 ` Larry McVoy 2002-10-05 23:50 ` Alan Cox 2002-10-06 4:25 ` David S. Miller 2002-10-06 9:00 ` Jeff Garzik 2 siblings, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-05 23:28 UTC (permalink / raw) To: Ulrich Drepper; +Cc: Larry McVoy, Ben Collins, linux-kernel > That's not what I was talking about. It is not possible anymore to use > the same process we did. It is not possible anymore to react right away > on "Linus checked the patch in; try it.". Because Linus is using BK it is easier for him to make his work in progress available, so he does. Before he was using BK, you got a snapshot when he put up for ftp. It is an absolute fact that Linus tree is far more quickly available, via regular patches or BK, than it was before he used BK. If he stopped using BK then you'd be back to the old patch availablity. If he used Subversion or CVS or Perforce or whatever, because of how those systems work, I'm positive that you'd see his publish rate drop. BK makes it really easy to do what Linus is doing. If he had to manage the same set of things using traditional branching techniques then he'd publish less because it would be harder to do so. The bottom line is that the use of BK is giving you faster access to the data you want, in whatever form you want. So I fail to see the problem. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:28 ` Larry McVoy @ 2002-10-05 23:50 ` Alan Cox 2002-10-05 23:44 ` Alexander Viro ` (6 more replies) 0 siblings, 7 replies; 223+ messages in thread From: Alan Cox @ 2002-10-05 23:50 UTC (permalink / raw) To: Larry McVoy; +Cc: Ulrich Drepper, Ben Collins, Linux Kernel Mailing List On Sun, 2002-10-06 at 00:28, Larry McVoy wrote: > Because Linus is using BK it is easier for him to make his work in > progress available, so he does. Before he was using BK, you got a > snapshot when he put up for ftp. It is an absolute fact that Linus > tree is far more quickly available, via regular patches or BK, than > it was before he used BK. Linus used to do about a patch every 2 days. Nowdays its a lot slower. I put that down to buttkeeper ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:50 ` Alan Cox @ 2002-10-05 23:44 ` Alexander Viro 2002-10-05 23:53 ` Larry McVoy ` (5 subsequent siblings) 6 siblings, 0 replies; 223+ messages in thread From: Alexander Viro @ 2002-10-05 23:44 UTC (permalink / raw) To: Alan Cox Cc: Larry McVoy, Ulrich Drepper, Ben Collins, Linux Kernel Mailing List On 6 Oct 2002, Alan Cox wrote: > On Sun, 2002-10-06 at 00:28, Larry McVoy wrote: > > Because Linus is using BK it is easier for him to make his work in > > progress available, so he does. Before he was using BK, you got a > > snapshot when he put up for ftp. It is an absolute fact that Linus > > tree is far more quickly available, via regular patches or BK, than > > it was before he used BK. > > Linus used to do about a patch every 2 days. Nowdays its a lot slower. I > put that down to buttkeeper Rik's snapshots are once every 2 hours, IIRC... ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:50 ` Alan Cox 2002-10-05 23:44 ` Alexander Viro @ 2002-10-05 23:53 ` Larry McVoy 2002-10-06 3:40 ` Jan Harkes 2002-10-06 8:28 ` Jeff Garzik 2002-10-06 0:49 ` New BK License Problem? Rik van Riel ` (4 subsequent siblings) 6 siblings, 2 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-05 23:53 UTC (permalink / raw) To: Alan Cox Cc: Larry McVoy, Ulrich Drepper, Ben Collins, Linux Kernel Mailing List On Sun, Oct 06, 2002 at 12:50:27AM +0100, Alan Cox wrote: > On Sun, 2002-10-06 at 00:28, Larry McVoy wrote: > > Because Linus is using BK it is easier for him to make his work in > > progress available, so he does. Before he was using BK, you got a > > snapshot when he put up for ftp. It is an absolute fact that Linus > > tree is far more quickly available, via regular patches or BK, than > > it was before he used BK. > > Linus used to do about a patch every 2 days. Nowdays its a lot slower. I > put that down to buttkeeper He may put up a patch for ftp less frequently, I haven't watched that. He is publishing an average of 39 changesets/day, 7 days a week, 365 days/year based on the number of changesets in the tree as of a minute ago. Some percentage of those are merge changesets which you would probably not count, I checked and it looks like about 15%, round it up to 20%, that's still 31/day. If you assume he's working 5 days a week, it's more like 44/day. That's a patch accepted every 11 minutes. Let's say I've screwed up my math somewhere, I'll give you a factor of 3, that's still a couple of patches an hour. 40 hours a week. Anyway, we have the BK data, if you have data that says the rate of change has gone down since he started using BK, let's see it. If all you are saying is that he isn't publishing ftp-able snapshots every hour, that's a problem that HPA or whoever could easily fix with a shell script. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:53 ` Larry McVoy @ 2002-10-06 3:40 ` Jan Harkes 2002-10-06 8:28 ` Jeff Garzik 1 sibling, 0 replies; 223+ messages in thread From: Jan Harkes @ 2002-10-06 3:40 UTC (permalink / raw) To: linux-kernel On Sat, Oct 05, 2002 at 04:53:16PM -0700, Larry McVoy wrote: > Anyway, we have the BK data, if you have data that says the rate of change > has gone down since he started using BK, let's see it. If all you are > saying is that he isn't publishing ftp-able snapshots every hour, that's > a problem that HPA or whoever could easily fix with a shell script. The BK stats don't prove whether the patch drop rate has improved at all, only what got merged. And even if Linus is dropping fewer patches, that could very well be a bad thing. I've had a couple of times that I looked at a dropped patch while pulling it up to a new kernel release and thought 'ok, what was I smoking'. Jan ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:53 ` Larry McVoy 2002-10-06 3:40 ` Jan Harkes @ 2002-10-06 8:28 ` Jeff Garzik 2002-10-06 8:46 ` Skip Ford 1 sibling, 1 reply; 223+ messages in thread From: Jeff Garzik @ 2002-10-06 8:28 UTC (permalink / raw) To: Larry McVoy Cc: Alan Cox, Ulrich Drepper, Ben Collins, Linux Kernel Mailing List Larry McVoy wrote: > Anyway, we have the BK data, if you have data that says the rate of change > has gone down since he started using BK, let's see it. If all you are > saying is that he isn't publishing ftp-able snapshots every hour, that's > a problem that HPA or whoever could easily fix with a shell script. Hourly snapshots can easily be done if wanted. Just a simple "crontab -e" for me. Note they are public now, at ftp://ftp.kernel.org/pub/linux/kernel/v2.5/snapshots/ (and I promised Marcelo I would do this for 2.4 too...) ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 8:28 ` Jeff Garzik @ 2002-10-06 8:46 ` Skip Ford 2002-10-06 9:06 ` Jeff Garzik 0 siblings, 1 reply; 223+ messages in thread From: Skip Ford @ 2002-10-06 8:46 UTC (permalink / raw) To: Jeff Garzik; +Cc: Linux Kernel Mailing List Jeff Garzik wrote: > Larry McVoy wrote: > > Anyway, we have the BK data, if you have data that says the rate of change > > has gone down since he started using BK, let's see it. If all you are > > saying is that he isn't publishing ftp-able snapshots every hour, that's > > a problem that HPA or whoever could easily fix with a shell script. > > Hourly snapshots can easily be done if wanted. > Just a simple "crontab -e" for me. > > Note they are public now, at > ftp://ftp.kernel.org/pub/linux/kernel/v2.5/snapshots/ > (and I promised Marcelo I would do this for 2.4 too...) What I would like to see is a 'linux-commits' mailing list where Woodhouse's per changeset diffs can all be posted. Refreshing the webpage over and over waiting for new patches isn't fun. And that info can't be fingered for. I appreciate that he does it. It's a nice service he provides. But I'm sure Linus could write a script that mails 'linux-commits' with a diff for each changeset easily. -- Skip ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 8:46 ` Skip Ford @ 2002-10-06 9:06 ` Jeff Garzik 2002-10-06 9:24 ` David S. Miller ` (2 more replies) 0 siblings, 3 replies; 223+ messages in thread From: Jeff Garzik @ 2002-10-06 9:06 UTC (permalink / raw) To: Skip Ford; +Cc: Linux Kernel Mailing List Skip Ford wrote: > What I would like to see is a 'linux-commits' mailing list where > Woodhouse's per changeset diffs can all be posted. Not a bad idea... Various people have called for a patches mailing list in the past. > I appreciate that he does it. It's a nice service he provides. But I'm > sure Linus could write a script that mails 'linux-commits' with a diff > for each changeset easily. I'm sure Linus could write and maintain my net drivers for me, too. :) Maybe you could submit a modification to dwmw2's script to him, or run this yourself...? Jeff ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 9:06 ` Jeff Garzik @ 2002-10-06 9:24 ` David S. Miller 2002-10-06 14:03 ` Larry McVoy 2002-10-06 15:27 ` Skip Ford 2002-10-08 21:13 ` David Woodhouse 2 siblings, 1 reply; 223+ messages in thread From: David S. Miller @ 2002-10-06 9:24 UTC (permalink / raw) To: jgarzik; +Cc: skip.ford, linux-kernel From: Jeff Garzik <jgarzik@pobox.com> Date: Sun, 06 Oct 2002 05:06:41 -0400 Skip Ford wrote: > What I would like to see is a 'linux-commits' mailing list where > Woodhouse's per changeset diffs can all be posted. Not a bad idea... Various people have called for a patches mailing list in the past. Not meaning to start a new flame war, but to my understanding triggers are only enabled in BK-pro. I haven't verified this, but the BK docs say it. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 9:24 ` David S. Miller @ 2002-10-06 14:03 ` Larry McVoy 2002-10-06 14:18 ` Ingo Molnar 0 siblings, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-06 14:03 UTC (permalink / raw) To: David S. Miller; +Cc: jgarzik, skip.ford, linux-kernel > Not meaning to start a new flame war, but to my understanding triggers > are only enabled in BK-pro. I haven't verified this, but the BK docs > say it. Bug in the docs, they are fully supported in BK/Free, always have been. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 14:03 ` Larry McVoy @ 2002-10-06 14:18 ` Ingo Molnar 0 siblings, 0 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 14:18 UTC (permalink / raw) To: Larry McVoy; +Cc: David S. Miller, jgarzik, skip.ford, linux-kernel On Sun, 6 Oct 2002, Larry McVoy wrote: > > Not meaning to start a new flame war, but to my understanding triggers > > are only enabled in BK-pro. I haven't verified this, but the BK docs > > say it. > > Bug in the docs, they are fully supported in BK/Free, always have been. i think Linus even uses some triggers, to avoid people accidentally pushing their trees to his tree on master.kernel.org. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 9:06 ` Jeff Garzik 2002-10-06 9:24 ` David S. Miller @ 2002-10-06 15:27 ` Skip Ford 2002-10-08 21:13 ` David Woodhouse 2 siblings, 0 replies; 223+ messages in thread From: Skip Ford @ 2002-10-06 15:27 UTC (permalink / raw) To: Jeff Garzik; +Cc: Linux Kernel Mailing List Jeff Garzik wrote: > Skip Ford wrote: > > What I would like to see is a 'linux-commits' mailing list where > > Woodhouse's per changeset diffs can all be posted. > > Not a bad idea... Various people have called for a patches mailing list > in the past. > > Maybe you could submit a modification to dwmw2's script to him, or run > this yourself...? I sort of had vger in mind, but I could set up a crude read-only list of some sort if need be on my dynamic IP line. I can't seem to find dwmw2's script.. -- Skip ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 9:06 ` Jeff Garzik 2002-10-06 9:24 ` David S. Miller 2002-10-06 15:27 ` Skip Ford @ 2002-10-08 21:13 ` David Woodhouse 2002-10-08 22:04 ` David S. Miller ` (2 more replies) 2 siblings, 3 replies; 223+ messages in thread From: David Woodhouse @ 2002-10-08 21:13 UTC (permalink / raw) To: Skip Ford; +Cc: Jeff Garzik, Linux Kernel Mailing List skip.ford@verizon.net said: > I sort of had vger in mind, but I could set up a crude read-only list > of some sort if need be on my dynamic IP line. If a list is set up on vger I'll feed the patches to it. > I can't seem to find dwmw2's script.. CVSROOT=:pserver:anoncvs@cvs.infradead.org:/home/cvs grep -q $CVSROOT ~/.cvspass || ( echo "$CVSROOT Ay=0=h<Z" >> ~/.cvspass ) cvs -d $CVSROOT co bkexport -- dwmw2 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 21:13 ` David Woodhouse @ 2002-10-08 22:04 ` David S. Miller 2002-10-08 22:06 ` Rik van Riel 2002-10-08 22:15 ` David Woodhouse 2 siblings, 0 replies; 223+ messages in thread From: David S. Miller @ 2002-10-08 22:04 UTC (permalink / raw) To: dwmw2; +Cc: skip.ford, jgarzik, linux-kernel From: David Woodhouse <dwmw2@infradead.org> Date: Tue, 08 Oct 2002 22:13:48 +0100 skip.ford@verizon.net said: > I sort of had vger in mind, but I could set up a crude read-only list > of some sort if need be on my dynamic IP line. If a list is set up on vger I'll feed the patches to it. Should we have two lists, one for 2.4 and one for 2.5? I'll set it up once decided. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 21:13 ` David Woodhouse 2002-10-08 22:04 ` David S. Miller @ 2002-10-08 22:06 ` Rik van Riel 2002-10-08 22:15 ` Skip Ford 2002-10-08 22:25 ` David Woodhouse 2002-10-08 22:15 ` David Woodhouse 2 siblings, 2 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-08 22:06 UTC (permalink / raw) To: David Woodhouse; +Cc: Skip Ford, Jeff Garzik, Linux Kernel Mailing List On Tue, 8 Oct 2002, David Woodhouse wrote: > skip.ford@verizon.net said: > > I sort of had vger in mind, but I could set up a crude read-only list > > of some sort if need be on my dynamic IP line. > > If a list is set up on vger I'll feed the patches to it. If the vger admins are busy I have no problem setting up a linux-patches list on nl.linux.org. Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 22:06 ` Rik van Riel @ 2002-10-08 22:15 ` Skip Ford 2002-10-08 22:53 ` Rik van Riel 2002-10-08 22:25 ` David Woodhouse 1 sibling, 1 reply; 223+ messages in thread From: Skip Ford @ 2002-10-08 22:15 UTC (permalink / raw) To: Rik van Riel Cc: David Woodhouse, Skip Ford, Jeff Garzik, Linux Kernel Mailing List Rik van Riel wrote: > On Tue, 8 Oct 2002, David Woodhouse wrote: > > skip.ford@verizon.net said: > > > I sort of had vger in mind, but I could set up a crude read-only list > > > of some sort if need be on my dynamic IP line. > > > > If a list is set up on vger I'll feed the patches to it. > > If the vger admins are busy I have no problem setting up a > linux-patches list on nl.linux.org. Just to clarify here, I suggested a linux-commits style list (patches Linus has applied) and Alan suggested a linux-patches list (patches submitted to Linus.) I like the cset diffs because I can see patches Linus has applied that weren't posted. If a linux-patches list is created (and people use it) then a commits list isn't as useful. -- Skip ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 22:15 ` Skip Ford @ 2002-10-08 22:53 ` Rik van Riel 0 siblings, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-08 22:53 UTC (permalink / raw) To: Skip Ford; +Cc: David Woodhouse, Jeff Garzik, Linux Kernel Mailing List On Tue, 8 Oct 2002, Skip Ford wrote: > I like the cset diffs because I can see patches Linus has applied that > weren't posted. If a linux-patches list is created (and people use it) > then a commits list isn't as useful. Somehow I doubt Linus mails himself the patches he writes himself. A linux-commits list is still useful. Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 22:06 ` Rik van Riel 2002-10-08 22:15 ` Skip Ford @ 2002-10-08 22:25 ` David Woodhouse 1 sibling, 0 replies; 223+ messages in thread From: David Woodhouse @ 2002-10-08 22:25 UTC (permalink / raw) To: Skip Ford; +Cc: Rik van Riel, Jeff Garzik, Linux Kernel Mailing List skip.ford@verizon.net said: > Just to clarify here, I suggested a linux-commits style list (patches > Linus has applied) and Alan suggested a linux-patches list (patches > submitted to Linus.) I am talking about the former only. The latter has been discussed many times and AFAICT is never going to happen. I suspect Linus will always take patches from his inbox and will never say 'resubmit via linux-patches or I don't take it'. > I like the cset diffs because I can see patches Linus has applied that > weren't posted. If a linux-patches list is created (and people use > it) then a commits list isn't as useful. Maybe. Why filter the crap from linux-patches when you can subscribe to bk-commits and let Linus do it for you? :) -- dwmw2 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 21:13 ` David Woodhouse 2002-10-08 22:04 ` David S. Miller 2002-10-08 22:06 ` Rik van Riel @ 2002-10-08 22:15 ` David Woodhouse 2002-10-08 22:24 ` Dave Jones ` (2 more replies) 2 siblings, 3 replies; 223+ messages in thread From: David Woodhouse @ 2002-10-08 22:15 UTC (permalink / raw) To: David S. Miller; +Cc: skip.ford, jgarzik, linux-kernel davem@redhat.com said: > Should we have two lists, one for 2.4 and one for 2.5? > I'll set it up once decided. Probably one for each. We could add headers which say which branch it is but that's still a lot of extra traffic for subscribers who only want the stable branch info and will filter the 2.5 ones to /dev/null. How about bk-commits-head bk-commits-2.4 then later bk-commits-2.6 etc... -- dwmw2 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 22:15 ` David Woodhouse @ 2002-10-08 22:24 ` Dave Jones 2002-10-08 22:20 ` David S. Miller 2002-10-08 22:26 ` David Woodhouse 2002-10-09 0:51 ` BK kernel commits list David S. Miller 2 siblings, 1 reply; 223+ messages in thread From: Dave Jones @ 2002-10-08 22:24 UTC (permalink / raw) To: David Woodhouse; +Cc: David S. Miller, skip.ford, jgarzik, linux-kernel On Tue, Oct 08, 2002 at 11:15:20PM +0100, David Woodhouse wrote: > > Should we have two lists, one for 2.4 and one for 2.5? > > I'll set it up once decided. > > Probably one for each. We could add headers which say which branch it is > but that's still a lot of extra traffic for subscribers who only want the > stable branch info and will filter the 2.5 ones to /dev/null. > > How about > bk-commits-head > bk-commits-2.4 > > then later bk-commits-2.6 etc... How about 'stable' and 'devel', then we won't have to worry about renaming/resubscribing when we switch revisions. Dave -- | Dave Jones. http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 22:24 ` Dave Jones @ 2002-10-08 22:20 ` David S. Miller 2002-10-08 22:31 ` Jeff Garzik 0 siblings, 1 reply; 223+ messages in thread From: David S. Miller @ 2002-10-08 22:20 UTC (permalink / raw) To: davej; +Cc: dwmw2, skip.ford, jgarzik, linux-kernel From: Dave Jones <davej@codemonkey.org.uk> Date: Tue, 8 Oct 2002 23:24:44 +0100 On Tue, Oct 08, 2002 at 11:15:20PM +0100, David Woodhouse wrote: > How about > bk-commits-head > bk-commits-2.4 > > then later bk-commits-2.6 etc... How about 'stable' and 'devel', then we won't have to worry about renaming/resubscribing when we switch revisions. I expect people to maintain 2.4.x even when 2.6.x is "stable" even once 2.7.x has begun. Therefore, I like your first idea the best. Ok? ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 22:20 ` David S. Miller @ 2002-10-08 22:31 ` Jeff Garzik 0 siblings, 0 replies; 223+ messages in thread From: Jeff Garzik @ 2002-10-08 22:31 UTC (permalink / raw) To: David S. Miller; +Cc: davej, dwmw2, skip.ford, linux-kernel David S. Miller wrote: > > How about > > bk-commits-head > > bk-commits-2.4 > > > > then later bk-commits-2.6 etc... > I expect people to maintain 2.4.x even when 2.6.x is > "stable" even once 2.7.x has begun. > > Therefore, I like your first idea the best. likewise ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 22:15 ` David Woodhouse 2002-10-08 22:24 ` Dave Jones @ 2002-10-08 22:26 ` David Woodhouse 2002-10-08 22:45 ` Dave Jones 2002-10-09 0:51 ` BK kernel commits list David S. Miller 2 siblings, 1 reply; 223+ messages in thread From: David Woodhouse @ 2002-10-08 22:26 UTC (permalink / raw) To: Dave Jones; +Cc: David S. Miller, skip.ford, jgarzik, linux-kernel davej@codemonkey.org.uk said: > How about 'stable' and 'devel', then we won't have to worry about > renaming/resubscribing when we switch revisions. Would you suggest sending 2.4 and 2.6 changesets to the same 'stable' list or making a new one for each release? I'd suggest the latter option, hence making the naming explicit from the start. -- dwmw2 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-08 22:26 ` David Woodhouse @ 2002-10-08 22:45 ` Dave Jones 0 siblings, 0 replies; 223+ messages in thread From: Dave Jones @ 2002-10-08 22:45 UTC (permalink / raw) To: David Woodhouse Cc: Dave Jones, David S. Miller, skip.ford, jgarzik, linux-kernel On Tue, Oct 08, 2002 at 11:26:41PM +0100, David Woodhouse wrote: > > How about 'stable' and 'devel', then we won't have to worry about > > renaming/resubscribing when we switch revisions. > > Would you suggest sending 2.4 and 2.6 changesets to the same 'stable' list > or making a new one for each release? I'd suggest the latter option, > hence making the naming explicit from the start. Good point. Dave -- | Dave Jones. http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 223+ messages in thread
* BK kernel commits list 2002-10-08 22:15 ` David Woodhouse 2002-10-08 22:24 ` Dave Jones 2002-10-08 22:26 ` David Woodhouse @ 2002-10-09 0:51 ` David S. Miller 2002-10-09 11:49 ` Skip Ford 2 siblings, 1 reply; 223+ messages in thread From: David S. Miller @ 2002-10-09 0:51 UTC (permalink / raw) To: linux-kernel I've created: bk-commits-head@vger.kernel.org bk-commits-24@vger.kernel.org (note: no "period" between the 2 and the 4) Have at it. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 0:51 ` BK kernel commits list David S. Miller @ 2002-10-09 11:49 ` Skip Ford 2002-10-09 11:58 ` David S. Miller 2002-10-09 12:17 ` David Woodhouse 0 siblings, 2 replies; 223+ messages in thread From: Skip Ford @ 2002-10-09 11:49 UTC (permalink / raw) To: David S. Miller; +Cc: linux-kernel David S. Miller wrote: > > I've created: > > bk-commits-head@vger.kernel.org > bk-commits-24@vger.kernel.org > > (note: no "period" between the 2 and the 4) > Have at it. Does this list need to allow posting as it does now? Only one address needs write permission, or maybe a few addresses as backup. Discussion should still happen on lkml. -- Skip ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 11:49 ` Skip Ford @ 2002-10-09 11:58 ` David S. Miller 2002-10-09 12:17 ` David Woodhouse 1 sibling, 0 replies; 223+ messages in thread From: David S. Miller @ 2002-10-09 11:58 UTC (permalink / raw) To: skip.ford; +Cc: linux-kernel From: Skip Ford <skip.ford@verizon.net> Date: Wed, 9 Oct 2002 07:49:32 -0400 Does this list need to allow posting as it does now? Only one address needs write permission, or maybe a few addresses as backup. Discussion should still happen on lkml. I can set this up once I know what the feeder's From addrss looks like. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 11:49 ` Skip Ford 2002-10-09 11:58 ` David S. Miller @ 2002-10-09 12:17 ` David Woodhouse 2002-10-09 12:12 ` David S. Miller 2002-10-09 14:11 ` Jeff Garzik 1 sibling, 2 replies; 223+ messages in thread From: David Woodhouse @ 2002-10-09 12:17 UTC (permalink / raw) To: David S. Miller; +Cc: skip.ford, linux-kernel davem@redhat.com said: > I can set this up once I know what the feeder's From addrss looks > like. Well I was thinking of using `bk changes -d:USER:@:HOST:` Can we make it accept mail only with an envelope sender of dwmw2@.*.kernel.org? -- dwmw2 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 12:17 ` David Woodhouse @ 2002-10-09 12:12 ` David S. Miller 2002-10-09 14:11 ` Jeff Garzik 1 sibling, 0 replies; 223+ messages in thread From: David S. Miller @ 2002-10-09 12:12 UTC (permalink / raw) To: dwmw2; +Cc: skip.ford, linux-kernel From: David Woodhouse <dwmw2@infradead.org> Date: Wed, 09 Oct 2002 13:17:58 +0100 Can we make it accept mail only with an envelope sender of dwmw2@.*.kernel.org? Any particular reason why the ".*." part can't be constant? ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 12:17 ` David Woodhouse 2002-10-09 12:12 ` David S. Miller @ 2002-10-09 14:11 ` Jeff Garzik 2002-10-09 14:44 ` Ben Collins 2002-10-09 14:55 ` David Woodhouse 1 sibling, 2 replies; 223+ messages in thread From: Jeff Garzik @ 2002-10-09 14:11 UTC (permalink / raw) To: David Woodhouse; +Cc: linux-kernel A couple of suggestions for the output... The BitKeeper header is unfortunately less than useful at times -- often multiple cset descriptions wind up in the header -- so I would suggest exporting the patch with "-hdu" instead of "-du", and then manually adding the changeset info and description at the top. Also, diffstat output prepended would be nice too. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 14:11 ` Jeff Garzik @ 2002-10-09 14:44 ` Ben Collins 2002-10-09 14:55 ` David Woodhouse 1 sibling, 0 replies; 223+ messages in thread From: Ben Collins @ 2002-10-09 14:44 UTC (permalink / raw) To: Jeff Garzik; +Cc: David Woodhouse, linux-kernel On Wed, Oct 09, 2002 at 10:11:55AM -0400, Jeff Garzik wrote: > A couple of suggestions for the output... > > The BitKeeper header is unfortunately less than useful at times -- often > multiple cset descriptions wind up in the header -- so I would suggest > exporting the patch with "-hdu" instead of "-du", and then manually > adding the changeset info and description at the top. > > Also, diffstat output prepended would be nice too. Just please make sure that the changeset info where it describes all the files in the delta. I.e. the ones that are moved, deleted, new. There's no way to deduce moves from the patch. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 14:11 ` Jeff Garzik 2002-10-09 14:44 ` Ben Collins @ 2002-10-09 14:55 ` David Woodhouse 2002-10-09 14:58 ` Ben Collins ` (2 more replies) 1 sibling, 3 replies; 223+ messages in thread From: David Woodhouse @ 2002-10-09 14:55 UTC (permalink / raw) To: Ben Collins; +Cc: Jeff Garzik, linux-kernel [-- Attachment #1: Type: text/plain, Size: 548 bytes --] bcollins@debian.org said: > Just please make sure that the changeset info where it describes all > the files in the delta. I.e. the ones that are moved, deleted, new. > There's no way to deduce moves from the patch. This bit? # This patch includes the following deltas: # ChangeSet 1.713 -> 1.714 # arch/i386/math-emu/poly.h 1.3 -> 1.4 # Any idea how to get it other than 'bk export -tpatch | sed' ? I need to do some real work... play with ths script and sort it out between yourselves :) -- dwmw2 [-- Attachment #2: mailcset.sh --] [-- Type: application/x-sh , Size: 858 bytes --] ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 14:55 ` David Woodhouse @ 2002-10-09 14:58 ` Ben Collins 2002-10-09 19:48 ` Jeff Garzik 2002-10-09 20:41 ` David Woodhouse 2 siblings, 0 replies; 223+ messages in thread From: Ben Collins @ 2002-10-09 14:58 UTC (permalink / raw) To: David Woodhouse; +Cc: Jeff Garzik, linux-kernel On Wed, Oct 09, 2002 at 03:55:00PM +0100, David Woodhouse wrote: > > bcollins@debian.org said: > > Just please make sure that the changeset info where it describes all > > the files in the delta. I.e. the ones that are moved, deleted, new. > > There's no way to deduce moves from the patch. > > This bit? > > # This patch includes the following deltas: > # ChangeSet 1.713 -> 1.714 > # arch/i386/math-emu/poly.h 1.3 -> 1.4 > # Yeah, that's it. > Any idea how to get it other than 'bk export -tpatch | sed' ? Probably some sort of "bk changes" output. Try checking the -d spec options. > I need to do some real work... play with ths script and sort it out between > yourselves :) I can't. Requires using BK :) -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 14:55 ` David Woodhouse 2002-10-09 14:58 ` Ben Collins @ 2002-10-09 19:48 ` Jeff Garzik 2002-10-09 19:59 ` Robert Love ` (2 more replies) 2002-10-09 20:41 ` David Woodhouse 2 siblings, 3 replies; 223+ messages in thread From: Jeff Garzik @ 2002-10-09 19:48 UTC (permalink / raw) To: David Woodhouse; +Cc: Ben Collins, linux-kernel Actually, after subscribing to bk-commits-* and seeing the output, I really think the only addition needed is to pipe the output through diffstat. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 19:48 ` Jeff Garzik @ 2002-10-09 19:59 ` Robert Love 2002-10-09 20:32 ` Skip Ford 2002-10-09 20:34 ` Jeff Garzik 2002-10-09 19:59 ` Ben Collins 2002-10-09 20:52 ` David Woodhouse 2 siblings, 2 replies; 223+ messages in thread From: Robert Love @ 2002-10-09 19:59 UTC (permalink / raw) To: Jeff Garzik; +Cc: David Woodhouse, Ben Collins, linux-kernel, davem On Wed, 2002-10-09 at 15:48, Jeff Garzik wrote: > Actually, after subscribing to bk-commits-* and seeing the output, > I really think the only addition needed is to pipe the output > through diffstat. I think this would be cool, too. I think simplicity is important, but more information is always helper. I also like Daniel's suggestion of having the sender's _name_ by the name attributed with the patch (or at least "BK Commit" or something). But nothing _needs_ to be done. This works great. Good job, Dave and Co. Robert Love ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 19:59 ` Robert Love @ 2002-10-09 20:32 ` Skip Ford 2002-10-09 20:34 ` Jeff Garzik 1 sibling, 0 replies; 223+ messages in thread From: Skip Ford @ 2002-10-09 20:32 UTC (permalink / raw) To: Robert Love Cc: Jeff Garzik, David Woodhouse, Ben Collins, linux-kernel, davem Robert Love wrote: > On Wed, 2002-10-09 at 15:48, Jeff Garzik wrote: > > > Actually, after subscribing to bk-commits-* and seeing the output, > > I really think the only addition needed is to pipe the output > > through diffstat. > > I think this would be cool, too. > > I also like Daniel's suggestion of having the sender's _name_ by the > name attributed with the patch (or at least "BK Commit" or something). > > But nothing _needs_ to be done. This works great. Good job, Dave and > Co. I agree. Thanks to David Woodhouse for feeding it and DaveM for creating it. I'd like to suggest that once Linus makes a release and all of the changeset diffs are wiped out on kernel.org, that a message be sent to bk-commits indicating that. Nothing fancy, just an empty message with a subject of "--MARK--" would be nice. But either way, it's a great list. -- Skip ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 19:59 ` Robert Love 2002-10-09 20:32 ` Skip Ford @ 2002-10-09 20:34 ` Jeff Garzik 1 sibling, 0 replies; 223+ messages in thread From: Jeff Garzik @ 2002-10-09 20:34 UTC (permalink / raw) To: Robert Love; +Cc: David Woodhouse, Ben Collins, linux-kernel, davem Robert Love wrote: > But nothing _needs_ to be done. This works great. Good job, Dave and > Co. Indeed: kudos and thanks. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 19:48 ` Jeff Garzik 2002-10-09 19:59 ` Robert Love @ 2002-10-09 19:59 ` Ben Collins 2002-10-09 20:52 ` David Woodhouse 2 siblings, 0 replies; 223+ messages in thread From: Ben Collins @ 2002-10-09 19:59 UTC (permalink / raw) To: Jeff Garzik; +Cc: David Woodhouse, linux-kernel On Wed, Oct 09, 2002 at 03:48:58PM -0400, Jeff Garzik wrote: > Actually, after subscribing to bk-commits-* and seeing the output, I > really think the only addition needed is to pipe the output through > diffstat. Without the info concerning the file revs being affected, it's pretty useless for me. I can actually just use that info and pull diffs locally from my repo via sccs. But I guess the point of the list is for diffs to kernel devs. Guess I'll get my info elsewhere. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 19:48 ` Jeff Garzik 2002-10-09 19:59 ` Robert Love 2002-10-09 19:59 ` Ben Collins @ 2002-10-09 20:52 ` David Woodhouse 2002-10-09 21:02 ` Robert Love 2 siblings, 1 reply; 223+ messages in thread From: David Woodhouse @ 2002-10-09 20:52 UTC (permalink / raw) To: Ben Collins; +Cc: Jeff Garzik, linux-kernel bcollins@debian.org said: > Without the info concerning the file revs being affected, it's pretty > useless for me. I can actually just use that info and pull diffs > locally from my repo via sccs. We can do that. Worst case, someone needs to teach me enough sed to grok the 'bk export -tpatch' output, find the line matching '^# This patch contains the following deltas:$' and spew output from that till the first line matching '^#$'. Ideally, there'll be an easier way of getting the info from bitkeeper though. Oh, and would anyone mind if, after feeding the mail through diffstat and seeing zero lines of change, I aborted sending the mail? Further criticism of the scripts will only be accepted in diff -u form unless you have an excuse at least as good as having been told personally by Larry that you're not allowed to use BitKeeper. CVSROOT=:pserver:anoncvs@cvs.infradead.org:/home/cvs grep -q $CVSROOT ~/.cvspass || ( echo "$CVSROOT Ay=0=h<Z" >> ~/.cvspass ) cvs -d $CVSROOT co bkexport -- dwmw2 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 20:52 ` David Woodhouse @ 2002-10-09 21:02 ` Robert Love 0 siblings, 0 replies; 223+ messages in thread From: Robert Love @ 2002-10-09 21:02 UTC (permalink / raw) To: David Woodhouse; +Cc: Ben Collins, Jeff Garzik, linux-kernel On Wed, 2002-10-09 at 16:52, David Woodhouse wrote: > Oh, and would anyone mind if, after feeding the mail through diffstat and > seeing zero lines of change, I aborted sending the mail? You mean so we did not see empty emails (usually those of the form "merge from x into y")? Not only do I not mind, I encourage... please do so. Robert Love ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list 2002-10-09 14:55 ` David Woodhouse 2002-10-09 14:58 ` Ben Collins 2002-10-09 19:48 ` Jeff Garzik @ 2002-10-09 20:41 ` David Woodhouse 2 siblings, 0 replies; 223+ messages in thread From: David Woodhouse @ 2002-10-09 20:41 UTC (permalink / raw) To: Jeff Garzik; +Cc: Ben Collins, linux-kernel jgarzik@pobox.com said: > Actually, after subscribing to bk-commits-* and seeing the output, I > really think the only addition needed is to pipe the output through > diffstat. Er, I did that last time you asked. Maybe it'll work better if I cvs update on hera after committing the change? :) -- dwmw2 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:50 ` Alan Cox 2002-10-05 23:44 ` Alexander Viro 2002-10-05 23:53 ` Larry McVoy @ 2002-10-06 0:49 ` Rik van Riel 2002-10-06 4:43 ` David S. Miller ` (3 subsequent siblings) 6 siblings, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-06 0:49 UTC (permalink / raw) To: Alan Cox Cc: Larry McVoy, Ulrich Drepper, Ben Collins, Linux Kernel Mailing List On 6 Oct 2002, Alan Cox wrote: > Linus used to do about a patch every 2 days. Nowdays its a lot slower. I > put that down to buttkeeper Linus snapshots are available on a 3-hourly basis from: ftp://nl.linux.org/pub/linux/bk2patch/ Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:50 ` Alan Cox ` (2 preceding siblings ...) 2002-10-06 0:49 ` New BK License Problem? Rik van Riel @ 2002-10-06 4:43 ` David S. Miller 2002-10-06 5:50 ` Linus Torvalds ` (2 subsequent siblings) 6 siblings, 0 replies; 223+ messages in thread From: David S. Miller @ 2002-10-06 4:43 UTC (permalink / raw) To: alan; +Cc: lm, drepper, bcollins, linux-kernel From: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: 06 Oct 2002 00:50:27 +0100 Linus used to do about a patch every 2 days. Nowdays its a lot slower. I put that down to buttkeeper You can get up to hourly patch snapshots, and the so-called buttkeeper is what makes that possible. Ask Rik or Jgarzik, as I believe those are two folks who provide this service. To me the ftp site patches serve what they should have always served, as major checkpoints. The every-2-day patch thing was necessary back then because we had no other window into what was in Linus's tree at any given point in time. Which was truly brutal for folks that needed to be merging with him on a daily basis just to keep the backlog in check. Now we have tons of windows into his live tree, some use bitkeeper others are in purely patch form and do not require the use of bitkeeper. You can even click on a website to see "did Linus eat that XXX diff I sent him 2 hours ago?" By all accounts, information is more available than it used to be. In fact, the information is available in so many formats and sources that you have quite a wide selection of how you get it. People like Andrew Morton even publish the "snapshot as of two hours ago" diffs of Linus's tree against the most recent FTP patch in their patch sets. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:50 ` Alan Cox ` (3 preceding siblings ...) 2002-10-06 4:43 ` David S. Miller @ 2002-10-06 5:50 ` Linus Torvalds 2002-10-06 7:43 ` Skip Ford 2002-10-06 8:00 ` Jeff Garzik 2002-10-06 11:04 ` Ingo Molnar 6 siblings, 1 reply; 223+ messages in thread From: Linus Torvalds @ 2002-10-06 5:50 UTC (permalink / raw) To: linux-kernel In article <1033861827.4441.31.camel@irongate.swansea.linux.org.uk>, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > >Linus used to do about a patch every 2 days. Nowdays its a lot slower. I >put that down to buttkeeper Don't be silly, Alan. I don't do any pre-patches or daily patches any more, because it's all automated. There are several snapshot bots that give you patches a lot more often than "every 2 days". You don't need BK to use it, it's there in the good old diff format. (I haven't checked whether the auto-patches do a good job of doing changelogs too, but since all the changelogs I generate for the _real_ releases are also automated and I make the tools I use to generate them available, that's certainly not anything fundamental). So yes, you can "put it down to bitkeeper" in the sense that it's because of the automation that BK allows that I don't _need_ to personally do pre-patches any more. "Big boo-hoo, bitkeeper is evil, and Linus doesn't manually do any more what BK plus a few scripts does better for us automatically." Linus ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 5:50 ` Linus Torvalds @ 2002-10-06 7:43 ` Skip Ford 2002-10-06 8:13 ` Jeff Garzik ` (2 more replies) 0 siblings, 3 replies; 223+ messages in thread From: Skip Ford @ 2002-10-06 7:43 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel Linus Torvalds wrote: > > I don't do any pre-patches or daily patches any more, because it's all > automated. There are several snapshot bots that give you patches a lot > more often than "every 2 days". You don't need BK to use it, it's there > in the good old diff format. However, a much larger percentage of patches are applied to your tree without a diff being posted to lkml first. My only wish would be that you only accept patches through the mailing list, and only from posts that include at least a link to a diff. -- Skip ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 7:43 ` Skip Ford @ 2002-10-06 8:13 ` Jeff Garzik 2002-10-06 9:21 ` David S. Miller 2002-10-06 16:38 ` Arnaldo Carvalho de Melo 2 siblings, 0 replies; 223+ messages in thread From: Jeff Garzik @ 2002-10-06 8:13 UTC (permalink / raw) To: Skip Ford; +Cc: Linus Torvalds, linux-kernel Skip Ford wrote: > Linus Torvalds wrote: > >>I don't do any pre-patches or daily patches any more, because it's all >>automated. There are several snapshot bots that give you patches a lot >>more often than "every 2 days". You don't need BK to use it, it's there >>in the good old diff format. > > > However, a much larger percentage of patches are applied to your tree > without a diff being posted to lkml first. IMO this is very incorrect -- the high volume submitters have never posted their stuff to lkml when sending to Linus. BK did not change this at all. Andrew is the notable exception. [1] > My only wish would be that > you only accept patches through the mailing list, that won't work for many reasons... lots of uninteresting patches posted to lkml, security patches should go out-of-band, etc. Do you _really_ want to see boring and huge arch merges posted to lkml? Ug. :) Jeff [1] One might argue that Ingo is another exception, but I don't count him among the high-volume submitters. This is not intended to diminish him, either: Ingo probably has one of the highest "important/trivial" patch ratios of anybody in the kernel... ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 7:43 ` Skip Ford 2002-10-06 8:13 ` Jeff Garzik @ 2002-10-06 9:21 ` David S. Miller 2002-10-06 16:38 ` Arnaldo Carvalho de Melo 2 siblings, 0 replies; 223+ messages in thread From: David S. Miller @ 2002-10-06 9:21 UTC (permalink / raw) To: skip.ford; +Cc: torvalds, linux-kernel From: Skip Ford <skip.ford@verizon.net> Date: Sun, 6 Oct 2002 03:43:08 -0400 However, a much larger percentage of patches are applied to your tree without a diff being posted to lkml first. My only wish would be that you only accept patches through the mailing list, and only from posts that include at least a link to a diff. That is unlikely to work very well. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 7:43 ` Skip Ford 2002-10-06 8:13 ` Jeff Garzik 2002-10-06 9:21 ` David S. Miller @ 2002-10-06 16:38 ` Arnaldo Carvalho de Melo 2002-10-06 17:02 ` Alan Cox 2002-10-06 17:03 ` Skip Ford 2 siblings, 2 replies; 223+ messages in thread From: Arnaldo Carvalho de Melo @ 2002-10-06 16:38 UTC (permalink / raw) To: Skip Ford; +Cc: Linus Torvalds, linux-kernel Em Sun, Oct 06, 2002 at 03:43:08AM -0400, Skip Ford escreveu: > Linus Torvalds wrote: > > I don't do any pre-patches or daily patches any more, because it's all > > automated. There are several snapshot bots that give you patches a lot > > more often than "every 2 days". You don't need BK to use it, it's there in > > the good old diff format. > However, a much larger percentage of patches are applied to your tree without > a diff being posted to lkml first. My only wish would be that you only > accept patches through the mailing list, and only from posts that include at > least a link to a diff. Are you dying to see X.25, lapbether, LLC, IPX and other non-sexy/mainstream patches here? I can start doing it for the stuff I've been sending only via bitkeeper to David Miller, I'm mostly alone in this and having people commenting on it would be great, but I don't think that people that have interest in this aren't helping/commenting because I don't post the changesets here, after all if they're interested they can use the regular releases from Linus or the diffs provided by bot services generally available. If people think that this will help with development of the stuff I work with, please say so. Patches that touches the networking core, etc, I post to netdev, and not here, and this is done by lots of other people, for several subsystems, and contributes to the feeling that things are not being posted to lkml. They are not, never had, nothing new, only BK has a license people disagree with and all of a sudden is the reason for patches not being more reviewed, etc. I beg to disagree. - Arnaldo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 16:38 ` Arnaldo Carvalho de Melo @ 2002-10-06 17:02 ` Alan Cox 2002-10-06 17:12 ` Russell King 2002-10-06 21:06 ` Rik van Riel 2002-10-06 17:03 ` Skip Ford 1 sibling, 2 replies; 223+ messages in thread From: Alan Cox @ 2002-10-06 17:02 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: Skip Ford, Linus Torvalds, Linux Kernel Mailing List On Sun, 2002-10-06 at 17:38, Arnaldo Carvalho de Melo wrote: > Are you dying to see X.25, lapbether, LLC, IPX and other non-sexy/mainstream > patches here? I can start doing it for the stuff I've been sending only via > bitkeeper to David Miller, I'm mostly alone in this and having people I would really like a linux-patches@vger.kernel.org list that was nothing but all the patches people planned to submit, with minimal commentaries, and which had a reply to pointing at linux-kernel. Things like the hugetlb crap might then not have gotten in ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 17:02 ` Alan Cox @ 2002-10-06 17:12 ` Russell King 2002-10-06 21:06 ` Rik van Riel 1 sibling, 0 replies; 223+ messages in thread From: Russell King @ 2002-10-06 17:12 UTC (permalink / raw) To: Alan Cox Cc: Arnaldo Carvalho de Melo, Skip Ford, Linus Torvalds, Linux Kernel Mailing List On Sun, Oct 06, 2002 at 06:02:39PM +0100, Alan Cox wrote: > I would really like a linux-patches@vger.kernel.org list that was > nothing but all the patches people planned to submit, with minimal > commentaries, and which had a reply to pointing at linux-kernel. > > Things like the hugetlb crap might then not have gotten in That's fine if we specifically exclude the people who don't know how to quote mails properly. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 17:02 ` Alan Cox 2002-10-06 17:12 ` Russell King @ 2002-10-06 21:06 ` Rik van Riel 1 sibling, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-06 21:06 UTC (permalink / raw) To: Alan Cox Cc: Arnaldo Carvalho de Melo, Skip Ford, Linus Torvalds, Linux Kernel Mailing List On 6 Oct 2002, Alan Cox wrote: > I would really like a linux-patches@vger.kernel.org list that was > nothing but all the patches people planned to submit, with minimal > commentaries, and which had a reply to pointing at linux-kernel. Seconded. </AOL> Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 16:38 ` Arnaldo Carvalho de Melo 2002-10-06 17:02 ` Alan Cox @ 2002-10-06 17:03 ` Skip Ford 2002-10-06 23:05 ` Larry McVoy 1 sibling, 1 reply; 223+ messages in thread From: Skip Ford @ 2002-10-06 17:03 UTC (permalink / raw) To: Arnaldo Carvalho de Melo, Linus Torvalds, linux-kernel Arnaldo Carvalho de Melo wrote: > Em Sun, Oct 06, 2002 at 03:43:08AM -0400, Skip Ford escreveu: > > Linus Torvalds wrote: > > > > I don't do any pre-patches or daily patches any more, because it's all > > > automated. There are several snapshot bots that give you patches a lot > > > more often than "every 2 days". You don't need BK to use it, it's there in > > > the good old diff format. > > > However, a much larger percentage of patches are applied to your tree without > > a diff being posted to lkml first. My only wish would be that you only > > accept patches through the mailing list, and only from posts that include at > > least a link to a diff. > > Are you dying to see X.25, lapbether, LLC, IPX and other non-sexy/mainstream > patches here? I can start doing it for the stuff I've been sending only via > bitkeeper to David Miller, I'm mostly alone in this and having people > commenting on it would be great, but I don't think that people that have > interest in this aren't helping/commenting because I don't post the changesets > here, after all if they're interested they can use the regular releases from > Linus or the diffs provided by bot services generally available. I was thinking more of just sharing the code. There are more trees out there than just Linus'. Deciding to apply one of your patches is much easier if we have the specific patch, rather than just a 600k patch from Linus that happens to include your patch buried inside it. > If people think that this will help with development of the stuff I work with, > please say so. > > Patches that touches the networking core, etc, I post to netdev, and not here, > and this is done by lots of other people, for several subsystems, and > contributes to the feeling that things are not being posted to lkml. They are > not, never had, nothing new, only BK has a license people disagree with and all > of a sudden is the reason for patches not being more reviewed, etc. I beg to > disagree. I'm not bitching about bk here. It's clearly improved Linus' productivity. I don't use it, but I like Linus using it. And with the udiff-ing of each changeset, I can see each patch he applied, even if it wasn't sent to lkml. That wasn't possible before bk. It's the next best thing to actually having the author of the patch think others may want the same patch Linus wants. -- Skip ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 17:03 ` Skip Ford @ 2002-10-06 23:05 ` Larry McVoy 2002-10-07 0:42 ` Rob Landley 0 siblings, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-06 23:05 UTC (permalink / raw) To: Skip Ford; +Cc: Arnaldo Carvalho de Melo, Linus Torvalds, linux-kernel On Sun, Oct 06, 2002 at 01:03:57PM -0400, Skip Ford wrote: > I was thinking more of just sharing the code. There are more trees out > there than just Linus'. Deciding to apply one of your patches is much > easier if we have the specific patch, rather than just a 600k patch from > Linus that happens to include your patch buried inside it. I think a commit trigger is what you want: cd BitKeeper test -d triggers || mkdir triggers cd triggers cat > post-commit-linux-patches <<EOF #!/bin/sh ( bk changes -v -r+ bk export -tpatch -r+ ) | mail linux-patches@vger.kernel.edu EOF bk new post-commit-linux-patches bk commit -y'Mail patches to linux-patches' I haven't tested this but I think this will work, it will mail the patches as they are created, not as they move through the trees. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 23:05 ` Larry McVoy @ 2002-10-07 0:42 ` Rob Landley 0 siblings, 0 replies; 223+ messages in thread From: Rob Landley @ 2002-10-07 0:42 UTC (permalink / raw) To: Larry McVoy, Skip Ford Cc: Arnaldo Carvalho de Melo, Linus Torvalds, linux-kernel On Sunday 06 October 2002 07:05 pm, Larry McVoy wrote: > ) | mail linux-patches@vger.kernel.edu .org, actually. Rob ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:50 ` Alan Cox ` (4 preceding siblings ...) 2002-10-06 5:50 ` Linus Torvalds @ 2002-10-06 8:00 ` Jeff Garzik 2002-10-06 11:04 ` Ingo Molnar 6 siblings, 0 replies; 223+ messages in thread From: Jeff Garzik @ 2002-10-06 8:00 UTC (permalink / raw) To: Alan Cox; +Cc: Linux Kernel Mailing List Alan Cox wrote: > Linus used to do about a patch every 2 days. Nowdays its a lot slower. I > put that down to buttkeeper Check out /pub/linux/kernel/v2.5/snapshots/ [updated nightly at 4:20am US/Pacific time] My script updates EXTRAVERSION to -bk1, -bk2, etc. so they are really just like pre-patches. And dwmw2's per-cset GNU patches. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:50 ` Alan Cox ` (5 preceding siblings ...) 2002-10-06 8:00 ` Jeff Garzik @ 2002-10-06 11:04 ` Ingo Molnar 2002-10-06 10:57 ` David S. Miller 2002-10-06 10:59 ` David S. Miller 6 siblings, 2 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 11:04 UTC (permalink / raw) To: Alan Cox Cc: Larry McVoy, Ulrich Drepper, Ben Collins, Linus Torvalds, Linux Kernel Mailing List On 6 Oct 2002, Alan Cox wrote: > Linus used to do about a patch every 2 days. Nowdays its a lot slower. > [...] it's actually much different, and the patch flux has not only became much larger (compare the current _per day_ patch flux with the one from one year ago), it has also become more consistent. The 'trivial' patches get in much more consistently, many subsystems have become more uptodate than in eg. the 2.3 kernel days. And for people to keep posting stuff they need dependability. Also, it's easier to get core stuff in these days because 1) the kernel is 'frozen' much more rarely 2) it's much easier for Linus to just unroll bad stuff. Plus the BK tools to look at a piece of source code's evolution over time are really nice and useful when trying to sync up with some code one has not seen for a couple of weeks. but i share some of your fundamental concerns. As much as i like Larry the person, Larry the businessman is apparently a distinct entity. I remember when moving the kernel tree over to BK was raised first time (it was not even called bitkeeper back in that time), Larry talked about some sort of guarantees that involve GPL-ing of BK code 1-2 years after it's first used by the kernel, to make sure the Linux kernel tree is not left in limbo. Today we are _very_ far away from such guarantees - and in fact i was Cc:-ed on a mail in where kernel.org's admin got flamed by Larry with "you get what you pay for" when he simply asked for a .rpm version of the binary-only bk stuff so that it becomes easier to maintain. Larry, do you have any plans to GPL the BK code at any future date? And i'm not sure what Larry the businessman would say to a $100m acquisition offer today. Or a $200m one, or a $500m one. Based on Larry's past comments we have to assume that "yes" would be the answer - because he has employees who have kids to be fed, etc. So i believe the hard point of no return is the day the commit metadata becomes proprietary, either via using a proprietary format, or via getting a patent awarded. (it isnt right now, despite increasing centralization.) That would be the time Ingo the kernel hacker would definitely say 'no' to BK. (despite of what Ingo the person thinks about Larry the person.) i'm also a bit worried about the legal status of commit messages posted via bkbits. Are they GPL-ed automatically, can we just take them and put them into a free-BK type server? We already have one precedent of a business entity abusing a free OS project and then suing it (and winning the suit), hindering the free OS's development for years. and frankly, i find it very sobering how Larry (the businessman?) plays down the fundamental and valid worries of the Linux community with "well you get what you pay for" type of arguments. There are tons of other businesses in the world that would 'pay' alot more than a free server, a T1 line, and "ask nicely enough and be prepared to be flamed when you are asking for too much" kind of free support, for the big PR-advantage of hosting the Linux kernel tree. Occasionally i ask myself whether the significant de-loading of Linus' patch management work is worth the increasing feeling of ... humiliation this causes. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 11:04 ` Ingo Molnar @ 2002-10-06 10:57 ` David S. Miller 2002-10-06 11:24 ` Ingo Molnar 2002-10-06 10:59 ` David S. Miller 1 sibling, 1 reply; 223+ messages in thread From: David S. Miller @ 2002-10-06 10:57 UTC (permalink / raw) To: mingo; +Cc: alan, lm, drepper, bcollins, torvalds, linux-kernel From: Ingo Molnar <mingo@elte.hu> Date: Sun, 6 Oct 2002 13:04:39 +0200 (CEST) Larry talked about some sort of guarantees that involve GPL-ing of BK code 1-2 years after it's first used by the kernel, to make sure the Linux kernel tree is not left in limbo. Ingo, he promised this if the bitkeeper logging went down for a period of time or if bitkeeper were to go out of buisness. He did not promise this just because we use it for kernel development for 1-2 years, are you out of your mind? :-) ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 10:57 ` David S. Miller @ 2002-10-06 11:24 ` Ingo Molnar 0 siblings, 0 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 11:24 UTC (permalink / raw) To: David S. Miller; +Cc: alan, lm, drepper, bcollins, torvalds, linux-kernel On Sun, 6 Oct 2002, David S. Miller wrote: > Larry talked about some sort of > guarantees that involve GPL-ing of BK code 1-2 years after it's first > used by the kernel, to make sure the Linux kernel tree is not left > in limbo. > > Ingo, he promised this if the bitkeeper logging went down for a period > of time or if bitkeeper were to go out of buisness. yes, i know. > He did not promise this just because we use it for kernel development > for 1-2 years, are you out of your mind? :-) actually, this discussion dates back many years, and i definitely remember an Alladin-soft -alike license being considered in where the GPL-ing of the infrastructure would be delayed by 1-2 years to give Larry a competitive advantage, but the potential damage to Linux would be limited. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 11:04 ` Ingo Molnar 2002-10-06 10:57 ` David S. Miller @ 2002-10-06 10:59 ` David S. Miller 2002-10-06 12:04 ` BK MetaData " Ingo Molnar 2002-10-06 12:10 ` New BK " Ingo Molnar 1 sibling, 2 replies; 223+ messages in thread From: David S. Miller @ 2002-10-06 10:59 UTC (permalink / raw) To: mingo; +Cc: alan, lm, drepper, bcollins, torvalds, linux-kernel From: Ingo Molnar <mingo@elte.hu> Date: Sun, 6 Oct 2002 13:04:39 +0200 (CEST) i'm also a bit worried about the legal status of commit messages posted via bkbits. Are they GPL-ed automatically, can we just take them and put them into a free-BK type server? We already have one precedent of a business entity abusing a free OS project and then suing it (and winning the suit), hindering the free OS's development for years. Larry has stated many times over that he doesn't own our bits. That is why once you extract content from the repository into some other form (a patch with the change logs prepended, for example) he doesn't care what you do with it. He even said this twice today. ^ permalink raw reply [flat|nested] 223+ messages in thread
* BK MetaData License Problem? 2002-10-06 10:59 ` David S. Miller @ 2002-10-06 12:04 ` Ingo Molnar 2002-10-06 11:52 ` David S. Miller 2002-10-06 13:48 ` Russell King 2002-10-06 12:10 ` New BK " Ingo Molnar 1 sibling, 2 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 12:04 UTC (permalink / raw) To: David S. Miller Cc: Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, linux-kernel On Sun, 6 Oct 2002, David S. Miller wrote: > i'm also a bit worried about the legal status of commit messages posted > via bkbits. Are they GPL-ed automatically, can we just take them and put > them into a free-BK type server? We already have one precedent of a > business entity abusing a free OS project and then suing it (and winning > the suit), hindering the free OS's development for years. > > Larry has stated many times over that he doesn't own our bits. > > That is why once you extract content from the repository into some other > form (a patch with the change logs prepended, for example) he doesn't > care what you do with it. for years people sent emails to Linus that described patches and this was not a big issue - Linus has kept 99% of the metadata in the source code. But today the 'Linux kernel' is not the source code anymore, it's the source code plus the BK metadata, which are separate bits, and this creates a new situation. the BKL.txt license currently says: By transmitting the Metadata to an Open Logging server, You hereby grant BitMover, or any other operator of an Open Logging server, per- mission to republish the Metadata sent by the Bit- Keeper Software to the Open Logging server. what i'm worried about is the following issue: by default the data and the MetaData is owned by whoever created it. You, me, other kernel developers. We GPL the code, but the metadata is not automatically GPL-ed, just like writing a book about the Linux kernel is is not necesserily GPL-ed. It's not a big problem today because if you ask me then i'll tell you that it's GPL-ed - but what will be the situation be in years? Couldnt 'BitMover or any other operator of an Open Logging server' argue that the MetaData is owned by whoever created them, and is not covered by the GPL - and only 'BitMover or any other operator of an Open Logging server' has 'permission to republish the Metadata'. there are a number of legal cases in the US that involve around exactly such issues (republishing of newpaper articles on the internet written by independent journalists, republishing of the CD info database created by anonymous users, etc.), and i'm sure we do not want the Linux kernel tree to become another legal precedent. it would be better if the license also said: By transmitting the MetaData to an Open Logging server, You hereby also agree to license the MetaData under the same license you license the data it describes. (or something to that extent - i'm not a lawyer.) this ensures that metadata attached to GPL-ed code is also licensed under the GPL, and creates a clearly GPL-ed repository, both data and metadata. I'm 100% sure that the Linux commit messages are already valuable today, and they will become a few orders more valuable in a few years. btw., this is also the case with the emails Linus puts into BK commit info - the email someone sends to Linus is _not_ GPL-ed by default. (perhaps the solution is simple - i'd be really happy if it was.) Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 12:04 ` BK MetaData " Ingo Molnar @ 2002-10-06 11:52 ` David S. Miller 2002-10-06 12:18 ` jbradford ` (2 more replies) 2002-10-06 13:48 ` Russell King 1 sibling, 3 replies; 223+ messages in thread From: David S. Miller @ 2002-10-06 11:52 UTC (permalink / raw) To: mingo; +Cc: alan, lm, drepper, bcollins, torvalds, linux-kernel From: Ingo Molnar <mingo@elte.hu> Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST) It's not a big problem today because if you ask me then i'll tell you that it's GPL-ed - but what will be the situation be in years? Couldnt 'BitMover or any other operator of an Open Logging server' argue that the MetaData is owned by whoever created them, and is not covered by the GPL - and only 'BitMover or any other operator of an Open Logging server' has 'permission to republish the Metadata'. Anything you write is automatically copyrighted by you, even if you don't specifically state it as such. That is my basic understanding of copyright law. BitMover et al. can't take your copyright powers away from you. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 11:52 ` David S. Miller @ 2002-10-06 12:18 ` jbradford 2002-10-06 12:35 ` jw schultz 2002-10-06 12:18 ` Ingo Molnar 2002-10-06 16:18 ` Daniel Berlin 2 siblings, 1 reply; 223+ messages in thread From: jbradford @ 2002-10-06 12:18 UTC (permalink / raw) To: David S. Miller Cc: alan, lm, drepper, bcollins, torvalds, linux-kernel, mingo > From: Ingo Molnar <mingo@elte.hu> > Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST) > > It's not a big problem today because if you ask me then i'll tell you that > it's GPL-ed - but what will be the situation be in years? Couldnt > 'BitMover or any other operator of an Open Logging server' argue that the > MetaData is owned by whoever created them, and is not covered by the GPL - > and only 'BitMover or any other operator of an Open Logging server' has > 'permission to republish the Metadata'. > > Anything you write is automatically copyrighted by you, even if you > don't specifically state it as such. In most countries nowadays, this is correct. > That is my basic understanding of copyright law. > > BitMover et al. can't take your copyright powers away from you. No, but since you own the copyright, you can give rights to the material to the operator of the Open Logging server. Why don't we have a system whereby we automatically assign copyright to one person, (I.E. Linus), who can then assign us GPL rights in return, so that by submitting material to any server, we are not able to assign anything other than GPL rights to it's owner. This is, I believe, although I could be wrong, the reason that the Free Software Foundation allows you to assign copyrights to them. John. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 12:18 ` jbradford @ 2002-10-06 12:35 ` jw schultz 0 siblings, 0 replies; 223+ messages in thread From: jw schultz @ 2002-10-06 12:35 UTC (permalink / raw) To: linux-kernel Please learn how to use the carriage return. On Sun, Oct 06, 2002 at 01:18:10PM +0100, jbradford@dial.pipex.com wrote: > > BitMover et al. can't take your copyright powers away > > from you. > > No, but since you own the copyright, you can give rights > to the material to the operator of the Open Logging > server. > > Why don't we have a system whereby we automatically assign > copyright to one person, (I.E. Linus), who can then assign > us GPL rights in return, so that by submitting material to > any server, we are not able to assign anything other than > GPL rights to it's owner. For good or ill by having the copyrights not held by one person but instead held by so many is that no-one can arbitrarily change the license or relicense under other terms without the permission of all of the copyright holders. However much you might trust Linus, do you want to trust his grandchildren? Or the foundation after corporate interests have subverted it? > This is, I believe, although I could be wrong, the reason > that the Free Software Foundation allows you to assign > copyrights to them. The reason to assign your copyright to the FSF is to give them standing in court to defend the copyright. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 11:52 ` David S. Miller 2002-10-06 12:18 ` jbradford @ 2002-10-06 12:18 ` Ingo Molnar 2002-10-06 16:18 ` Daniel Berlin 2 siblings, 0 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 12:18 UTC (permalink / raw) To: David S. Miller Cc: Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, linux-kernel On Sun, 6 Oct 2002, David S. Miller wrote: > Anything you write is automatically copyrighted by you, even if you > don't specifically state it as such. > > That is my basic understanding of copyright law. > > BitMover et al. can't take your copyright powers away from you. yes, this is my understanding as well, but the BK license can require you to license your bits in exchange for allowing you to use the BK product. It already does require 'republishing rights' for the metadata bits in fact. (which is a perfectly fair requirement - Larry needs this assurance to be able to host bkbits in a legally safe way.) the issue is that in the BK repository data and metadata is distinctly separate. The Linux kernel is fully functional without any of the metadata, and the GPL only covers the Linux kernel. And i'd like note it that this situation is not "BK's fault" in any way, it's simply the thing that copyright law says about not explicitly licensed bits. But it's a situation created by BK, and it could be eliminated by the BK license requiring the metadata to be licensed under the same conditions the data itself is licensed. Or we could put this into the Linux kernel license. (which OTOH might violate the GPL.) i'm sure this issue was raised before - eg. what is the legal standing of the commit messages of the BSD kernels? Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 11:52 ` David S. Miller 2002-10-06 12:18 ` jbradford 2002-10-06 12:18 ` Ingo Molnar @ 2002-10-06 16:18 ` Daniel Berlin 2 siblings, 0 replies; 223+ messages in thread From: Daniel Berlin @ 2002-10-06 16:18 UTC (permalink / raw) To: David S. Miller Cc: mingo, alan, lm, drepper, bcollins, torvalds, linux-kernel On Sun, 6 Oct 2002, David S. Miller wrote: > From: Ingo Molnar <mingo@elte.hu> > Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST) > > It's not a big problem today because if you ask me then i'll tell you that > it's GPL-ed - but what will be the situation be in years? Couldnt > 'BitMover or any other operator of an Open Logging server' argue that the > MetaData is owned by whoever created them, and is not covered by the GPL - > and only 'BitMover or any other operator of an Open Logging server' has > 'permission to republish the Metadata'. > > Anything you write is automatically copyrighted by you, even if you > don't specifically state it as such. > > That is my basic understanding of copyright law. Correct. Registration, for the most part, only affects remedies. There are, as one would expect, weird corner cases and whatnot (bad engineering :P). But the short of it is that registration gives you the ability to get statutory damages and attorneys fees. Without registering, you can only get actual damages. --Dan ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 12:04 ` BK MetaData " Ingo Molnar 2002-10-06 11:52 ` David S. Miller @ 2002-10-06 13:48 ` Russell King 2002-10-06 14:10 ` Ingo Molnar 2002-10-06 17:17 ` Jes Sorensen 1 sibling, 2 replies; 223+ messages in thread From: Russell King @ 2002-10-06 13:48 UTC (permalink / raw) To: Ingo Molnar Cc: David S. Miller, Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, linux-kernel On Sun, Oct 06, 2002 at 02:04:42PM +0200, Ingo Molnar wrote: > the BKL.txt license currently says: > > By transmitting the Metadata > to an Open Logging server, You hereby grant BitMover, > or any other operator of an Open Logging server, per- > mission to republish the Metadata sent by the Bit- > Keeper Software to the Open Logging server. IANAL, but this is just to protect BitMover against _you_ suing them for publishing your log entries. Completely sensible. They're not claiming copyright over the metadata. They're not claiming any license over the metadata. > what i'm worried about is the following issue: by default the data and the > MetaData is owned by whoever created it. You, me, other kernel developers. > We GPL the code, but the metadata is not automatically GPL-ed, just like > writing a book about the Linux kernel is is not necesserily GPL-ed. It doesn't say "you transfer all your IP and soul to bitmover." > it would be better if the license also said: > > By transmitting the MetaData to an Open Logging server, You > hereby also agree to license the MetaData under the same license > you license the data it describes. > > (or something to that extent - i'm not a lawyer.) That doesn't explicitly allow bitmover to put the metadata up in public view, which would mean the openlogging stuff will leave bitmover wide open for legal action. > btw., this is also the case with the emails Linus puts into BK commit info > - the email someone sends to Linus is _not_ GPL-ed by default. > > (perhaps the solution is simple - i'd be really happy if it was.) The exact same problem applies to pre-BK Linus and Alan, and whoever else produces a change log that contains information produced by a third party. Does Linus and Alan have an implicit right to republish the documentation that was sent to them with the patch? Does Red Hat have the right to republish comments placed into the bugzilla database by external users of that service? Does Debian have a right to reproduce emails on their website which have been sent to foo@bugs.debian.org (or whatever the address is?) There is a _big_ question about reproducing peoples personal information in the EU (eg, email addresses) on web sites, even archives of public mailing lists. The exim mailing lists were recently threatened with legal action over this very point, and there was talk at one point about having to shut down the whole exim.org site because of this. The end result of this debarcle was various posts were deleted from the list archive. So, this isn't a BK problem. Its a community problem. Please don't shovel shit into other peoples back yards. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 13:48 ` Russell King @ 2002-10-06 14:10 ` Ingo Molnar 2002-10-06 14:08 ` Russell King ` (2 more replies) 2002-10-06 17:17 ` Jes Sorensen 1 sibling, 3 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 14:10 UTC (permalink / raw) To: Russell King Cc: David S. Miller, Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, linux-kernel On Sun, 6 Oct 2002, Russell King wrote: > > it would be better if the license also said: > > > > By transmitting the MetaData to an Open Logging server, You > > hereby also agree to license the MetaData under the same license > > you license the data it describes. > > That doesn't explicitly allow bitmover to put the metadata up in public > view, which would mean the openlogging stuff will leave bitmover wide > open for legal action. (this is why i said 'also' in the above sentence. It would be in addition to the existing (and sensible) requirement for BM to be able to republish the commit logs.) > > btw., this is also the case with the emails Linus puts into BK commit info > > - the email someone sends to Linus is _not_ GPL-ed by default. > > > > (perhaps the solution is simple - i'd be really happy if it was.) > > The exact same problem applies to pre-BK Linus and Alan, and whoever > else produces a change log that contains information produced by a third > party. with the difference that the changelog was a few orders of magnitude less of an infrastructure element. Plus if you read those changelogs you'll see that it's 100% written by Alan or Linus - in 99% of the cases it just describes what the patch does, and in the remaining 1% it quotes a few key sentences that can be considered fair use. Ie. the ChangeLog was owned by Alan and Linus. [it would be a bit more robust if the ChangeLogs would be part of the kernel repository, that would make them covered by the GPL.] > Does Linus and Alan have an implicit right to republish the > documentation that was sent to them with the patch? [...] yes, as long as the documentation comes with the patch and is part of the kernel tree, which the patch derives, and which kernel tree has a certain 'COPYING' file in the top directory. Patches *are* actively monitored for conflicting licenses in individual files, and occasionally we had to remove files. > [...] The exim mailing lists were recently threatened with legal action > over this very point, and there was talk at one point about having to > shut down the whole exim.org site because of this. [...] > So, this isn't a BK problem. Its a community problem. it *is* a BK problem caused by BK becase now this whole can of worms got silently exported to the kernel tree, and while BM itself is safe via its license, the kernel tree 'as a whole' is exposed. until now the Linux kernel tree was distributed in a tarball that had a nice COPYING file in a very prominent spot. With BK the situation is different - and like i said in previous mails it's not BK's "fault", but BK's "effect" - and it's a situation that needs to be remedied, right? Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 14:10 ` Ingo Molnar @ 2002-10-06 14:08 ` Russell King 2002-10-06 16:58 ` Alan Cox 2002-10-06 14:23 ` jbradford 2002-10-06 19:39 ` Linus Torvalds 2 siblings, 1 reply; 223+ messages in thread From: Russell King @ 2002-10-06 14:08 UTC (permalink / raw) To: Ingo Molnar Cc: David S. Miller, Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, linux-kernel On Sun, Oct 06, 2002 at 04:10:46PM +0200, Ingo Molnar wrote: > it *is* a BK problem caused by BK becase now this whole can of worms got > silently exported to the kernel tree, and while BM itself is safe via its > license, the kernel tree 'as a whole' is exposed. Actually, the more I think about it, the more you are correct. The way BK openlogging works, it exports personal information out of the EU. This is explicitly prohibited under EU law, unless the owner of that personal information has explicitly granted that it may be used in that manner. Therefore, I'd stronlg advise people in the EU not to use BK's BK_USER/ BK_HOST feature when importing patches. The following question remains though: peoples names are "personal information." Personal information falls under the UK data protection act, which is one implementation of the EU law. This means that unless Alan has an explicit agreement with every person who has sent him a patch, he has no right to publish the list of names in his change log, especially when that information travels leaves the EU. This is certainly an interesting problem. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 14:08 ` Russell King @ 2002-10-06 16:58 ` Alan Cox 2002-10-06 17:06 ` jbradford 2002-10-06 19:12 ` Marek Habersack 0 siblings, 2 replies; 223+ messages in thread From: Alan Cox @ 2002-10-06 16:58 UTC (permalink / raw) To: Russell King Cc: Ingo Molnar, David S. Miller, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, Linux Kernel Mailing List On Sun, 2002-10-06 at 15:08, Russell King wrote: > The way BK openlogging works, it exports personal information out of the > EU. This is explicitly prohibited under EU law, unless the owner of that > personal information has explicitly granted that it may be used in that > manner. You can give anyone you like your -own- personal info. That is your problem. What you can't do is do that with someone elses. If it bothers you start a project in some free country that is about cracking DRM schemes, use bitkeeper, document profusely in commit messages and wait ;) ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 16:58 ` Alan Cox @ 2002-10-06 17:06 ` jbradford 2002-10-06 19:12 ` Marek Habersack 1 sibling, 0 replies; 223+ messages in thread From: jbradford @ 2002-10-06 17:06 UTC (permalink / raw) To: Alan Cox; +Cc: linux-kernel, rmk, mingo, davem, bcollins, torvalds > > On Sun, 2002-10-06 at 15:08, Russell King wrote: > > The way BK openlogging works, it exports personal information out of the > > EU. This is explicitly prohibited under EU law, unless the owner of that > > personal information has explicitly granted that it may be used in that > > manner. > > You can give anyone you like your -own- personal info. That is your > problem. What you can't do is do that with someone elses. That's not the issue he is raising. What he is saying is that say I make a patch and E-Mail it to you, with a change log entry that says, "John Bradford did this 1337 patch", and then you pass it on to somebody outside the EU, then you've violated the EU regulation. John. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 16:58 ` Alan Cox 2002-10-06 17:06 ` jbradford @ 2002-10-06 19:12 ` Marek Habersack 1 sibling, 0 replies; 223+ messages in thread From: Marek Habersack @ 2002-10-06 19:12 UTC (permalink / raw) To: Alan Cox Cc: Russell King, Ingo Molnar, David S. Miller, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 686 bytes --] On Sun, Oct 06, 2002 at 05:58:26PM +0100, Alan Cox scribbled: > On Sun, 2002-10-06 at 15:08, Russell King wrote: > > The way BK openlogging works, it exports personal information out of the > > EU. This is explicitly prohibited under EU law, unless the owner of that > > personal information has explicitly granted that it may be used in that > > manner. > > You can give anyone you like your -own- personal info. That is your > problem. What you can't do is do that with someone elses. Yes, but giving that info to anyone doesn't grant them the permission to redistribute the information. I think that might be the problem Russel is concerned about. regards, marek [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 14:10 ` Ingo Molnar 2002-10-06 14:08 ` Russell King @ 2002-10-06 14:23 ` jbradford 2002-10-06 19:39 ` Linus Torvalds 2 siblings, 0 replies; 223+ messages in thread From: jbradford @ 2002-10-06 14:23 UTC (permalink / raw) To: mingo; +Cc: mingo, linux-kernel > > until now the Linux kernel tree was distributed in a tarball that had a > nice COPYING file in a very prominent spot. With BK the situation is > different - and like i said in previous mails it's not BK's "fault", but > BK's "effect" - and it's a situation that needs to be remedied, right? Strictly speaking, isn't it a violation of the GPL for somebody to distribute a single file of any GPLed project, without attaching the COPYING file to it? E.G. say somebody makes a CVS tree available via the web - you can download foobar.c without ever seeing the COPYING file. John. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 14:10 ` Ingo Molnar 2002-10-06 14:08 ` Russell King 2002-10-06 14:23 ` jbradford @ 2002-10-06 19:39 ` Linus Torvalds 2002-10-06 20:00 ` Ingo Molnar 2002-10-06 22:52 ` Larry McVoy 2 siblings, 2 replies; 223+ messages in thread From: Linus Torvalds @ 2002-10-06 19:39 UTC (permalink / raw) To: Ingo Molnar Cc: Russell King, David S. Miller, Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, linux-kernel [ Different issue, and slightly off-topic ] On Sun, 6 Oct 2002, Ingo Molnar wrote: > > until now the Linux kernel tree was distributed in a tarball that had a > nice COPYING file in a very prominent spot. With BK the situation is > different - and like i said in previous mails it's not BK's "fault", but > BK's "effect" - and it's a situation that needs to be remedied, right? If this is a concern, it actually appears that BK has the capability to "enforce" a license, in that I coul dmake BK aware of the GPL and that would cause BK to pop up a window saying "Do you agree to this license" before the first check-in by a person (the same way it asked you whether you wanted to allow openlogging). Do people feel that would be a good idea? I actually dismissed it when Larry talked about it, because I felt people might take it as another "too much BK in your face", even though the license would be the _Linux_ license, not the BK one. Linus ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 19:39 ` Linus Torvalds @ 2002-10-06 20:00 ` Ingo Molnar 2002-10-06 22:52 ` Larry McVoy 1 sibling, 0 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 20:00 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, David S. Miller, Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, linux-kernel On Sun, 6 Oct 2002, Linus Torvalds wrote: > If this is a concern, it actually appears that BK has the capability to > "enforce" a license, in that I coul dmake BK aware of the GPL and that > would cause BK to pop up a window saying "Do you agree to this license" > before the first check-in by a person (the same way it asked you whether > you wanted to allow openlogging). sounds interesting - is it difficult to enabled it, just to see how much impact it has on daily work? > Do people feel that would be a good idea? I actually dismissed it when > Larry talked about it, because I felt people might take it as another > "too much BK in your face", even though the license would be the _Linux_ > license, not the BK one. well, if it can be made a one-time thing, ie. something like: 'from now on if you commit in the repository and distribute the changes then all those changes and related BK metadata are licensed under the GPL', that would be less intrusive i guess? Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 19:39 ` Linus Torvalds 2002-10-06 20:00 ` Ingo Molnar @ 2002-10-06 22:52 ` Larry McVoy 2002-10-07 6:08 ` Ingo Molnar 1 sibling, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-06 22:52 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Russell King, David S. Miller, Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, linux-kernel On Sun, Oct 06, 2002 at 12:39:48PM -0700, Linus Torvalds wrote: > > [ Different issue, and slightly off-topic ] > > On Sun, 6 Oct 2002, Ingo Molnar wrote: > > > > until now the Linux kernel tree was distributed in a tarball that had a > > nice COPYING file in a very prominent spot. With BK the situation is > > different - and like i said in previous mails it's not BK's "fault", but > > BK's "effect" - and it's a situation that needs to be remedied, right? > > If this is a concern, it actually appears that BK has the capability to > "enforce" a license, in that I coul dmake BK aware of the GPL and that > would cause BK to pop up a window saying "Do you agree to this license" > before the first check-in by a person (the same way it asked you whether > you wanted to allow openlogging). Yes, but you'd want to make sure that you stated that your license extended to the BK metadata. In our opinion, only you as the creator of the repository gets to make that rule but you certainly can, that's one of the reasons we put that clause in there. By the way, the way this code works in bk-3.0 is that it saves a md5sum or some sort of strong hash of the license in question and it will ask you only once, assuming you are using the same home directory. It will ask you again if the license changes, that's what the hash is for. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 22:52 ` Larry McVoy @ 2002-10-07 6:08 ` Ingo Molnar 2002-10-07 6:07 ` Larry McVoy 0 siblings, 1 reply; 223+ messages in thread From: Ingo Molnar @ 2002-10-07 6:08 UTC (permalink / raw) To: Larry McVoy Cc: Linus Torvalds, Russell King, David S. Miller, Alan Cox, Ulrich Drepper, bcollins, linux-kernel On Sun, 6 Oct 2002, Larry McVoy wrote: > Yes, but you'd want to make sure that you stated that your license > extended to the BK metadata. In our opinion, only you as the creator of > the repository gets to make that rule but you certainly can, that's one > of the reasons we put that clause in there. so in theory it's perfectly possible to 'link' the data's and metadata's license via BKL.txt - after all you already added licensing rules for the metadata into the BK license, for the purposes of OpenLogging. It would also perhaps make your position slightly more robust - besides you already having the right to 'republish' metadata [which is a term not directly defined in the license], you'd also have all the rights that come through the license of the data it describes - whatever that is worth. There are some problems like the fact that metadata might describe multiple pieces of data that might have different licenses, the solution would be to license metadata under every license that data is licensed under - if there's any. This would be in addition to the already existing republishing rights for OpenLogging. > By the way, the way this code works in bk-3.0 is that it saves a md5sum > or some sort of strong hash of the license in question and it will ask > you only once, assuming you are using the same home directory. It will > ask you again if the license changes, that's what the hash is for. this sounds really nice and unintrusive, how does one enable it? Is this BK_FORCE, or something else? I cannot find any reference to this in 'bk helptool'. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-07 6:08 ` Ingo Molnar @ 2002-10-07 6:07 ` Larry McVoy 0 siblings, 0 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-07 6:07 UTC (permalink / raw) To: Ingo Molnar Cc: Larry McVoy, Linus Torvalds, Russell King, David S. Miller, Alan Cox, Ulrich Drepper, bcollins, linux-kernel > so in theory it's perfectly possible to 'link' the data's and metadata's > license via BKL.txt - after all you already added licensing rules for the > metadata into the BK license, for the purposes of OpenLogging. It is our position and we believe that it is supported by the BKL license that it is the right and authority of the original creator of the project to enforce any license they so wish. If Linus wants to make it clear that if you make changesets using BK that the checkin comments are also GPLed, that's his right. That's our intent and that's what we believe the license says. See clause 3(b). > > By the way, the way this code works in bk-3.0 is that it saves a md5sum > > or some sort of strong hash of the license in question and it will ask > > you only once, assuming you are using the same home directory. It will > > ask you again if the license changes, that's what the hash is for. > > this sounds really nice and unintrusive, how does one enable it? Is this > BK_FORCE, or something else? I cannot find any reference to this in 'bk > helptool'. That's because we haven't shipped bk-3.0 yet, we expect to do so this week. The license clause has been there for a long time, these rules are part of the BKL. However, we only recently added the "click to accept" stuff for the extra license and the lawyers tell us that is required to be enforceable. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 13:48 ` Russell King 2002-10-06 14:10 ` Ingo Molnar @ 2002-10-06 17:17 ` Jes Sorensen 2002-10-06 17:38 ` Larry McVoy 2002-10-06 17:41 ` Alan Cox 1 sibling, 2 replies; 223+ messages in thread From: Jes Sorensen @ 2002-10-06 17:17 UTC (permalink / raw) To: Russell King Cc: Ingo Molnar, David S. Miller, Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, linux-kernel >>>>> "Russell" == Russell King <rmk@arm.linux.org.uk> writes: [snip] Russell> There is a _big_ question about reproducing peoples personal Russell> information in the EU (eg, email addresses) on web sites, Russell> even archives of public mailing lists. The exim mailing Russell> lists were recently threatened with legal action over this Russell> very point, and there was talk at one point about having to Russell> shut down the whole exim.org site because of this. The end Russell> result of this debarcle was various posts were deleted from Russell> the list archive. This whole metadata discussion leads me to another question which has been bothering me about BK's 'Open' Logging and hosted trees for a while. What is happening to all the infomation that BitMover is (or could gather) from people accessing the Open Logging site as well as the hosted repositories? There could be a lot of marketing value in this if BM decided to abuse it. Ie. some marketing manager could decide to run advertisement campaigns listing names of known individuals using the software. I just checked http://www.bitkeeper.com/Sales.Licensing.Free.html and the word 'privacy' does not occur on that page at all. While I understand BK need for a license to publish the metadata, then I'd be a lot more comfortable with a written guarantee restricting the use to the logging site or similar. Jes ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 17:17 ` Jes Sorensen @ 2002-10-06 17:38 ` Larry McVoy 2002-10-06 17:41 ` Alan Cox 1 sibling, 0 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-06 17:38 UTC (permalink / raw) To: Jes Sorensen Cc: Russell King, Ingo Molnar, David S. Miller, Alan Cox, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, linux-kernel > I just checked http://www.bitkeeper.com/Sales.Licensing.Free.html and > the word 'privacy' does not occur on that page at all. > > While I understand BK need for a license to publish the metadata, then > I'd be a lot more comfortable with a written guarantee restricting the > use to the logging site or similar. We're happy to say we won't sell or publish the material in any way *other* than the openlogging web pages. I'm not sure what good that does, the cat is out of the bag on the web pages so I can't imagine a market for the data which is freely available, but if you are worried, propose some language, we'll shove it in the above web page if the language is reasonable (i.e., doesn't preclude openlogging itself). -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 17:17 ` Jes Sorensen 2002-10-06 17:38 ` Larry McVoy @ 2002-10-06 17:41 ` Alan Cox 2002-10-06 17:45 ` Jes Sorensen 1 sibling, 1 reply; 223+ messages in thread From: Alan Cox @ 2002-10-06 17:41 UTC (permalink / raw) To: Jes Sorensen Cc: Russell King, Ingo Molnar, David S. Miller, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, Linux Kernel Mailing List On Sun, 2002-10-06 at 18:17, Jes Sorensen wrote: > This whole metadata discussion leads me to another question which has > been bothering me about BK's 'Open' Logging and hosted trees for a > while. What is happening to all the infomation that BitMover is (or > could gather) from people accessing the Open Logging site as well as > the hosted repositories? There could be a lot of marketing value in > this if BM decided to abuse it. Ie. some marketing manager could > decide to run advertisement campaigns listing names of known > individuals using the software. They can do that anyway. The metadata is public. Nobody even needs to bother Larry about it, any more than folks who trawl it for spam email targets do ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 17:41 ` Alan Cox @ 2002-10-06 17:45 ` Jes Sorensen 2002-10-06 22:49 ` Larry McVoy 0 siblings, 1 reply; 223+ messages in thread From: Jes Sorensen @ 2002-10-06 17:45 UTC (permalink / raw) To: Alan Cox Cc: Russell King, Ingo Molnar, David S. Miller, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, Linux Kernel Mailing List >>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes: Alan> On Sun, 2002-10-06 at 18:17, Jes Sorensen wrote: >> This whole metadata discussion leads me to another question which >> has been bothering me about BK's 'Open' Logging and hosted trees >> for a while. What is happening to all the infomation that BitMover >> is (or could gather) from people accessing the Open Logging site as >> well as the hosted repositories? There could be a lot of marketing >> value in this if BM decided to abuse it. Ie. some marketing manager >> could decide to run advertisement campaigns listing names of known >> individuals using the software. Alan> They can do that anyway. The metadata is public. Nobody even Alan> needs to bother Larry about it, any more than folks who trawl it Alan> for spam email targets do Whether or not it's legal to post it is something else, that doesn't make it right. Besides, in many countries you can't put someone's name up on a billboard unless they have agreed to it, or if they are considered a 'public person' or something to that extend. Of course with the totally broken privacy system in the US, and Canada for that safe ;-(, I am sure you can publish whatever you want. I have no issue with a company like BM or anyone else using anonymous statistics for advertisement, but I'd be royally pissed if I had my name on someone's leaflet without having given my written permission first. Hence the suggestion for a privacy clause in the license. Cheers, Jes ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK MetaData License Problem? 2002-10-06 17:45 ` Jes Sorensen @ 2002-10-06 22:49 ` Larry McVoy 0 siblings, 0 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-06 22:49 UTC (permalink / raw) To: Jes Sorensen Cc: Alan Cox, Russell King, Ingo Molnar, David S. Miller, Larry McVoy, Ulrich Drepper, bcollins, Linus Torvalds, Linux Kernel Mailing List On Sun, Oct 06, 2002 at 01:45:04PM -0400, Jes Sorensen wrote: > I have no issue with a company like BM or anyone else using anonymous > statistics for advertisement, but I'd be royally pissed if I had my > name on someone's leaflet without having given my written permission > first. Hence the suggestion for a privacy clause in the license. OK, so find some legal language that does what you want and send it to me. If it doesn't prevent the openlogging web pages or the bkbits.net web pages and bkd ports, we'll add it. We don't do a darn thing with that info, I hear, understand, and agree with your concern, I just need some sample language that threads the needle. All the language I've seen would prevent us from displaying the web pages. That's no good. We can't say we won't redistribute because the web pages are definitely redistribution. We can say we won't sell it if that helps. If we say we can't aggragate it then we can't do stuff like this: http://www.bitkeeper.com/stats/linux-csets-L3W.png which is something we'd like to make part of bkbits.net. And I think it's something that the community wants. So what's the language that says we won't do the spam style crud that you are legitimately afraid of but does allow the useful stuff for the community? It's good to handle this now, if we can get it nailed down to something reasonable it's hard for BitMover the corporation to lose its mind and change things later, you can argue fair use or breach of promise or one of those lovely legal terms, I don't remember which covers this, but I know there is one. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 10:59 ` David S. Miller 2002-10-06 12:04 ` BK MetaData " Ingo Molnar @ 2002-10-06 12:10 ` Ingo Molnar 1 sibling, 0 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 12:10 UTC (permalink / raw) To: David S. Miller; +Cc: alan, lm, drepper, bcollins, torvalds, linux-kernel On Sun, 6 Oct 2002, David S. Miller wrote: > Larry has stated many times over that he doesn't own our bits. yes, but does Larry realize that BK creates a situation in where 'our bits' are separated into 'data' and 'metadata', in which currently only "BitMover, or any other operator of an Open Logging server" has a default permission to "republish the Metadata sent by the BitKeeper Software to the Open Logging server". i'd be happy if data and metadata could be considered one work, which is covered by the GPL as a whole - is it? Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 20:21 ` Ulrich Drepper 2002-10-05 23:28 ` Larry McVoy @ 2002-10-06 4:25 ` David S. Miller 2002-10-06 9:00 ` Jeff Garzik 2 siblings, 0 replies; 223+ messages in thread From: David S. Miller @ 2002-10-06 4:25 UTC (permalink / raw) To: drepper; +Cc: lm, bcollins, linux-kernel From: Ulrich Drepper <drepper@redhat.com> Date: Sat, 05 Oct 2002 13:21:45 -0700 You mentioned rsync to replicate the archive and then use CSSC. Would be fine with me. But: knowing how to set up rsync would probably require me to look at all the bk infrastructure and mechanisms more than I had to do in the whole time I was using bk the check out sources and while doing this I probably once again violate your license. Not true, you just take the entire tree (like a tarball) and then run SCCS get on it. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 20:21 ` Ulrich Drepper 2002-10-05 23:28 ` Larry McVoy 2002-10-06 4:25 ` David S. Miller @ 2002-10-06 9:00 ` Jeff Garzik 2 siblings, 0 replies; 223+ messages in thread From: Jeff Garzik @ 2002-10-06 9:00 UTC (permalink / raw) To: Ulrich Drepper; +Cc: Larry McVoy, linux-kernel Ulrich Drepper wrote: > That's not what I was talking about. It is not possible anymore to use > the same process we did. It is not possible anymore to react right away > on "Linus checked the patch in; try it.". Whatever. In the past, it was completely impossible, because Linus did not post his tree. You had to wait, sometimes several days, for a pre-patch in order to see a patch Linus "checked in." And even then, you were required to pick apart the prepatch to dig out the specific change(s) you are interested in. BK has actually made this _possible_, since you can now see (even without BK) Linus's tree as it gets updated throughout each day. Individual csets or full patches against point releases. This is a much more fine grain than in the past. > You mentioned rsync to replicate the archive and then use CSSC. Would > be fine with me. But: knowing how to set up rsync would probably > require me to look at all the bk infrastructure and mechanisms more than > I had to do in the whole time I was using bk the check out sources and > while doing this I probably once again violate your license. Instead of ranting, asking a simple question would have gotten you the simple answer (given by DaveM). Man, when you make an assumption, you go all out... I bet the Microsoft PR department could put your FUD skills to good use. Jeff ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:43 ` Larry McVoy 2002-10-05 19:51 ` Nicolas Pitre 2002-10-05 20:21 ` Ulrich Drepper @ 2002-10-06 3:35 ` Jan Harkes 2 siblings, 0 replies; 223+ messages in thread From: Jan Harkes @ 2002-10-06 3:35 UTC (permalink / raw) To: linux-kernel; +Cc: Larry McVoy, Ulrich Drepper, Ben Collins On Sat, Oct 05, 2002 at 12:43:21PM -0700, Larry McVoy wrote: > > patches in the kernel every day. Now this isn't possible anymore without > > Nonsense. There are all sorts of people who have taken the BK trees and > made the patch snapshots available on timely basis. Garzik's done it, > Woodhouse has done it, Rik has done it, I'm sure there are piles more. I promised myself to stay out of this one, but according to the wording of your license they all thereby losts their licenses because they 'developed a product which competes with the BK software' as the GNU patches they make available are clearly allowing others to make things accessible with competing products. And to automate it they must have developed some sort of script to pull the changesets out of the BK repository. Similarily any fs developer is creating something that can store multiple revisions of a source tree which, albeit inefficiently, has similar capabilities. And if someone uses a filesystem to store his development trees instead of BK, it is clearly a competing product. I do see your point and consider it valid, you have to make a living too, but I can also see how the wording of the license could be 'misinterpreted'. That 'reasonable opinion of BitMover' is somewhat of a safety net which probably would nullify the violations I mentioned above. Jan ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:24 ` Ulrich Drepper 2002-10-05 19:43 ` Larry McVoy @ 2002-10-05 19:47 ` Nicolas Pitre 2002-10-05 19:54 ` Larry McVoy 2002-10-06 0:34 ` Rik van Riel 2 siblings, 1 reply; 223+ messages in thread From: Nicolas Pitre @ 2002-10-05 19:47 UTC (permalink / raw) To: Ulrich Drepper; +Cc: Larry McVoy, lkml On Sat, 5 Oct 2002, Ulrich Drepper wrote: > I have never looked closer at bk than I had to be able to check out the > latest sources. I'm not doing any development with it and I'm not > checking in anything using bk. What about Larry making available a special version of BK that would only be able to perform checkouts? This special version could have a less controversial license, even be GPL with source. This only to provide a tool to extract data out of public BK repositories (like Linus' kernel repository) for people who don't intend or aren't willing to actually use the real value of the full fledged BK. Nicolas ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:47 ` Nicolas Pitre @ 2002-10-05 19:54 ` Larry McVoy 2002-10-05 19:56 ` Larry McVoy ` (2 more replies) 0 siblings, 3 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-05 19:54 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Ulrich Drepper, Larry McVoy, lkml On Sat, Oct 05, 2002 at 03:47:09PM -0400, Nicolas Pitre wrote: > On Sat, 5 Oct 2002, Ulrich Drepper wrote: > > > I have never looked closer at bk than I had to be able to check out the > > latest sources. I'm not doing any development with it and I'm not > > checking in anything using bk. > > What about Larry making available a special version of BK that would only be > able to perform checkouts? > > This special version could have a less controversial license, even be GPL > with source. This only to provide a tool to extract data out of public BK > repositories (like Linus' kernel repository) for people who don't intend or > aren't willing to actually use the real value of the full fledged BK. You can do this today. rsync a BK tree and use GNU CSSC to check out the sources. We maintained SCCS compat for exactly that reason. You've had the ability to ignore the BKL since day one if you aren't running the BK binaries. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:54 ` Larry McVoy @ 2002-10-05 19:56 ` Larry McVoy 2002-10-07 2:01 ` Ben Collins 2002-10-06 22:03 ` Aaron Lehmann 2002-10-06 23:15 ` Pavel Machek 2 siblings, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-05 19:56 UTC (permalink / raw) To: Nicolas Pitre, Ulrich Drepper, Larry McVoy, lkml On Sat, Oct 05, 2002 at 12:54:12PM -0700, Larry McVoy wrote: > On Sat, Oct 05, 2002 at 03:47:09PM -0400, Nicolas Pitre wrote: > > On Sat, 5 Oct 2002, Ulrich Drepper wrote: > > > > > I have never looked closer at bk than I had to be able to check out the > > > latest sources. I'm not doing any development with it and I'm not > > > checking in anything using bk. > > > > What about Larry making available a special version of BK that would only be > > able to perform checkouts? > > > > This special version could have a less controversial license, even be GPL > > with source. This only to provide a tool to extract data out of public BK > > repositories (like Linus' kernel repository) for people who don't intend or > > aren't willing to actually use the real value of the full fledged BK. > > You can do this today. rsync a BK tree and use GNU CSSC to check out > the sources. We maintained SCCS compat for exactly that reason. > You've had the ability to ignore the BKL since day one if you aren't > running the BK binaries. Whoops, forgot one thing. Take the GNU CSSC sources, they look for ^Ah%05u\n at the top of the file. Make them accept both "h" and "H" and then it will work. We changed it so that ATT SCCS would overwrite our metadata. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:56 ` Larry McVoy @ 2002-10-07 2:01 ` Ben Collins 2002-10-07 2:10 ` Rik van Riel 0 siblings, 1 reply; 223+ messages in thread From: Ben Collins @ 2002-10-07 2:01 UTC (permalink / raw) To: Nicolas Pitre, Ulrich Drepper, lkml > Whoops, forgot one thing. Take the GNU CSSC sources, they look for > > ^Ah%05u\n Here's a patch for those interested diff -urN CSSC-0.14alpha.pl0.orig/sccsfile.cc CSSC-0.14alpha.pl0/sccsfile.cc --- CSSC-0.14alpha.pl0.orig/sccsfile.cc 2002-03-24 19:07:09.000000000 -0500 +++ CSSC-0.14alpha.pl0/sccsfile.cc 2002-10-06 21:52:12.000000000 -0400 @@ -73,13 +73,17 @@ return NULL; } - if (getc(f_local) != '\001' || getc(f_local) != 'h') + if (getc(f_local) != '\001') { - (void)fclose(f_local); - s_corrupt_quit("%s: No SCCS-file magic number. " - "Did you specify the right file?", name); - /*NOTEACHED*/ - return NULL; + int tmp_c = getc(f_local); + if (tmp_c != 'h' && tmp_c != 'H') + { + (void)fclose(f_local); + s_corrupt_quit("%s: No SCCS-file magic number. " + "Did you specify the right file?", name); + /*NOTEACHED*/ + return NULL; + } } @@ -532,7 +536,7 @@ } int c = read_line(); - ASSERT(c == 'h'); + ASSERT(c == 'h' || c == 'H'); /* the checksum is represented in the file as decimal. */ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 2:01 ` Ben Collins @ 2002-10-07 2:10 ` Rik van Riel 2002-10-07 2:29 ` Larry McVoy 2002-10-10 3:48 ` rsync kernel tree " jw schultz 0 siblings, 2 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-07 2:10 UTC (permalink / raw) To: Ben Collins; +Cc: Nicolas Pitre, Ulrich Drepper, lkml On Sun, 6 Oct 2002, Ben Collins wrote: > > Whoops, forgot one thing. Take the GNU CSSC sources, they look for > > > > ^Ah%05u\n > > Here's a patch for those interested People can grab the repository for use with CSSC from: ftp://nl.linux.org/pub/linux/bk2patch/ Or using rsync: rsync -rav --delete nl.linux.org::kernel/linux-2.4 linux-2.4 rsync -rav --delete nl.linux.org::kernel/linux-2.5 linux-2.5 Currently these repositories are updated every two hours, but if there is a large demand I could update it every hour or even every 30 minutes. Don't feel ashamed to put the above rsyncs into your crontabs, grab the source and use it ;) have fun, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 2:10 ` Rik van Riel @ 2002-10-07 2:29 ` Larry McVoy 2002-10-07 2:38 ` Rik van Riel 2002-10-10 3:48 ` rsync kernel tree " jw schultz 1 sibling, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-07 2:29 UTC (permalink / raw) To: Rik van Riel; +Cc: Ben Collins, Nicolas Pitre, Ulrich Drepper, lkml > People can grab the repository for use with CSSC from: > > ftp://nl.linux.org/pub/linux/bk2patch/ Make sure you do a bk -r admin -Znone on that tree. We support gzipped repos, SCCS/CSSC don't. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 2:29 ` Larry McVoy @ 2002-10-07 2:38 ` Rik van Riel 2002-10-07 3:07 ` Rik van Riel 0 siblings, 1 reply; 223+ messages in thread From: Rik van Riel @ 2002-10-07 2:38 UTC (permalink / raw) To: Larry McVoy; +Cc: Ben Collins, Nicolas Pitre, Ulrich Drepper, lkml On Sun, 6 Oct 2002, Larry McVoy wrote: > > People can grab the repository for use with CSSC from: > > > > ftp://nl.linux.org/pub/linux/bk2patch/ > > Make sure you do a > bk -r admin -Znone > on that tree. We support gzipped repos, SCCS/CSSC don't. Thanks for the advise, I'm running this command right now. Does this need to be run every time I pull changes into the tree or is it enough that I run it once ? Now, with any vendor locking arguments out of the way the various source control systems should be able to compete on a level ground. If you (for random values of 'you') want to put the Linux kernel source in another source control system and/or you develop another source control system, you won't need bitkeeper in order to do so ... I won't be holding my breath for a better tool than bitkeeper, though ... it'll probably be quite a while for the other source control tools to come close to the functionality I'm using on a daily basis ;) regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 2:38 ` Rik van Riel @ 2002-10-07 3:07 ` Rik van Riel 0 siblings, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-07 3:07 UTC (permalink / raw) To: Larry McVoy; +Cc: Ben Collins, Nicolas Pitre, Ulrich Drepper, lkml On Sun, 6 Oct 2002, Rik van Riel wrote: > On Sun, 6 Oct 2002, Larry McVoy wrote: > > > > ftp://nl.linux.org/pub/linux/bk2patch/ > > > > Make sure you do a > > bk -r admin -Znone > > on that tree. We support gzipped repos, SCCS/CSSC don't. > > Thanks for the advise, I'm running this command right now. If you worried why your rsync session just died ... I killed it after finishing uncompressing the repositories. From now on you'll get an uncompressed repository that SCCS/CSSC can handle. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: rsync kernel tree Re: New BK License Problem? 2002-10-07 2:10 ` Rik van Riel 2002-10-07 2:29 ` Larry McVoy @ 2002-10-10 3:48 ` jw schultz 1 sibling, 0 replies; 223+ messages in thread From: jw schultz @ 2002-10-10 3:48 UTC (permalink / raw) To: lkml On Sun, Oct 06, 2002 at 11:10:48PM -0300, Rik van Riel wrote: > People can grab the repository for use with CSSC from: > > ftp://nl.linux.org/pub/linux/bk2patch/ > > Or using rsync: > rsync -rav --delete nl.linux.org::kernel/linux-2.4 linux-2.4 > rsync -rav --delete nl.linux.org::kernel/linux-2.5 linux-2.5 > > Currently these repositories are updated every two hours, but if > there is a large demand I could update it every hour or even every > 30 minutes. Don't feel ashamed to put the above rsyncs into your > crontabs, grab the source and use it ;) > > have fun, I just might. Although a straight tree (instead of repository) would suit me better. Like many i haven't been folowing the BK license thread. I only found out about this message because of a kernel trap headline. Rik you might get a better exposure if you announced this outside of the BK license thread. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:54 ` Larry McVoy 2002-10-05 19:56 ` Larry McVoy @ 2002-10-06 22:03 ` Aaron Lehmann 2002-10-06 22:33 ` Rik van Riel 2002-10-06 23:15 ` Pavel Machek 2 siblings, 1 reply; 223+ messages in thread From: Aaron Lehmann @ 2002-10-06 22:03 UTC (permalink / raw) To: Larry McVoy, Nicolas Pitre, Ulrich Drepper, Larry McVoy, lkml On Sat, Oct 05, 2002 at 12:54:12PM -0700, Larry McVoy wrote: > You can do this today. rsync a BK tree and use GNU CSSC to check out > the sources. We maintained SCCS compat for exactly that reason. > You've had the ability to ignore the BKL since day one if you aren't > running the BK binaries. Sounds great, but where can I rsync a linux bk tree from? ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 22:03 ` Aaron Lehmann @ 2002-10-06 22:33 ` Rik van Riel 2002-10-06 22:45 ` Aaron Lehmann 0 siblings, 1 reply; 223+ messages in thread From: Rik van Riel @ 2002-10-06 22:33 UTC (permalink / raw) To: Aaron Lehmann Cc: Larry McVoy, Nicolas Pitre, Ulrich Drepper, Larry McVoy, lkml On Sun, 6 Oct 2002, Aaron Lehmann wrote: > On Sat, Oct 05, 2002 at 12:54:12PM -0700, Larry McVoy wrote: > > You can do this today. rsync a BK tree and use GNU CSSC to check out > > the sources. We maintained SCCS compat for exactly that reason. > > You've had the ability to ignore the BKL since day one if you aren't > > running the BK binaries. > > Sounds great, but where can I rsync a linux bk tree from? I just started exporting this on nl.linux.org, see ftp://nl.linux.org/pub/linux/bk2patch/README The following command should work: rsync -rav --delete nl.linux.org::kernel/linux-2.4 linux-2.4 regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 22:33 ` Rik van Riel @ 2002-10-06 22:45 ` Aaron Lehmann 2002-10-06 22:59 ` Rik van Riel 0 siblings, 1 reply; 223+ messages in thread From: Aaron Lehmann @ 2002-10-06 22:45 UTC (permalink / raw) To: Rik van Riel; +Cc: lkml On Sun, Oct 06, 2002 at 07:33:55PM -0300, Rik van Riel wrote: > The following command should work: > > rsync -rav --delete nl.linux.org::kernel/linux-2.4 linux-2.4 Thanks. Note that -a implies -r. You also might want -z in there depending how your availability of bandwidth and CPU cycles compare. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 22:45 ` Aaron Lehmann @ 2002-10-06 22:59 ` Rik van Riel 0 siblings, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-06 22:59 UTC (permalink / raw) To: Aaron Lehmann; +Cc: lkml On Sun, 6 Oct 2002, Aaron Lehmann wrote: > On Sun, Oct 06, 2002 at 07:33:55PM -0300, Rik van Riel wrote: > > The following command should work: > > > > rsync -rav --delete nl.linux.org::kernel/linux-2.4 linux-2.4 > > Note that -a implies -r. You also might want -z in there depending how > your availability of bandwidth and CPU cycles compare. The way things are now, nl.linux.org has more bandwidth than CPU. Using -z is a good idea though, if you've got more CPU than bandwith. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:54 ` Larry McVoy 2002-10-05 19:56 ` Larry McVoy 2002-10-06 22:03 ` Aaron Lehmann @ 2002-10-06 23:15 ` Pavel Machek 2002-10-07 19:06 ` Nicolas Pitre 2 siblings, 1 reply; 223+ messages in thread From: Pavel Machek @ 2002-10-06 23:15 UTC (permalink / raw) To: Nicolas Pitre, Ulrich Drepper, Larry McVoy, lkml Hi! > > > I have never looked closer at bk than I had to be able to check out the > > > latest sources. I'm not doing any development with it and I'm not > > > checking in anything using bk. > > > > What about Larry making available a special version of BK that would only be > > able to perform checkouts? > > > > This special version could have a less controversial license, even be GPL > > with source. This only to provide a tool to extract data out of public BK > > repositories (like Linus' kernel repository) for people who don't intend or > > aren't willing to actually use the real value of the full fledged BK. > > You can do this today. rsync a BK tree and use GNU CSSC to check out > the sources. We maintained SCCS compat for exactly that reason. > You've had the ability to ignore the BKL since day one if you aren't > running the BK binaries. Would someone write nice HOWTO do this? And where's guarantee that you are not migrating BK to proprietary format to cut this off once someone writes the HOWTO? Pavel -- When do you have heart between your knees? ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 23:15 ` Pavel Machek @ 2002-10-07 19:06 ` Nicolas Pitre 2002-10-07 20:19 ` Alan Cox 0 siblings, 1 reply; 223+ messages in thread From: Nicolas Pitre @ 2002-10-07 19:06 UTC (permalink / raw) To: Pavel Machek; +Cc: Ulrich Drepper, Larry McVoy, lkml On Mon, 7 Oct 2002, Pavel Machek wrote: > > You can do this today. rsync a BK tree and use GNU CSSC to check out > > the sources. We maintained SCCS compat for exactly that reason. > > You've had the ability to ignore the BKL since day one if you aren't > > running the BK binaries. > > Would someone write nice HOWTO do this? > > And where's guarantee that you are not migrating BK to proprietary > format to cut this off once someone writes the HOWTO? Please stop the paranoia and have faith. Where's guarantee you won't be hit by a bus today? If BK migrates to proprietary format everybody will notice and you'll still have the opportunity to rescue a not too old repository and carry on with life using whatever alternate SCM you wish. If such a thing happened Lary would be publicly and universally discredited and he's not looking for that I'm sure. Nicolas ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 19:06 ` Nicolas Pitre @ 2002-10-07 20:19 ` Alan Cox 2002-10-07 20:24 ` Nicolas Pitre 0 siblings, 1 reply; 223+ messages in thread From: Alan Cox @ 2002-10-07 20:19 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Pavel Machek, Ulrich Drepper, Larry McVoy, lkml On Mon, 2002-10-07 at 20:06, Nicolas Pitre wrote: > If BK migrates to proprietary format everybody will notice and you'll still > have the opportunity to rescue a not too old repository and carry on with > life using whatever alternate SCM you wish. If such a thing happened Lary > would be publicly and universally discredited and he's not looking for that > I'm sure. If BK migrates to a proprietary format the code won't be in the preferred form of the work for making modifications. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 20:19 ` Alan Cox @ 2002-10-07 20:24 ` Nicolas Pitre 2002-10-07 20:37 ` Pavel Machek 0 siblings, 1 reply; 223+ messages in thread From: Nicolas Pitre @ 2002-10-07 20:24 UTC (permalink / raw) To: Alan Cox; +Cc: Pavel Machek, Ulrich Drepper, Larry McVoy, lkml On 7 Oct 2002, Alan Cox wrote: > On Mon, 2002-10-07 at 20:06, Nicolas Pitre wrote: > > If BK migrates to proprietary format everybody will notice and you'll still > > have the opportunity to rescue a not too old repository and carry on with > > life using whatever alternate SCM you wish. If such a thing happened Lary > > would be publicly and universally discredited and he's not looking for that > > I'm sure. > > If BK migrates to a proprietary format the code won't be in the > preferred form of the work for making modifications. Because you think BK will still have the backing of all kernel developers using it today if that happens? Some might find BK's nice to use despite its license, but locking the main kernel repository into a proprietary format is totally unacceptable for most if not all of them I'm sure. That's why Larry won't go that route or he'll lose the Linux kernel user base right away. Nicolas ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 20:24 ` Nicolas Pitre @ 2002-10-07 20:37 ` Pavel Machek 2002-10-07 20:54 ` Nicolas Pitre 0 siblings, 1 reply; 223+ messages in thread From: Pavel Machek @ 2002-10-07 20:37 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Alan Cox, Ulrich Drepper, Larry McVoy, lkml Hi! > > > If BK migrates to proprietary format everybody will notice and you'll still > > > have the opportunity to rescue a not too old repository and carry on with > > > life using whatever alternate SCM you wish. If such a thing happened Lary > > > would be publicly and universally discredited and he's not looking for that > > > I'm sure. > > > > If BK migrates to a proprietary format the code won't be in the > > preferred form of the work for making modifications. > > Because you think BK will still have the backing of all kernel developers > using it today if that happens? Some might find BK's nice to use despite its > license, but locking the main kernel repository into a proprietary format is > totally unacceptable for most if not all of them I'm sure. Of course Larry would have to do the changes "slowly" so people would not notice. And every time someone complains he can repeat his "I'm running business". Pavel -- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 20:37 ` Pavel Machek @ 2002-10-07 20:54 ` Nicolas Pitre 2002-10-07 21:10 ` Pavel Machek 2002-10-08 1:05 ` Mark Mielke 0 siblings, 2 replies; 223+ messages in thread From: Nicolas Pitre @ 2002-10-07 20:54 UTC (permalink / raw) To: Pavel Machek; +Cc: Alan Cox, Ulrich Drepper, Larry McVoy, lkml On Mon, 7 Oct 2002, Pavel Machek wrote: > Hi! > > > > > > If BK migrates to proprietary format everybody will notice and you'll still > > > > have the opportunity to rescue a not too old repository and carry on with > > > > life using whatever alternate SCM you wish. If such a thing happened Lary > > > > would be publicly and universally discredited and he's not looking for that > > > > I'm sure. > > > > > > If BK migrates to a proprietary format the code won't be in the > > > preferred form of the work for making modifications. > > > > Because you think BK will still have the backing of all kernel developers > > using it today if that happens? Some might find BK's nice to use despite its > > license, but locking the main kernel repository into a proprietary format is > > totally unacceptable for most if not all of them I'm sure. > > Of course Larry would have to do the changes "slowly" so people would > not notice. And every time someone complains he can repeat his "I'm > running business". At which point he'll piss of more and more kernel developers and lose them "slowly" as well, unless Linus himself gets pissed at which point the kernel user base will disappear in a single glitch. Breaking SCCS compatibility "slowly" without anybody noticing before it's too late is a bit far fetched IMHO. Anyway this whole story boils down to the New Conspiracy Theory: "The world wants to screw Larry vs Larry wants to screw the world" Nicolas ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 20:54 ` Nicolas Pitre @ 2002-10-07 21:10 ` Pavel Machek 2002-10-08 9:11 ` Vojtech Pavlik 2002-10-08 1:05 ` Mark Mielke 1 sibling, 1 reply; 223+ messages in thread From: Pavel Machek @ 2002-10-07 21:10 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Alan Cox, Ulrich Drepper, Larry McVoy, lkml Hi! > At which point he'll piss of more and more kernel developers and lose them > "slowly" as well, unless Linus himself gets pissed at which point the kernel > user base will disappear in a single glitch. Breaking SCCS compatibility > "slowly" without anybody noticing before it's too late is a bit far fetched > IMHO. I hope you are right. > Anyway this whole story boils down to the New Conspiracy Theory: > > "The world wants to screw Larry vs Larry wants to screw the > world" :-) Pavel -- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 21:10 ` Pavel Machek @ 2002-10-08 9:11 ` Vojtech Pavlik 0 siblings, 0 replies; 223+ messages in thread From: Vojtech Pavlik @ 2002-10-08 9:11 UTC (permalink / raw) To: Pavel Machek; +Cc: Nicolas Pitre, Alan Cox, Ulrich Drepper, Larry McVoy, lkml On Mon, Oct 07, 2002 at 11:10:09PM +0200, Pavel Machek wrote: > Hi! > > > At which point he'll piss of more and more kernel developers and lose them > > "slowly" as well, unless Linus himself gets pissed at which point the kernel > > user base will disappear in a single glitch. Breaking SCCS compatibility > > "slowly" without anybody noticing before it's too late is a bit far fetched > > IMHO. > > I hope you are right. He is, I use the SCCS functionality regularly, because patch(1) knows SCCS and can get the files right from the repository without the need to check them out using BK. If that stopped working, I'd notice immediately. -- Vojtech Pavlik SuSE Labs ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 20:54 ` Nicolas Pitre 2002-10-07 21:10 ` Pavel Machek @ 2002-10-08 1:05 ` Mark Mielke 1 sibling, 0 replies; 223+ messages in thread From: Mark Mielke @ 2002-10-08 1:05 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Pavel Machek, Alan Cox, Ulrich Drepper, Larry McVoy, lkml On Mon, Oct 07, 2002 at 04:54:47PM -0400, Nicolas Pitre wrote: > On Mon, 7 Oct 2002, Pavel Machek wrote: > > Of course Larry would have to do the changes "slowly" so people would > > not notice. And every time someone complains he can repeat his "I'm > > running business". > At which point he'll piss of more and more kernel developers and lose them > "slowly" as well, unless Linus himself gets pissed at which point the kernel > user base will disappear in a single glitch. Breaking SCCS compatibility > "slowly" without anybody noticing before it's too late is a bit far fetched > IMHO. Also, I think Larry would find it difficult to 'slowly' break SCCS compatibility. It either works, or it doesn't. As somebody in a similar field, I find it odd that Larry bothered to keep SCCS compatibility in the first place. If anything, it holds him back for only questionable gain. It would not be unreasonable for Larry to license an extractor utility under looser restrictions than BK. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:24 ` Ulrich Drepper 2002-10-05 19:43 ` Larry McVoy 2002-10-05 19:47 ` Nicolas Pitre @ 2002-10-06 0:34 ` Rik van Riel 2002-10-06 0:45 ` Larry McVoy 2 siblings, 1 reply; 223+ messages in thread From: Rik van Riel @ 2002-10-06 0:34 UTC (permalink / raw) To: Ulrich Drepper; +Cc: Ben Collins, linux-kernel, Larry McVoy On Sat, 5 Oct 2002, Ulrich Drepper wrote: > a) me finding another route to get the latest kernel in realtime ftp://nl.linux.org/pub/linux/bk2patch/ > (which still could be considered illegal since somebody else, for the > expressed purpose of making the result available to me, is using bk); Good question, does Larry have any objections to people exporting stuff from bitkeeper as patches and making those patches available for download ? ;) I'm pretty sure he doesn't, since Linus and Marcelo are doing exactly this. > b) the kernel developers I work with not depending on bk anymore. > > The second point is what is causing the trouble. Any team which wants > to use bk to synchronize the work is tainted by one single individual > being tainted. I haven't found this to be any problem at all with -rmap, I happily accept patches from both bitkeeper users and non-users. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 0:34 ` Rik van Riel @ 2002-10-06 0:45 ` Larry McVoy 0 siblings, 0 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-06 0:45 UTC (permalink / raw) To: Rik van Riel; +Cc: Ulrich Drepper, Ben Collins, linux-kernel, Larry McVoy > Good question, does Larry have any objections to people > exporting stuff from bitkeeper as patches and making those > patches available for download ? ;) > > I'm pretty sure he doesn't, since Linus and Marcelo are > doing exactly this. Right. I'd make a fuss if it were someone who was also working on Subversion, yeah, for the obvious reasons. That's why that clause is in there. On the other hand, if Ben was ftping all the csets from your machine and shoving them into Subversion there isn't a darn thing I can do about it, it's not my data. So you're fine. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 18:41 ` Lars Marowsky-Bree 2002-10-05 19:06 ` Ben Collins @ 2002-10-05 19:15 ` Larry McVoy 2002-10-05 19:46 ` jbradford 2002-10-06 22:18 ` Daniel Phillips 1 sibling, 2 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-05 19:15 UTC (permalink / raw) To: Lars Marowsky-Bree; +Cc: linux-kernel > I'd suggest that you need to have an interoperability clause for Open Source > software. Otherwise using BK for kernel development suddenly seems like a very > bad idea, because the community has suddenly been locked out of developing a > free SCM (ie, working on CVS, Subversion etc); he couldn't be an effective > kernel developer today (ie, using BK) and also continue working on the other > open source project... > > You know I am rather fond of BK and your goals in general, but that would just > suck. BitKeeper is a *business*. What you are saying is "it would suck if you wouldn't allow the use of BitKeeper in the development of products which would make that business die." It may suck that Ben can't use BK to try and put BK out of business. It would suck a whole lot worse, in our view, to allow him to do so. I'm sympathetic to the fact that this means that people who are both working on the kernel and competing with us can't use BK, that does suck. But we thought of that, that's why BK is so friendly to external systems, it's why BK is happy to both import and export regular patches. If you think about it, Ben is absolutely no worse off than he was before BK was used. He can get the same patches he always got. He can work the same way he always did. The only thing that has changed from Ben's point of view is that Linus is a little less stressed out and somewhat less likely to drop a patch. It's a net positive for Ben. Not as big of one as being able to use BK, perhaps, but it hasn't hurt Ben's ability to contribute to the kernel one iota. It's Ben's choice to compete with us. Yes, we're forcing you to choose between competing with us or using BK as a way of contributing to the kernel. I could see that that would suck if Linus refused to take regular patches, or even if he slowed down on taking regular patches. But he doesn't, he hasn't, he's actually sped up. And he's committed to taking regular patches, there are people out there who oppose the BKL on grounds that they want a completely free tool chain. Both Linus and I respect that, take a look at bk-3.0 when it comes out, it's got much improved (both performance and reliability) GNU patch import abilities. We've spent money to support people who don't want to use BK, it's not just lip service. I'm not against people having a go at reimplementing BK. But you had better believe that I'm against helping them, they are actively trying to destroy our company. No company is under any obligation, moral, ethical, or legal, to be self destructive when they are doing nothing wrong. What you are saying is that it sucks that we don't want to help put ourselves out of business. If that sucks, so be it. I think some people here are under the mistaken impression that BK is my hobby sort of like LMbench was my hobby. It's not a hobby. It's a business. It would take medium sized bus to hold all the people who depend on BK for their livelihood. What you are asking for is for us to allow and aid in work which would materially damage our business. That's nuts, it's absolutely out of the question, it's way past the point of being a reasonable thing to expect. If you can't see that, I'm sorry, but that's the way it is. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:15 ` Larry McVoy @ 2002-10-05 19:46 ` jbradford 2002-10-06 22:18 ` Daniel Phillips 1 sibling, 0 replies; 223+ messages in thread From: jbradford @ 2002-10-05 19:46 UTC (permalink / raw) To: Larry McVoy; +Cc: lmb, linux-kernel, bcollins, reiser, wa1ter > The only thing that has changed from Ben's point of view is that Linus > is a little less stressed out and somewhat less likely to drop a patch. #if defined(sense_of_humor) Plus the fact that his inbox is probably overflowing because of this thread ;-). Sorry, I couldn't resist that one :-). #endif John. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 19:15 ` Larry McVoy 2002-10-05 19:46 ` jbradford @ 2002-10-06 22:18 ` Daniel Phillips 2002-10-06 23:54 ` Jeff Dike 1 sibling, 1 reply; 223+ messages in thread From: Daniel Phillips @ 2002-10-06 22:18 UTC (permalink / raw) To: Larry McVoy; +Cc: linux-kernel On Saturday 05 October 2002 21:15, Larry McVoy wrote: > there are people out there who oppose the BKL on grounds that they > want a completely free tool chain. Both Linus and I respect that, Linus has indeed shown respect, but you have not, quite the contrary. -- Daniel ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 22:18 ` Daniel Phillips @ 2002-10-06 23:54 ` Jeff Dike 2002-10-06 22:57 ` Rik van Riel 2002-10-06 22:57 ` Daniel Phillips 0 siblings, 2 replies; 223+ messages in thread From: Jeff Dike @ 2002-10-06 23:54 UTC (permalink / raw) To: Daniel Phillips; +Cc: Larry McVoy, linux-kernel phillips@arcor.de said: > Linus has indeed shown respect, but you have not, quite the contrary. Don't you have anything better to do than to take useless, content-free potshots at things you don't like? Surely, there's some code that needs writing. Jeff ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 23:54 ` Jeff Dike @ 2002-10-06 22:57 ` Rik van Riel 2002-10-06 22:57 ` Daniel Phillips 1 sibling, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-06 22:57 UTC (permalink / raw) To: Jeff Dike; +Cc: Daniel Phillips, Larry McVoy, linux-kernel On Sun, 6 Oct 2002, Jeff Dike wrote: > phillips@arcor.de said: > > Linus has indeed shown respect, but you have not, quite the contrary. > > Don't you have anything better to do than to take useless, content-free > potshots at things you don't like? <obligatory explanation of "ad-hominem" here> <retort> <counter retort> <hitler or immoral equivalent> <godwin, I win!> (there, some bandwidth saved already) > Surely, there's some code that needs writing. Shhhh, if he hears he might attack us for not having written the code he's been wanting for weeks now ;) cheers, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 23:54 ` Jeff Dike 2002-10-06 22:57 ` Rik van Riel @ 2002-10-06 22:57 ` Daniel Phillips 1 sibling, 0 replies; 223+ messages in thread From: Daniel Phillips @ 2002-10-06 22:57 UTC (permalink / raw) To: Jeff Dike; +Cc: Larry McVoy, linux-kernel On Monday 07 October 2002 01:54, Jeff Dike wrote: > phillips@arcor.de said: > > Linus has indeed shown respect, but you have not, quite the contrary. > > Don't you have anything better to do than to take useless, content-free > potshots at things you don't like? The issue of respect is far from content-free. -- Daniel ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 18:25 ` Larry McVoy 2002-10-05 18:35 ` Ben Collins 2002-10-05 18:41 ` Lars Marowsky-Bree @ 2002-10-06 13:46 ` Ingo Molnar 2002-10-06 13:59 ` Ingo Molnar ` (2 more replies) 2002-10-06 22:11 ` BK is *evil* corporate software [was Re: New BK License Problem?] Pavel Machek 3 siblings, 3 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 13:46 UTC (permalink / raw) To: David S. Miller; +Cc: Larry McVoy, Linus Torvalds, Alan Cox, linux-kernel On Fri, 4 Oct 2002, Larry McVoy wrote: > The clause is specifically designed to target those companies which > produce or sell commercial SCM systems. [...] The open source developers > have nothing to worry about. and: On Sat, 5 Oct 2002, Larry McVoy wrote: > > Larry, I develop for the Subversion project. Does that mean my license > > to use bitkeeper is revoked? > > Yes. It has been since we shipped that license or when you started > working on Subversion, whichever came last. this kind of sudden change in Larry's written opinion within 24 hours is that makes this whole issue dangerous. Fact is that Larry is free to license his product under fair or unfair terms - it's his. While we already gave BK/BM tons of feedback, free beta-testing and free publicity, all we have is this volatile promise that the binary bits of BK are going to remain licensed - and with every day it will be harder and harder to move the repository. what happens if Linux merges some sort of kernel based versioned filesystem, eg. something similar to what ClearCase does today? Will the license suddenly change to 'as long as you do not work on the versioned-FS kernel subsystem'? Or isnt this already a violation of the current license? this is why i'd rather want to have an iron-clad legal way out first, and not have to rely on nonbinding promises done on public lists. I'm sure Larry understands this position, he has exactly the same position when trying to protect his business against hordes of freebies. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 13:46 ` Ingo Molnar @ 2002-10-06 13:59 ` Ingo Molnar 2002-10-06 14:56 ` Larry McVoy 2002-10-06 13:59 ` Ben Collins 2002-10-06 14:53 ` Larry McVoy 2 siblings, 1 reply; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 13:59 UTC (permalink / raw) To: Larry McVoy; +Cc: David S. Miller, Linus Torvalds, Alan Cox, linux-kernel Larry, a simple question: does the BK license allow the Rational kernel developers to use BK (to eg. check out Linus' tree) when working on kernel support for ClearCase? ie. is all kernel development activity against your license as long as the activity is a competitor of yours? perhaps you should restrict the BK license's wording to closed-source 'competitors' only - after all your own explanation in: bk help openlogging says that for version-control software there exists no sustainable open-source based business-model, so they cannot be any viable competitors of yours. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 13:59 ` Ingo Molnar @ 2002-10-06 14:56 ` Larry McVoy 2002-10-06 15:22 ` Ingo Molnar 0 siblings, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-06 14:56 UTC (permalink / raw) To: Ingo Molnar Cc: Larry McVoy, David S. Miller, Linus Torvalds, Alan Cox, linux-kernel On Sun, Oct 06, 2002 at 03:59:33PM +0200, Ingo Molnar wrote: > a simple question: does the BK license allow the Rational kernel > developers to use BK (to eg. check out Linus' tree) when working on kernel > support for ClearCase? I think the license is clear on that point. > perhaps you should restrict the BK license's wording to closed-source > 'competitors' only And how would that solve the problem posed in your first question? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 14:56 ` Larry McVoy @ 2002-10-06 15:22 ` Ingo Molnar 2002-10-06 15:15 ` Larry McVoy ` (2 more replies) 0 siblings, 3 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 15:22 UTC (permalink / raw) To: Larry McVoy; +Cc: David S. Miller, Linus Torvalds, Alan Cox, linux-kernel On Sun, 6 Oct 2002, Larry McVoy wrote: > > a simple question: does the BK license allow the Rational kernel > > developers to use BK (to eg. check out Linus' tree) when working on kernel > > support for ClearCase? > > I think the license is clear on that point. so BK cannot be used to access the kernel tree in that case, correct? I'm just wondering where the boundary line is. Eg. if i started working on a versioned filesystem today, i'd not be allowed to use BK. I just have to keep stuff like that in mind when using BK. > > perhaps you should restrict the BK license's wording to closed-source > > 'competitors' only > > And how would that solve the problem posed in your first question? in no way - but it would be a (small) incentive for them to open-source their kernel mods. Which would also enable you to use the technology. Ie. potentially good for you. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 15:22 ` Ingo Molnar @ 2002-10-06 15:15 ` Larry McVoy 2002-10-06 15:39 ` Alexandre Dulaunoy 2002-10-07 1:21 ` Rob Landley 2002-10-06 16:30 ` Werner Almesberger 2002-10-06 21:31 ` Miquel van Smoorenburg 2 siblings, 2 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-06 15:15 UTC (permalink / raw) To: Ingo Molnar Cc: Larry McVoy, David S. Miller, Linus Torvalds, Alan Cox, linux-kernel On Sun, Oct 06, 2002 at 05:22:33PM +0200, Ingo Molnar wrote: > in no way - but it would be a (small) incentive for them to open-source > their kernel mods. Which would also enable you to use the technology. Ie. > potentially good for you. We're not interested in ClearCase technology, no company makes advances by trying to chase the leader. You lead by leading, not catching up. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 15:15 ` Larry McVoy @ 2002-10-06 15:39 ` Alexandre Dulaunoy 2002-10-07 1:21 ` Rob Landley 1 sibling, 0 replies; 223+ messages in thread From: Alexandre Dulaunoy @ 2002-10-06 15:39 UTC (permalink / raw) To: Larry McVoy Cc: Ingo Molnar, David S. Miller, Linus Torvalds, Alan Cox, linux-kernel On Sun, 6 Oct 2002, Larry McVoy wrote: > On Sun, Oct 06, 2002 at 05:22:33PM +0200, Ingo Molnar wrote: > > in no way - but it would be a (small) incentive for them to open-source > > their kernel mods. Which would also enable you to use the technology. Ie. > > potentially good for you. > > We're not interested in ClearCase technology, no company makes advances by > trying to chase the leader. You lead by leading, not catching up. > You cut off this part from Ingo Molnar : > so BK cannot be used to access the kernel tree in that case, correct? > I'm just wondering where the boundary line is. Eg. if i started > working on a versioned filesystem today, i'd not be allowed to use > BK. I just have to keep stuff like that in mind when using BK. Is it true ? The legal issue around is quite difficult to calculate and generate a classical problem of exclusion around the four freedoms of Free Software. (and so the GNU General Public License) In that case, your proprietary software cannot be used to produce Free Software licensed under the GNU General Public License. As in #6: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." If the case explained by Ingo Molnar, you are adding further restrictions. (in the case of the Linux Kernel, they are contributors (so also recipients of the rights of the GNU GPL) using your proprietary software license to produce Free Software licensed under GNU GPL) If this is correct, this is an important issue. Maybe we should forward the issue to the FSF for clarification ? Thanks. adulau -- Alexandre Dulaunoy 3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD --- AD993-6BONE "People who fight may lose.People who do not fight have already lost." Bertolt Brecht ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 15:15 ` Larry McVoy 2002-10-06 15:39 ` Alexandre Dulaunoy @ 2002-10-07 1:21 ` Rob Landley 2002-10-07 6:29 ` Larry McVoy 2002-10-07 15:43 ` Jan Harkes 1 sibling, 2 replies; 223+ messages in thread From: Rob Landley @ 2002-10-07 1:21 UTC (permalink / raw) To: Larry McVoy, Ingo Molnar Cc: Larry McVoy, David S. Miller, Linus Torvalds, Alan Cox, linux-kernel It's Interesting what question Larry is going out of his way NOT to answer. Ingo asked: > what happens if Linux merges some sort of kernel based versioned > filesystem, eg. something similar to what ClearCase does today? Larry responded, unhelpefully: > I think the license is clear on that point. So why did Ingo ask the question? Oh well. Ingo again: > so BK cannot be used to access the kernel tree in that case, correct? I'm > just wondering where the boundary line is. Eg. if i started working on a > versioned filesystem today, i'd not be allowed to use BK. I just have to > keep stuff like that in mind when using BK. Larry responded again, but again ducked the question, choosing insead to talk about ClearCase. It seems pretty clear that the people who object to BitKeeper have an easy way to force it out out of Kernel developent: You don't have to reproduce bitkeeper, just write a version controlled filesystem (or version control extension to an existing filesystem) that Linus likes enough to include in the tree. (EVMS probably doesn't qualify as such, but I'm sure Larry could make a case it does if he really wanted to. So nobody really has a license to use no-charge bitkeeper, they really just have permission as long as Larry's in a good mood. But this is nothing new, is it?) It's possible that a version controlled filesystem will never be accepted into the Linux tree just because Linus wouldn't want to give up bitkeeper. Oh well. Can't say I've ever personally had a need for one, and you could always do it via Coda, assuming the existince of such a tool wouldn't taint the Coda parts of the kernel... :) Rob ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 1:21 ` Rob Landley @ 2002-10-07 6:29 ` Larry McVoy 2002-10-07 2:27 ` Rob Landley 2002-10-07 15:43 ` Jan Harkes 1 sibling, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-07 6:29 UTC (permalink / raw) To: Rob Landley Cc: Larry McVoy, Ingo Molnar, David S. Miller, Linus Torvalds, Alan Cox, linux-kernel > to use no-charge bitkeeper, they really just have permission as long as > Larry's in a good mood. But this is nothing new, is it?) You're right, I'm completely arbitrary and you are putting me in a bad mood. Shame on you for putting the entire free world in jeopardy. How dare you! What is with you anyway? Do you have nothing better to do than try and yank my chain and cause trouble? Sorry, not gonna bite, I've done enough stupid things in the last few days, don't need one more. Try again though, I'm probably gullible enough you can get me next time. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 6:29 ` Larry McVoy @ 2002-10-07 2:27 ` Rob Landley 0 siblings, 0 replies; 223+ messages in thread From: Rob Landley @ 2002-10-07 2:27 UTC (permalink / raw) To: Larry McVoy; +Cc: linux-kernel On Monday 07 October 2002 02:29 am, Larry McVoy wrote: > > to use no-charge bitkeeper, they really just have permission as long as > > Larry's in a good mood. But this is nothing new, is it?) > > You're right, I'm completely arbitrary and you are putting me in a bad > mood. Shame on you for putting the entire free world in jeopardy. How dare > you! Actually, I was just hoping to prod you into answering Ingo's question... :) > Try again though, I'm probably gullible enough you can get me next time. Nah, too much traffic on the topic already. Rob ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 1:21 ` Rob Landley 2002-10-07 6:29 ` Larry McVoy @ 2002-10-07 15:43 ` Jan Harkes 2002-10-07 16:06 ` Rik van Riel 1 sibling, 1 reply; 223+ messages in thread From: Jan Harkes @ 2002-10-07 15:43 UTC (permalink / raw) To: Rob Landley; +Cc: linux-kernel On Sun, Oct 06, 2002 at 09:21:19PM -0400, Rob Landley wrote: > It's possible that a version controlled filesystem will never be accepted > into the Linux tree just because Linus wouldn't want to give up bitkeeper. > Oh well. Can't say I've ever personally had a need for one, and you could > always do it via Coda, assuming the existince of such a tool wouldn't taint > the Coda parts of the kernel... :) Somebody already did, there is a backend somewhere that accesses RCS archives as files through the Coda kernel module. Besides Coda clients and servers have 'versioning' to detect conflicts, and have a convenient 'OldFiles' directory with the backup volume with yesterday's files. By increasing the backup interval that could f.i. be the files you had an hour ago. The only reason why I think this doesn't affect the license is because these solutions are not 'competing' with BK (yet) so they don't trigger the "don't piss off Larry" clause... I'm expecting that all the BK->gnu patch gateways will be shut down in about 5 years, which should be around the time that other systems (perhaps subversion) come in the 'competing with BK' stage. Because at that point they are aiding in the wider deployment and development of the competing version control system. Jan ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 15:43 ` Jan Harkes @ 2002-10-07 16:06 ` Rik van Riel 2002-10-07 16:18 ` Larry McVoy 0 siblings, 1 reply; 223+ messages in thread From: Rik van Riel @ 2002-10-07 16:06 UTC (permalink / raw) To: Jan Harkes; +Cc: Rob Landley, linux-kernel On Mon, 7 Oct 2002, Jan Harkes wrote: > I'm expecting that all the BK->gnu patch gateways will be shut down in > about 5 years, I doubt that, the BK->patch "gateway" is a necessary part of kernel development. Without it, bitkeeper would stop being useful. I could be wrong, but I'm under the impression that Larry doesn't want others to just copy bitkeeper to come up with a free tool almost as good as bitkeeper. There is no vendor lock-in or anything else going on, afaics. People who want to make something better than bitkeeper can simply rsync the BK/SCCS repository from nl.linux.org and use some SCCS clone to import the kernel data and commit comments into their own repository ... they just can't use bitkeeper to help them with their work. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 16:06 ` Rik van Riel @ 2002-10-07 16:18 ` Larry McVoy 0 siblings, 0 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-07 16:18 UTC (permalink / raw) To: Rik van Riel; +Cc: Jan Harkes, Rob Landley, linux-kernel On Mon, Oct 07, 2002 at 01:06:21PM -0300, Rik van Riel wrote: > On Mon, 7 Oct 2002, Jan Harkes wrote: > > > I'm expecting that all the BK->gnu patch gateways will be shut down in > > about 5 years, > > I doubt that, the BK->patch "gateway" is a necessary part of > kernel development. Without it, bitkeeper would stop being > useful. Right. It always was and always will be a feature that it is easy to get in and get *out* of BK. We may be pains in the butt on the license front but once you are using BK, if you have to get the data out, BK makes that as pleasant as can possibly be made. See the export and prs man pages for a starter. It's policy that *every* item of metadata is accessible via prs. > I could be wrong, but I'm under the impression that Larry > doesn't want others to just copy bitkeeper to come up with a > free tool almost as good as bitkeeper. There is no vendor > lock-in or anything else going on, afaics. Exactly right. It wouldn't be so bad if someone were to clone it and come up with a business model so that they could continue to develop it at the same or better rate that we develop BK. My real fear is that someone will do a "good enough" clone to get around the license issues and it won't be as good as BK and it won't continue get better like BK does. That would be a "lowering of the bar" in terms of how good is good. BK has raised the bar for what you should expect from a SCM system and we're not done. My take is that BK is at the "barely useable" stage, not remotely close to being perfect. We want to make it perfect. We won't get there because my definition of perfect means that no operation takes more than 250 milliseconds and that's pretty impossible if you want to do any I/O but we keep trying. bk-3.0 is definitely faster and we have some more perf changes in the queue. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 15:22 ` Ingo Molnar 2002-10-06 15:15 ` Larry McVoy @ 2002-10-06 16:30 ` Werner Almesberger 2002-10-07 9:37 ` Geert Uytterhoeven 2002-10-06 21:31 ` Miquel van Smoorenburg 2 siblings, 1 reply; 223+ messages in thread From: Werner Almesberger @ 2002-10-06 16:30 UTC (permalink / raw) To: Ingo Molnar; +Cc: Larry McVoy, linux-kernel [ Ccs trimmed ] Ingo Molnar wrote: > just wondering where the boundary line is. Eg. if i started working on a > versioned filesystem today, i'd not be allowed to use BK. I just have to > keep stuff like that in mind when using BK. Worse yet, assuming you work for a sufficiently large company, your license is void if or as soon as anybody works in that company's name on something BKS (or any legal successor of them *) considers as competition. (* I'm not a lawyer, but I'm not sure if GPLing BK in the last moment before, say, bankruptcy, would really work.) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 16:30 ` Werner Almesberger @ 2002-10-07 9:37 ` Geert Uytterhoeven 2002-10-07 14:50 ` Larry McVoy 0 siblings, 1 reply; 223+ messages in thread From: Geert Uytterhoeven @ 2002-10-07 9:37 UTC (permalink / raw) To: Werner Almesberger; +Cc: Ingo Molnar, Larry McVoy, Linux Kernel Development On Sun, 6 Oct 2002, Werner Almesberger wrote: > Ingo Molnar wrote: > > just wondering where the boundary line is. Eg. if i started working on a > > versioned filesystem today, i'd not be allowed to use BK. I just have to > > keep stuff like that in mind when using BK. > > Worse yet, assuming you work for a sufficiently large company, > your license is void if or as soon as anybody works in that > company's name on something BKS (or any legal successor of > them *) considers as competition. That's something which worries me. So far my Linux kernel work is not related to my daytime job at Sony. Sony is big, and it's impossible for me to find out whether someone at Sony is working on BK competition. I guess the same is true for other large companies with multiple hands that don't know what the other hands are doing... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 9:37 ` Geert Uytterhoeven @ 2002-10-07 14:50 ` Larry McVoy 2002-10-07 18:45 ` Abramo Bagnara 0 siblings, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-07 14:50 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Werner Almesberger, Ingo Molnar, Larry McVoy, Linux Kernel Development On Mon, Oct 07, 2002 at 11:37:17AM +0200, Geert Uytterhoeven wrote: > That's something which worries me. So far my Linux kernel work is not related > to my daytime job at Sony. Sony is big, and it's impossible for me to find out > whether someone at Sony is working on BK competition. I guess the same is true > for other large companies with multiple hands that don't know what the other > hands are doing... Yes, that's true. If there were some way to say "it's only a problem if you or someone you work with develops..." and make that stick, that would be OK. We don't know how to do that. I'm open to suggestions, it would be good to not throw the baby out with the bathwater. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-07 14:50 ` Larry McVoy @ 2002-10-07 18:45 ` Abramo Bagnara 0 siblings, 0 replies; 223+ messages in thread From: Abramo Bagnara @ 2002-10-07 18:45 UTC (permalink / raw) To: Larry McVoy Cc: Geert Uytterhoeven, Werner Almesberger, Ingo Molnar, Linux Kernel Development Larry McVoy wrote: > > On Mon, Oct 07, 2002 at 11:37:17AM +0200, Geert Uytterhoeven wrote: > > That's something which worries me. So far my Linux kernel work is not related > > to my daytime job at Sony. Sony is big, and it's impossible for me to find out > > whether someone at Sony is working on BK competition. I guess the same is true > > for other large companies with multiple hands that don't know what the other > > hands are doing... > > Yes, that's true. If there were some way to say "it's only a problem if you > or someone you work with develops..." and make that stick, that would be > OK. We don't know how to do that. I'm open to suggestions, it would be > good to not throw the baby out with the bathwater. I've followed with a lot of interest this thread and the parallel ones and I want to say that I understand very well the point that Larry is supporting: "defend our BK business". Larry affirm too that an other fundamental interest is to defend and improve BK quality, a quality supportable only by that kind of business. I think that this second statement is less important than the first because 1) it's not provable, 2) it needs full trust on Larry good faith and in that Larry == BM now and ever (not provable again). Although I'm personally fully convinced of Larry's good faith I'm also convinced that Larry should not reiterate this last argument (at least for a kind of modesty/decency). Considering only the first, IMHO very good point, I still have some difficulty to accept it fully. A lot of software engineer/projects are in the same position of BM/BK. Now I wonder if Larry thinks that everybody should make similar decision about license. It's a reasoning in the edge between ethics and economics and I'm personally confused about what's The Right Thing(tm). Imagine that many years ago the FSF told us: you can use our utility, our compiler, our stuff *only* if you're not developing something that might substitute our utilities, compiler and all the other stuff. You understand: you might undermine our de facto standard position. Imagine Hans that tell to ext3 developers: "you can't have reiserfs on your machine, you might screw my business in future". I could make one hundred similar examples but I think that everybody can imagine some others regarding his paid work experience. What I ask is: "Should we have the same respect for all current paid open source workers/firm if they had limited the use of their stuff only to non competitor?" Sometime ago Larry wrote something like "if someone write something better that BK... who care, at BM we are almost all Linux engineer and perhaps we'll make what we really like: CC Cluster by example...". When I read that I thought that a good engineer is someone that transform the difficulties in good occasion, relying on his creativity and perseverance. Now I'm confused and I think that many on this list are confused like me, it's not only matter of economy, it's something that call the hacker culture that lkml express today in question. I'd like very much that Larry would hear the objections that subscribers make also under this point of view: that part of BK license hurts a bit our beliefs and our point of reference. -- Abramo Bagnara mailto:abramo.bagnara@libero.it Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 15:22 ` Ingo Molnar 2002-10-06 15:15 ` Larry McVoy 2002-10-06 16:30 ` Werner Almesberger @ 2002-10-06 21:31 ` Miquel van Smoorenburg 2002-10-06 22:05 ` Larry McVoy 2002-10-06 23:22 ` Hans Reiser 2 siblings, 2 replies; 223+ messages in thread From: Miquel van Smoorenburg @ 2002-10-06 21:31 UTC (permalink / raw) To: linux-kernel In article <Pine.LNX.4.44.0210061718370.9062-100000@localhost.localdomain>, Ingo Molnar <mingo@elte.hu> wrote: >so BK cannot be used to access the kernel tree in that case, correct? I'm >just wondering where the boundary line is. Eg. if i started working on a >versioned filesystem today, i'd not be allowed to use BK. I just have to >keep stuff like that in mind when using BK. And what if that versioning filesystem got accepted into mainline? Every kernel developer would have to buy a BK license. Either that or a versioning filesystem cannot get into mainline. Sorry Hans, no reiser4 in the kernel. Mike. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 21:31 ` Miquel van Smoorenburg @ 2002-10-06 22:05 ` Larry McVoy 2002-10-06 22:16 ` Rik van Riel 2002-10-06 22:19 ` Robert Love 2002-10-06 23:22 ` Hans Reiser 1 sibling, 2 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-06 22:05 UTC (permalink / raw) To: Miquel van Smoorenburg; +Cc: linux-kernel On Sun, Oct 06, 2002 at 09:31:02PM +0000, Miquel van Smoorenburg wrote: > In article <Pine.LNX.4.44.0210061718370.9062-100000@localhost.localdomain>, > Ingo Molnar <mingo@elte.hu> wrote: > >so BK cannot be used to access the kernel tree in that case, correct? I'm > >just wondering where the boundary line is. Eg. if i started working on a > >versioned filesystem today, i'd not be allowed to use BK. I just have to > >keep stuff like that in mind when using BK. > > And what if that versioning filesystem got accepted into mainline? > Every kernel developer would have to buy a BK license. > > Either that or a versioning filesystem cannot get into mainline. > Sorry Hans, no reiser4 in the kernel. If Hans decides to get into the version control space and compete directly against us, your position is that we should be obligated to give him free seats? And that's reasonable in your mind? At the end of the day, we're doing the best that we can to help out the most that we can. If you were in my shoes I think you'd have the same concerns and issues I have. I'm more than willing to believe you could handle them better than I do but the issues wouldn't change. Let's talk about why that clause is in the license. There are two possible problems: a commercial company decides to replicate BK or an open source project tries to replicate BK. Either path has the strong likelihood of putting us out of business if they execute better than we have. If it's the commercial path, you know they aren't going to give you what they build for free like we did, especially after seeing the problems it has caused us. The *only* reason anyone would do what we are doing is if they really wanted to help the kernel. The so called PR value that we supposedly get is simply dwarfed by the PR problems it has caused, the time it has wasted, and the salaries it has cost us. So the business guys aren't a good choice, they won't treat you anywhere near as well as we treat you because they are not part of your community. I am. Maybe not a well loved part, but a part non the less. If it is an open source project, they'll replicate what we have, which would drop our revenue stream to zero, and BK development stops. The replica won't be any better than BK, it will be worse. It won't have the same level of polish or architecture, that's too much work. Subversion is a funded project, they have had way more money than we had when we started, and they aren't anywhere near to being a BK replacement. The open source route isn't a good choice because it costs too much to do this and it's just not very fun work. Look at all the "projects" on source forge to see data which supports my point of view. Some people say "I don't care, BK is good enough, a replica would be fine". Actually, it wouldn't. No more so than CVS is. BK as it stands has real limitations, those need to be fixed. Linus or one of the other kernel hackers will be happy to list those limitations and I can fill in the problems they haven't hit yet but certainly will. The real question is: if you want us to allow things that we believe will put us out of business, then where are you going to get tools like BK from? Complain all you want about the license, but it's clear that BK has helped. Going back to diff&patch would suck. BK is a competitive advantage for the kernel as it stands. We're making it better so it won't fall over dead 3 years from when the history gets to big or some other problem occurs. If you could have figured out a way to do the same amount of good that we are providing but in a more politically correct (i.e. GPLed) way, then why the hell haven't you? And if you can't, how about easing off a bit and letting us do what we can? If you have suggestions on how we could do things in a nier way without putting the company, and therefor the kernel team, at risk, then make them. I'm one of you. We're helping as best we are able. You might stop to realize that we've been doing this for 5 years, we never took VC, we never sold out, even though we had multiple chances to do both, because that would put helping you at risk. You don't like my choices? Put on my shoes, suggest better choices. I'll listen. But you have to really think it through. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 22:05 ` Larry McVoy @ 2002-10-06 22:16 ` Rik van Riel 2002-10-06 22:19 ` Robert Love 1 sibling, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-06 22:16 UTC (permalink / raw) To: Larry McVoy; +Cc: Miquel van Smoorenburg, linux-kernel On Sun, 6 Oct 2002, Larry McVoy wrote: > If you could have figured out a way to do the same amount of good that > we are providing but in a more politically correct (i.e. GPLed) way, > then why the hell haven't you? Because ... Whining Is Easy (tm) I'm running into this all the time, with discussions that go like: Me: "It's hard to build a VM that does the right thing in every situation" Somebody: "So why don't you build a separate desktop and server VM?" Me: "Umm, what would those two need to do differently ? What functional difference would there be ?" Somebody: "Dunno, I don't care, why don't you just do it and figure out the details later?" These discussions tend to go downhill from there... cheers, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 22:05 ` Larry McVoy 2002-10-06 22:16 ` Rik van Riel @ 2002-10-06 22:19 ` Robert Love 2002-10-06 22:36 ` Larry McVoy 1 sibling, 1 reply; 223+ messages in thread From: Robert Love @ 2002-10-06 22:19 UTC (permalink / raw) To: Larry McVoy; +Cc: Miquel van Smoorenburg, linux-kernel On Sun, 2002-10-06 at 18:05, Larry McVoy wrote: > On Sun, Oct 06, 2002 at 09:31:02PM +0000, Miquel van Smoorenburg wrote: > > > And what if that versioning filesystem got accepted into mainline? > > Every kernel developer would have to buy a BK license. > > > > Either that or a versioning filesystem cannot get into mainline. > > Sorry Hans, no reiser4 in the kernel. > > If Hans decides to get into the version control space and compete directly > against us, your position is that we should be obligated to give him free > seats? And that's reasonable in your mind? I think the fear is more that via the license you could deny any kernel seats. I.e., let's say I never intend to work on reiser4 but it is part of the source tree I would be working on via BK. Am I at risk? Or, what if I do not directly work on reiser4 but I do post an ancillary patch - perhaps to fix a compile issue or update reiser4 to some new locking change. Am I at risk now? I agree 100% with your intentions. You are under no obligation to help your competitors for free - nor should you. But BitKeeper is now in a position where it is a main-stay in kernel development and it is crucial to resolve issues like this. I do not feel arguments like "you get what you pay for" or "that is life" are valid, anymore: developers are relying on BK and the choice is to resolve the issues or drop BK altogether -- not just "live with it". Robert Love ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 22:19 ` Robert Love @ 2002-10-06 22:36 ` Larry McVoy 0 siblings, 0 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-06 22:36 UTC (permalink / raw) To: Robert Love; +Cc: Larry McVoy, Miquel van Smoorenburg, linux-kernel On Sun, Oct 06, 2002 at 06:19:03PM -0400, Robert Love wrote: > your competitors for free - nor should you. But BitKeeper is now in a > position where it is a main-stay in kernel development and it is crucial > to resolve issues like this. I do not feel arguments like "you get what > you pay for" or "that is life" are valid, anymore: developers are > relying on BK and the choice is to resolve the issues or drop BK > altogether -- not just "live with it". As I've said repeatedly, show me a better solution to the set of problems, I'll look at it. So far, there is a flood of "oh, my god, larry is the devil and is going to make bk do <insert evil thing here>". Not helpful. The real answer isn't "live with it", the real answer is to consider the health of the organization that gives you BK, consider the things that you want, propose answers that take *both* sets of issues into account. We could have worded that clause differently, several people have proposed changes similar to ones we considered. If you assume everyone is an honorable and nice guy then it doesn't really matter, you could have a license that says "you are granted everything so long as you do the right thing". That actually works if people do the right thing and there is widespread agreement on the right thing. They don't and there isn't. So we have to restrict things that would do us damage. We haven't found any way to say it in a way that doesn't make you nervous because all of those ways just open the door to the bad guys. I'm open to suggestions. Just make ones that make sense. I hear your fears, I'm not saying your fears are invalid, they are very valid, extremely valid in the event that I lose control of the company. I'd welcome a license that protected the company and protected you, especially if that license outlives any change in power here. We tried. You don't like it. Come up with something better, just remember that if it doesn't protect the hand, that hand can't feed you. Right now at least, it's important that we stay healthy, you still need BK to move forward, it's far from perfect. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 21:31 ` Miquel van Smoorenburg 2002-10-06 22:05 ` Larry McVoy @ 2002-10-06 23:22 ` Hans Reiser 1 sibling, 0 replies; 223+ messages in thread From: Hans Reiser @ 2002-10-06 23:22 UTC (permalink / raw) To: Miquel van Smoorenburg; +Cc: linux-kernel, jmacd, Rik van Riel Miquel van Smoorenburg wrote: >In article <Pine.LNX.4.44.0210061718370.9062-100000@localhost.localdomain>, >Ingo Molnar <mingo@elte.hu> wrote: > > >>so BK cannot be used to access the kernel tree in that case, correct? I'm >>just wondering where the boundary line is. Eg. if i started working on a >>versioned filesystem today, i'd not be allowed to use BK. I just have to >>keep stuff like that in mind when using BK. >> >> > >And what if that versioning filesystem got accepted into mainline? >Every kernel developer would have to buy a BK license. > >Either that or a versioning filesystem cannot get into mainline. >Sorry Hans, no reiser4 in the kernel. > >Mike. > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > > reiser4 will not contain version control. I don't know when version control will go into ReiserFS. I do think it should go in eventually though, as it makes distributed filesystems more effective if there is version control functionality. We would do something that in no way resembled BK. We would do it after implementing the core distributed tree algorithms. Probably not going to happen in less than 3-5 years. Unless I became a much larger business, it would not have the fancy gui and all that, and it would not really be targeted at source code, it would be targeted at distributed file system users and applications. It would handle source code only as an accidental side effect. I don't find the version control for programmers market nearly as interesting as the version control for distributed/disconnected filesystem users market. Probably Larry could buy a license from us for it, and then do his source code targeted stuff on top of it.;-) But hey, talk to Josh Macdonald, the author of PRCS. If he wants to code it, I'll pay for his time to do it. Right now, I think he is recovering from the stress of working on reiser4, and last we spoke he was more interested in doing key based file system security models than in adding version control to reiser5. There are so many features missing from ReiserFS, and I am not really picky about what order they go in..... With Reiser4 we finally have storage layer performance "good enough for now", and now we can focus on semantic features and fun/easy stuff for a few years. Hans ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 13:46 ` Ingo Molnar 2002-10-06 13:59 ` Ingo Molnar @ 2002-10-06 13:59 ` Ben Collins 2002-10-06 14:14 ` Ingo Molnar 2002-10-06 14:53 ` Larry McVoy 2 siblings, 1 reply; 223+ messages in thread From: Ben Collins @ 2002-10-06 13:59 UTC (permalink / raw) To: Ingo Molnar; +Cc: linux-kernel On Sun, Oct 06, 2002 at 03:46:29PM +0200, Ingo Molnar wrote: > > On Fri, 4 Oct 2002, Larry McVoy wrote: > > > The clause is specifically designed to target those companies which > > produce or sell commercial SCM systems. [...] The open source developers > > have nothing to worry about. > > and: > > On Sat, 5 Oct 2002, Larry McVoy wrote: > > > > Larry, I develop for the Subversion project. Does that mean my license > > > to use bitkeeper is revoked? > > > > Yes. It has been since we shipped that license or when you started > > working on Subversion, whichever came last. > > > this kind of sudden change in Larry's written opinion within 24 hours is > that makes this whole issue dangerous. Fact is that Larry is free to > license his product under fair or unfair terms - it's his. While we > already gave BK/BM tons of feedback, free beta-testing and free publicity, > all we have is this volatile promise that the binary bits of BK are going > to remain licensed - and with every day it will be harder and harder to > move the repository. In all honesty, Larry and I have a dislike for each other. I've emailed him in private venting my frustration against him in the past. I wasn't very nice at all. It's no surprise that he has a grudge against me. His decision above is more of a power play against me to smack me down, than anything else (something he's admitted to me in private email since sending that email to the list). He got his payback. Question is, if he shows a history of using license interpretation to handle personal grudges, how long before he gets pissed at someone else and inteprets his license in another way to toss around power over users of his product...a way more damaging than simply losing ones right to use BK freely. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 13:59 ` Ben Collins @ 2002-10-06 14:14 ` Ingo Molnar 0 siblings, 0 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 14:14 UTC (permalink / raw) To: Ben Collins; +Cc: Larry McVoy, linux-kernel On Sun, 6 Oct 2002, Ben Collins wrote: > In all honesty, Larry and I have a dislike for each other. [...] i have no intention (and knowledge - it's your private matter) to say anything meaningful about this issue, this is why i asked the kernel based versioned filesystem question, that is a sufficiently neutral issue i believe. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 13:46 ` Ingo Molnar 2002-10-06 13:59 ` Ingo Molnar 2002-10-06 13:59 ` Ben Collins @ 2002-10-06 14:53 ` Larry McVoy 2002-10-06 15:37 ` Ingo Molnar 2 siblings, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-06 14:53 UTC (permalink / raw) To: Ingo Molnar Cc: David S. Miller, Larry McVoy, Linus Torvalds, Alan Cox, linux-kernel On Sun, Oct 06, 2002 at 03:46:29PM +0200, Ingo Molnar wrote: > this kind of sudden change in Larry's written opinion within 24 hours is > that makes this whole issue dangerous. What change? > this is why i'd rather want to have an iron-clad legal way out first, and > not have to rely on nonbinding promises done on public lists. I'm sure > Larry understands this position, he has exactly the same position when > trying to protect his business against hordes of freebies. We spend a lot of time thinking about this from your point of view. There is a rule around here that we can't impose any rule that we wouldn't be willing to live with if the situations were reversed. I'm composing a reply to the rest of the thread, stand by. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 14:53 ` Larry McVoy @ 2002-10-06 15:37 ` Ingo Molnar 0 siblings, 0 replies; 223+ messages in thread From: Ingo Molnar @ 2002-10-06 15:37 UTC (permalink / raw) To: Larry McVoy; +Cc: David S. Miller, Linus Torvalds, Alan Cox, linux-kernel On Sun, 6 Oct 2002, Larry McVoy wrote: > > this kind of sudden change in Larry's written opinion within 24 hours is > > that makes this whole issue dangerous. > > What change? i wanted to say 'apparent change' - as the issue presents itself to me, based on the incomplete snippets of information i have on this mailing list. Your first statement reads: > The clause is specifically designed to target those companies which > produce or sell commercial SCM systems. [...] The open source developers > have nothing to worry about. this reads to me: "even if i'm an SCM developer i am using BK fairly as long as i license my SCM code under an open-source license." Is this an incorrect interpretation of your words? the second statement: > > Larry, I develop for the Subversion project. Does that mean my license > > to use bitkeeper is revoked? > > Yes. It has been since we shipped that license or when you started > working on Subversion, whichever came last. Subversion itself appears to be licensed under a Apache-ish license, so a cursory interpretation of the first statement qualifies it as an 'open-source' project. It might or might not be worth anything, it might or might not be related to a commercial entity otherwise, like each and every other open-source project - commercial activities and open-source do not exclude each other. Ingo ^ permalink raw reply [flat|nested] 223+ messages in thread
* BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-05 18:25 ` Larry McVoy ` (2 preceding siblings ...) 2002-10-06 13:46 ` Ingo Molnar @ 2002-10-06 22:11 ` Pavel Machek 2002-10-07 18:49 ` BK is *evil* corporate software David S. Miller ` (3 more replies) 3 siblings, 4 replies; 223+ messages in thread From: Pavel Machek @ 2002-10-06 22:11 UTC (permalink / raw) To: Ben Collins, Larry McVoy, linux-kernel Hi! > We're a business. We're a business which happens to be committed to > helping the kernel team because we think that the kernel is vital to > the world at large. Helping the kernel absolutely does not translate > to helping people who happen to be our competitors. By your own Stop lying. Your job is to make lots of money and you are using Linux as cheap advertising. You are trying to make people pay *you* to do kernel development (as it stands you want $5000 for any bk-using developer inside RedHat and SuSE). I hope your company dies ASAP and bitkeeper stops poisoning air here. Pavel -- When do you have heart between your knees? ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-06 22:11 ` BK is *evil* corporate software [was Re: New BK License Problem?] Pavel Machek @ 2002-10-07 18:49 ` David S. Miller 2002-10-07 20:12 ` Alan Cox 2002-10-07 21:23 ` Roman Zippel 2002-10-07 18:51 ` BK is *evil* corporate software [was Re: New BK License Problem?] Mike Galbraith ` (2 subsequent siblings) 3 siblings, 2 replies; 223+ messages in thread From: David S. Miller @ 2002-10-07 18:49 UTC (permalink / raw) To: pavel; +Cc: bcollins, lm, linux-kernel From: Pavel Machek <pavel@ucw.cz> Date: Mon, 7 Oct 2002 00:11:37 +0200 (as it stands you want $5000 for any bk-using developer inside RedHat and SuSE). Stop spreading crap and fud. I, and nobody else at Red Hat, give or need to give Larry one dime to use BK for kernel work. And to be honest, I get better support from Larry for *free* than you'll most often get when paying some company for software support. This is a fact. When was the last time you got a ring on your cell phone 4 minutes after emailing a bug report to someone? Larry isn't Microsoft, and whether you choose to recognize the positive things he does for kernel development or not is your decision. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-07 18:49 ` BK is *evil* corporate software David S. Miller @ 2002-10-07 20:12 ` Alan Cox 2002-10-07 20:14 ` Pavel Machek 2002-10-07 21:23 ` Roman Zippel 1 sibling, 1 reply; 223+ messages in thread From: Alan Cox @ 2002-10-07 20:12 UTC (permalink / raw) To: David S. Miller; +Cc: pavel, bcollins, lm, Linux Kernel Mailing List On Mon, 2002-10-07 at 19:49, David S. Miller wrote: > From: Pavel Machek <pavel@ucw.cz> > Date: Mon, 7 Oct 2002 00:11:37 +0200 > > (as it stands you want $5000 for any bk-using developer inside > RedHat and SuSE). > > Stop spreading crap and fud. I, and nobody else at Red Hat, give or > need to give Larry one dime to use BK for kernel work. We do fix cvs things. Oh wait Larry has publically said CVS is no competition 8) I'd agree with Dave - Larry is an arrogant egomaniac, but he's not 'evil' and if he was that, he'd be like a Bond villain - so busy explaining how clever he was that he'd not actually manage it ;) ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-07 20:12 ` Alan Cox @ 2002-10-07 20:14 ` Pavel Machek 0 siblings, 0 replies; 223+ messages in thread From: Pavel Machek @ 2002-10-07 20:14 UTC (permalink / raw) To: Alan Cox; +Cc: David S. Miller, pavel, bcollins, lm, Linux Kernel Mailing List Hi! > > (as it stands you want $5000 for any bk-using developer inside > > RedHat and SuSE). > > > > Stop spreading crap and fud. I, and nobody else at Red Hat, give or > > need to give Larry one dime to use BK for kernel work. > We do fix cvs things. Oh wait Larry has publically said CVS is no > competition 8) And what happens when you will want to include subversion in distribution? You'll surely want to do some fixing before including it... Pavel -- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-07 18:49 ` BK is *evil* corporate software David S. Miller 2002-10-07 20:12 ` Alan Cox @ 2002-10-07 21:23 ` Roman Zippel 1 sibling, 0 replies; 223+ messages in thread From: Roman Zippel @ 2002-10-07 21:23 UTC (permalink / raw) To: David S. Miller; +Cc: pavel, bcollins, lm, linux-kernel Hi, On Mon, 7 Oct 2002, David S. Miller wrote: > (as it stands you want $5000 for any bk-using developer inside > RedHat and SuSE). > > Stop spreading crap and fud. I, and nobody else at Red Hat, give or > need to give Larry one dime to use BK for kernel work. Actually RedHat does support subversion development, so RedHat must have some special agreement with BM, so you can legally use BK for free. bye, Roman ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-06 22:11 ` BK is *evil* corporate software [was Re: New BK License Problem?] Pavel Machek 2002-10-07 18:49 ` BK is *evil* corporate software David S. Miller @ 2002-10-07 18:51 ` Mike Galbraith 2002-10-07 21:31 ` Larry McVoy 2002-10-07 18:56 ` tom_gall 2002-10-07 20:30 ` BK is *evil* corporate software [was Re: New BK License Problem?] Rik van Riel 3 siblings, 1 reply; 223+ messages in thread From: Mike Galbraith @ 2002-10-07 18:51 UTC (permalink / raw) To: Pavel Machek, Ben Collins, Larry McVoy, linux-kernel At 12:11 AM 10/7/2002 +0200, Pavel Machek wrote: >Hi! > > > We're a business. We're a business which happens to be committed to > > helping the kernel team because we think that the kernel is vital to > > the world at large. Helping the kernel absolutely does not translate > > to helping people who happen to be our competitors. By your own > >Stop lying. Your job is to make lots of money and you are using Linux >as cheap advertising. You are trying to make people pay *you* to do >kernel development (as it stands you want $5000 for any bk-using >developer inside RedHat and SuSE). More info on $5k assertion please? -Mike ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-07 18:51 ` BK is *evil* corporate software [was Re: New BK License Problem?] Mike Galbraith @ 2002-10-07 21:31 ` Larry McVoy 2002-10-09 23:34 ` Henning P. Schmiedehausen 0 siblings, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-07 21:31 UTC (permalink / raw) To: Mike Galbraith; +Cc: Pavel Machek, Ben Collins, Larry McVoy, linux-kernel On Mon, Oct 07, 2002 at 08:51:16PM +0200, Mike Galbraith wrote: > At 12:11 AM 10/7/2002 +0200, Pavel Machek wrote: > >Hi! > > > > > We're a business. We're a business which happens to be committed to > > > helping the kernel team because we think that the kernel is vital to > > > the world at large. Helping the kernel absolutely does not translate > > > to helping people who happen to be our competitors. By your own > > > >Stop lying. Your job is to make lots of money and you are using Linux > >as cheap advertising. You are trying to make people pay *you* to do > >kernel development (as it stands you want $5000 for any bk-using > >developer inside RedHat and SuSE). > > More info on $5k assertion please? Let's clear this one up right away. The commercial licenses can be perpetual (you bought it, you own that version forever) or annual lease. The lease includes the right to use, support, and upgrades for as long as you maintain the lease. The buy includes a year of support & upgrades; after that you can buy support or not as you so choose. So you have the buy vs buy+support vs lease options. We vary our prices based on volume and everyone gets the same price. We don't publish the prices because engineers will reject the product based on any price more than $100/seat. Management is far more reasonable, they want to know how much they spend and how much it saves them, and are pretty unconcerned with what an engineer thinks. They just want to see bottom line return on investment. Because our support costs are higher per seat at low volumes, the product is priced accordingly. We really hate to sell less than lots of 15 seats or so, it's not cost effective. When we come across those situations we try and steer them towards CVS (can't beat the price), single user (also free), or we may give them an extended eval license and tell them to come back when they are bigger. At our end, the cost of rolling out a new commercial customer is about $10 - $15K in salaries. Part of that is normal support, part of that is that we almost always sweeten a sale by letting the customer say "I'm not going to buy unless it does XYZ" provided that XYZ is something we think is generically useful. So the sale gets to shuffle our priorities a bit and that ends up costing us extra money. It's all good, it just means that if a sale is less than $15K we probably don't want it. We love the level of support we give, it's a huge part of why our users love BK, so we price where we have to price. We're not a low end, low service shop, quite the opposite. The annual lease prices vary from $1K/seat for lots of seats to $2.4K/seat for one seat (nobody leases or buys one seat, they use it in single user mode). The buy prices range from $2800/seat to $5800/seat. The buy vs lease trade off is such that it is between 4 and 6 years before it becomes cheaper to have bought than to have leased so everyone leases. A seat is defined as a person who makes changes and floats automatically every three months (to handle employee turnover, that sort of thing). Noone has ever given us $5K for a seat and I doubt very much that anyone ever will. Everyone leases and they lease at high enough volumes that the lease price is around $1.5K. A couple things are worth noting. We compete mostly with <insert market leader here, we'll call them BIG>. Our lease prices, at high enough volumes, are the same as or lower than BIG annual support prices. BIG runs around $5K/seat plus 20% / year in support. So we're quite competitive on the licensing costs. But it gets much, much better. The BIG architecture is centralized so performance bottlenecks are also centralized. As you add users you have to add server hardware. It's very common to spend $300K on a big Sun SMP box to keep up with the load. A $2K PC can do the same thing with BK, look at bkbits.net, it's a 750Mhz Athlon, it has about 2000 different users. The next cost center is administration. Again, the centralized architecture means that you pay people a lot of money to make sure that the BIG server never dies because everyone goes home if it does. We had a customer who had a site license for BIG and they wanted a 4 site multisite config. They asked us to price it for BIG and for BK. They already had some of the hardware and some of the people they would need, and they didn't have to pay for BIG, just support, so these numbers are lower than they should. Doesn't matter. The costs for them worked out to about $218K to get started plus $144K/year to keep going. The BK costs worked out to $8K to get started and $52K/year to keep going. 5 year cost of ownership: BIG: $938, BK: $268. The customer looked at our math and said "Your BIG costs are way too low but it doesn't matter, you made your point" and they bought BK seats. Who wouldn't if the numbers work out like that and the product suits your needs? So, to reiterate, we don't publish our prices because an engineer will look at $2000 and say "bug off, I'm not paying that much for that". They don't think that $2K is 1-2% of what their management pays them in a year, they don't think about the hardware costs, they don't think about the people costs, they just go "I wouldn't pay for that so forget that". -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-07 21:31 ` Larry McVoy @ 2002-10-09 23:34 ` Henning P. Schmiedehausen 2002-10-09 23:50 ` BK is *evil* corporate software David S. Miller ` (2 more replies) 0 siblings, 3 replies; 223+ messages in thread From: Henning P. Schmiedehausen @ 2002-10-09 23:34 UTC (permalink / raw) To: linux-kernel Larry McVoy <lm@bitmover.com> writes: >On Mon, Oct 07, 2002 at 08:51:16PM +0200, Mike Galbraith wrote: >> At 12:11 AM 10/7/2002 +0200, Pavel Machek wrote: >> >Hi! >> > >> > > We're a business. We're a business which happens to be committed to >> > > helping the kernel team because we think that the kernel is vital to >> > > the world at large. Helping the kernel absolutely does not translate >> > > to helping people who happen to be our competitors. By your own >> > >> >Stop lying. Your job is to make lots of money and you are using Linux >> >as cheap advertising. You are trying to make people pay *you* to do >> >kernel development (as it stands you want $5000 for any bk-using >> >developer inside RedHat and SuSE). >> >> More info on $5k assertion please? >Let's clear this one up right away. The commercial licenses can be >perpetual (you bought it, you own that version forever) or annual lease. >The lease includes the right to use, support, and upgrades for as long as >you maintain the lease. The buy includes a year of support & upgrades; >after that you can buy support or not as you so choose. So you have the >buy vs buy+support vs lease options. >We vary our prices based on volume and everyone gets the same price. >We don't publish the prices because engineers will reject the product >based on any price more than $100/seat. Management is far more Let's insert some fact in this discussion: --- cut --- Annual lease: < 5 seats, $2490/seat/year. 5-15 seats, $1920/seat/year. Lifetime Purchase: < 5 seats, $5220/seat. 5-15 seats, $4230/seat. --- cut --- Basically you charge a small(-ish) company about $25k for any reasonable license. This is about as much as we spent for Software in the last seven years (we do own a few Windows and Office licenses). bk might be interesting for larger companies with software budgets in the six figure range and for open source. For the vast number of three to five developers enterprises, it's simply unreasonably priced. For 25k$ I get about six man months from a really good developer to work on <insert your SCM here>. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de D-91054 Buckenhof Fax.: 09131 / 50654-20 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-09 23:34 ` Henning P. Schmiedehausen @ 2002-10-09 23:50 ` David S. Miller 2002-10-10 1:08 ` Larry McVoy 2002-10-10 8:09 ` Henning Schmiedehausen 2002-10-09 23:55 ` BK is *evil* corporate software [was Re: New BK License Problem?] Larry McVoy 2002-10-10 0:03 ` Jamie Lokier 2 siblings, 2 replies; 223+ messages in thread From: David S. Miller @ 2002-10-09 23:50 UTC (permalink / raw) To: hps; +Cc: linux-kernel From: "Henning P. Schmiedehausen" <hps@intermeta.de> Date: Wed, 9 Oct 2002 23:34:25 +0000 (UTC) For the vast number of three to five developers enterprises, it's simply unreasonably priced. Larry is trying to tell you that BK isn't for you. It costs too much to support small numbers of groups which is why he can't price it the way you want. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-09 23:50 ` BK is *evil* corporate software David S. Miller @ 2002-10-10 1:08 ` Larry McVoy 2002-10-10 1:47 ` Keith Owens 2002-10-10 8:09 ` Henning Schmiedehausen 1 sibling, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-10 1:08 UTC (permalink / raw) To: hps, linux-kernel On Wed, Oct 09, 2002 at 04:50:03PM -0700, David S. Miller wrote: > From: "Henning P. Schmiedehausen" <hps@intermeta.de> > Date: Wed, 9 Oct 2002 23:34:25 +0000 (UTC) > > For the vast number of three to five developers enterprises, it's > simply unreasonably priced. > > Larry is trying to tell you that BK isn't for you. > It costs too much to support small numbers of groups > which is why he can't price it the way you want. One of the other BitMover founders, Andrew Chang, told me a few months ago that he realized that CVS was our "low end entry level product". He's right. Much like I suck at public relations (and boy do I suck, smacks head for Nth time), we also could be better at sales. Our sales pitch is "does anything hurt? No? Go use CVS. Come back when it hurts. If it never hurts you should never pay for BK". I learned this the one time we ever did any marketing, which was way back in 1999 or 1998 at Linux Expo. I was program chair for the technical conference and Red Hat kindly gave us a booth. So we printed out the BK logo on a big sheet of paper and sat at a booth and answered questions, all of which went like this for the first 10 or 15 people: Random Person: "Why should I use BitKeeper instead of CVS?" Larry: <insert long winded, rambling answer extolling the BK virtues> Random Person: <eyes glaze over, walks away> I'm slow so it took me at least 10 of those to realize that I just wasn't getting through these people. And in true "larry form" I got pissed off. So with the next guy it went like this: Random Person: "Why should I use BitKeeper instead of CVS?" Larry: "If you have to ask that stupid question, you haven't suffered enough. Go away, come back when it hurts." Random Person: "Well, actually, renames under CVS really hurt, do you fix that?" Larry: "You bet we do, it works like ...." Very important lesson. People don't give a rats ass about how cool your technology is, how elegant it is, or any other thing that makes engineers get excited. What they care about is pain or the lack thereof. So these days we bill ourselves as "Novacaine for source management". If you are suffering then we may be able to help and the price will look cheap. If you aren't suffering you should stay with what you have. The same thing applies to the Linux Kernel team. It's an absolute fact that the BK license isn't what you want, it's not open source, it's evil corporate software, at least in the view of any open source fanatic and a lot of fairly reasonable people. If you are using it, it's because it makes your pain go away. Or at least partially go away. If I could have figured out a way to do that with a GPLed license I would have done so, but I couldn't, so the license is what it is. The bad news is that the license isn't what you want. The good news is that *all* of us at BitMover are hackers just like you and we hate tools that cause pain, so we are very motivated & committed to make BK an even more effective tool. We want you to do what you can do what you do best: code. The less than ideal license is, in our opinion, what allows us to help you do that. It's entirely possible that there is a better licensing answer, we just don't see it. On the other hand, I swear to you that there is no development team anywhere on the planet more committed to making your work pleasant. If you can look past the license, we're the best thing that has ever happened to you, we are here to make you happy. The license sucks, we can't help that. The software doesn't suck a lot and we are trying to make it not suck at all. To steal a line from Mutt, "All SCM systems suck, BK just sucks less". I'm really sorry the license has caused this much fuss. We'll try to make it more acceptable to the extent that we can. On the other hand, those of you who are flaming should be ashamed of yourselves for attacking a group of engineers doing everything they can to help make things better for the kernel. We've been here for a long time; throwing stones at us and saying we're just out to make a quick buck is nonsense, we're here to help and our track record speaks for itself. I do understand that our choices aren't popular with the GPL fans, but that doesn't make us evil. We're doing what we need to do in order to help. This market space, as Henning has pointed out, is very cost sensitive and there is no hope, in our opinion, that a GPLed answer could do what we are doing. If it could, we'd be doing it that way. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-10 1:08 ` Larry McVoy @ 2002-10-10 1:47 ` Keith Owens 0 siblings, 0 replies; 223+ messages in thread From: Keith Owens @ 2002-10-10 1:47 UTC (permalink / raw) To: linux-kernel On Wed, 9 Oct 2002 18:08:34 -0700, Larry McVoy <lm@bitmover.com> wrote: >"does anything hurt? No? Go use CVS. Come back when it hurts. >If it never hurts you should never pay for BK". <plug> For single users or a small team on a LAN, PRCS is much better than CVS Change sets, branching, merging, easy extraction from any version ... What is missing from PRCS is the distributed repository. Even Larry thinks that PRCS is good for single users. http://prcs.sourceforge.net/ </plug> prcs info linux-2.4 | wc -> 1179 changesets. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-09 23:50 ` BK is *evil* corporate software David S. Miller 2002-10-10 1:08 ` Larry McVoy @ 2002-10-10 8:09 ` Henning Schmiedehausen 2002-10-10 8:28 ` Off topic, bandwidth wasting, waffle about Bit Keeper jbradford 1 sibling, 1 reply; 223+ messages in thread From: Henning Schmiedehausen @ 2002-10-10 8:09 UTC (permalink / raw) To: David S. Miller; +Cc: linux-kernel On Thu, 2002-10-10 at 01:50, David S. Miller wrote: > From: "Henning P. Schmiedehausen" <hps@intermeta.de> > Date: Wed, 9 Oct 2002 23:34:25 +0000 (UTC) > > For the vast number of three to five developers enterprises, it's > simply unreasonably priced. > > Larry is trying to tell you that BK isn't for you. > It costs too much to support small numbers of groups > which is why he can't price it the way you want. Guess what, I did understand this in Larrys' mail. I didn't need you to figure it out for me. :-) But I didn't know this when we first asked for a price quote about six month ago. I found no boiler plate sign saying "we're going for the big guys. If you don't have a yearly cash flow well into seven figures, go away". BitMover Inc. pushes its lead product (which seems to be quite nice, unfortunately it's not for _us_) aggressivly into the market by tackling the 2nd most successful open source product ever [1]: the Linux Kernel. I'd guess that 90% of the Linux kernel developers are either individuals (and I count people like you or Alan still as "individuals", though you're working for bigger companies. Is RedHat using bk internally on a regular base?) or working for very small companies which develop a specific part of the kernel (Driver, network protocol, name it) which is needed in a product based on Linux. So there is a discrepancy that is a thorn at least in my side: If I do "fun work" on the Linux Kernel, I get to play with the "big boys' tools" but I must not use them in my daily-bread work. (BTW: There I use CVS). What I envision (Larry, are you listening?) would be a sort of "small company license". Let's say "three to five seats, not expandable, if you need a bigger license, you have to pay the full step up to the regular bk prices even for the first seats" with a limited support (or support contract at additional costs) for one version on one unix platform [2] from a limited choice (Let's say Linux, BSD). Bundle this at about Euro 1k. Now you can whine about "you tailored a license just for yourself". Right. Selfish me :-) One point that BitMover shouldn't underestimate is the "familiarity with tools". All of our developers came with "CVS pre-knowledge". So we didn't have to train them from the start; we showed them the tools and they were set. If you get a larger user base using bk, you IMHO would get a "grass roots movement" into bigger companies. BTW: Anyone using bk for Java development? Regards Henning [1] #1 is IMHO still the GNU C Compiler suite. [2] Everyone who can afford Windows XP Professional edition for five developers can pay bk regular pricing too. :-) -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de D-91054 Buckenhof Fax.: 09131 / 50654-20 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Off topic, bandwidth wasting, waffle about Bit Keeper 2002-10-10 8:09 ` Henning Schmiedehausen @ 2002-10-10 8:28 ` jbradford 0 siblings, 0 replies; 223+ messages in thread From: jbradford @ 2002-10-10 8:28 UTC (permalink / raw) To: linux-kernel; +Cc: lm The solution, as I see it, is to wait for a couple of years until Larry drops his asking price of $12,000,000 to GPL it, and then ask a few of the large Linux distros to help raise that money. Think about it - there will be more competition against BK in a couple of years time, so GPLing it to get more market share would make sense. That way it could compete against, E.G. Subversion, if Subversion becomes a viable competitor. Larry - what are your thoughts on this? John. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-09 23:34 ` Henning P. Schmiedehausen 2002-10-09 23:50 ` BK is *evil* corporate software David S. Miller @ 2002-10-09 23:55 ` Larry McVoy 2002-10-10 3:50 ` Mark Mielke ` (2 more replies) 2002-10-10 0:03 ` Jamie Lokier 2 siblings, 3 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-09 23:55 UTC (permalink / raw) To: Henning P. Schmiedehausen; +Cc: linux-kernel > Let's insert some fact in this discussion: OK. > Basically you charge a small(-ish) company about $25k for any > reasonable license. This is about as much as we spent for Software in > the last seven years (we do own a few Windows and Office licenses). > > bk might be interesting for larger companies with software budgets in > the six figure range and for open source. For the vast number of three > to five developers enterprises, it's simply unreasonably priced. For > 25k$ I get about six man months from a really good developer to work > on <insert your SCM here>. Sure. And if you have 3-5 developers there is no reason to not use CVS, it works well enough. Or Subversion after it matures, or Arch, or Aegis, or tarballs+diff+patch. We can't, and won't, compete at that level. You're comparing free against what we charge. We're infinitely expensive in that comparison. OK, now let's look at it as you grow. Most of our customers are in the 25-100 developer range. They move very quickly and have lots of parallelism in the code. So things like work flow and merging are critical, if that doesn't work, the whole team slows down. Let's say we have a 60 seat sale. That's $90K/year for BK. Let's say the engineers cost $100K/each (it may be lower where you are but it's more like $180-220 here when you add in building/mgmt/all the other overhead). So that's $6M/year in engineers. The BK cost is 1.5% of that. You say that your guys are $50K/year? OK, so we're at 3% of that. The point is that if BK makes your team 3% more productive, it costs zero. And none of that includes the hardware costs, which are dramatically cheaper for BK, it works on a laptop. Clearcase doesn't. Whatever, I know that BK doesn't make sense for a 3 man shop. And I know you think it is way too expensive. Your opinion is not universally shared because the costs start to make more and more sense as you get larger. I am sorry if you don't agree but that's the way it is. You are welcome to use Perforce or CVS instead, we encourage it in fact. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-09 23:55 ` BK is *evil* corporate software [was Re: New BK License Problem?] Larry McVoy @ 2002-10-10 3:50 ` Mark Mielke 2002-10-10 4:16 ` Derek D. Martin 2002-10-10 7:26 ` Rogier Wolff 2002-10-10 14:04 ` yodaiken 2 siblings, 1 reply; 223+ messages in thread From: Mark Mielke @ 2002-10-10 3:50 UTC (permalink / raw) To: Larry McVoy, Henning P. Schmiedehausen, linux-kernel On Wed, Oct 09, 2002 at 04:55:00PM -0700, Larry McVoy wrote: > And none of that includes the hardware costs, which are dramatically > cheaper for BK, it works on a laptop. Clearcase doesn't. ClearCase does work on lap tops. Even if you mean disconnected, ClearCase allows work to continue with snapshot views... :-) Hardware costs are nothing really. The true killer with ClearCase is the support costs. Not only do you need several full time people to deal with user problems, you need several full time people to customize your solution such that it meets your needs, several full time people to baby the servers, and a whole management structure on top to ensure that the full time people talk to each other, and the actual users. $3000/head really is nothing to large companies. CVS developers don't understand, but for companies with several hundred designers, using CVS would end up costing a heckuvalot more. I have become so accustomed to features that are available in higher level systems such as ClearCase that I find it difficult to use CVS. It is the difference between black and white and colour. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 3:50 ` Mark Mielke @ 2002-10-10 4:16 ` Derek D. Martin 2002-10-10 4:56 ` Mark Mielke 0 siblings, 1 reply; 223+ messages in thread From: Derek D. Martin @ 2002-10-10 4:16 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: msg.pgp --] [-- Type: text/plain, Size: 2247 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At some point hitherto, Mark Mielke hath spake thusly: > Hardware costs are nothing really. The true killer with ClearCase is > the support costs. Not only do you need several full time people to > deal with user problems, you need several full time people to > customize your solution such that it meets your needs, several full > time people to baby the servers, and a whole management structure on > top to ensure that the full time people talk to each other, and the > actual users. I'd have to disagree... though it probably depends on your environment a great deal, and possibly how braindead your development team and/or your sysadmin team is. At a previous job, I was one of two system administrators that supported ClearCase in our Solaris environment for about 100 engineers. That is, there were two of us, and I never touched it. My coworker spent maybe an hour a week on it, discounting time spent migrating to new hardware and a new config when our environment changed (drastically). I think that, like most applications that aren't inherently broken, once you have it set up PROPERLY for your environment, it doesn't require much maintenance. Nor should it. OTOH like I said, I didn't touch it, so for all I know it could have been a horrid mess that the developers just weren't inclined to complain about. But I tend to doubt that... Oh, and we never really saw our manager much... ;-) Actually most of the time, the engineers appreciated that. For the most part, when they had problems, they just came to us directly, and we took care of them. The only time management got involved was when each of our visions of how things were supposed to work were miles apart, and we each felt strongly about our own vision. It was, in many ways, an ideal job. Unfortunately, as in most cases, circumstances change... I have no comment about whether or not BK is evil... ;-) - -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9pP8vdjdlQoHP510RAjFyAKC+LnSfXgaju5u0ujc+ZRgoLZcgwwCff3hU jiGSLgbERQ2QALdx4MRO4CI= =hfSD -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 4:16 ` Derek D. Martin @ 2002-10-10 4:56 ` Mark Mielke 2002-10-10 7:33 ` Jirka David 0 siblings, 1 reply; 223+ messages in thread From: Mark Mielke @ 2002-10-10 4:56 UTC (permalink / raw) To: linux-kernel On Thu, Oct 10, 2002 at 12:16:48AM -0400, Derek D. Martin wrote: > At some point hitherto, Mark Mielke hath spake thusly: > > Hardware costs are nothing really. The true killer with ClearCase is > > the support costs. Not only do you need several full time people to > > deal with user problems, you need several full time people to > > customize your solution such that it meets your needs, several full > > time people to baby the servers, and a whole management structure on > > top to ensure that the full time people talk to each other, and the > > actual users. > I'd have to disagree... though it probably depends on your environment > a great deal, and possibly how braindead your development team and/or > your sysadmin team is. At a previous job, I was one of two system > administrators that supported ClearCase in our Solaris environment for > about 100 engineers. That is, there were two of us, and I never > ... I may be talking about a company with 5000+ designers using ClearCase with many sites around the world... :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 4:56 ` Mark Mielke @ 2002-10-10 7:33 ` Jirka David 0 siblings, 0 replies; 223+ messages in thread From: Jirka David @ 2002-10-10 7:33 UTC (permalink / raw) To: linux-kernel Hi all. I'm currently working like a ClearCase admin and configuration manager in a world-wide company. And I can say the CC (ClearCase) is unbelievable expensive. In my country 1 developer on-site license costs about $6500. And another $6500 for multi-site license to share the same source code between two or more sites or countries. You have to have both of them to access multi-sited source database. It means $13000 !!!! for single developer. > > At a previous job, I was one of two system > > administrators that supported ClearCase in our Solaris environment for > > about 100 engineers. That is, there were two of us, and I never I am one of two administrators too. Configuration of the fully automated multi-sited with synchronisation of replicas system took us about 6 moths. But now a year after it works fine and without significant troubles. > I may be talking about a company with 5000+ designers using ClearCase > with many sites around the world... :-) So this is my point of wiew from CC admin of CC network with cca 1000 developers. CC is milk cow for Rational and is totaly unusable for the linux kernel developers. In this time I know nothing about BK, but who knows the future ... :o) Jiri ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-09 23:55 ` BK is *evil* corporate software [was Re: New BK License Problem?] Larry McVoy 2002-10-10 3:50 ` Mark Mielke @ 2002-10-10 7:26 ` Rogier Wolff 2002-10-10 13:36 ` Larry McVoy 2002-10-10 14:04 ` yodaiken 2 siblings, 1 reply; 223+ messages in thread From: Rogier Wolff @ 2002-10-10 7:26 UTC (permalink / raw) To: Larry McVoy, Henning P. Schmiedehausen, linux-kernel On Wed, Oct 09, 2002 at 04:55:00PM -0700, Larry McVoy wrote: > Sure. And if you have 3-5 developers there is no reason to not use CVS, > it works well enough. Or Subversion after it matures, or Arch, or Aegis, > or tarballs+diff+patch. > > We can't, and won't, compete at that level. You're comparing free against > what we charge. We're infinitely expensive in that comparison. > [at 25-100 developers, BK makes sense]... Larry, Why do you "give away" BK for single-user use? That's to make people familiar with the product so that they will know about it when they DO need it in the case that they end up in a situation where it does make sense. right? Now you're saying that you don't want the market of 2-10 developers: the other version control systems don't hurt enough. Would it make sense to allow these people to use BK for free under these circumstances, so that WHEN they grow, they are already using BK, and know exactly how to use it? My company with 2 developers will survive on tar&diff if you want money for BK from us. We might decide that "tar&diff" still works when we cross the 25 developer line..... You might want us to be using BK by that time. Roger. -- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * The Worlds Ecosystem is a stable system. Stable systems may experience * * excursions from the stable situation. We are currenly in such an * * excursion: The stable situation does not include humans. *************** ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 7:26 ` Rogier Wolff @ 2002-10-10 13:36 ` Larry McVoy 0 siblings, 0 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-10 13:36 UTC (permalink / raw) To: Rogier Wolff; +Cc: Larry McVoy, Henning P. Schmiedehausen, linux-kernel > Now you're saying that you don't want the market of 2-10 developers: > the other version control systems don't hurt enough. > > Would it make sense to allow these people to use BK for free under > these circumstances, so that WHEN they grow, they are already > using BK, and know exactly how to use it? If and only if letting them do so is zero cost to us. Otherwise what you are asking is that we spend money and not take in money. Doesn't make sense. And I don't think the BK docs are good enough that it would cost us zero dollars to roll out a new customer. > My company with 2 developers will survive on tar&diff if you want > money for BK from us. We might decide that "tar&diff" still works > when we cross the 25 developer line..... You might want us to be > using BK by that time. When you cross the 25 developer line, if tar+diff are working for you then there is no price where BK makes sense for you. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-09 23:55 ` BK is *evil* corporate software [was Re: New BK License Problem?] Larry McVoy 2002-10-10 3:50 ` Mark Mielke 2002-10-10 7:26 ` Rogier Wolff @ 2002-10-10 14:04 ` yodaiken 2002-10-10 16:14 ` Henning P. Schmiedehausen 2 siblings, 1 reply; 223+ messages in thread From: yodaiken @ 2002-10-10 14:04 UTC (permalink / raw) To: Larry McVoy, Henning P. Schmiedehausen, linux-kernel On Wed, Oct 09, 2002 at 04:55:00PM -0700, Larry McVoy wrote: > > Let's insert some fact in this discussion: > > OK. > > > Basically you charge a small(-ish) company about $25k for any > > reasonable license. This is about as much as we spent for Software in > > the last seven years (we do own a few Windows and Office licenses). The historical expense for software in your company has absolutely no relation to the cost-effectiveness of a new purchase as far as I can see. But it is interesting that you can hire a full time "really good" programmer for total cost of $50K/year. Salaries are dropping. -- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 14:04 ` yodaiken @ 2002-10-10 16:14 ` Henning P. Schmiedehausen 2002-10-10 16:25 ` Jeff Garzik 2002-10-10 16:38 ` Larry McVoy 0 siblings, 2 replies; 223+ messages in thread From: Henning P. Schmiedehausen @ 2002-10-10 16:14 UTC (permalink / raw) To: linux-kernel yodaiken@fsmlabs.com writes: >But it is interesting that you can hire a full time "really good" >programmer for total cost of $50K/year. Salaries are dropping. For small and medium companies (such as Siemens...), $50k (or the rough aequivalent of EUR 50k) are already good developers salary. The time of the "I can do Visual Basic and start at EUR 70k/year and expect 5% raise every year" developers are gone. Thank goodness for that. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de D-91054 Buckenhof Fax.: 09131 / 50654-20 ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 16:14 ` Henning P. Schmiedehausen @ 2002-10-10 16:25 ` Jeff Garzik 2002-10-10 16:52 ` Richard B. Johnson 2002-10-10 16:38 ` Larry McVoy 1 sibling, 1 reply; 223+ messages in thread From: Jeff Garzik @ 2002-10-10 16:25 UTC (permalink / raw) To: hps; +Cc: linux-kernel Henning P. Schmiedehausen wrote: > yodaiken@fsmlabs.com writes: > > >>But it is interesting that you can hire a full time "really good" >>programmer for total cost of $50K/year. Salaries are dropping. > > > For small and medium companies (such as Siemens...), $50k (or the > rough aequivalent of EUR 50k) are already good developers salary. You consider Siemens a medium company? ;-) They're friggin huge... 42 companies under their umbrella when I worked for them 10 years ago... Siemens AG was one of the world's largest conglomerates... Jeff ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 16:25 ` Jeff Garzik @ 2002-10-10 16:52 ` Richard B. Johnson 2002-10-10 17:28 ` Alan Cox 0 siblings, 1 reply; 223+ messages in thread From: Richard B. Johnson @ 2002-10-10 16:52 UTC (permalink / raw) To: Jeff Garzik; +Cc: hps, linux-kernel On Thu, 10 Oct 2002, Jeff Garzik wrote: > Henning P. Schmiedehausen wrote: > > yodaiken@fsmlabs.com writes: > > > > > >>But it is interesting that you can hire a full time "really good" > >>programmer for total cost of $50K/year. Salaries are dropping. > > > > > > For small and medium companies (such as Siemens...), $50k (or the > > rough aequivalent of EUR 50k) are already good developers salary. > > > You consider Siemens a medium company? ;-) They're friggin huge... 42 > companies under their umbrella when I worked for them 10 years ago... > Siemens AG was one of the world's largest conglomerates... > > Jeff > ...and they own and control more of the world than anything else, including the world's major armies, ever has during recorded history. If they were to abuse their power, Siemens could control the ultimate destiny of mankind. Scarey! Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). The US military has given us many words, FUBAR, SNAFU, now ENRON. Yes, top management were graduates of West Point and Annapolis. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 16:52 ` Richard B. Johnson @ 2002-10-10 17:28 ` Alan Cox 0 siblings, 0 replies; 223+ messages in thread From: Alan Cox @ 2002-10-10 17:28 UTC (permalink / raw) To: root; +Cc: Jeff Garzik, hps, Linux Kernel Mailing List On Thu, 2002-10-10 at 17:52, Richard B. Johnson wrote: > ...and they own and control more of the world than anything else, > including the world's major armies, ever has during recorded history. > If they were to abuse their power, Siemens could control the ultimate > destiny of mankind. Scarey! Siemens to take over redmond using transferrable power from the barvarian illuminat.. Oh wait wrong mailing list Can well kill the BK thread now please ? ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 16:14 ` Henning P. Schmiedehausen 2002-10-10 16:25 ` Jeff Garzik @ 2002-10-10 16:38 ` Larry McVoy 2002-10-10 18:57 ` Eli Carter 1 sibling, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-10 16:38 UTC (permalink / raw) To: Henning P. Schmiedehausen; +Cc: linux-kernel On Thu, Oct 10, 2002 at 04:14:03PM +0000, Henning P. Schmiedehausen wrote: > yodaiken@fsmlabs.com writes: > > >But it is interesting that you can hire a full time "really good" > >programmer for total cost of $50K/year. Salaries are dropping. > > For small and medium companies (such as Siemens...), $50k (or the > rough aequivalent of EUR 50k) are already good developers salary. But that $50K is not the whole story. That's *unburdened*, it doesn't include any of the associated costs such as benefits, taxes, office space, expenses, etc. When I was at SGI I was making around $130K and I was pretty high up in the salary curve. At the time, their *average* burdened cost was $180K/engineer/year. There is no way that $130K was the average engineer salary, it was quite a bit lower than that, my guess would be around 90 or 100. You're looking at all this from the typical engineer perspective. That's not a reasonable perspective at a company of any size. Management cares how much the tools cost if they make the engineers significantly more productive. The human costs dwarf the tools cost. So the real question is how much more do you get out of a team who is using BK than you would get out of a team who is using CVS or whatever. If the answer isn't at least the cost of BK then BK is obviously the wrong choice. My personal feeling is that the absolute lowest point that would make sense is a 2x difference. The reality is that for a company of any size, it's way bigger than that. If it wasn't, we'd have no customers. Times are tough. People aren't giving us money because they like us, they do it because the tool gives value in excess of the costs. One customer, when asked if we could tell people about their use of BK, refused to let us because they believe that BK was a competitive advantage, it helped them get to market faster than anyone else. Everyone has to decide for themselves what make sense. I tend to agree that paying for BK for a small number of seats doesn't make sense, with a small number of people you can get by easily with CVS or one of the other free tools. Eventually that will cause you problems and once those problems are costing you money, then you may see that spending that money on BK is actually a net reduction of cost. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 16:38 ` Larry McVoy @ 2002-10-10 18:57 ` Eli Carter 2002-10-10 19:01 ` Larry McVoy 0 siblings, 1 reply; 223+ messages in thread From: Eli Carter @ 2002-10-10 18:57 UTC (permalink / raw) To: Larry McVoy; +Cc: linux-kernel Larry McVoy wrote: [snip] > Everyone has to decide for themselves what make sense. I tend to agree > that paying for BK for a small number of seats doesn't make sense, > with a small number of people you can get by easily with CVS or one of > the other free tools. Eventually that will cause you problems and once > those problems are costing you money, then you may see that spending > that money on BK is actually a net reduction of cost. Ok, honest question for you Larry: Assume for the moment that I'm not eligible for the free BK license (I don't think that's the case, but for the question...). Assume that I plan a project that is going to start at 1 person and grow. Assume that at some point in the future, that project will grow large and complex enough to need BK. What source control should I use _now_ so that I can grow into BK over time? Bonus question: Why? (The answer may be something like 'CVS -> Subversion -> ... -> BK', but I don't know.) A little bit of background: In college I didn't know of source control. CVS was a godsend for me when I found it. But renames, copies, directories, dealing with multiple files in a change, those kinds of things "hurt" in CVS, even with just me. I want better tools, ideally open-source, but I suspect that I don't know what I'm looking for. TIA, Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 18:57 ` Eli Carter @ 2002-10-10 19:01 ` Larry McVoy 0 siblings, 0 replies; 223+ messages in thread From: Larry McVoy @ 2002-10-10 19:01 UTC (permalink / raw) To: Eli Carter; +Cc: Larry McVoy, linux-kernel > What source control should I use _now_ so that I can grow into BK over > time? Bonus question: Why? CVS. It's the most widely used system in the world, it has problems but you can work around those problems, the FreeBSD guys are all in CVS and so is Mozilla. When the day comes that you want to move out, we can import your history perfectly, you can't see the boundary where CVS stopped and BK started. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-09 23:34 ` Henning P. Schmiedehausen 2002-10-09 23:50 ` BK is *evil* corporate software David S. Miller 2002-10-09 23:55 ` BK is *evil* corporate software [was Re: New BK License Problem?] Larry McVoy @ 2002-10-10 0:03 ` Jamie Lokier 2002-10-10 7:31 ` Rogier Wolff 2 siblings, 1 reply; 223+ messages in thread From: Jamie Lokier @ 2002-10-10 0:03 UTC (permalink / raw) To: Henning P. Schmiedehausen; +Cc: linux-kernel Henning P. Schmiedehausen wrote: > bk might be interesting for larger companies with software budgets in > the six figure range and for open source. For the vast number of three > to five developers enterprises, it's simply unreasonably priced. For > 25k$ I get about six man months from a really good developer to work > on <insert your SCM here>. Larry's point is that six man months won't get you anywhere near as good as BK. I'm not sure how much effort Larry and his team put in, but a hand waving guess puts it at 200 or so man months (5 years times 3 developers, I am just guessing), minus the overhead of running a business (need to hunt for sales, follow the market etc.) which you wouldn't have. Let's call that 80% overhead, another hand waving guesstimate from my experience with working in a company. Assuming you miraculously would have no developer overhead, not even the cost of office space, admin, accountants etc. for employing someone, then at your really good developer rates, the correct price is 166k$ :-) For a small enterprise both prices are unreasonable. Which is precisely why you cannot afford to develop something like BK yourself from scratch -- and unfortunately you can't afford to buy it either. Oh you can probably _clone_ BK in 6 months though; programming's much less work than developing the concepts behind the program. Good luck, btw I'd appreciate if you GPL it, thanks :) -- Jamie ps. From my limited experience, the hard part in writing a program like BK isn't quantifiable in $$. One talented and motivated programmer probably _could_ develop BK in 6 months given all the right environment, input, skills, motivations and history. But their salary is the smallest part of that. How likely are you to _find_ a person who's specifically interested and skilled in developing high quality SCM systems, and who's been refining the ideas for the last 10 years? If it's the right person, you probably don't even need to pay them, just keep them fed and housed for the time it takes :-) ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-10 0:03 ` Jamie Lokier @ 2002-10-10 7:31 ` Rogier Wolff 0 siblings, 0 replies; 223+ messages in thread From: Rogier Wolff @ 2002-10-10 7:31 UTC (permalink / raw) To: Jamie Lokier; +Cc: Henning P. Schmiedehausen, linux-kernel On Thu, Oct 10, 2002 at 01:03:55AM +0100, Jamie Lokier wrote: > ps. From my limited experience, the hard part in writing a program > like BK isn't quantifiable in $$. One talented and motivated > programmer probably _could_ develop BK in 6 months given all the right > environment, input, skills, motivations and history. But their salary > is the smallest part of that. How likely are you to _find_ a person > who's specifically interested and skilled in developing high quality > SCM systems, and who's been refining the ideas for the last 10 years? Ehmmm. I think your're talking about BitMover. The talented guy with the vision is called Larry, and he's still using over 200 man-months to develop the b*tch... Roger. -- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * The Worlds Ecosystem is a stable system. Stable systems may experience * * excursions from the stable situation. We are currenly in such an * * excursion: The stable situation does not include humans. *************** ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-06 22:11 ` BK is *evil* corporate software [was Re: New BK License Problem?] Pavel Machek 2002-10-07 18:49 ` BK is *evil* corporate software David S. Miller 2002-10-07 18:51 ` BK is *evil* corporate software [was Re: New BK License Problem?] Mike Galbraith @ 2002-10-07 18:56 ` tom_gall 2002-10-07 20:44 ` Pavel Machek 2002-10-07 20:30 ` BK is *evil* corporate software [was Re: New BK License Problem?] Rik van Riel 3 siblings, 1 reply; 223+ messages in thread From: tom_gall @ 2002-10-07 18:56 UTC (permalink / raw) To: Pavel Machek; +Cc: Ben Collins, Larry McVoy, linux-kernel On Sunday, October 6, 2002, at 05:11 PM, Pavel Machek wrote: > Hi! > >> We're a business. We're a business which happens to be committed to >> helping the kernel team because we think that the kernel is vital to >> the world at large. Helping the kernel absolutely does not translate >> to helping people who happen to be our competitors. By your own > > Stop lying. Your job is to make lots of money and you are using Linux > as cheap advertising. You are trying to make people pay *you* to do > kernel development (as it stands you want $5000 for any bk-using > developer inside RedHat and SuSE). O Please! As the person that started this thread this is way way way way out there and quite frankly I find offensive. I do NOT honestly think that Larry made the change to the license that he did for the express purpose of milking some set of companies out of $$$$. That's just dumb. Like Larry and others who have made some rather good points over the couple of days, I think we're all trying to find a way to reasonably solve this that is is everyone's best interesting, including Larry's company. Granted it's a different kind of license, (IE Microsoft doesn't have a clause in IE that says Netscape developers can't use IE) but hey, it's Larry's company and he's perfectly in his rights to do so. It is truely a good thing that Larry is allowing some set of us in the open source community to use his product without costs. Personally I'm willing to pay a reasonable license fee for it but it's gotta be something that I can afford without getting my head torn off by my wife. Of course the other solution is to adjust the license a bit so folks like me who are just doing kernel work and not in competition with Larry's company (no matter what others in my company are doing) can use it. That's what I hope for... maybe it'll come true. Regards, Tom ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-07 18:56 ` tom_gall @ 2002-10-07 20:44 ` Pavel Machek 2002-10-07 20:55 ` Rik van Riel ` (2 more replies) 0 siblings, 3 replies; 223+ messages in thread From: Pavel Machek @ 2002-10-07 20:44 UTC (permalink / raw) To: tom_gall; +Cc: Pavel Machek, Ben Collins, Larry McVoy, linux-kernel Hi! > >>We're a business. We're a business which happens to be committed to > >>helping the kernel team because we think that the kernel is vital to > >>the world at large. Helping the kernel absolutely does not translate > >>to helping people who happen to be our competitors. By your own > > > >Stop lying. Your job is to make lots of money and you are using Linux > >as cheap advertising. You are trying to make people pay *you* to do > >kernel development (as it stands you want $5000 for any bk-using > >developer inside RedHat and SuSE). > > O Please! As the person that started this thread this is way way way > way out there and quite frankly I find offensive. > > I do NOT honestly think that Larry made the change to the license that > he did for the express purpose of milking some set of companies out of > $$$$. That's just dumb. Maybe it is doing for purpose of slowing down subversion/CVS/arch development. Thats about as bad. > Granted it's a different kind of license, (IE Microsoft doesn't have a > clause in IE that says Netscape developers can't use IE) but hey, it's > Larry's company and he's perfectly in his rights to do so. It is > truely a good thing that Larry is allowing some set of us in the open > source community to use his product without costs. Good thing for who? Good thing for Larry? I don't know. Good thing for us? I don't think so. Good thing for subversion developers? Definitely not. Pavel -- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-07 20:44 ` Pavel Machek @ 2002-10-07 20:55 ` Rik van Riel 2002-10-07 21:28 ` BK is *evil* corporate software tom_gall 2002-10-07 21:36 ` BK is *evil* corporate software [was Re: New BK License Problem?] Alexander Viro 2 siblings, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-07 20:55 UTC (permalink / raw) To: Pavel Machek Cc: tom_gall, Pavel Machek, Ben Collins, Larry McVoy, linux-kernel On Mon, 7 Oct 2002, Pavel Machek wrote: > Maybe it is doing for purpose of slowing down subversion/CVS/arch > development. Thats about as bad. You sound about as pissed off as you do in a random thread about somebody who violates the GPL, only now you're on the other side of the fence. If you don't like the new bitkeeper license, don't use bitkeeper. If you feel _really_ strongly about it, help the subversion people to build something as good as, or better than, bitkeeper so you can convince kernel hackers to switch. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software 2002-10-07 20:44 ` Pavel Machek 2002-10-07 20:55 ` Rik van Riel @ 2002-10-07 21:28 ` tom_gall 2002-10-07 21:36 ` BK is *evil* corporate software [was Re: New BK License Problem?] Alexander Viro 2 siblings, 0 replies; 223+ messages in thread From: tom_gall @ 2002-10-07 21:28 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-kernel On Monday, October 7, 2002, at 03:44 PM, Pavel Machek wrote: > Hi! > >> O Please! As the person that started this thread this is way way way >> way out there and quite frankly I find offensive. >> >> I do NOT honestly think that Larry made the change to the license that >> he did for the express purpose of milking some set of companies out of >> $$$$. That's just dumb. > > Maybe it is doing for purpose of slowing down subversion/CVS/arch > development. Thats about as bad. Bah! >> Granted it's a different kind of license, (IE Microsoft doesn't have a >> clause in IE that says Netscape developers can't use IE) but hey, it's >> Larry's company and he's perfectly in his rights to do so. It is >> truely a good thing that Larry is allowing some set of us in the open >> source community to use his product without costs. > > Good thing for who? Those developers who can use BitKeeper in their work, regardless if they paid for it or not. > Good thing for Larry? I don't know. Well that's for Larry to decide. I would hope that the benefits would be there for him. > Good thing for us? I don't think so. Don't look a productivity gain in the mouth. > Good thing for subversion developers? Definitely not. In this case yes are you correct. It's not good for them or for related technologies. OTOH, you'll get no break from companies such as Microsoft. Wanna clone MS Word, well you're buying it to do that. Course generally there's the reverse engineering clause. I do not understand in any way shape or form why you THINK it's reasonable for a company to give a competitor a leg up on putting them out of business. It's not. While it is normal for open source projects to cross pollinate, this is not the case here. BitKeeper is not open source software so you can't subject it to the same standards that you apply to Open source works. Regards, Tom ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-07 20:44 ` Pavel Machek 2002-10-07 20:55 ` Rik van Riel 2002-10-07 21:28 ` BK is *evil* corporate software tom_gall @ 2002-10-07 21:36 ` Alexander Viro 2002-10-17 17:52 ` 2.5.43 disk repartitioning problems Dave Olien 2 siblings, 1 reply; 223+ messages in thread From: Alexander Viro @ 2002-10-07 21:36 UTC (permalink / raw) To: Pavel Machek Cc: tom_gall, Pavel Machek, Ben Collins, Larry McVoy, linux-kernel On Mon, 7 Oct 2002, Pavel Machek wrote: > Good thing for who? > > Good thing for Larry? I don't know. > > Good thing for us? I don't think so. > > Good thing for subversion developers? Definitely not. Damn you. That thread got me to download subversion source and read it - mistake I won't repeat any time soon. I've spent several months wading through fairly disgusting code - block device drivers are not pretty, ditto for devfs. I had more than once found myself grabbing Lovecraft to read something that would be less nightmare-inducing. But _THAT_ takes the fscking cake - I don't _care_ what Larry (or anybody else for that matter) does to people who had excreted that code. No, wait - I _do_ care. I want video of the... event. I don't use BK, but you can be damn sure that I won't touch SVN. Ever. ^ permalink raw reply [flat|nested] 223+ messages in thread
* 2.5.43 disk repartitioning problems 2002-10-07 21:36 ` BK is *evil* corporate software [was Re: New BK License Problem?] Alexander Viro @ 2002-10-17 17:52 ` Dave Olien 2002-10-17 18:04 ` Dave Olien 2002-10-18 19:45 ` Bill Davidsen 0 siblings, 2 replies; 223+ messages in thread From: Dave Olien @ 2002-10-17 17:52 UTC (permalink / raw) To: Alexander Viro; +Cc: linux-kernel Al, I'm working on the Mylex DAC960 device driver, bring in up to date with the new block and dma interfaces. I've been posting patches on occasion. I've also noticed you updating the driver when you make changes to the gendisk kernel interfaces. Those updates are very helpful. I've noticed in 2.4.3 at least, that some changes to disk partitions aren't noticed until you reboot. The same problem is seen with aacraid. I don't THINK this is a driver issue. But, I might have missed something. I tried repartitioning two disks. On the first disk, I used fdisk to split a single large partition into four smaller ones. Afterwards, the first partition on that drive was still accessible. But I couldn't access the three new partitions. I didn't test to see if the first partition had been reduced in size. Rebooting made the new partitions accessible. In the second case, I split an unpartitioned drive into four partitions. None of the new partitions were accessible until I rebooted. Is this still a work in progress, or is there some driver hook I've missed? Thanks! Dave Olien Open Source Development Lab ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: 2.5.43 disk repartitioning problems 2002-10-17 17:52 ` 2.5.43 disk repartitioning problems Dave Olien @ 2002-10-17 18:04 ` Dave Olien 2002-10-18 19:45 ` Bill Davidsen 1 sibling, 0 replies; 223+ messages in thread From: Dave Olien @ 2002-10-17 18:04 UTC (permalink / raw) To: Alexander Viro; +Cc: linux-kernel I made a typo in the message below. The partitioning issue appears in linux 2.5.43. (NOT 2.4.3 ..) On Thu, Oct 17, 2002 at 10:52:05AM -0700, Dave Olien wrote: > > Al, > > I'm working on the Mylex DAC960 device driver, bring in up to date > with the new block and dma interfaces. I've been posting patches on > occasion. I've also noticed you updating the driver when you make changes > to the gendisk kernel interfaces. Those updates are very helpful. > > I've noticed in 2.4.3 at least, that some changes to disk partitions > aren't noticed until you reboot. The same problem is seen with aacraid. > I don't THINK this is a driver issue. But, I might have missed something. > > I tried repartitioning two disks. On the first disk, I used fdisk > to split a single large partition into four smaller ones. Afterwards, > the first partition on that drive was still accessible. But I couldn't > access the three new partitions. I didn't test to see if the first > partition had been reduced in size. Rebooting made the new partitions > accessible. > > In the second case, I split an unpartitioned drive into four partitions. > None of the new partitions were accessible until I rebooted. > > Is this still a work in progress, or is there some driver hook I've missed? > > Thanks! > > Dave Olien > Open Source Development Lab > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: 2.5.43 disk repartitioning problems 2002-10-17 17:52 ` 2.5.43 disk repartitioning problems Dave Olien 2002-10-17 18:04 ` Dave Olien @ 2002-10-18 19:45 ` Bill Davidsen 2002-10-18 22:17 ` Dave Olien 1 sibling, 1 reply; 223+ messages in thread From: Bill Davidsen @ 2002-10-18 19:45 UTC (permalink / raw) To: Dave Olien; +Cc: Alexander Viro, linux-kernel On Thu, 17 Oct 2002, Dave Olien wrote: > I'm working on the Mylex DAC960 device driver, bring in up to date > with the new block and dma interfaces. I've been posting patches on > occasion. I've also noticed you updating the driver when you make changes > to the gendisk kernel interfaces. Those updates are very helpful. > > I've noticed in 2.4.3 at least, that some changes to disk partitions > aren't noticed until you reboot. The same problem is seen with aacraid. > I don't THINK this is a driver issue. But, I might have missed something. Linux has always read the partition table at first use AFAIK. So if you have never used a drive you can repartition it and then use it, but once you use any one partition the table is not reread. I *think* if you unmount all partitions (including swapoff swaps) you can see changes, but that's from memory, I haven't tried it in a long time. Don't believe it's a bug, it's a design decision. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: 2.5.43 disk repartitioning problems 2002-10-18 19:45 ` Bill Davidsen @ 2002-10-18 22:17 ` Dave Olien 2002-10-19 17:39 ` Bill Davidsen 0 siblings, 1 reply; 223+ messages in thread From: Dave Olien @ 2002-10-18 22:17 UTC (permalink / raw) To: Bill Davidsen; +Cc: Alexander Viro, linux-kernel Bill, Hmm. The disks I'm working with aren't mounted and are not being used for swap. There are no applications holding any partitions open. At the time I'm modifying a disk's partition tables, there are no users of any partitions on that disk. I experimented removing and adding partitions in 2.4.18, and repeating those experiemnts in 2.5.43. The two versions of OS definately behave differently. Dave On Fri, Oct 18, 2002 at 03:45:50PM -0400, Bill Davidsen wrote: > On Thu, 17 Oct 2002, Dave Olien wrote: > > > I'm working on the Mylex DAC960 device driver, bring in up to date > > with the new block and dma interfaces. I've been posting patches on > > occasion. I've also noticed you updating the driver when you make changes > > to the gendisk kernel interfaces. Those updates are very helpful. > > > > I've noticed in 2.4.3 at least, that some changes to disk partitions > > aren't noticed until you reboot. The same problem is seen with aacraid. > > I don't THINK this is a driver issue. But, I might have missed something. > > Linux has always read the partition table at first use AFAIK. So if you > have never used a drive you can repartition it and then use it, but once > you use any one partition the table is not reread. > > I *think* if you unmount all partitions (including swapoff swaps) you can > see changes, but that's from memory, I haven't tried it in a long time. > > Don't believe it's a bug, it's a design decision. > > -- > bill davidsen <davidsen@tmr.com> > CTO, TMR Associates, Inc > Doing interesting things with little computers since 1979. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: 2.5.43 disk repartitioning problems 2002-10-18 22:17 ` Dave Olien @ 2002-10-19 17:39 ` Bill Davidsen 0 siblings, 0 replies; 223+ messages in thread From: Bill Davidsen @ 2002-10-19 17:39 UTC (permalink / raw) To: Dave Olien; +Cc: Alexander Viro, linux-kernel On Fri, 18 Oct 2002, Dave Olien wrote: > Hmm. > > The disks I'm working with aren't mounted and are not being used for > swap. There are no applications holding any partitions open. > At the time I'm modifying a disk's partition tables, there are no users > of any partitions on that disk. > > I experimented removing and adding partitions in 2.4.18, and repeating > those experiemnts in 2.5.43. The two versions of OS definately > behave differently. Okay, just wanted to clarify, since the stable 2.4 kernels do hold the partition table once they use it. Of course recent ones only use the first one in any case, but hopefully that's going to be fixed (or may have in 2.5.43-mm2, don't remember). -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK is *evil* corporate software [was Re: New BK License Problem?] 2002-10-06 22:11 ` BK is *evil* corporate software [was Re: New BK License Problem?] Pavel Machek ` (2 preceding siblings ...) 2002-10-07 18:56 ` tom_gall @ 2002-10-07 20:30 ` Rik van Riel 3 siblings, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-07 20:30 UTC (permalink / raw) To: Pavel Machek; +Cc: Ben Collins, Larry McVoy, linux-kernel On Mon, 7 Oct 2002, Pavel Machek wrote: > Stop lying. Look who's talking. *plonk* > (as it stands you want $5000 for any bk-using > developer inside RedHat and SuSE). Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 17:54 ` Ben Collins 2002-10-05 18:25 ` Larry McVoy @ 2002-10-06 0:27 ` Rik van Riel 2002-10-06 0:32 ` Ben Collins 1 sibling, 1 reply; 223+ messages in thread From: Rik van Riel @ 2002-10-06 0:27 UTC (permalink / raw) To: Ben Collins; +Cc: Larry McVoy, linux-kernel On Sat, 5 Oct 2002, Ben Collins wrote: > I've also been wanting to use bitkeeper to create a Subversion mirror of > the kernel repository, You don't need to use bitkeeper for that, you can download all the bitkeeper changesets as patches from my ftp site: ftp://nl.linux.org/pub/linux/bk2patch/ cheers, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 0:27 ` New BK License Problem? Rik van Riel @ 2002-10-06 0:32 ` Ben Collins 2002-10-06 0:53 ` Rik van Riel 0 siblings, 1 reply; 223+ messages in thread From: Ben Collins @ 2002-10-06 0:32 UTC (permalink / raw) To: Rik van Riel; +Cc: Larry McVoy, linux-kernel On Sat, Oct 05, 2002 at 09:27:25PM -0300, Rik van Riel wrote: > On Sat, 5 Oct 2002, Ben Collins wrote: > > > I've also been wanting to use bitkeeper to create a Subversion mirror of > > the kernel repository, > > You don't need to use bitkeeper for that, you can download all the > bitkeeper changesets as patches from my ftp site: > > ftp://nl.linux.org/pub/linux/bk2patch/ Oh, but that may be useless, unless you regenerate your patches whenever the tree is reparented. I ran into this while trying to do the same thing. Basing it on the ChangeSet ID is a waste, and it needs to be based on the ChangeSet key instead (the ChangeSet ID for a given key can change when a merge is done). -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 0:32 ` Ben Collins @ 2002-10-06 0:53 ` Rik van Riel 0 siblings, 0 replies; 223+ messages in thread From: Rik van Riel @ 2002-10-06 0:53 UTC (permalink / raw) To: Ben Collins; +Cc: Larry McVoy, linux-kernel On Sat, 5 Oct 2002, Ben Collins wrote: > > ftp://nl.linux.org/pub/linux/bk2patch/ > > Oh, but that may be useless, unless you regenerate your patches whenever > the tree is reparented. I ran into this while trying to do the same > thing. Basing it on the ChangeSet ID is a waste, and it needs to be > based on the ChangeSet key instead (the ChangeSet ID for a given key can > change when a merge is done). Good point. I'll need to look at this more closely... Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 20:55 New BK License Problem? tom_gall 2002-10-04 21:08 ` Larry McVoy @ 2002-10-05 13:10 ` Hans Reiser 2002-10-05 22:53 ` Murray J. Root 2002-10-05 13:17 ` Hans Reiser 2 siblings, 1 reply; 223+ messages in thread From: Hans Reiser @ 2002-10-05 13:10 UTC (permalink / raw) To: tom_gall; +Cc: linux-kernel tom_gall@mac.com wrote: > Greetings all, > > I noticed Larry recently changed the license on bk. Once clause in > particular struck me and I thought I'd better point it out for your > reactions... > > Specifically from Section 3: > > (d) Notwithstanding any other terms in this License, this > License is not available to You if You and/or your > employer develop, produce, sell, and/or resell a > product which contains substantially similar capabil- > ities of the BitKeeper Software, or, in the reason- > able opinion of BitMover, competes with the BitKeeper > Software. > Seems like a pretty straightforward violation of the anti-trust laws, and a conspiracy to restrain trade. Hope Larry votes for Bush's reelection, cause Bush judges will keep Larry safe from the law on this for sure. Hans ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 13:10 ` Hans Reiser @ 2002-10-05 22:53 ` Murray J. Root 2002-10-05 23:21 ` Larry McVoy 2002-10-06 0:48 ` Rik van Riel 0 siblings, 2 replies; 223+ messages in thread From: Murray J. Root @ 2002-10-05 22:53 UTC (permalink / raw) To: linux-kernel On Sat, Oct 05, 2002 at 05:10:33PM +0400, Hans Reiser wrote: > tom_gall@mac.com wrote: > > >Greetings all, > > > >I noticed Larry recently changed the license on bk. Once clause in > >particular struck me and I thought I'd better point it out for your > >reactions... > > > >Specifically from Section 3: > > > > (d) Notwithstanding any other terms in this License, this > > License is not available to You if You and/or your > > employer develop, produce, sell, and/or resell a > > product which contains substantially similar capabil- > > ities of the BitKeeper Software, or, in the reason- > > able opinion of BitMover, competes with the BitKeeper > > Software. > > > Seems like a pretty straightforward violation of the anti-trust laws, > and a conspiracy to restrain trade. Hope Larry votes for Bush's > reelection, cause Bush judges will keep Larry safe from the law on this > for sure. > Yup - a blatant and outright violation. Worse - it's also illegal to refuse to do business with someone based on who their employer is, in most states. Also - it's an attempt to restrict first-purchase rights. Most courts have found such clauses to be unenforcable in standard contracts - I doubt a shrink-wrap license is gonna fare any better. -- Murray J. Root ------------------------------------------------ DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/ ------------------------------------------------ Mandrake on irc.freenode.net: #mandrake & #mandrake-linux = help for newbies #mdk-cooker = Mandrake Cooker ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 22:53 ` Murray J. Root @ 2002-10-05 23:21 ` Larry McVoy 2002-10-05 23:49 ` Murray J. Root 2002-10-06 0:48 ` Rik van Riel 1 sibling, 1 reply; 223+ messages in thread From: Larry McVoy @ 2002-10-05 23:21 UTC (permalink / raw) To: linux-kernel On Sat, Oct 05, 2002 at 06:53:10PM -0400, Murray J. Root wrote: > > Seems like a pretty straightforward violation of the anti-trust laws, > > and a conspiracy to restrain trade. Hope Larry votes for Bush's > > reelection, cause Bush judges will keep Larry safe from the law on this > > for sure. > > > Yup - a blatant and outright violation. Then by all means, file a lawsuit if that's what you feel. > Worse - it's also illegal to refuse to do business with someone > based on who their employer is, in most states. Err, this is the BKL, no money is changing hands. I'm pretty sure that the courts will let us decide under what terms we allow people to use our software for free. > Also - it's an attempt to restrict first-purchase rights. No, this is the BKL. There is no such clause in the BKCL. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 23:21 ` Larry McVoy @ 2002-10-05 23:49 ` Murray J. Root 0 siblings, 0 replies; 223+ messages in thread From: Murray J. Root @ 2002-10-05 23:49 UTC (permalink / raw) To: linux-kernel; +Cc: Larry McVoy On Sat, Oct 05, 2002 at 04:21:44PM -0700, Larry McVoy wrote: > On Sat, Oct 05, 2002 at 06:53:10PM -0400, Murray J. Root wrote: > > > Seems like a pretty straightforward violation of the anti-trust laws, > > > and a conspiracy to restrain trade. Hope Larry votes for Bush's > > > reelection, cause Bush judges will keep Larry safe from the law on this > > > for sure. > > > > > Yup - a blatant and outright violation. > > Then by all means, file a lawsuit if that's what you feel. > My only intent is to offer potential defenses should you choose to go after any kernel hackers. Beyond that - I don't care. Put whatever you want into the license. -- Murray J. Root ------------------------------------------------ DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/ ------------------------------------------------ Mandrake on irc.freenode.net: #mandrake & #mandrake-linux = help for newbies #mdk-cooker = Mandrake Cooker ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 22:53 ` Murray J. Root 2002-10-05 23:21 ` Larry McVoy @ 2002-10-06 0:48 ` Rik van Riel 2002-10-06 19:21 ` Mark Mielke 1 sibling, 1 reply; 223+ messages in thread From: Rik van Riel @ 2002-10-06 0:48 UTC (permalink / raw) To: Murray J. Root; +Cc: linux-kernel On Sat, 5 Oct 2002, Murray J. Root wrote: > On Sat, Oct 05, 2002 at 05:10:33PM +0400, Hans Reiser wrote: > > Seems like a pretty straightforward violation of the anti-trust laws, > Worse - it's also illegal to refuse to do business with someone > based on who their employer is, in most states. Bitkeeper isn't refusing business. They just refuse to give away their product for free to competitors, but these competitors can still ask Bitkeeper for the normal commercial license ... regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-06 0:48 ` Rik van Riel @ 2002-10-06 19:21 ` Mark Mielke 0 siblings, 0 replies; 223+ messages in thread From: Mark Mielke @ 2002-10-06 19:21 UTC (permalink / raw) To: Rik van Riel; +Cc: Murray J. Root, linux-kernel On Sat, Oct 05, 2002 at 09:48:25PM -0300, Rik van Riel wrote: > On Sat, 5 Oct 2002, Murray J. Root wrote: > > On Sat, Oct 05, 2002 at 05:10:33PM +0400, Hans Reiser wrote: > > > Seems like a pretty straightforward violation of the anti-trust laws, > > Worse - it's also illegal to refuse to do business with someone > > based on who their employer is, in most states. > Bitkeeper isn't refusing business. They just refuse to give away > their product for free to competitors, but these competitors can > still ask Bitkeeper for the normal commercial license ... For perspective on where Larry's license may work against him... (NOTE: Larry: I'm not telling you what you can or cannot put in your license... I am only offering perspective...) At Nortel I am the software architect for a source management system based on top of ClearCase that our department develops. One of the concepts that we have implemented on top of ClearCase is change sets. Under the wording of the license, I believe that I am not allowed to use BK for free. >From the perspective of Linux kernel development, it means that I cannot submit patches using BK unless I pay for BK, which I do not intend to do. As I am not an active kernel developer (I am spending time familiarizing myself with it at the current point in time), my personal case does not hamper Linux kernel development, however, I do not believe it is a stretch to imagine somebody in a similar position as me, wanting to actively submit patches to Linux. As a professional in the source management field, I am very aware of the benefits of using an effective source management system, and would find it difficult (psychologically and practically speaking) to maintain a large set of patches outside of BK. >From the perspective of BK commercial interests, since I am not able to use BK for free, and I do not intend to spend money out of my own pocket to purchase the right to use BK, I am limited in the manner in which I could encourage people within Nortel to consider BK as a creditable alternative to ClearCase either as a full solution, or as a solution that we customized. This point is dampened by the fact that Nortel is (still) very large, and would need more reasons that 'it works better' to invest money into significantly altering their source management infrastructure, however, I think the point still stands. If BK truly is as better than ClearCase as some of us may feel that it is, the point definately stands. In any case, I'm confident that if somebody such as myself presented a proper case to Larry, that allowed Larry to be comfortable enough to believe that 'somebody' would not use the free license to steal Larry's customers (present and future) without having paid for a license, he would consider doing something about it and making an exception. Larry isn't Satan, even though he dares to sell 'almost Open Source' software. I'm only offering some perspective... :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-04 20:55 New BK License Problem? tom_gall 2002-10-04 21:08 ` Larry McVoy 2002-10-05 13:10 ` Hans Reiser @ 2002-10-05 13:17 ` Hans Reiser 2002-10-05 13:48 ` FD Cami 2 siblings, 1 reply; 223+ messages in thread From: Hans Reiser @ 2002-10-05 13:17 UTC (permalink / raw) To: tom_gall; +Cc: linux-kernel Oh my, does this mean that if I use BitKeeper software, I am a participant in a conspiracy to restrain trade? Consider: I make reiser4 available by bitkeeper. Competitor of larry wants to use reiser4 but can't access it because access requires bitkeeper. Larry has given me an incentive to participate in discriminating against his competitors (free license for bitkeeper). Am I legally liable and subject to criminal charges if a Clinton judge gets the case? Hans tom_gall@mac.com wrote: > Greetings all, > > I noticed Larry recently changed the license on bk. Once clause in > particular struck me and I thought I'd better point it out for your > reactions... > > Specifically from Section 3: > > (d) Notwithstanding any other terms in this License, this > License is not available to You if You and/or your > employer develop, produce, sell, and/or resell a > product which contains substantially similar capabil- > ities of the BitKeeper Software, or, in the reason- > able opinion of BitMover, competes with the BitKeeper > Software. > > Doesn't this affect maintainers all across the map that work for > distros such as RedHat, SuSE, Connectiva, etc? Obviously these > distros SELL as part of their respective products CVS and similar > tools. Or even non-distro open source shops, you even resell CVS or > the like in some way and you'd be in trouble. > > While I am all for Larry having a profitable business, this would seem > to be a change which is not Open Source developer friendly. > > Regards, > > Tom > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 13:17 ` Hans Reiser @ 2002-10-05 13:48 ` FD Cami 2002-10-05 13:41 ` Hans Reiser 0 siblings, 1 reply; 223+ messages in thread From: FD Cami @ 2002-10-05 13:48 UTC (permalink / raw) To: Hans Reiser; +Cc: linux-kernel, Larry McVoy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans Reiser wrote: | Oh my, does this mean that if I use BitKeeper software, I am a | participant in a conspiracy to restrain trade? | | Consider: I make reiser4 available by bitkeeper. Competitor of larry | wants to use reiser4 but can't access it because access requires | bitkeeper. Larry has given me an incentive to participate in | discriminating against his competitors (free license for bitkeeper). Am | I legally liable and subject to criminal charges if a Clinton judge gets | the case? | | Hans Good point... Although I think it would be unfair, for example, to be able to use BitKeeper to develop a _commercial_ product that would compete with BitKeeper. So, _maybe_ the license should be : " Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a closed source (GPL, like CVS) product which contains substantially similar capabilities of the BitKeeper Software, or, in the reasonable opinion of BitMover, competes with the BitKeeper Software. " But of course, who am I to decide... Larry ? ;-) FD Cami | tom_gall@mac.com wrote: | |> Greetings all, |> |> I noticed Larry recently changed the license on bk. Once clause in |> particular struck me and I thought I'd better point it out for your |> reactions... |> |> Specifically from Section 3: |> |> (d) Notwithstanding any other terms in this License, this |> License is not available to You if You and/or your |> employer develop, produce, sell, and/or resell a |> product which contains substantially similar capabil- |> ities of the BitKeeper Software, or, in the reason- |> able opinion of BitMover, competes with the BitKeeper |> Software. |> |> Doesn't this affect maintainers all across the map that work for |> distros such as RedHat, SuSE, Connectiva, etc? Obviously these |> distros SELL as part of their respective products CVS and similar |> tools. Or even non-distro open source shops, you even resell CVS or |> the like in some way and you'd be in trouble. |> |> While I am all for Larry having a profitable business, this would seem |> to be a change which is not Open Source developer friendly. |> |> Regards, |> |> Tom - ---------------------------------------------------------- ~ "To disable the Internet to save EMI and Disney is the moral equivalent of burning down the library of Alexandria to ensure the livelihood of monastic scribes." ~ - John Ippolito (Guggenheim Institute) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9nu2suBGY13rZQM8RAt4XAJ4xGVm8ZgF1MmdrkUzKoP8dJIrWRQCfVs8w ZXwhHmIuKAyuKqK7bCM8YWs= =rNXC -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: New BK License Problem? 2002-10-05 13:48 ` FD Cami @ 2002-10-05 13:41 ` Hans Reiser 0 siblings, 0 replies; 223+ messages in thread From: Hans Reiser @ 2002-10-05 13:41 UTC (permalink / raw) To: FD Cami; +Cc: linux-kernel, Larry McVoy I don't see how your wording changes anything in regards to whether the effect is to restrain trade. Hans FD Cami wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hans Reiser wrote: > | Oh my, does this mean that if I use BitKeeper software, I am a > | participant in a conspiracy to restrain trade? > | > | Consider: I make reiser4 available by bitkeeper. Competitor of larry > | wants to use reiser4 but can't access it because access requires > | bitkeeper. Larry has given me an incentive to participate in > | discriminating against his competitors (free license for > bitkeeper). Am > | I legally liable and subject to criminal charges if a Clinton judge > gets > | the case? > | > | Hans > > Good point... Although I think it would be unfair, for example, to > be able to use BitKeeper to develop a _commercial_ product that > would compete with BitKeeper. > So, _maybe_ the license should be : > > " > Notwithstanding any other terms in this License, this License is not > available to You if You and/or your employer develop, produce, > sell, and/or resell a closed source (GPL, like CVS) product which > contains substantially similar capabilities of the BitKeeper Software, > or, in the reasonable opinion of BitMover, competes with the BitKeeper > Software. > " > > But of course, who am I to decide... Larry ? ;-) > > FD Cami > > ^ permalink raw reply [flat|nested] 223+ messages in thread
* Re: BK kernel commits list
@ 2002-10-09 21:05 Hank Leininger
0 siblings, 0 replies; 223+ messages in thread
From: Hank Leininger @ 2002-10-09 21:05 UTC (permalink / raw)
To: linux-kernel
On 2002-10-09, "David S. Miller" <davem@redhat.com> wrote:
> I've created:
> bk-commits-head@vger.kernel.org
> bk-commits-24@vger.kernel.org
FYI, I added these to the MARC list archives:
http://marc.theaimsgroup.com/?l=bk-commits-head&r=1&w=2
http://marc.theaimsgroup.com/?l=bk-commits-24&r=1&w=2
...Sometime last night, so they've got all of today's traffic.
--
Hank Leininger <hlein@progressive-comp.com>
^ permalink raw reply [flat|nested] 223+ messages in thread
end of thread, other threads:[~2002-10-19 17:34 UTC | newest] Thread overview: 223+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-10-04 20:55 New BK License Problem? tom_gall 2002-10-04 21:08 ` Larry McVoy 2002-10-04 21:33 ` tom_gall 2002-10-04 21:38 ` Larry McVoy 2002-10-04 22:16 ` Dr. David Alan Gilbert 2002-10-04 22:36 ` Roman Zippel 2002-10-05 0:04 ` David S. Miller 2002-10-05 0:32 ` Larry McVoy 2002-10-05 1:54 ` John Levon 2002-10-05 10:26 ` Roman Zippel 2002-10-05 10:23 ` David S. Miller 2002-10-05 0:50 ` Rob Landley 2002-10-06 2:17 ` Daniel Berlin 2002-10-04 23:02 ` David S. Miller 2002-10-04 23:33 ` Larry McVoy 2002-10-04 23:28 ` David S. Miller [not found] ` <20021005003840.GQ710@gallifrey> [not found] ` <20021004174501.Q835@work.bitmover.com> [not found] ` <20021005005344.GR710@gallifrey> [not found] ` <20021004180600.R835@work.bitmover.com> [not found] ` <20021005011706.GU710@gallifrey> [not found] ` <20021004185325.V835@work.bitmover.com> 2002-10-05 11:54 ` Dr. David Alan Gilbert 2002-10-05 17:54 ` Ben Collins 2002-10-05 18:25 ` Larry McVoy 2002-10-05 18:35 ` Ben Collins 2002-10-05 18:41 ` Lars Marowsky-Bree 2002-10-05 19:06 ` Ben Collins 2002-10-05 19:24 ` Ulrich Drepper 2002-10-05 19:43 ` Larry McVoy 2002-10-05 19:51 ` Nicolas Pitre 2002-10-06 0:42 ` Rik van Riel 2002-10-05 20:21 ` Ulrich Drepper 2002-10-05 23:28 ` Larry McVoy 2002-10-05 23:50 ` Alan Cox 2002-10-05 23:44 ` Alexander Viro 2002-10-05 23:53 ` Larry McVoy 2002-10-06 3:40 ` Jan Harkes 2002-10-06 8:28 ` Jeff Garzik 2002-10-06 8:46 ` Skip Ford 2002-10-06 9:06 ` Jeff Garzik 2002-10-06 9:24 ` David S. Miller 2002-10-06 14:03 ` Larry McVoy 2002-10-06 14:18 ` Ingo Molnar 2002-10-06 15:27 ` Skip Ford 2002-10-08 21:13 ` David Woodhouse 2002-10-08 22:04 ` David S. Miller 2002-10-08 22:06 ` Rik van Riel 2002-10-08 22:15 ` Skip Ford 2002-10-08 22:53 ` Rik van Riel 2002-10-08 22:25 ` David Woodhouse 2002-10-08 22:15 ` David Woodhouse 2002-10-08 22:24 ` Dave Jones 2002-10-08 22:20 ` David S. Miller 2002-10-08 22:31 ` Jeff Garzik 2002-10-08 22:26 ` David Woodhouse 2002-10-08 22:45 ` Dave Jones 2002-10-09 0:51 ` BK kernel commits list David S. Miller 2002-10-09 11:49 ` Skip Ford 2002-10-09 11:58 ` David S. Miller 2002-10-09 12:17 ` David Woodhouse 2002-10-09 12:12 ` David S. Miller 2002-10-09 14:11 ` Jeff Garzik 2002-10-09 14:44 ` Ben Collins 2002-10-09 14:55 ` David Woodhouse 2002-10-09 14:58 ` Ben Collins 2002-10-09 19:48 ` Jeff Garzik 2002-10-09 19:59 ` Robert Love 2002-10-09 20:32 ` Skip Ford 2002-10-09 20:34 ` Jeff Garzik 2002-10-09 19:59 ` Ben Collins 2002-10-09 20:52 ` David Woodhouse 2002-10-09 21:02 ` Robert Love 2002-10-09 20:41 ` David Woodhouse 2002-10-06 0:49 ` New BK License Problem? Rik van Riel 2002-10-06 4:43 ` David S. Miller 2002-10-06 5:50 ` Linus Torvalds 2002-10-06 7:43 ` Skip Ford 2002-10-06 8:13 ` Jeff Garzik 2002-10-06 9:21 ` David S. Miller 2002-10-06 16:38 ` Arnaldo Carvalho de Melo 2002-10-06 17:02 ` Alan Cox 2002-10-06 17:12 ` Russell King 2002-10-06 21:06 ` Rik van Riel 2002-10-06 17:03 ` Skip Ford 2002-10-06 23:05 ` Larry McVoy 2002-10-07 0:42 ` Rob Landley 2002-10-06 8:00 ` Jeff Garzik 2002-10-06 11:04 ` Ingo Molnar 2002-10-06 10:57 ` David S. Miller 2002-10-06 11:24 ` Ingo Molnar 2002-10-06 10:59 ` David S. Miller 2002-10-06 12:04 ` BK MetaData " Ingo Molnar 2002-10-06 11:52 ` David S. Miller 2002-10-06 12:18 ` jbradford 2002-10-06 12:35 ` jw schultz 2002-10-06 12:18 ` Ingo Molnar 2002-10-06 16:18 ` Daniel Berlin 2002-10-06 13:48 ` Russell King 2002-10-06 14:10 ` Ingo Molnar 2002-10-06 14:08 ` Russell King 2002-10-06 16:58 ` Alan Cox 2002-10-06 17:06 ` jbradford 2002-10-06 19:12 ` Marek Habersack 2002-10-06 14:23 ` jbradford 2002-10-06 19:39 ` Linus Torvalds 2002-10-06 20:00 ` Ingo Molnar 2002-10-06 22:52 ` Larry McVoy 2002-10-07 6:08 ` Ingo Molnar 2002-10-07 6:07 ` Larry McVoy 2002-10-06 17:17 ` Jes Sorensen 2002-10-06 17:38 ` Larry McVoy 2002-10-06 17:41 ` Alan Cox 2002-10-06 17:45 ` Jes Sorensen 2002-10-06 22:49 ` Larry McVoy 2002-10-06 12:10 ` New BK " Ingo Molnar 2002-10-06 4:25 ` David S. Miller 2002-10-06 9:00 ` Jeff Garzik 2002-10-06 3:35 ` Jan Harkes 2002-10-05 19:47 ` Nicolas Pitre 2002-10-05 19:54 ` Larry McVoy 2002-10-05 19:56 ` Larry McVoy 2002-10-07 2:01 ` Ben Collins 2002-10-07 2:10 ` Rik van Riel 2002-10-07 2:29 ` Larry McVoy 2002-10-07 2:38 ` Rik van Riel 2002-10-07 3:07 ` Rik van Riel 2002-10-10 3:48 ` rsync kernel tree " jw schultz 2002-10-06 22:03 ` Aaron Lehmann 2002-10-06 22:33 ` Rik van Riel 2002-10-06 22:45 ` Aaron Lehmann 2002-10-06 22:59 ` Rik van Riel 2002-10-06 23:15 ` Pavel Machek 2002-10-07 19:06 ` Nicolas Pitre 2002-10-07 20:19 ` Alan Cox 2002-10-07 20:24 ` Nicolas Pitre 2002-10-07 20:37 ` Pavel Machek 2002-10-07 20:54 ` Nicolas Pitre 2002-10-07 21:10 ` Pavel Machek 2002-10-08 9:11 ` Vojtech Pavlik 2002-10-08 1:05 ` Mark Mielke 2002-10-06 0:34 ` Rik van Riel 2002-10-06 0:45 ` Larry McVoy 2002-10-05 19:15 ` Larry McVoy 2002-10-05 19:46 ` jbradford 2002-10-06 22:18 ` Daniel Phillips 2002-10-06 23:54 ` Jeff Dike 2002-10-06 22:57 ` Rik van Riel 2002-10-06 22:57 ` Daniel Phillips 2002-10-06 13:46 ` Ingo Molnar 2002-10-06 13:59 ` Ingo Molnar 2002-10-06 14:56 ` Larry McVoy 2002-10-06 15:22 ` Ingo Molnar 2002-10-06 15:15 ` Larry McVoy 2002-10-06 15:39 ` Alexandre Dulaunoy 2002-10-07 1:21 ` Rob Landley 2002-10-07 6:29 ` Larry McVoy 2002-10-07 2:27 ` Rob Landley 2002-10-07 15:43 ` Jan Harkes 2002-10-07 16:06 ` Rik van Riel 2002-10-07 16:18 ` Larry McVoy 2002-10-06 16:30 ` Werner Almesberger 2002-10-07 9:37 ` Geert Uytterhoeven 2002-10-07 14:50 ` Larry McVoy 2002-10-07 18:45 ` Abramo Bagnara 2002-10-06 21:31 ` Miquel van Smoorenburg 2002-10-06 22:05 ` Larry McVoy 2002-10-06 22:16 ` Rik van Riel 2002-10-06 22:19 ` Robert Love 2002-10-06 22:36 ` Larry McVoy 2002-10-06 23:22 ` Hans Reiser 2002-10-06 13:59 ` Ben Collins 2002-10-06 14:14 ` Ingo Molnar 2002-10-06 14:53 ` Larry McVoy 2002-10-06 15:37 ` Ingo Molnar 2002-10-06 22:11 ` BK is *evil* corporate software [was Re: New BK License Problem?] Pavel Machek 2002-10-07 18:49 ` BK is *evil* corporate software David S. Miller 2002-10-07 20:12 ` Alan Cox 2002-10-07 20:14 ` Pavel Machek 2002-10-07 21:23 ` Roman Zippel 2002-10-07 18:51 ` BK is *evil* corporate software [was Re: New BK License Problem?] Mike Galbraith 2002-10-07 21:31 ` Larry McVoy 2002-10-09 23:34 ` Henning P. Schmiedehausen 2002-10-09 23:50 ` BK is *evil* corporate software David S. Miller 2002-10-10 1:08 ` Larry McVoy 2002-10-10 1:47 ` Keith Owens 2002-10-10 8:09 ` Henning Schmiedehausen 2002-10-10 8:28 ` Off topic, bandwidth wasting, waffle about Bit Keeper jbradford 2002-10-09 23:55 ` BK is *evil* corporate software [was Re: New BK License Problem?] Larry McVoy 2002-10-10 3:50 ` Mark Mielke 2002-10-10 4:16 ` Derek D. Martin 2002-10-10 4:56 ` Mark Mielke 2002-10-10 7:33 ` Jirka David 2002-10-10 7:26 ` Rogier Wolff 2002-10-10 13:36 ` Larry McVoy 2002-10-10 14:04 ` yodaiken 2002-10-10 16:14 ` Henning P. Schmiedehausen 2002-10-10 16:25 ` Jeff Garzik 2002-10-10 16:52 ` Richard B. Johnson 2002-10-10 17:28 ` Alan Cox 2002-10-10 16:38 ` Larry McVoy 2002-10-10 18:57 ` Eli Carter 2002-10-10 19:01 ` Larry McVoy 2002-10-10 0:03 ` Jamie Lokier 2002-10-10 7:31 ` Rogier Wolff 2002-10-07 18:56 ` tom_gall 2002-10-07 20:44 ` Pavel Machek 2002-10-07 20:55 ` Rik van Riel 2002-10-07 21:28 ` BK is *evil* corporate software tom_gall 2002-10-07 21:36 ` BK is *evil* corporate software [was Re: New BK License Problem?] Alexander Viro 2002-10-17 17:52 ` 2.5.43 disk repartitioning problems Dave Olien 2002-10-17 18:04 ` Dave Olien 2002-10-18 19:45 ` Bill Davidsen 2002-10-18 22:17 ` Dave Olien 2002-10-19 17:39 ` Bill Davidsen 2002-10-07 20:30 ` BK is *evil* corporate software [was Re: New BK License Problem?] Rik van Riel 2002-10-06 0:27 ` New BK License Problem? Rik van Riel 2002-10-06 0:32 ` Ben Collins 2002-10-06 0:53 ` Rik van Riel 2002-10-05 13:10 ` Hans Reiser 2002-10-05 22:53 ` Murray J. Root 2002-10-05 23:21 ` Larry McVoy 2002-10-05 23:49 ` Murray J. Root 2002-10-06 0:48 ` Rik van Riel 2002-10-06 19:21 ` Mark Mielke 2002-10-05 13:17 ` Hans Reiser 2002-10-05 13:48 ` FD Cami 2002-10-05 13:41 ` Hans Reiser 2002-10-09 21:05 BK kernel commits list Hank Leininger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).