Re: New BK License Problem?

Re: New BK License Problem?

[walt]

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

I Am Not A Lawyer, but AFAIK the anti-trust laws in no way obligate
a business to aid its own competitors.

Restraint of trade occurs when two competitors conspire to crush a
third competitor.  Who is Larry's co-conspirator in your scenario?

Re: New BK License Problem?

[Larry McVoy]

I can tell that this issue isn't going away quickly so here are some
thoughts.

If the only thing that happens is a pile of complaints about how bad
the license is, the license isn't going to change.

Try and think about this from our point of view.  We provide a complex
yet useful product for free.  While doing so accomplishes our goal of
helping the kernel community, it also puts us at far greater risk that
someone will just reimplement the software.  Creating this software 
was quite difficult and we are not in the business of providing a 
roadmap to our competitors, they get to find their own way.  

If you want to suggest license changes do so showing that you understand
why we did what we did and show how your changes accomplish that in
a better way.  Suggestions like "you guys are idiots, just GPL it and
you can make money from support" just get ignored.  Suggestions which
increase, rather than decrease, our risk also get ignored.

If someone has a magic way of saying "you can use the software if and
only if your use of it does not put BitMover at financial risk" I'd
love to hear it.  So far, however, what I'm hearing is "your license
screws me and I want you to change it".  I hear your complaints, 
but they are just noise because they are one-sided.

There are other ways to work out the problem.  For example, the
openlogging stuff doesn't work for researchers.  We make a standard
practice of providing waivers to institutions or groups who are doing
pure research (not work for hire for BigFatCompany, Inc).  There is no
reason we can't do that for you for the non-compete clause.  We're 
in the process of developing that language for IBM's Linux Technology
Center, we can reuse it for anyone else.

Unless someone can come up with language which protects us, the license
stands as is.  We'll do waivers for kernel developers who happen to 
work at Rational or whatever as needed.  It's no different than dealing
with patents by Red Hat or whoever, if you are concerned about it, you
can ask us to make our intentions clear to you personally in writing.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[jbradford]

> Try and think about this from our point of view.  We provide a complex
> yet useful product for free.  While doing so accomplishes our goal of
> helping the kernel community, it also puts us at far greater risk that
> someone will just reimplement the software.  Creating this software 
> was quite difficult and we are not in the business of providing a 
> roadmap to our competitors, they get to find their own way.  

That's somewhat analogous to the situation with Trolltech's QT, before it was GPLed.

> If you want to suggest license changes do so showing that you understand
> why we did what we did and show how your changes accomplish that in
> a better way.  Suggestions like "you guys are idiots, just GPL it and
> you can make money from support" just get ignored.  Suggestions which
> increase, rather than decrease, our risk also get ignored.

You could do what Trolltech originally did, before they GPLed QT, and grant free licenses to developers who are developing free software - no matter who they work for.  I.E. If they work for BigFatCompany, Inc, but work on kernel patches in their lunch break, they get to have a free Bitkeeper license, whether they use it on the work computer or their own laptop.

John.

Re: New BK License Problem?

[tom_gall]

On Saturday, October 5, 2002, at 10:10 AM, Larry McVoy wrote:

> I can tell that this issue isn't going away quickly so here are some
> thoughts.

I think it can go away quickly. It just a matter of how you want to 
address it.

> If the only thing that happens is a pile of complaints about how bad
> the license is, the license isn't going to change.

The license on the whole is a good license. It's just that one claus 
the gives me pause.

> Try and think about this from our point of view.  We provide a complex
> yet useful product for free.  While doing so accomplishes our goal of
> helping the kernel community, it also puts us at far greater risk that
> someone will just reimplement the software.  Creating this software
> was quite difficult and we are not in the business of providing a
> roadmap to our competitors, they get to find their own way.

And that's perfectly fair. However as worded in your license today, the 
individuals who work for those companies and have nothing to do with 
the competitive software you are worried about can't use your product 
to work on open source software.

If we can fix this problem somehow, I would be a very happy camper.

> If you want to suggest license changes do so showing that you 
> understand
> why we did what we did and show how your changes accomplish that in
> a better way.  Suggestions like "you guys are idiots, just GPL it and
> you can make money from support" just get ignored.  Suggestions which
> increase, rather than decrease, our risk also get ignored.

How about this:

(d) Notwithstanding any other terms in this License, this License *MAY* 
not
be available to you if you and / or your employer develop, produce, 
sell,
and/or resell a product which contains substantially similar 
capabilities
of the BitKeeper Software or in the reasonable opinion of BitMover, 
competes
with the BitKeeper Software.

