New BK License Problem?

New BK License Problem?

[tom_gall]

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

Re: New BK License Problem?

[Larry McVoy]

> 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 

Re: New BK License Problem?

[tom_gall]

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

Re: New BK License Problem?

[Larry McVoy]

> > 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 

Re: New BK License Problem?

[Dr. David Alan Gilbert]

* 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   |_______/

Re: New BK License Problem?

[Roman Zippel]

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

Re: New BK License Problem?

[David S. Miller]

   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~~~~~~

Re: New BK License Problem?

[Larry McVoy]

> 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 

Re: New BK License Problem?

[John Levon]

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

Re: New BK License Problem?

[Roman Zippel]

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

Re: New BK License Problem?

[David S. Miller]

   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 :-)

Re: New BK License Problem?

[Rob Landley]

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

Re: New BK License Problem?

[Daniel Berlin]

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

Re: New BK License Problem?

[David S. Miller]

   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 :-)

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[David S. Miller]

   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.

Re: New BK License Problem?

[Dr. David Alan Gilbert]

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   |_______/

Re: New BK License Problem?

[Ben Collins]

> >         (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/

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Ben Collins]

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/

Re: New BK License Problem?

[Lars Marowsky-Bree]

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

Re: New BK License Problem?

[Ben Collins]

> 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/

Re: New BK License Problem?

[Ulrich Drepper]

-----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-----

Re: New BK License Problem?

[Larry McVoy]

> 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 

Re: New BK License Problem?

[Nicolas Pitre]

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

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Ulrich Drepper]

-----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-----

Re: New BK License Problem?

[Larry McVoy]

> 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 

Re: New BK License Problem?

[Alan Cox]

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

Re: New BK License Problem?

[Alexander Viro]

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...

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Jan Harkes]

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

Re: New BK License Problem?

[Jeff Garzik]

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...)

Re: New BK License Problem?

[Skip Ford]

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

Re: New BK License Problem?

[Jeff Garzik]

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

Re: New BK License Problem?

[David S. Miller]

   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.

Re: New BK License Problem?

[Larry McVoy]

> 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 

Re: New BK License Problem?

[Ingo Molnar]

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

Re: New BK License Problem?

[Skip Ford]

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

Re: New BK License Problem?

[David Woodhouse]

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

Re: New BK License Problem?

[David S. Miller]

   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.

Re: New BK License Problem?

[Rik van Riel]

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>

Re: New BK License Problem?

[Skip Ford]

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

Re: New BK License Problem?

[Rik van Riel]

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>

Re: New BK License Problem?

[David Woodhouse]

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

Re: New BK License Problem?

[David Woodhouse]

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

Re: New BK License Problem?

[Dave Jones]

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

Re: New BK License Problem?

[David S. Miller]

   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?

Re: New BK License Problem?

[Jeff Garzik]

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

Re: New BK License Problem?

[David Woodhouse]

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

Re: New BK License Problem?

[Dave Jones]

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

BK kernel commits list

[David S. Miller]

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.

Re: BK kernel commits list

[Skip Ford]

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

Re: BK kernel commits list

[David S. Miller]

   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.

Re: BK kernel commits list

[David Woodhouse]

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

Re: BK kernel commits list

[David S. Miller]

   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?

Re: BK kernel commits list

[Jeff Garzik]

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.

Re: BK kernel commits list

[Ben Collins]

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/

Re: BK kernel commits list

[David Woodhouse]

[-- 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 --]

Re: BK kernel commits list

[Ben Collins]

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/

Re: BK kernel commits list

[Jeff Garzik]

Actually, after subscribing to bk-commits-* and seeing the output, I 
really think the only addition needed is to pipe the output through 
diffstat.

Re: BK kernel commits list

[Robert Love]

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

Re: BK kernel commits list

[Skip Ford]

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

Re: BK kernel commits list

[Jeff Garzik]

Robert Love wrote:
> But nothing _needs_ to be done.  This works great.  Good job, Dave and
> Co.


Indeed: kudos and thanks.

Re: BK kernel commits list

[Ben Collins]

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/

Re: BK kernel commits list

[David Woodhouse]

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

Re: BK kernel commits list

[Robert Love]

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

Re: BK kernel commits list

[David Woodhouse]

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

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[David S. Miller]

   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.