For those individuals who work on Open Source Software, that is software
as defined by being under a license meeting the Open Source Definition 
as
defined on www.opensource.org, may apply for a waiver to 
<someuser@bitmover.com>
stating
1) Which company they work for
2) Which Open Source Project(s) they are going to be using the 
Bitkeeper software for
3) Identify if they are working on this project in their "free" time or 
as part of their
job definition

If granted the waiver will only cover the stated Open Source project(s) 
you have named. If you expand your use of the BitKeeper software to 
other Open Source project(s) you will need to apply for a waiver for 
those project(s) as well.

> There are other ways to work out the problem.  For example, the
> openlogging stuff doesn't work for researchers.  We make a standard
> practice of providing waivers to institutions or groups who are doing
> pure research (not work for hire for BigFatCompany, Inc).  There is no
> reason we can't do that for you for the non-compete clause.  We're
> in the process of developing that language for IBM's Linux Technology
> Center, we can reuse it for anyone else.

It is good to hear that you're open to being flexible. I hope that 
might include
this case as well.

> Unless someone can come up with language which protects us, the license
> stands as is.  We'll do waivers for kernel developers who happen to
> work at Rational or whatever as needed.  <snip>

Well if you would, please have a read, Hopefully my idea sounds 
reasonable to you.

Thanks

Tom

Re: New BK License Problem?

[Hans Reiser]

walt wrote:

> 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...
>
>
> I Am Not A Lawyer, but AFAIK the anti-trust laws in no way obligate
> a business to aid its own competitors.

Read about the essential facilities doctrine.

>
>
> Restraint of trade occurs when two competitors conspire to crush a
> third competitor.  Who is Larry's co-conspirator in your scenario?
>
>
> -
> 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/
>
>
A single company is considered a conspiracy under the anti-trust laws.

Hans

Re: New BK License Problem?

[Larry McVoy]

On Sat, Oct 05, 2002 at 08:18:51PM +0400, Hans Reiser wrote:
> >> Seems like a pretty straightforward violation of the anti-trust laws, 
> >> and a conspiracy to restrain trade...
> >
> > I Am Not A Lawyer, but AFAIK the anti-trust laws in no way obligate
> > a business to aid its own competitors.
> 
> Read about the essential facilities doctrine.

I'm not a lawyer either but I spend about 40% of my working hours on
legal issues, such as contracts and IP law.  So I'm not uninformed 
about the topic either.  

In order for the essential facilities doctrine to apply, we have to
have control of some "essential facility".  If anyone wants to bring
suit attempting to claim that we have control over such a facility, I
wish them luck.  I'm pretty sure that if I claimed BK was such a thing
you'd all fall over laughing and so would a judge.  That may change in
the future but for now, not a chance of a judge or a jury seeing it that
way, in my opinion.  Feel free to sue if you feel differently.

It would be interesting case law since the suit would be over something
that we give away for free.  Might not matter but then again it might.
I doubt the courts can compel a business to give away their products.
If we were a monopoly they could compel us to sell them but I really
don't see how a court could say "you have to give this away for free".

If anything, the courts seem to be going in the opposite direction.
There was an interesting case recently where the courts upheld that
it was illegal to take a competitor's product, play with it, and then
copy the features.  It was an old case, the decision just came down,
but if we went to court over this stuff, that would be the first thing
we'd hold up as case law which supports our position.

Unlike the slashdot kiddies, the courts seem to recognize that the real
work is in the initial creation of a product, not in the replication of
that product.  The courts are quite supportive of that point, as well 
they should be.  They tend to switch sides as one becomes a monopoly,
but as things stand to day, that is a problem that we'll worry about
if and when it happens.  I have a feeling I'll be retired before then
so you can argue with someone else about it.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[Roman Zippel]

Hi,

On Sat, 5 Oct 2002, Larry McVoy wrote:

> Unlike the slashdot kiddies, the courts seem to recognize that the real
> work is in the initial creation of a product, not in the replication of
> that product.

So labor isn't worth anything anymore?

bye, Roman

Re: New BK License Problem?

[Larry McVoy]

> And that's perfectly fair. However as worded in your license today, the 
> individuals who work for those companies and have nothing to do with 
> the competitive software you are worried about can't use your product 
> to work on open source software.

Yes, that's true.  But that doesn't mean we can't make exceptions, we can
and do.

> defined on www.opensource.org, may apply for a waiver to 
> <someuser@bitmover.com>
> stating
> 1) Which company they work for
> 2) Which Open Source Project(s) they are going to be using the 
> Bitkeeper software for
> 3) Identify if they are working on this project in their "free" time or 
> as part of their
> job definition
> 
> If granted the waiver will only cover the stated Open Source project(s) 
> you have named. If you expand your use of the BitKeeper software to 
> other Open Source project(s) you will need to apply for a waiver for 
> those project(s) as well.