Re: New BK License Problem?

[Linus Torvalds]

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

Re: New BK License Problem?

[Skip Ford]

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

Re: New BK License Problem?

[Jeff Garzik]

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...

Re: New BK License Problem?

[David S. Miller]

   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.

Re: New BK License Problem?

[Arnaldo Carvalho de Melo]

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

Re: New BK License Problem?

[Alan Cox]

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

Re: New BK License Problem?

[Russell King]

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

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Skip Ford]

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

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Rob Landley]

On Sunday 06 October 2002 07:05 pm, Larry McVoy wrote:

> 	) | mail linux-patches@vger.kernel.edu

.org, actually.

Rob

Re: New BK License Problem?

[Jeff Garzik]

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.

Re: New BK License Problem?

[Ingo Molnar]

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

Re: New BK License Problem?

[David S. Miller]

   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? :-)

Re: New BK License Problem?

[Ingo Molnar]

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

Re: New BK License Problem?

[David S. Miller]

   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.

BK MetaData License Problem?

[Ingo Molnar]

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

Re: BK MetaData License Problem?

[David S. Miller]

   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.

Re: BK MetaData License Problem?

[jbradford]

>    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.

Re: BK MetaData License Problem?

[jw schultz]

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

Re: BK MetaData License Problem?

[Ingo Molnar]

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

Re: BK MetaData License Problem?

[Daniel Berlin]

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

Re: BK MetaData License Problem?

[Russell King]

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

Re: BK MetaData License Problem?

[Ingo Molnar]

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

Re: BK MetaData License Problem?

[Russell King]

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

Re: BK MetaData License Problem?

[Alan Cox]

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 ;)

Re: BK MetaData License Problem?

[jbradford]

> 
> 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.

Re: BK MetaData License Problem?

[Marek Habersack]

[-- 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 --]

Re: BK MetaData License Problem?

[jbradford]

> 
> 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.

Re: BK MetaData License Problem?

[Linus Torvalds]

[ 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

Re: BK MetaData License Problem?

[Ingo Molnar]

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

Re: BK MetaData License Problem?

[Larry McVoy]

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 

Re: BK MetaData License Problem?

[Ingo Molnar]

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

Re: BK MetaData License Problem?

[Larry McVoy]

> 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 

Re: BK MetaData License Problem?

[Jes Sorensen]

>>>>> "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

Re: BK MetaData License Problem?

[Larry McVoy]

> 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 

Re: BK MetaData License Problem?

[Alan Cox]

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

Re: BK MetaData License Problem?

[Jes Sorensen]

>>>>> "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

Re: BK MetaData License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Ingo Molnar]

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

Re: New BK License Problem?

[David S. Miller]

   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.

Re: New BK License Problem?

[Jeff Garzik]

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

Re: New BK License Problem?

[Jan Harkes]

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

Re: New BK License Problem?

[Nicolas Pitre]

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

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Ben Collins]

> 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.
    */

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Larry McVoy]

> 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 

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Rik van Riel]

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

Re: rsync kernel tree Re: New BK License Problem?

[jw schultz]

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

Re: New BK License Problem?

[Aaron Lehmann]

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?

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Aaron Lehmann]

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.

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Pavel Machek]

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?

Re: New BK License Problem?

[Nicolas Pitre]

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

Re: New BK License Problem?

[Alan Cox]

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.

Re: New BK License Problem?

[Nicolas Pitre]

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

Re: New BK License Problem?

[Pavel Machek]

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.

Re: New BK License Problem?

[Nicolas Pitre]

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

Re: New BK License Problem?

[Pavel Machek]

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.

Re: New BK License Problem?

[Vojtech Pavlik]

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

Re: New BK License Problem?

[Mark Mielke]

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/

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[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 

Re: New BK License Problem?

[Larry McVoy]

> 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 

Re: New BK License Problem?

[jbradford]

> 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.

Re: New BK License Problem?

[Daniel Phillips]

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

Re: New BK License Problem?

[Jeff Dike]

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

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Daniel Phillips]

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

Re: New BK License Problem?

[Ingo Molnar]

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

Re: New BK License Problem?

[Ingo Molnar]

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

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Ingo Molnar]

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

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Alexandre Dulaunoy]

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