If *I* had suggested this language I would have been flamed off the face
of the earth.  The people who are complaining the loudest are complaining
that BitKeeper limits their choices or takes their freedom away or whatever.
They absolutely *despise* any sort of authority figure and the idea of 
coming begging to BitMover for a waiver each time just makes them crazy.

That said, what you outlined is more or less our current practice anyway.
It's not clear to me that changing the license in any way other than 
GPLing it will shut up the whiners, so my preference is to leave it the
way it is and let you ask for a waiver.  The effect is the same both ways.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[Rik van Riel]

On Sat, 5 Oct 2002, Larry McVoy wrote:

> If someone has a magic way of saying "you can use the software if and
> only if your use of it does not put BitMover at financial risk"

The main complaint I've heard now is "if I develop a product
that competes with bitkeeper, won't I be able to grab <free
software project available in BK> any more ??"

A fix for this would be "make patches available from bkbits.net".

This way everybody can still get the free software, they just
won't have the benefits of bitkeeper's version control or other
nice luxuries.

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]

On Sat, Oct 05, 2002 at 09:19:41PM -0300, Rik van Riel wrote:
> On Sat, 5 Oct 2002, Larry McVoy wrote:
> > If someone has a magic way of saying "you can use the software if and
> > only if your use of it does not put BitMover at financial risk"
> 
> The main complaint I've heard now is "if I develop a product
> that competes with bitkeeper, won't I be able to grab <free
> software project available in BK> any more ??"
> 
> A fix for this would be "make patches available from bkbits.net".

bkbits.net is a free service.  It costs us about $1600/month in cash
to run it, that doesn't count any salaries, that's just fixed costs.
If rsync and/or ftp didn't use about 100x as much bandwidth to do what
BK does we'd have already done what you are asking.  We simply can't
afford it.

But as I said to someone else, why doesn't someone register "nobkbits.net"
and use BK to mirror the repos and then provide the tarballs/patches as
you see fit.

I'm quite happy to help someone set this up, I'm just not willing to 
foot the bill.  The bandwidth costs will kill you.  kernel.org could
do this and that would be fine with me.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[Rik van Riel]

On Sat, 5 Oct 2002, Larry McVoy wrote:
> On Sat, Oct 05, 2002 at 09:19:41PM -0300, Rik van Riel wrote:

> > The main complaint I've heard now is "if I develop a product
> > that competes with bitkeeper, won't I be able to grab <free
> > software project available in BK> any more ??"
> >
> > A fix for this would be "make patches available from bkbits.net".
>
> bkbits.net is a free service.  [snip good arguments]

> But as I said to someone else, why doesn't someone register
> "nobkbits.net" and use BK to mirror the repos and then provide the
> tarballs/patches as you see fit.

I can do this on NL.linux.org.   I'm already doing it for the
2.4 and 2.5 Linux kernel trees and am willing to run the script
for other bitkeeper trees too.

If people want it, just let me know.

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]

> > > A fix for this would be "make patches available from bkbits.net".
> >
> > bkbits.net is a free service.  [snip good arguments]
> 
> > But as I said to someone else, why doesn't someone register
> > "nobkbits.net" and use BK to mirror the repos and then provide the
> > tarballs/patches as you see fit.
> 
> I can do this on NL.linux.org.   I'm already doing it for the
> 2.4 and 2.5 Linux kernel trees and am willing to run the script
> for other bitkeeper trees too.
> 
> If people want it, just let me know.

If this turns into a serious thing we could polish up the bkbits.net
infrastructure and provide it with one extra URL that lets you get 
gnu style patches.  I already have the code for this, I just have it
disabled for bandwidth reasons.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[Robert Love]

On Sat, 2002-10-05 at 20:53, Larry McVoy wrote:

> If this turns into a serious thing we could polish up the bkbits.net
> infrastructure and provide it with one extra URL that lets you get 
> gnu style patches.  I already have the code for this, I just have it
> disabled for bandwidth reasons.

So are you saying I could look at Linus's tree on bkbits.net and click
on a changeset and get a GNU diff?

That would be amazingly good of you, Larry.

	Robert Love

Re: New BK License Problem?

[Larry McVoy]

On Sat, Oct 05, 2002 at 09:00:04PM -0400, Robert Love wrote:
> On Sat, 2002-10-05 at 20:53, Larry McVoy wrote:
> 
> > If this turns into a serious thing we could polish up the bkbits.net
> > infrastructure and provide it with one extra URL that lets you get 
> > gnu style patches.  I already have the code for this, I just have it
> > disabled for bandwidth reasons.
> 
> So are you saying I could look at Linus's tree on bkbits.net and click
> on a changeset and get a GNU diff?

No, I'm saying that I could give you the technology to do that if you wanted
to host on your server.  Bandwidth == money.  We already have a T1 line for
the kernel, we're not buying another one.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[Willy Tarreau]

On Sat, Oct 05, 2002 at 10:24:05PM -0700, Larry McVoy wrote:
> No, I'm saying that I could give you the technology to do that if you wanted
> to host on your server.  Bandwidth == money.  We already have a T1 line for
> the kernel, we're not buying another one.

BTW, you could save more bandwidth by compressing every data that goes out,
html diffs, changelogs, patches... You are in some ways lucky to have one site
which hosts really compressible data.

And concerning the hosting of the gnu patches, you could put them on another
port on the same physical server, and then cap the bandwidth based on the port
so that it wouldn't slow down your main activity, and still be available
without upgrading your T1.

Just a few thoughts...
Cheers,
Willy

Re: New BK License Problem?

[Troy Benjegerdes]

> Unlike the slashdot kiddies, the courts seem to recognize that the real
> work is in the initial creation of a product, not in the replication of
> that product.  The courts are quite supportive of that point, as well 
> they should be.  They tend to switch sides as one becomes a monopoly,
> but as things stand to day, that is a problem that we'll worry about
> if and when it happens.  I have a feeling I'll be retired before then
> so you can argue with someone else about it.
> -- 

Someone's going to get sued over BK use eventually. (Probably not until
after Larry retires). But I don't want it to wind up a 'scorched earth'
mess where nobody can 'legally' use BK or develop on the kernel for it
while some messy lawsuit is going on.

But until Larry retires, I have found it much easier to think of the 
Bitkeeper license as the "don't piss off Larry license". Don't antagonize 
Larry, or directly mess up his business model, and you'll all get along 
find ;P

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Re: New BK License Problem?

[Larry McVoy]

> But until Larry retires, I have found it much easier to think of the 
> Bitkeeper license as the "don't piss off Larry license". Don't antagonize 
> Larry, or directly mess up his business model, and you'll all get along 
> find ;P

Another way to say it is "don't bite the hand that feeds you".  We work
hard to help the kernel team, we make the decisions we make based on the
premise that we have to be healthy to continue to help the kernel team as
well as our other users, and it's disheartening to get yelled it for it.

It's worth noting that the kernel's use of BK has and will continue to
expose either weaknesses in BK or missing features.  We already know 
of enough things that need engineering for the kernel (and any other
kernel sized project) to keep us busy for a couple of years.  If we
GPLed BK today it would do two things:

1) make you stop yelling at us
2) stop BK development

It costs a lot of money to do what we are doing, we know exactly how
much, and a GPLed answer won't support those costs.  We have to do what
we are doing in order to support the kernel team and our other users.
We see no other choice and not one of you have presented a viable 
alternative in the last 5 years.

The reason we don't want to help our competitors is that they want
to imitate us.  That's fine on the surface, a GPLed clone solves the
immediate problems you see, but it doesn't address how to solve the next
generation of problems.  You'd need a team of at least 6-8 senior kernel
level developers working full time for several years to get BK to the
point where it won't need to be enhanced in order to support something
like the kernel for the next 20 years (or more).  If we GPL it or we allow
clones, all that does is stop the development.  It's not a question of is
there the ability in the community to do what we do, there certainly is.
It's a question of will they.  And the answer is no they won't or they
would have already.  The problems that we solve aren't new at all.
They just aren't that all fun to solve.  Our user base is small, they
are very picky, there isn't a lot of money or fun here, so why would
anyone do what we do?  

You can argue all you like that I'm wrong, I'm misguided, I don't have
a clue about opensource or whatever.  The problem is that if I did what
you'd like to see, GPL the code, and it turns out I was right, there is no
turning back.  That's a gamble I'm unwilling to make because I am positive
of the outcome.  And given what I've been doing for the last 5 years,
my knowledge is probably more complete than your for this particular
space.  I know it isn't a popular position to take, I'd love to be the
guy everyone loved instead of hated, but I'm not going to screw up BK's
future and our ability to support our users to win a popularity contest.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[jbradford]

> You can argue all you like that I'm wrong, I'm misguided, I don't have
> a clue about opensource or whatever.  The problem is that if I did what
> you'd like to see, GPL the code, and it turns out I was right, there is no
> turning back.  That's a gamble I'm unwilling to make because I am positive
> of the outcome.  And given what I've been doing for the last 5 years,
> my knowledge is probably more complete than your for this particular
> space.  I know it isn't a popular position to take, I'd love to be the
> guy everyone loved instead of hated, but I'm not going to screw up BK's
> future and our ability to support our users to win a popularity contest.