Re: New BK License Problem?

[Rob Landley]

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

Re: New BK License Problem?

[Larry McVoy]

> 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 

Re: New BK License Problem?

[Rob Landley]

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

Re: New BK License Problem?

[Jan Harkes]

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

Re: New BK License Problem?

[Rik van Riel]

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>

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Werner Almesberger]

[ 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/____________________________________________/

Re: New BK License Problem?

[Geert Uytterhoeven]

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

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Abramo Bagnara]

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

Re: New BK License Problem?

[Miquel van Smoorenburg]

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.

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Robert Love]

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

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Hans Reiser]

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

Re: New BK License Problem?

[Ben Collins]

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/

Re: New BK License Problem?

[Ingo Molnar]

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

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Ingo Molnar]

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

BK is *evil* corporate software [was Re: New BK License Problem?]

[Pavel Machek]

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?

Re: BK is *evil* corporate software

[David S. Miller]

   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.

Re: BK is *evil* corporate software

[Alan Cox]

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 ;)

Re: BK is *evil* corporate software

[Pavel Machek]

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.

Re: BK is *evil* corporate software

[Roman Zippel]

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

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Mike Galbraith]

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

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Larry McVoy]

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 

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Henning P. Schmiedehausen]

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   

Re: BK is *evil* corporate software

[David S. Miller]

   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.

Re: BK is *evil* corporate software

[Larry McVoy]

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 

Re: BK is *evil* corporate software

[Keith Owens]

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.

Re: BK is *evil* corporate software

[Henning Schmiedehausen]

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   

Off topic, bandwidth wasting, waffle about Bit Keeper

[jbradford]

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.

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Larry McVoy]

> 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 

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Mark Mielke]

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/

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Derek D. Martin]

[-- 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-----

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Mark Mielke]

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/

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Jirka David]

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

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Rogier Wolff]

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. ***************

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Larry McVoy]