Roughly how much would you want to raise, in order to GPL Bit Keeper?  Seriously, this was done with Blender...

John.

Re: New BK License Problem?

[Larry McVoy]

On Sun, Oct 06, 2002 at 07:33:13PM +0100, jbradford@dial.pipex.com wrote:
> > You can argue all you like that I'm wrong, I'm misguided, I don't have
> > a clue about opensource or whatever.  The problem is that if I did what
> > you'd like to see, GPL the code, and it turns out I was right, there is no
> > turning back.  That's a gamble I'm unwilling to make because I am positive
> > of the outcome.  And given what I've been doing for the last 5 years,
> > my knowledge is probably more complete than your for this particular
> > space.  I know it isn't a popular position to take, I'd love to be the
> > guy everyone loved instead of hated, but I'm not going to screw up BK's
> > future and our ability to support our users to win a popularity contest.
> 
> Roughly how much would you want to raise, in order to GPL Bit Keeper?  Seriously, this was done with Blender...

My guess is that it would take about another $12M to do what we are
planning to do.  So if you were just trying to raise enough money
to cover salaries, it's in that range.  On the other, you need to
consider that we'd like to get back more than salaries for our efforts.
We're not greedy but I walked away from $60M of Cobalt stock to do BK.
I also walked away from Google when there were three people there (the
full story is that I din't know it was $60M at Cobalt, I was guessing
more like $5-12M million, but I was fully aware of what I was giving up
at Google and it was certainly more, at least it is in my opinion).

Other people here also gave up a lot.  The first three years, we didn't
pay anyone, we all lived off of savings.  It's not unreasonable to want
that back.

If we decided to GPL it, I don't see how it would make sense for us 
to do so for any reasonable price.  Noone is going to give us $12M to
then give away the IP.  They want their $12M back with a return on the
investment.  

I hate to burst your bubble, but that's what it takes to do this stuff.
Most of what we do you don't directly see, it's bugs that you never hit
because we've fixed them, writing regression tests, stuff like that.
It's not very fun work, but it has to be done, it's what makes BK useable.
BK isn't done by volunteers because there is *no* way that anyone would
do this work for free.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[Roman Zippel]

Hi,

On Sun, 6 Oct 2002, Larry McVoy wrote:

> Another way to say it is "don't bite the hand that feeds you".  We work
> hard to help the kernel team, we make the decisions we make based on the
> premise that we have to be healthy to continue to help the kernel team as
> well as our other users, and it's disheartening to get yelled it for it.

You get what you asked for, promoting a nonfree product in a free
environment will never be fun.
Can we all stop the whining now? Everyone using nonfree software should
know, that he can get screwed.
BK won't be the only (distributed) source management system forever and if
there should be any interoperability problems caused by BK, Linus has
hopefully a good filter on his inbox.

bye, Roman

Re: New BK License Problem?

[FD Cami]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jbradford@dial.pipex.com wrote:
|>You can argue all you like that I'm wrong, I'm misguided, I don't have
|>a clue about opensource or whatever.  The problem is that if I did what
|>you'd like to see, GPL the code, and it turns out I was right, there is no
|>turning back.  That's a gamble I'm unwilling to make because I am positive
|>of the outcome.  And given what I've been doing for the last 5 years,
|>my knowledge is probably more complete than your for this particular
|>space.  I know it isn't a popular position to take, I'd love to be the
|>guy everyone loved instead of hated, but I'm not going to screw up BK's
|>future and our ability to support our users to win a popularity contest.
|
|
| Roughly how much would you want to raise, in order to GPL Bit Keeper?
  Seriously, this was done with Blender...
|
| John.

Blender's parent company, NotANumber, went bankrupt.
That's not the case of bitmover I think...
And I think Larry wants to keep his own business, he has the right to do
so...


- --

F. CAMI
- ----------------------------------------------------------
~ "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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9oIdPuBGY13rZQM8RAggpAJ9D50jP8mJcU5MByXDraZzXgscw6QCggxDW
IoCRUPTOKU5/lMtIhj5IuWk=
=XCXU
-----END PGP SIGNATURE-----

Re: New BK License Problem?

[Florian Weimer]

Larry McVoy <lm@bitmover.com> writes:

> I hate to burst your bubble, but that's what it takes to do this stuff.
> Most of what we do you don't directly see, it's bugs that you never hit
> because we've fixed them, writing regression tests, stuff like that.
> It's not very fun work, but it has to be done, it's what makes BK useable.
> BK isn't done by volunteers because there is *no* way that anyone would
> do this work for free.

Oh, somebody is crazy enough to write extensive regression tests for
his GPLed SCM system...

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898

Re: New BK License Problem?

[Rik van Riel]

On Sun, 6 Oct 2002, Larry McVoy wrote:

> If we GPL it or we allow clones, all that does is stop the development.
> It's not a question of is there the ability in the community to do what
> we do, there certainly is. It's a question of will they.  And the answer
> is no they won't or they would have already.

As usual, I agree with this point and think it's worth highlighting.

The GPL fanatics can flame me all they want, but that's not going
to change the reality.  The only thing that _will_ change the
situation is a team of people getting together to develop a GPL
alternative to bitkeeper.

Subversion isn't it, we can't work from the same repository with
tens of thousands of people, any BK replacement would have to be
a distributed system.

PRCS2 might become a suitable system, if somebody gets around to
picking up its development.  Arch might work too, but I remember
talking to some Arch fans a while back who "were about to" import
the whole kernel history into an Arch repository ... the fact
that I never heard from them again makes it look like maybe Arch
couldn't yet handle a repository the size of the kernel.

In short, until somebody builds a free (as in RMS-free) source
control system that's as good as bitkeeper for what the kernel
needs, bitkeeper is the only available tool for the job.

If you (for random values of you) care enough about bitkeeper
not being free, you should probably implement something as good
as, or better, than bitkeeper ;)

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, Larry McVoy wrote:

> If we decided to GPL it, I don't see how it would make sense for us
> to do so for any reasonable price.

Not only that, but GPLing bitkeeper while you still have a large
TODO list seems like a bad thing for the software.

Once the TODO list has shrunk to zero and the whole bitkeeper
team wants to move on to new and exciting things, maybe then it
might make sense to GPL bitkeeper ...

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]

On Sun, Oct 06, 2002 at 06:26:17PM -0300, Rik van Riel wrote:
> > If we decided to GPL it, I don't see how it would make sense for us
> > to do so for any reasonable price.
> 
> Not only that, but GPLing bitkeeper while you still have a large
> TODO list seems like a bad thing for the software.

*Exactly*.  And don't forget the followon stuff like integrated bug tracking.
That's not done yet either.  I wasn't pulling that $12M number out of thin
air, it's very real.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[Rob Landley]

On Sunday 06 October 2002 01:58 pm, Larry McVoy wrote:
> > But until Larry retires, I have found it much easier to think of the
> > Bitkeeper license as the "don't piss off Larry license". Don't antagonize
> > Larry, or directly mess up his business model, and you'll all get along
> > find ;P
>
> Another way to say it is "don't bite the hand that feeds you".  We work

Okay, settled.  The bitkeeper license is the "don't piss off Larry license", 
and Larry agrees.

Nice to have that sorted out.  Moving on...

Rob

Re: New BK License Problem?

[jbradford]

> > > If we decided to GPL it, I don't see how it would make sense for us
> > > to do so for any reasonable price.
> > 
> > Not only that, but GPLing bitkeeper while you still have a large
> > TODO list seems like a bad thing for the software.
> 
> *Exactly*.  And don't forget the followon stuff like integrated bug tracking.
> That's not done yet either.  I wasn't pulling that $12M number out of thin
> air, it's very real.

I can quite believe that.  I wasn't thinking it was a practical suggestion straight away, but there are obviously people on this list who won't be happy until, either we stop using BK or it is GPLed, (OK, or put under another free license).

I am staying out of that argument, but if you're not entirely against the idea of, in a few years, trying to get a few large corporations to sponsor the opening of the source, that might satisfy a few people, and _maybe_, just _maybe_, put an end to this huge thread.  :-)

John.

Re: New BK License Problem?

[Pavel Machek]

Hi!

> It's worth noting that the kernel's use of BK has and will continue to
> expose either weaknesses in BK or missing features.  We already know 
> of enough things that need engineering for the kernel (and any other
> kernel sized project) to keep us busy for a couple of years.  If we
> GPLed BK today it would do two things:
> 
> 1) make you stop yelling at us
> 2) stop BK development

And 

3) make me use it.

and

4) have widely-usable CVS replacement.

> It costs a lot of money to do what we are doing, we know exactly how
> much, and a GPLed answer won't support those costs.  We have to do
> what

Even if *you* stopped developping bitkeeper, there would be plenty of
other people to develop it, into way better product.

If you don't think GPLed bitkeeper can not be developed, then I do not
know why you are trying to kill subversion.

Aha, you addressed that:

> The reason we don't want to help our competitors is that they want
> to imitate us.  That's fine on the surface, a GPLed clone solves the
> immediate problems you see, but it doesn't address how to solve the next
> generation of problems.  You'd need a team of at least 6-8 senior
> kernel

By the time it takes to clone you you should have "next generation"
ready. If not, then you are doing something wrong.

							Pavel