> 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 

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[yodaiken]

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

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Henning P. Schmiedehausen]

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   

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Jeff Garzik]

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

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Richard B. Johnson]

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.

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Alan Cox]

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 ?

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Larry McVoy]

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 

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Eli Carter]

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 `-------------------------------------------------

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Larry McVoy]

> 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 

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Jamie Lokier]

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 :-)

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Rogier Wolff]

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. ***************

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[tom_gall]

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

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Pavel Machek]

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.

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Rik van Riel]

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>

Re: BK is *evil* corporate software

[tom_gall]

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

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Alexander Viro]

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.

2.5.43 disk repartitioning problems

[Dave Olien]

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

Re: 2.5.43 disk repartitioning problems

[Dave Olien]

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/

Re: 2.5.43 disk repartitioning problems

[Bill Davidsen]

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.

Re: 2.5.43 disk repartitioning problems

[Dave Olien]

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/

Re: 2.5.43 disk repartitioning problems

[Bill Davidsen]

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.

Re: BK is *evil* corporate software [was Re: New BK License Problem?]

[Rik van Riel]

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>

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Ben Collins]

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/

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Hans Reiser]

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

Re: New BK License Problem?

[Murray J. Root]

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 

Re: New BK License Problem?

[Larry McVoy]

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 

Re: New BK License Problem?

[Murray J. Root]

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 

Re: New BK License Problem?

[Rik van Riel]

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

Re: New BK License Problem?

[Mark Mielke]

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/

Re: New BK License Problem?

[Hans Reiser]

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/
>
>

Re: New BK License Problem?

[FD Cami]

-----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-----

Re: New BK License Problem?

[Hans Reiser]

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
>
>

Re: BK MetaData License Problem?

[Manfred Spraul]

>                              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.
> 

Where is the problem? This asks for a permission, not for exclusive rights.


> 	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's a problem for Linux, not for Larry.

If you send a patch to Linus this means you distribute a modification to 
GPLed source, which means it's automatically placed under the GPL.

What's missing is a comment in the BK-usage document that informs the 
submitter that he must give the permission to republish the commit info. 
i.e. asking Linus to pull from an url is not a private message to Linus, 
it's the equivalent of sending a mail to a public, moderated mailing list.

--
	Manfred

Re: BK MetaData License Problem?

[Ingo Molnar]

On Sun, 6 Oct 2002, Manfred Spraul wrote:

> Where is the problem? This asks for a permission, not for exclusive
> rights.

yes, but what i say is that BK *creates* a problem, (just like CVS would
create similar problems) and the license clearly shows that BM is aware of
and tries to handle part of this legal problem. (And given that the BK
metadata is richer than eg. CVS, i suspect it will be a magnified problem
later on.)

i surely would find it to be a problem if BitMover would be the only
entity that has clean legal permissions to host the whole Linux kernel
repository. Even if Larry does not intend this to be the case. (which
assumption i grant blindly.)

what we had so far, at least according to my understanding, is that people
sent patches to a public and well-archived list, and that the GPL-ing of
the patch did not happen because the mailing shows their intent [i sure
never mention that the patch is GPL-ed], but because by the act of mailing
to the public list and to Linus they *distributed* the derived work, and
thus the GPL's provisions wrt. redistribution trigger - and Linus is fair
to pick the patch up.

the commit message on the other hand is the same as eg. SuSE's PR
announcement of SuSE Linux 20.9, it's metadata connected to their
publishing of a GPL-ed piece of code, but it's otherwise copyright and
owned by SuSE. The pure fact that a commit message about a GPL-ed work is
distributed publicly does not necessarily trigger any licensing of the
commit message itself.

> What's missing is a comment in the BK-usage document that informs the
> submitter that he must give the permission to republish the commit info.  
> i.e. asking Linus to pull from an url is not a private message to Linus,
> it's the equivalent of sending a mail to a public, moderated mailing
> list.

well, republishing permission is not enough i guess to keep the Linux
kernel tree as one entity i suspect. Plus even if a commit message is sent
to a public list, it does not necessarily mean it's put into the public
domain or something equivalent to that.

perhaps the best solution would be to make this part of BKL.txt - to give
protection to *both* BM and the Linux community. After all the commit is
performed by the owner of the commit message, so a good point for legal
stuff to trigger is in BKL.txt.

	Ingo

Re: BK MetaData License Problem?

[Marek Habersack]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Sun, Oct 06, 2002 at 03:13:24PM +0200, Ingo Molnar scribbled:
> 
> On Sun, 6 Oct 2002, Manfred Spraul wrote:
> 
> > Where is the problem? This asks for a permission, not for exclusive
> > rights.
> 
[snip]
> the commit message on the other hand is the same as eg. SuSE's PR
> announcement of SuSE Linux 20.9, it's metadata connected to their
> publishing of a GPL-ed piece of code, but it's otherwise copyright and
> owned by SuSE. The pure fact that a commit message about a GPL-ed work is
> distributed publicly does not necessarily trigger any licensing of the
> commit message itself.
Perhaps I am being silly at the moment, but wouldn't it suffice in this case
to put a statement in your commit message (I believe it can be automated)
stating that this message and the comitted data are licensed under the GPL?
As much as it would be an annoyance on the long run, it would effectively
protect every message from being abused by BitMover (or anyone else, for
that matter)*?

regards,

marek

* Note that I'm not implying BitMover or anyone else would claim ownership
  of the mentioned message - I'm just following your thread of thinking.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: BK MetaData License Problem?

[Manfred Spraul]

Russel King wrote:
 >
 > Therefore, I'd stronlg advise people in the EU not to use BK's
 > BK_USER/BK_HOST feature when importing patches.
 >
I think the user info is not critical: according to the GPL, you must 
tag your changes with date+name. By making a patch, you have agreed to 
the GPL terms, which means you have agreed that your name will be used 
together with the change.
I think the copyright laws require that, too.

But the GPL doesn't mandate a changelog...


Marek Habersack wrote:
> 
> Perhaps I am being silly at the moment, but wouldn't it suffice in this case
> to put a statement in your commit message (I believe it can be automated)
> stating that this message and the comitted data are licensed under the GPL?
 >

For example.
Or a sentence in the Licensing file, or whatever.("If you want to 
contribute to the development at www.kernel.org, then you must agree to 
the following conditions: You name will be used, your commit text will 
be used, your mail address will be published etc." No GPL conflict, you
are free to fork)

I agree with Ingo that there is the danger that without anything, it 
might happen that we'd have to throw away the changelogs [or that 
express permission for all existing entries will be needed, which is 
more or less equivalent]

--
	Manfred

Re: BK MetaData License Problem?

[Marek Habersack]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Sun, Oct 06, 2002 at 06:26:18PM +0200, Manfred Spraul scribbled:
[snip] 
> Marek Habersack wrote:
> >
> >Perhaps I am being silly at the moment, but wouldn't it suffice in this 
> >case
> >to put a statement in your commit message (I believe it can be automated)
> >stating that this message and the comitted data are licensed under the GPL?
> >
> 
> For example.
> Or a sentence in the Licensing file, or whatever.("If you want to 
> contribute to the development at www.kernel.org, then you must agree to 
> the following conditions: You name will be used, your commit text will 
> be used, your mail address will be published etc." No GPL conflict, you
> are free to fork)
I don't think that would suffice in this case. The problem is not in your or
anybody else's consent to the terms of GPL, but that the BK license doesn't
make it clear (as I understand) as to what is the legal status of the
metadata - i.e. what's the license that pertains to it. Also, this is not
BitMover's problem actually - thus the user, developer, would have to take
care to make a clear statement as to what the changelog license is. Or,
perhaps, BitMover could add to the license that the any software (i.e.
source code, documentation, log messages etc.) are accepted under the same
license as the, say, whole repository for the software unless otherwise
stated. Then only one file in the repository would suffice to make the
situation clear - it might be even done in a way that the bk tools display
the contents of this file (let's call it a "banner") once per "session" (by
default, of course) - to ascertain that anybody using the repository will
(or may) see the contents of the file. Maybe I'm rambling :), but that looks
like a sane solution to me (not being the BK user and not even liking it, I
don't know whether such a "motd" file is possible).

regards,

marek

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: BK MetaData License Problem?

[Alan Cox]

On Sun, 2002-10-06 at 14:13, Ingo Molnar wrote:
> yes, but what i say is that BK *creates* a problem, (just like CVS would
> create similar problems) and the license clearly shows that BM is aware of
> and tries to handle part of this legal problem. (And given that the BK
> metadata is richer than eg. CVS, i suspect it will be a magnified problem
> later on.)

The onyl real problem BK creates here IMHO is its not possible to use BK
to maintain the true master tree of a piece of software, because like
everyone else Linux people get security reports/fixes which are set to
go out on specific dates by people like CERT. The BK rules prevent
anyone from checking a change into their BK tree until the embargo date,
which can be a pain in the butt.

Fortunately its not a problem to me because I don't use it 8)

Re: BK MetaData License Problem?

[Larry McVoy]

On Sun, Oct 06, 2002 at 05:29:07PM +0100, Alan Cox wrote:
> On Sun, 2002-10-06 at 14:13, Ingo Molnar wrote:
> > yes, but what i say is that BK *creates* a problem, (just like CVS would
> > create similar problems) and the license clearly shows that BM is aware of
> > and tries to handle part of this legal problem. (And given that the BK
> > metadata is richer than eg. CVS, i suspect it will be a magnified problem
> > later on.)
> 
> The onyl real problem BK creates here IMHO is its not possible to use BK
> to maintain the true master tree of a piece of software, because like
> everyone else Linux people get security reports/fixes which are set to
> go out on specific dates by people like CERT. The BK rules prevent
> anyone from checking a change into their BK tree until the embargo date,
> which can be a pain in the butt.

We could easily fix this at our end.  We already have mechanisms to not
publish openlogging trees, that's how we handle the research/edu waivers,
we could figure out some way to do the same for individual changesets.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

RE: BK MetaData License Problem?

[Hell.Surfers]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

The file must be available for free, seperately if its not poss to include it, the source must say its a GPL, thats about it.

Cheers, Dean McEwan. Currently hacking KGI, which I don't understand, oh and ask me about OpenModemTalk...

On 	Sun, 6 Oct 2002 15:23:38 +0100 (BST) 	jbradford@dial.pipex.com wrote:

[-- Attachment #2: Type: message/rfc822, Size: 2183 bytes --]

From: jbradford@dial.pipex.com
To: mingo@elte.hu
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: BK MetaData License Problem?
Date: Sun, 6 Oct 2002 15:23:38 +0100 (BST)
Message-ID: <200210061423.g96ENcH3003097@darkstar.example.net>

> 
> 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.
-
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/