-- 
When do you have heart between your knees?

Re: New BK License Problem?

[Rik van Riel]

On Thu, 10 Oct 2002, Pavel Machek wrote:

> 4) have widely-usable CVS replacement.

Subversion is a CVS replacement already.

Why aren't you using it, Pavel ?

> > It costs a lot of money to do what we are doing, we know exactly how
> > much, and a GPLed answer won't support those costs.  We have to do
> > what
>
> Even if *you* stopped developping bitkeeper, there would be plenty of
> other people to develop it, into way better product.
>
> If you don't think GPLed bitkeeper can not be developed, then I do not
> know why you are trying to kill subversion.

Pavel, I know you want to kill bitkeeper.  However, whining
isn't going to achieve that. Turning subversion into a better
tool than bitkeeper might...

I think Ben Collins already has a script to extract changesets
from the kernel tree using just CSSC as a tool. Why don't you
help him get those changesets imported into Subversion ?

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?

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

[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

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?

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

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

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

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

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

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

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

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

[Hell.Surfers]

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

Marketing plays a huge part...

Cheers, Dean.

On 	Mon, 7 Oct 2002 18:19:56 -0300 (BRT) 	Rik van Riel <riel@conectiva.com.br> wrote:

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

From: Rik van Riel <riel@conectiva.com.br>
To: Hell.Surfers@cwctv.net
Cc: nico@cam.org, <alan@lxorguk.ukuu.org.uk>, <pavel@suse.cz>, <drepper@redhat.com>, <lm@bitmover.com>, <linux-kernel@vger.kernel.org>
Subject: RE:Re: New BK License Problem?
Date: Mon, 7 Oct 2002 18:19:56 -0300 (BRT)
Message-ID: <Pine.LNX.4.44L.0210071817450.22735-100000@imladris.surriel.com>

On Mon, 7 Oct 2002 Hell.Surfers@cwctv.net wrote:

> Whats the point of switching licences, YOU CAN make money from support,
> Mandrake makes a mint.

If they can, surely you can, too?  And surely the subversion people
would be swimming in money now, from all the support contracts they've
been doing.  Also look at those huge profits being made by all those
open source companies.

Hint:  if the support model worked for source control software,
surely somebody would have gotten rich off it already ?

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?

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

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

[Nicolas Pitre]

On Mon, 7 Oct 2002, Vojtech Pavlik wrote:

> On Mon, Oct 07, 2002 at 10:35:22AM -0700, Larry McVoy wrote:
> > > Could you clarify exactly why it is a problem that someone both uses
> > > BitKeeper and works on potentially-competing SCM systems, if the two
> > > activities are unrelated? 
> > ...
> > > Is it that you think that direct
> > > experience with BK will give someone insight into its pluses and minuses
> > > beyond what they could get from just reading about it, thereby
> > > indirectly making their competing product better?
> > 
> > That's it.  BK is fairly subtle, it takes a while to wrap your brain around
> > it.  The way it works is hard to see from the outside and it is hard to see
> > the value.  So blind copying is more likely to copy the wrong parts.  On
> > the other hand, if I'm using BK every day and then working on a clone, it's
> > very easy to "do some unrelated work" to see how BK works.
> 
> Q: Does the paid license also prohibit usage by people whose companies
> work on other source-management systems? In that case, well, if they
> need to get used with BK to evaluate it's strong points, then they will.

Well they'll even use the free version, use it for a dummy project with some
anonymous email address for the open logging requirement, and won't tell
anyone about it.  We need to be realistic here this is common practice in 
the industry even if no one will admit it.

Maybe we should add an additional restriction to the Linux kernel license 
saying that Microsoft has no right to use Linux since they're making a 
competitor product.  Let's see if that changes anything.


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

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

[Vojtech Pavlik]

On Mon, Oct 07, 2002 at 10:35:22AM -0700, Larry McVoy wrote:
> > Could you clarify exactly why it is a problem that someone both uses
> > BitKeeper and works on potentially-competing SCM systems, if the two
> > activities are unrelated? 
> ...
> > Is it that you think that direct
> > experience with BK will give someone insight into its pluses and minuses
> > beyond what they could get from just reading about it, thereby
> > indirectly making their competing product better?
> 
> That's it.  BK is fairly subtle, it takes a while to wrap your brain around
> it.  The way it works is hard to see from the outside and it is hard to see
> the value.  So blind copying is more likely to copy the wrong parts.  On
> the other hand, if I'm using BK every day and then working on a clone, it's
> very easy to "do some unrelated work" to see how BK works.

Q: Does the paid license also prohibit usage by people whose companies
work on other source-management systems? In that case, well, if they
need to get used with BK to evaluate it's strong points, then they will.

-- 
Vojtech Pavlik
SuSE Labs

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?

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

[Larry McVoy]

On Mon, Oct 07, 2002 at 10:18:12AM -0700, Craig Dickson wrote:
> Larry McVoy wrote:
> 
> > 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.
> 
> This is all very well, but is this not something that might change if
> someone else were to come into control of the company? It isn't hard to
> imagine some future BitMover CEO with a more Microsoft-like mentality
> looking at the product and thinking, "This 'ease of getting data out'
> has to go -- we need to make it less convenient for our customers to
> defect."

Yup.  Don't know what to do about it other than stay in charge.  If it
weren't for interactions like this with the community, I could make a
compelling case that giving away the software and maintaining the status
quo is in the best interests of BitMover.  As it stands right now, we
do it only because I insist on it and I own more stock than anyone else.

My goal is to arrive at some sort of reasonable point, put this flamage
behind us, and live happily ever after.  

We definitely derive benefit from having the kernel in BK.  It stresses
it, the kernel team has hard problems that we have no choice but to fix,
the product is better and continues to get better because of it.  The fact
that it works with what you guys do to it validates the product, that's
an important thing for us.  The so-called PR value is definitely offset
by the negative PR value we get from things like this weekend.  I think
I could make that go away simply by unsubscribing from the kernel list.
That's not very realistic, I like being on the list.  Another way to make
it go away is hire Chris Mason and get him to do for me what he did for
Hans.  Hans and I share some of that shoot-yourself-in-the-foot behaviour.
When Hans got Chris and Chris became the defacto interface to the outside
world I believe that was a turning point for the acceptance of resierfs.
Sometimes we are our own worst enemies.  So I need a Chris for BitMover.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[Larry McVoy]

> Could you clarify exactly why it is a problem that someone both uses
> BitKeeper and works on potentially-competing SCM systems, if the two
> activities are unrelated? 
...
> Is it that you think that direct
> experience with BK will give someone insight into its pluses and minuses
> beyond what they could get from just reading about it, thereby
> indirectly making their competing product better?

That's it.  BK is fairly subtle, it takes a while to wrap your brain around
it.  The way it works is hard to see from the outside and it is hard to see
the value.  So blind copying is more likely to copy the wrong parts.  On
the other hand, if I'm using BK every day and then working on a clone, it's
very easy to "do some unrelated work" to see how BK works.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: New BK License Problem?

[David Lang]

if this happens then you just check the code out of the kernel as of the
last version prior to the one that makes this change.

if this happens then we are worse off then we are now, but not worse off
then we were before useing BK (diff+patch still work remember)

David Lang

On Mon, 7 Oct 2002, Craig Dickson wrote:

> Date: Mon, 7 Oct 2002 10:18:12 -0700
> From: Craig Dickson <crdic@pacbell.net>
> To: linux-kernel@vger.kernel.org
> Subject: Re: New BK License Problem?
>
> Larry McVoy wrote:
>
> > 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.
>
> This is all very well, but is this not something that might change if
> someone else were to come into control of the company? It isn't hard to
> imagine some future BitMover CEO with a more Microsoft-like mentality
> looking at the product and thinking, "This 'ease of getting data out'
> has to go -- we need to make it less convenient for our customers to
> defect."
>
> It is a general problem with power that you have to worry not just about
> whether those who currently wield it will abuse it, but also their
> successors.
>
> Craig
> -
> 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?

[Craig Dickson]

Larry McVoy wrote:

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

This is all very well, but is this not something that might change if
someone else were to come into control of the company? It isn't hard to
imagine some future BitMover CEO with a more Microsoft-like mentality
looking at the product and thinking, "This 'ease of getting data out'
has to go -- we need to make it less convenient for our customers to
defect."

It is a general problem with power that you have to worry not just about
whether those who currently wield it will abuse it, but also their
successors.

Craig

Re: New BK License Problem?

[Craig Dickson]

Larry McVoy wrote:

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

Could you clarify exactly why it is a problem that someone both uses
BitKeeper and works on potentially-competing SCM systems, if the two
activities are unrelated? I can understand that you would not want
someone using BK for free on a project that is itself competitive with
BK (because that would amount to using your own product against you),
but I don't quite see why it is a problem if someone uses BK only for,
say, Linux kernel work, and also separately works on some other SCM
system such as Subversion or Arch. Is it that you think that direct
experience with BK will give someone insight into its pluses and minuses
beyond what they could get from just reading about it, thereby
indirectly making their competing product better? Or is it some other
reason?

Craig

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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?

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

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

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

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

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

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

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

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?

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

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?

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

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

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?

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

> 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 

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