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
> 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: [email protected] 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
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
> > 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
* Larry McVoy ([email protected]) 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 |_______/
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
From: Larry McVoy <[email protected]>
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 :-)
From: Larry McVoy <[email protected]>
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.
On Fri, Oct 04, 2002 at 04:02:16PM -0700, David S. Miller wrote:
> From: Larry McVoy <[email protected]>
> 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
From: Roman Zippel <[email protected]>
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~~~~~~
> 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
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
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
From: Roman Zippel <[email protected]>
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 :-)
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 |_______/
[email protected] 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
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
[email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-----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
| [email protected] 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-----
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
>
>
Hans Reiser wrote:
> [email protected] 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?
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
> 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.
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 http://www.opensource.org, may apply for a waiver to
<[email protected]>
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
walt wrote:
> Hans Reiser wrote:
>
>> [email protected] 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 [email protected]
> 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
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
> > (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/
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
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/
On 2002-10-05T11:25:52,
Larry McVoy <[email protected]> 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 <[email protected]>
--
Principal Squirrel
Research and Development, SuSE Linux AG
``Immortality is an adequate definition of high availability for me.''
--- Gregory F. Pfister
> 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/
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
> 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
-----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-----
> 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
> 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.
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
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
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
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
-----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-----
On Sat, Oct 05, 2002 at 05:10:33PM +0400, Hans Reiser wrote:
> [email protected] 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
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
> 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
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...
> 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 http://www.opensource.org, may apply for a waiver to
> <[email protected]>
> 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
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
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
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
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: [email protected] [email protected]
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: [email protected] [email protected]
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: [email protected] [email protected]
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
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/
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: [email protected] [email protected]
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: [email protected] [email protected]
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: [email protected] [email protected]
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: [email protected] [email protected]
> 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
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: [email protected] [email protected]
> > > 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
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
On Friday 04 October 2002 05:33 pm, [email protected] 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
On Fri, 4 Oct 2002, Rob Landley wrote:
> On Friday 04 October 2002 05:33 pm, [email protected] 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
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
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
From: Ulrich Drepper <[email protected]>
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.
From: Alan Cox <[email protected]>
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.
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
In article <[email protected]>,
Alan Cox <[email protected]> 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
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
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.
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
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...
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...)
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
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
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
From: Skip Ford <[email protected]>
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.
From: Jeff Garzik <[email protected]>
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.
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
From: Ingo Molnar <[email protected]>
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.
From: Ingo Molnar <[email protected]>
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? :-)
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
On Sun, 6 Oct 2002, David S. Miller wrote:
> i'm also a bit worried about the legal status of commit messages posted
> via bkbits. Are they GPL-ed automatically, can we just take them and put
> them into a free-BK type server? We already have one precedent of a
> business entity abusing a free OS project and then suing it (and winning
> the suit), hindering the free OS's development for years.
>
> Larry has stated many times over that he doesn't own our bits.
>
> That is why once you extract content from the repository into some other
> form (a patch with the change logs prepended, for example) he doesn't
> care what you do with it.
for years people sent emails to Linus that described patches and this was
not a big issue - Linus has kept 99% of the metadata in the source code.
But today the 'Linux kernel' is not the source code anymore, it's the
source code plus the BK metadata, which are separate bits, and this
creates a new situation.
the BKL.txt license currently says:
By transmitting the Metadata
to an Open Logging server, You hereby grant BitMover,
or any other operator of an Open Logging server, per-
mission to republish the Metadata sent by the Bit-
Keeper Software to the Open Logging server.
what i'm worried about is the following issue: by default the data and the
MetaData is owned by whoever created it. You, me, other kernel developers.
We GPL the code, but the metadata is not automatically GPL-ed, just like
writing a book about the Linux kernel is is not necesserily GPL-ed.
It's not a big problem today because if you ask me then i'll tell you that
it's GPL-ed - but what will be the situation be in years? Couldnt
'BitMover or any other operator of an Open Logging server' argue that the
MetaData is owned by whoever created them, and is not covered by the GPL -
and only 'BitMover or any other operator of an Open Logging server' has
'permission to republish the Metadata'.
there are a number of legal cases in the US that involve around exactly
such issues (republishing of newpaper articles on the internet written by
independent journalists, republishing of the CD info database created by
anonymous users, etc.), and i'm sure we do not want the Linux kernel tree
to become another legal precedent.
it would be better if the license also said:
By transmitting the MetaData to an Open Logging server, You
hereby also agree to license the MetaData under the same license
you license the data it describes.
(or something to that extent - i'm not a lawyer.)
this ensures that metadata attached to GPL-ed code is also licensed under
the GPL, and creates a clearly GPL-ed repository, both data and metadata.
I'm 100% sure that the Linux commit messages are already valuable today,
and they will become a few orders more valuable in a few years.
btw., this is also the case with the emails Linus puts into BK commit info
- the email someone sends to Linus is _not_ GPL-ed by default.
(perhaps the solution is simple - i'd be really happy if it was.)
Ingo
From: Ingo Molnar <[email protected]>
Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST)
It's not a big problem today because if you ask me then i'll tell you that
it's GPL-ed - but what will be the situation be in years? Couldnt
'BitMover or any other operator of an Open Logging server' argue that the
MetaData is owned by whoever created them, and is not covered by the GPL -
and only 'BitMover or any other operator of an Open Logging server' has
'permission to republish the Metadata'.
Anything you write is automatically copyrighted by you, even if you
don't specifically state it as such.
That is my basic understanding of copyright law.
BitMover et al. can't take your copyright powers away from you.
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
On Sun, 6 Oct 2002, David S. Miller wrote:
> Anything you write is automatically copyrighted by you, even if you
> don't specifically state it as such.
>
> That is my basic understanding of copyright law.
>
> BitMover et al. can't take your copyright powers away from you.
yes, this is my understanding as well, but the BK license can require you
to license your bits in exchange for allowing you to use the BK product.
It already does require 'republishing rights' for the metadata bits in
fact. (which is a perfectly fair requirement - Larry needs this assurance
to be able to host bkbits in a legally safe way.)
the issue is that in the BK repository data and metadata is distinctly
separate. The Linux kernel is fully functional without any of the
metadata, and the GPL only covers the Linux kernel.
And i'd like note it that this situation is not "BK's fault" in any way,
it's simply the thing that copyright law says about not explicitly
licensed bits. But it's a situation created by BK, and it could be
eliminated by the BK license requiring the metadata to be licensed under
the same conditions the data itself is licensed. Or we could put this into
the Linux kernel license. (which OTOH might violate the GPL.)
i'm sure this issue was raised before - eg. what is the legal standing of
the commit messages of the BSD kernels?
Ingo
> From: Ingo Molnar <[email protected]>
> Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST)
>
> It's not a big problem today because if you ask me then i'll tell you that
> it's GPL-ed - but what will be the situation be in years? Couldnt
> 'BitMover or any other operator of an Open Logging server' argue that the
> MetaData is owned by whoever created them, and is not covered by the GPL -
> and only 'BitMover or any other operator of an Open Logging server' has
> 'permission to republish the Metadata'.
>
> Anything you write is automatically copyrighted by you, even if you
> don't specifically state it as such.
In most countries nowadays, this is correct.
> That is my basic understanding of copyright law.
>
> BitMover et al. can't take your copyright powers away from you.
No, but since you own the copyright, you can give rights to the material to the operator of the Open Logging server.
Why don't we have a system whereby we automatically assign copyright to one person, (I.E. Linus), who can then assign us GPL rights in return, so that by submitting material to any server, we are not able to assign anything other than GPL rights to it's owner.
This is, I believe, although I could be wrong, the reason that the Free Software Foundation allows you to assign copyrights to them.
John.
Please learn how to use the carriage return.
On Sun, Oct 06, 2002 at 01:18:10PM +0100, [email protected] wrote:
> > BitMover et al. can't take your copyright powers away
> > from you.
>
> No, but since you own the copyright, you can give rights
> to the material to the operator of the Open Logging
> server.
>
> Why don't we have a system whereby we automatically assign
> copyright to one person, (I.E. Linus), who can then assign
> us GPL rights in return, so that by submitting material to
> any server, we are not able to assign anything other than
> GPL rights to it's owner.
For good or ill by having the copyrights not held by one
person but instead held by so many is that no-one can
arbitrarily change the license or relicense under other
terms without the permission of all of the copyright
holders. However much you might trust Linus, do you want to
trust his grandchildren? Or the foundation after corporate
interests have subverted it?
> This is, I believe, although I could be wrong, the reason
> that the Free Software Foundation allows you to assign
> copyrights to them.
The reason to assign your copyright to the FSF is to give
them standing in court to defend the copyright.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
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
On Sun, Oct 06, 2002 at 02:04:42PM +0200, Ingo Molnar wrote:
> the BKL.txt license currently says:
>
> By transmitting the Metadata
> to an Open Logging server, You hereby grant BitMover,
> or any other operator of an Open Logging server, per-
> mission to republish the Metadata sent by the Bit-
> Keeper Software to the Open Logging server.
IANAL, but this is just to protect BitMover against _you_ suing them for
publishing your log entries. Completely sensible. They're not claiming
copyright over the metadata. They're not claiming any license over the
metadata.
> what i'm worried about is the following issue: by default the data and the
> MetaData is owned by whoever created it. You, me, other kernel developers.
> We GPL the code, but the metadata is not automatically GPL-ed, just like
> writing a book about the Linux kernel is is not necesserily GPL-ed.
It doesn't say "you transfer all your IP and soul to bitmover."
> it would be better if the license also said:
>
> By transmitting the MetaData to an Open Logging server, You
> hereby also agree to license the MetaData under the same license
> you license the data it describes.
>
> (or something to that extent - i'm not a lawyer.)
That doesn't explicitly allow bitmover to put the metadata up in public
view, which would mean the openlogging stuff will leave bitmover wide
open for legal action.
> btw., this is also the case with the emails Linus puts into BK commit info
> - the email someone sends to Linus is _not_ GPL-ed by default.
>
> (perhaps the solution is simple - i'd be really happy if it was.)
The exact same problem applies to pre-BK Linus and Alan, and whoever
else produces a change log that contains information produced by a
third party.
Does Linus and Alan have an implicit right to republish the documentation
that was sent to them with the patch? Does Red Hat have the right to
republish comments placed into the bugzilla database by external users
of that service? Does Debian have a right to reproduce emails on their
website which have been sent to [email protected] (or whatever the
address is?)
There is a _big_ question about reproducing peoples personal information
in the EU (eg, email addresses) on web sites, even archives of public
mailing lists. The exim mailing lists were recently threatened with
legal action over this very point, and there was talk at one point about
having to shut down the whole exim.org site because of this. The end
result of this debarcle was various posts were deleted from the list
archive.
So, this isn't a BK problem. Its a community problem.
Please don't shovel shit into other peoples back yards.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
> 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
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
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/
On Sun, 6 Oct 2002, Russell King wrote:
> > it would be better if the license also said:
> >
> > By transmitting the MetaData to an Open Logging server, You
> > hereby also agree to license the MetaData under the same license
> > you license the data it describes.
>
> That doesn't explicitly allow bitmover to put the metadata up in public
> view, which would mean the openlogging stuff will leave bitmover wide
> open for legal action.
(this is why i said 'also' in the above sentence. It would be in addition
to the existing (and sensible) requirement for BM to be able to republish
the commit logs.)
> > btw., this is also the case with the emails Linus puts into BK commit info
> > - the email someone sends to Linus is _not_ GPL-ed by default.
> >
> > (perhaps the solution is simple - i'd be really happy if it was.)
>
> The exact same problem applies to pre-BK Linus and Alan, and whoever
> else produces a change log that contains information produced by a third
> party.
with the difference that the changelog was a few orders of magnitude less
of an infrastructure element. Plus if you read those changelogs you'll see
that it's 100% written by Alan or Linus - in 99% of the cases it just
describes what the patch does, and in the remaining 1% it quotes a few key
sentences that can be considered fair use. Ie. the ChangeLog was owned by
Alan and Linus. [it would be a bit more robust if the ChangeLogs would be
part of the kernel repository, that would make them covered by the GPL.]
> Does Linus and Alan have an implicit right to republish the
> documentation that was sent to them with the patch? [...]
yes, as long as the documentation comes with the patch and is part of the
kernel tree, which the patch derives, and which kernel tree has a certain
'COPYING' file in the top directory. Patches *are* actively monitored for
conflicting licenses in individual files, and occasionally we had to
remove files.
> [...] The exim mailing lists were recently threatened with legal action
> over this very point, and there was talk at one point about having to
> shut down the whole exim.org site because of this. [...]
> So, this isn't a BK problem. Its a community problem.
it *is* a BK problem caused by BK becase now this whole can of worms got
silently exported to the kernel tree, and while BM itself is safe via its
license, the kernel tree 'as a whole' is exposed.
until now the Linux kernel tree was distributed in a tarball that had a
nice COPYING file in a very prominent spot. With BK the situation is
different - and like i said in previous mails it's not BK's "fault", but
BK's "effect" - and it's a situation that needs to be remedied, right?
Ingo
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
>
> until now the Linux kernel tree was distributed in a tarball that had a
> nice COPYING file in a very prominent spot. With BK the situation is
> different - and like i said in previous mails it's not BK's "fault", but
> BK's "effect" - and it's a situation that needs to be remedied, right?
Strictly speaking, isn't it a violation of the GPL for somebody to distribute a single file of any GPLed project, without attaching the COPYING file to it?
E.G. say somebody makes a CVS tree available via the web - you can download foobar.c without ever seeing the COPYING file.
John.
On Sun, Oct 06, 2002 at 04:10:46PM +0200, Ingo Molnar wrote:
> it *is* a BK problem caused by BK becase now this whole can of worms got
> silently exported to the kernel tree, and while BM itself is safe via its
> license, the kernel tree 'as a whole' is exposed.
Actually, the more I think about it, the more you are correct.
The way BK openlogging works, it exports personal information out of the
EU. This is explicitly prohibited under EU law, unless the owner of that
personal information has explicitly granted that it may be used in that
manner.
Therefore, I'd stronlg advise people in the EU not to use BK's BK_USER/
BK_HOST feature when importing patches.
The following question remains though: peoples names are "personal
information." Personal information falls under the UK data protection
act, which is one implementation of the EU law. This means that unless
Alan has an explicit agreement with every person who has sent him a patch,
he has no right to publish the list of names in his change log, especially
when that information travels leaves the EU.
This is certainly an interesting problem.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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
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
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
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
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
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
On Sun, 6 Oct 2002, David S. Miller wrote:
> From: Ingo Molnar <[email protected]>
> Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST)
>
> It's not a big problem today because if you ask me then i'll tell you that
> it's GPL-ed - but what will be the situation be in years? Couldnt
> 'BitMover or any other operator of an Open Logging server' argue that the
> MetaData is owned by whoever created them, and is not covered by the GPL -
> and only 'BitMover or any other operator of an Open Logging server' has
> 'permission to republish the Metadata'.
>
> Anything you write is automatically copyrighted by you, even if you
> don't specifically state it as such.
>
> That is my basic understanding of copyright law.
Correct.
Registration, for the most part, only affects remedies.
There are, as one would expect, weird corner cases and whatnot (bad
engineering :P).
But the short of it is that registration gives you the ability
to get statutory damages and attorneys fees. Without registering, you can
only get actual damages.
--Dan
Russel King wrote:
>
> Therefore, I'd stronlg advise people in the EU not to use BK's
> BK_USER/BK_HOST feature when importing patches.
>
I think the user info is not critical: according to the GPL, you must
tag your changes with date+name. By making a patch, you have agreed to
the GPL terms, which means you have agreed that your name will be used
together with the change.
I think the copyright laws require that, too.
But the GPL doesn't mandate a changelog...
Marek Habersack wrote:
>
> Perhaps I am being silly at the moment, but wouldn't it suffice in this case
> to put a statement in your commit message (I believe it can be automated)
> stating that this message and the comitted data are licensed under the GPL?
>
For example.
Or a sentence in the Licensing file, or whatever.("If you want to
contribute to the development at http://www.kernel.org, then you must agree to
the following conditions: You name will be used, your commit text will
be used, your mail address will be published etc." No GPL conflict, you
are free to fork)
I agree with Ingo that there is the danger that without anything, it
might happen that we'd have to throw away the changelogs [or that
express permission for all existing entries will be needed, which is
more or less equivalent]
--
Manfred
[ 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 [email protected] /
/_http://www.almesberger.net/____________________________________________/
On Sun, Oct 06, 2002 at 05:29:07PM +0100, Alan Cox wrote:
> On Sun, 2002-10-06 at 14:13, Ingo Molnar wrote:
> > yes, but what i say is that BK *creates* a problem, (just like CVS would
> > create similar problems) and the license clearly shows that BM is aware of
> > and tries to handle part of this legal problem. (And given that the BK
> > metadata is richer than eg. CVS, i suspect it will be a magnified problem
> > later on.)
>
> The onyl real problem BK creates here IMHO is its not possible to use BK
> to maintain the true master tree of a piece of software, because like
> everyone else Linux people get security reports/fixes which are set to
> go out on specific dates by people like CERT. The BK rules prevent
> anyone from checking a change into their BK tree until the embargo date,
> which can be a pain in the butt.
We could easily fix this at our end. We already have mechanisms to not
publish openlogging trees, that's how we handle the research/edu waivers,
we could figure out some way to do the same for individual changesets.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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
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 [email protected] 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
On Sun, 2002-10-06 at 15:08, Russell King wrote:
> The way BK openlogging works, it exports personal information out of the
> EU. This is explicitly prohibited under EU law, unless the owner of that
> personal information has explicitly granted that it may be used in that
> manner.
You can give anyone you like your -own- personal info. That is your
problem. What you can't do is do that with someone elses.
If it bothers you start a project in some free country that is about
cracking DRM schemes, use bitkeeper, document profusely in commit
messages and wait ;)
>
> On Sun, 2002-10-06 at 15:08, Russell King wrote:
> > The way BK openlogging works, it exports personal information out of the
> > EU. This is explicitly prohibited under EU law, unless the owner of that
> > personal information has explicitly granted that it may be used in that
> > manner.
>
> You can give anyone you like your -own- personal info. That is your
> problem. What you can't do is do that with someone elses.
That's not the issue he is raising. What he is saying is that say I make a patch and E-Mail it to you, with a change log entry that says, "John Bradford did this 1337 patch", and then you pass it on to somebody outside the EU, then you've violated the EU regulation.
John.
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
On Sun, Oct 06, 2002 at 06:02:39PM +0100, Alan Cox wrote:
> I would really like a [email protected] 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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
>>>>> "Russell" == Russell King <[email protected]> writes:
[snip]
Russell> There is a _big_ question about reproducing peoples personal
Russell> information in the EU (eg, email addresses) on web sites,
Russell> even archives of public mailing lists. The exim mailing
Russell> lists were recently threatened with legal action over this
Russell> very point, and there was talk at one point about having to
Russell> shut down the whole exim.org site because of this. The end
Russell> result of this debarcle was various posts were deleted from
Russell> the list archive.
This whole metadata discussion leads me to another question which has
been bothering me about BK's 'Open' Logging and hosted trees for a
while. What is happening to all the infomation that BitMover is (or
could gather) from people accessing the Open Logging site as well as
the hosted repositories? There could be a lot of marketing value in
this if BM decided to abuse it. Ie. some marketing manager could
decide to run advertisement campaigns listing names of known
individuals using the software.
I just checked http://www.bitkeeper.com/Sales.Licensing.Free.html and
the word 'privacy' does not occur on that page at all.
While I understand BK need for a license to publish the metadata, then
I'd be a lot more comfortable with a written guarantee restricting the
use to the logging site or similar.
Jes
> 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' | [email protected]
-----"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
> I just checked http://www.bitkeeper.com/Sales.Licensing.Free.html and
> the word 'privacy' does not occur on that page at all.
>
> While I understand BK need for a license to publish the metadata, then
> I'd be a lot more comfortable with a written guarantee restricting the
> use to the logging site or similar.
We're happy to say we won't sell or publish the material in any way
*other* than the openlogging web pages. I'm not sure what good that
does, the cat is out of the bag on the web pages so I can't imagine
a market for the data which is freely available, but if you are worried,
propose some language, we'll shove it in the above web page if the
language is reasonable (i.e., doesn't preclude openlogging itself).
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
>>>>> "Alan" == Alan Cox <[email protected]> writes:
Alan> On Sun, 2002-10-06 at 18:17, Jes Sorensen wrote:
>> This whole metadata discussion leads me to another question which
>> has been bothering me about BK's 'Open' Logging and hosted trees
>> for a while. What is happening to all the infomation that BitMover
>> is (or could gather) from people accessing the Open Logging site as
>> well as the hosted repositories? There could be a lot of marketing
>> value in this if BM decided to abuse it. Ie. some marketing manager
>> could decide to run advertisement campaigns listing names of known
>> individuals using the software.
Alan> They can do that anyway. The metadata is public. Nobody even
Alan> needs to bother Larry about it, any more than folks who trawl it
Alan> for spam email targets do
Whether or not it's legal to post it is something else, that doesn't
make it right. Besides, in many countries you can't put someone's name
up on a billboard unless they have agreed to it, or if they are
considered a 'public person' or something to that extend. Of course
with the totally broken privacy system in the US, and Canada for that
safe ;-(, I am sure you can publish whatever you want.
I have no issue with a company like BM or anyone else using anonymous
statistics for advertisement, but I'd be royally pissed if I had my
name on someone's leaflet without having given my written permission
first. Hence the suggestion for a privacy clause in the license.
Cheers,
Jes
On Sun, 2002-10-06 at 18:17, Jes Sorensen wrote:
> This whole metadata discussion leads me to another question which has
> been bothering me about BK's 'Open' Logging and hosted trees for a
> while. What is happening to all the infomation that BitMover is (or
> could gather) from people accessing the Open Logging site as well as
> the hosted repositories? There could be a lot of marketing value in
> this if BM decided to abuse it. Ie. some marketing manager could
> decide to run advertisement campaigns listing names of known
> individuals using the software.
They can do that anyway. The metadata is public. Nobody even needs to
bother Larry about it, any more than folks who trawl it for spam email
targets do
> 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
> 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.
On Sun, Oct 06, 2002 at 07:33:13PM +0100, [email protected] 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
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[email protected] 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-----
On Sun, Oct 06, 2002 at 06:26:18PM +0200, Manfred Spraul scribbled:
[snip]
> Marek Habersack wrote:
> >
> >Perhaps I am being silly at the moment, but wouldn't it suffice in this
> >case
> >to put a statement in your commit message (I believe it can be automated)
> >stating that this message and the comitted data are licensed under the GPL?
> >
>
> For example.
> Or a sentence in the Licensing file, or whatever.("If you want to
> contribute to the development at http://www.kernel.org, then you must agree to
> the following conditions: You name will be used, your commit text will
> be used, your mail address will be published etc." No GPL conflict, you
> are free to fork)
I don't think that would suffice in this case. The problem is not in your or
anybody else's consent to the terms of GPL, but that the BK license doesn't
make it clear (as I understand) as to what is the legal status of the
metadata - i.e. what's the license that pertains to it. Also, this is not
BitMover's problem actually - thus the user, developer, would have to take
care to make a clear statement as to what the changelog license is. Or,
perhaps, BitMover could add to the license that the any software (i.e.
source code, documentation, log messages etc.) are accepted under the same
license as the, say, whole repository for the software unless otherwise
stated. Then only one file in the repository would suffice to make the
situation clear - it might be even done in a way that the bk tools display
the contents of this file (let's call it a "banner") once per "session" (by
default, of course) - to ascertain that anybody using the repository will
(or may) see the contents of the file. Maybe I'm rambling :), but that looks
like a sane solution to me (not being the BK user and not even liking it, I
don't know whether such a "motd" file is possible).
regards,
marek
On Sun, Oct 06, 2002 at 05:58:26PM +0100, Alan Cox scribbled:
> On Sun, 2002-10-06 at 15:08, Russell King wrote:
> > The way BK openlogging works, it exports personal information out of the
> > EU. This is explicitly prohibited under EU law, unless the owner of that
> > personal information has explicitly granted that it may be used in that
> > manner.
>
> You can give anyone you like your -own- personal info. That is your
> problem. What you can't do is do that with someone elses.
Yes, but giving that info to anyone doesn't grant them the permission to
redistribute the information. I think that might be the problem Russel is
concerned about.
regards,
marek
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
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/
[ Different issue, and slightly off-topic ]
On Sun, 6 Oct 2002, Ingo Molnar wrote:
>
> until now the Linux kernel tree was distributed in a tarball that had a
> nice COPYING file in a very prominent spot. With BK the situation is
> different - and like i said in previous mails it's not BK's "fault", but
> BK's "effect" - and it's a situation that needs to be remedied, right?
If this is a concern, it actually appears that BK has the capability to
"enforce" a license, in that I coul dmake BK aware of the GPL and that
would cause BK to pop up a window saying "Do you agree to this license"
before the first check-in by a person (the same way it asked you whether
you wanted to allow openlogging).
Do people feel that would be a good idea? I actually dismissed it when
Larry talked about it, because I felt people might take it as another "too
much BK in your face", even though the license would be the _Linux_
license, not the BK one.
Linus
On Sun, 6 Oct 2002, Linus Torvalds wrote:
> If this is a concern, it actually appears that BK has the capability to
> "enforce" a license, in that I coul dmake BK aware of the GPL and that
> would cause BK to pop up a window saying "Do you agree to this license"
> before the first check-in by a person (the same way it asked you whether
> you wanted to allow openlogging).
sounds interesting - is it difficult to enabled it, just to see how much
impact it has on daily work?
> Do people feel that would be a good idea? I actually dismissed it when
> Larry talked about it, because I felt people might take it as another
> "too much BK in your face", even though the license would be the _Linux_
> license, not the BK one.
well, if it can be made a one-time thing, ie. something like: 'from now on
if you commit in the repository and distribute the changes then all those
changes and related BK metadata are licensed under the GPL', that would be
less intrusive i guess?
Ingo
On 6 Oct 2002, Alan Cox wrote:
> I would really like a [email protected] 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: [email protected] [email protected]
Larry McVoy <[email protected]> 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 [email protected]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
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: [email protected] [email protected]
In article <[email protected]>,
Ingo Molnar <[email protected]> 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.
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: [email protected] [email protected]
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
On Sun, Oct 06, 2002 at 09:31:02PM +0000, Miquel van Smoorenburg wrote:
> In article <[email protected]>,
> Ingo Molnar <[email protected]> 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
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?
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: [email protected] [email protected]
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
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
[email protected] 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
On Sun, Oct 06, 2002 at 01:45:04PM -0400, Jes Sorensen wrote:
> I have no issue with a company like BM or anyone else using anonymous
> statistics for advertisement, but I'd be royally pissed if I had my
> name on someone's leaflet without having given my written permission
> first. Hence the suggestion for a privacy clause in the license.
OK, so find some legal language that does what you want and send it to me.
If it doesn't prevent the openlogging web pages or the bkbits.net web pages
and bkd ports, we'll add it. We don't do a darn thing with that info,
I hear, understand, and agree with your concern, I just need some sample
language that threads the needle.
All the language I've seen would prevent us from displaying the web pages.
That's no good. We can't say we won't redistribute because the web pages
are definitely redistribution. We can say we won't sell it if that helps.
If we say we can't aggragate it then we can't do stuff like this:
http://www.bitkeeper.com/stats/linux-csets-L3W.png
which is something we'd like to make part of bkbits.net. And I think it's
something that the community wants.
So what's the language that says we won't do the spam style crud that you
are legitimately afraid of but does allow the useful stuff for the
community? It's good to handle this now, if we can get it nailed down
to something reasonable it's hard for BitMover the corporation to lose
its mind and change things later, you can argue fair use or breach of
promise or one of those lovely legal terms, I don't remember which
covers this, but I know there is one.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, 6 Oct 2002, Jeff Dike wrote:
> [email protected] 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: [email protected] [email protected]
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: [email protected] [email protected]
On Monday 07 October 2002 01:54, Jeff Dike wrote:
> [email protected] 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
On Sun, Oct 06, 2002 at 12:39:48PM -0700, Linus Torvalds wrote:
>
> [ Different issue, and slightly off-topic ]
>
> On Sun, 6 Oct 2002, Ingo Molnar wrote:
> >
> > until now the Linux kernel tree was distributed in a tarball that had a
> > nice COPYING file in a very prominent spot. With BK the situation is
> > different - and like i said in previous mails it's not BK's "fault", but
> > BK's "effect" - and it's a situation that needs to be remedied, right?
>
> If this is a concern, it actually appears that BK has the capability to
> "enforce" a license, in that I coul dmake BK aware of the GPL and that
> would cause BK to pop up a window saying "Do you agree to this license"
> before the first check-in by a person (the same way it asked you whether
> you wanted to allow openlogging).
Yes, but you'd want to make sure that you stated that your license
extended to the BK metadata. In our opinion, only you as the creator
of the repository gets to make that rule but you certainly can, that's
one of the reasons we put that clause in there.
By the way, the way this code works in bk-3.0 is that it saves a md5sum or
some sort of strong hash of the license in question and it will ask you
only once, assuming you are using the same home directory. It will ask
you again if the license changes, that's what the hash is for.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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
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.
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: [email protected] [email protected]
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 [email protected]
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
Miquel van Smoorenburg wrote:
>In article <[email protected]>,
>Ingo Molnar <[email protected]> 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 [email protected]
>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
The file must be available for free, seperately if its not poss to include it, the source must say its a GPL, thats about it.
Cheers, Dean McEwan. Currently hacking KGI, which I don't understand, oh and ask me about OpenModemTalk...
On Sun, 6 Oct 2002 15:23:38 +0100 (BST) [email protected] wrote:
> 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.
*/
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: [email protected] [email protected]
> 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
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: [email protected] [email protected]
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: [email protected] [email protected]
> > > 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.
On Sunday 06 October 2002 07:05 pm, Larry McVoy wrote:
> ) | mail [email protected]
.org, actually.
Rob
On Sun, 6 Oct 2002, Larry McVoy wrote:
> Yes, but you'd want to make sure that you stated that your license
> extended to the BK metadata. In our opinion, only you as the creator of
> the repository gets to make that rule but you certainly can, that's one
> of the reasons we put that clause in there.
so in theory it's perfectly possible to 'link' the data's and metadata's
license via BKL.txt - after all you already added licensing rules for the
metadata into the BK license, for the purposes of OpenLogging.
It would also perhaps make your position slightly more robust - besides
you already having the right to 'republish' metadata [which is a term not
directly defined in the license], you'd also have all the rights that come
through the license of the data it describes - whatever that is worth.
There are some problems like the fact that metadata might describe
multiple pieces of data that might have different licenses, the solution
would be to license metadata under every license that data is licensed
under - if there's any. This would be in addition to the already existing
republishing rights for OpenLogging.
> By the way, the way this code works in bk-3.0 is that it saves a md5sum
> or some sort of strong hash of the license in question and it will ask
> you only once, assuming you are using the same home directory. It will
> ask you again if the license changes, that's what the hash is for.
this sounds really nice and unintrusive, how does one enable it? Is this
BK_FORCE, or something else? I cannot find any reference to this in 'bk
helptool'.
Ingo
> so in theory it's perfectly possible to 'link' the data's and metadata's
> license via BKL.txt - after all you already added licensing rules for the
> metadata into the BK license, for the purposes of OpenLogging.
It is our position and we believe that it is supported by the BKL license
that it is the right and authority of the original creator of the project
to enforce any license they so wish. If Linus wants to make it clear
that if you make changesets using BK that the checkin comments are also
GPLed, that's his right. That's our intent and that's what we believe
the license says. See clause 3(b).
> > By the way, the way this code works in bk-3.0 is that it saves a md5sum
> > or some sort of strong hash of the license in question and it will ask
> > you only once, assuming you are using the same home directory. It will
> > ask you again if the license changes, that's what the hash is for.
>
> this sounds really nice and unintrusive, how does one enable it? Is this
> BK_FORCE, or something else? I cannot find any reference to this in 'bk
> helptool'.
That's because we haven't shipped bk-3.0 yet, we expect to do so this
week. The license clause has been there for a long time, these rules are
part of the BKL. However, we only recently added the "click to accept"
stuff for the extra license and the lawyers tell us that is required to
be enforceable.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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
> 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
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
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
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 -- [email protected]
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
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
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
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:"[email protected]">[email protected]</a>
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
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
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
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
> 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
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 <[email protected]>
> To: [email protected]
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi!
> > > I have never looked closer at bk than I had to be able to check out the
> > > latest sources. I'm not doing any development with it and I'm not
> > > checking in anything using bk.
> >
> > What about Larry making available a special version of BK that would only be
> > able to perform checkouts?
> >
> > This special version could have a less controversial license, even be GPL
> > with source. This only to provide a tool to extract data out of public BK
> > repositories (like Linus' kernel repository) for people who don't intend or
> > aren't willing to actually use the real value of the full fledged BK.
>
> You can do this today. rsync a BK tree and use GNU CSSC to check out
> the sources. We maintained SCCS compat for exactly that reason.
> You've had the ability to ignore the BKL since day one if you aren't
> running the BK binaries.
Would someone write nice HOWTO do this?
And where's guarantee that you are not migrating BK to proprietary
format to cut this off once someone writes the HOWTO?
Pavel
--
When do you have heart between your knees?
Hi!
> We're a business. We're a business which happens to be committed to
> helping the kernel team because we think that the kernel is vital to
> the world at large. Helping the kernel absolutely does not translate
> to helping people who happen to be our competitors. By your own
Stop lying. Your job is to make lots of money and you are using Linux
as cheap advertising. You are trying to make people pay *you* to do
kernel development (as it stands you want $5000 for any bk-using
developer inside RedHat and SuSE).
I hope your company dies ASAP and bitkeeper stops poisoning air here.
Pavel
--
When do you have heart between your knees?
At 12:11 AM 10/7/2002 +0200, Pavel Machek wrote:
>Hi!
>
> > We're a business. We're a business which happens to be committed to
> > helping the kernel team because we think that the kernel is vital to
> > the world at large. Helping the kernel absolutely does not translate
> > to helping people who happen to be our competitors. By your own
>
>Stop lying. Your job is to make lots of money and you are using Linux
>as cheap advertising. You are trying to make people pay *you* to do
>kernel development (as it stands you want $5000 for any bk-using
>developer inside RedHat and SuSE).
More info on $5k assertion please?
-Mike
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:[email protected]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
On Sunday, October 6, 2002, at 05:11 PM, Pavel Machek wrote:
> Hi!
>
>> We're a business. We're a business which happens to be committed to
>> helping the kernel team because we think that the kernel is vital to
>> the world at large. Helping the kernel absolutely does not translate
>> to helping people who happen to be our competitors. By your own
>
> Stop lying. Your job is to make lots of money and you are using Linux
> as cheap advertising. You are trying to make people pay *you* to do
> kernel development (as it stands you want $5000 for any bk-using
> developer inside RedHat and SuSE).
O Please! As the person that started this thread this is way way way
way out there and quite frankly I find offensive.
I do NOT honestly think that Larry made the change to the license that
he did for the express purpose of milking some set of companies out of
$$$$. That's just dumb.
Like Larry and others who have made some rather good points over the
couple of days, I think we're all trying to find a way to reasonably
solve this that is is everyone's best interesting, including Larry's
company.
Granted it's a different kind of license, (IE Microsoft doesn't have a
clause in IE that says Netscape developers can't use IE) but hey, it's
Larry's company and he's perfectly in his rights to do so. It is
truely a good thing that Larry is allowing some set of us in the open
source community to use his product without costs. Personally I'm
willing to pay a reasonable license fee for it but it's gotta be
something that I can afford without getting my head torn off by my
wife. Of course the other solution is to adjust the license a bit so
folks like me who are just doing kernel work and not in competition
with Larry's company (no matter what others in my company are doing)
can use it.
That's what I hope for... maybe it'll come true.
Regards,
Tom
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
From: Pavel Machek <[email protected]>
Date: Mon, 7 Oct 2002 00:11:37 +0200
(as it stands you want $5000 for any bk-using developer inside
RedHat and SuSE).
Stop spreading crap and fud. I, and nobody else at Red Hat, give or
need to give Larry one dime to use BK for kernel work.
And to be honest, I get better support from Larry for *free* than
you'll most often get when paying some company for software support.
This is a fact. When was the last time you got a ring on your cell
phone 4 minutes after emailing a bug report to someone?
Larry isn't Microsoft, and whether you choose to recognize the
positive things he does for kernel development or not is your
decision.
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
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
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.
Hi!
> > (as it stands you want $5000 for any bk-using developer inside
> > RedHat and SuSE).
> >
> > Stop spreading crap and fud. I, and nobody else at Red Hat, give or
> > need to give Larry one dime to use BK for kernel work.
> We do fix cvs things. Oh wait Larry has publically said CVS is no
> competition 8)
And what happens when you will want to include subversion in
distribution? You'll surely want to do some fixing before including
it...
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Mon, 2002-10-07 at 19:49, David S. Miller wrote:
> From: Pavel Machek <[email protected]>
> Date: Mon, 7 Oct 2002 00:11:37 +0200
>
> (as it stands you want $5000 for any bk-using developer inside
> RedHat and SuSE).
>
> Stop spreading crap and fud. I, and nobody else at Red Hat, give or
> need to give Larry one dime to use BK for kernel work.
We do fix cvs things. Oh wait Larry has publically said CVS is no
competition 8)
I'd agree with Dave - Larry is an arrogant egomaniac, but he's not
'evil' and if he was that, he'd be like a Bond villain - so busy
explaining how clever he was that he'd not actually manage it ;)
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.
Hi!
> >>We're a business. We're a business which happens to be committed to
> >>helping the kernel team because we think that the kernel is vital to
> >>the world at large. Helping the kernel absolutely does not translate
> >>to helping people who happen to be our competitors. By your own
> >
> >Stop lying. Your job is to make lots of money and you are using Linux
> >as cheap advertising. You are trying to make people pay *you* to do
> >kernel development (as it stands you want $5000 for any bk-using
> >developer inside RedHat and SuSE).
>
> O Please! As the person that started this thread this is way way way
> way out there and quite frankly I find offensive.
>
> I do NOT honestly think that Larry made the change to the license that
> he did for the express purpose of milking some set of companies out of
> $$$$. That's just dumb.
Maybe it is doing for purpose of slowing down subversion/CVS/arch
development. Thats about as bad.
> Granted it's a different kind of license, (IE Microsoft doesn't have a
> clause in IE that says Netscape developers can't use IE) but hey, it's
> Larry's company and he's perfectly in his rights to do so. It is
> truely a good thing that Larry is allowing some set of us in the open
> source community to use his product without costs.
Good thing for who?
Good thing for Larry? I don't know.
Good thing for us? I don't think so.
Good thing for subversion developers? Definitely not.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
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
On Mon, 7 Oct 2002, Pavel Machek wrote:
> Stop lying.
Look who's talking. *plonk*
> (as it stands you want $5000 for any bk-using
> developer inside RedHat and SuSE).
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
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
On Mon, 7 Oct 2002, Pavel Machek wrote:
> Maybe it is doing for purpose of slowing down subversion/CVS/arch
> development. Thats about as bad.
You sound about as pissed off as you do in a random thread about
somebody who violates the GPL, only now you're on the other side
of the fence.
If you don't like the new bitkeeper license, don't use bitkeeper.
If you feel _really_ strongly about it, help the subversion people
to build something as good as, or better than, bitkeeper so you
can convince kernel hackers to switch.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Mon, 7 Oct 2002 [email protected] 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:"[email protected]">[email protected]</a>
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.
On Mon, Oct 07, 2002 at 08:51:16PM +0200, Mike Galbraith wrote:
> At 12:11 AM 10/7/2002 +0200, Pavel Machek wrote:
> >Hi!
> >
> > > We're a business. We're a business which happens to be committed to
> > > helping the kernel team because we think that the kernel is vital to
> > > the world at large. Helping the kernel absolutely does not translate
> > > to helping people who happen to be our competitors. By your own
> >
> >Stop lying. Your job is to make lots of money and you are using Linux
> >as cheap advertising. You are trying to make people pay *you* to do
> >kernel development (as it stands you want $5000 for any bk-using
> >developer inside RedHat and SuSE).
>
> More info on $5k assertion please?
Let's clear this one up right away. The commercial licenses can be
perpetual (you bought it, you own that version forever) or annual lease.
The lease includes the right to use, support, and upgrades for as long as
you maintain the lease. The buy includes a year of support & upgrades;
after that you can buy support or not as you so choose. So you have the
buy vs buy+support vs lease options.
We vary our prices based on volume and everyone gets the same price.
We don't publish the prices because engineers will reject the product
based on any price more than $100/seat. Management is far more
reasonable, they want to know how much they spend and how much it
saves them, and are pretty unconcerned with what an engineer thinks.
They just want to see bottom line return on investment.
Because our support costs are higher per seat at low volumes, the product
is priced accordingly. We really hate to sell less than lots of 15 seats
or so, it's not cost effective. When we come across those situations
we try and steer them towards CVS (can't beat the price), single user
(also free), or we may give them an extended eval license and tell them
to come back when they are bigger. At our end, the cost of rolling out
a new commercial customer is about $10 - $15K in salaries. Part of that
is normal support, part of that is that we almost always sweeten a sale
by letting the customer say "I'm not going to buy unless it does XYZ"
provided that XYZ is something we think is generically useful. So the
sale gets to shuffle our priorities a bit and that ends up costing
us extra money. It's all good, it just means that if a sale is less than
$15K we probably don't want it. We love the level of support we give,
it's a huge part of why our users love BK, so we price where we have to
price. We're not a low end, low service shop, quite the opposite.
The annual lease prices vary from $1K/seat for lots of seats to
$2.4K/seat for one seat (nobody leases or buys one seat, they use it in
single user mode). The buy prices range from $2800/seat to $5800/seat.
The buy vs lease trade off is such that it is between 4 and 6 years before
it becomes cheaper to have bought than to have leased so everyone leases.
A seat is defined as a person who makes changes and floats automatically
every three months (to handle employee turnover, that sort of thing).
Noone has ever given us $5K for a seat and I doubt very much that anyone
ever will. Everyone leases and they lease at high enough volumes that
the lease price is around $1.5K.
A couple things are worth noting. We compete mostly with <insert market
leader here, we'll call them BIG>. Our lease prices, at high enough
volumes, are the same as or lower than BIG annual support prices.
BIG runs around $5K/seat plus 20% / year in support. So we're quite
competitive on the licensing costs. But it gets much, much better.
The BIG architecture is centralized so performance bottlenecks are
also centralized. As you add users you have to add server hardware.
It's very common to spend $300K on a big Sun SMP box to keep up with
the load. A $2K PC can do the same thing with BK, look at bkbits.net,
it's a 750Mhz Athlon, it has about 2000 different users. The next cost
center is administration. Again, the centralized architecture means
that you pay people a lot of money to make sure that the BIG server
never dies because everyone goes home if it does.
We had a customer who had a site license for BIG and they wanted a 4 site
multisite config. They asked us to price it for BIG and for BK. They
already had some of the hardware and some of the people they would need,
and they didn't have to pay for BIG, just support, so these numbers are
lower than they should. Doesn't matter. The costs for them worked out
to about $218K to get started plus $144K/year to keep going. The BK
costs worked out to $8K to get started and $52K/year to keep going.
5 year cost of ownership: BIG: $938, BK: $268. The customer looked
at our math and said "Your BIG costs are way too low but it doesn't
matter, you made your point" and they bought BK seats. Who wouldn't
if the numbers work out like that and the product suits your needs?
So, to reiterate, we don't publish our prices because an engineer will
look at $2000 and say "bug off, I'm not paying that much for that". They
don't think that $2K is 1-2% of what their management pays them in a
year, they don't think about the hardware costs, they don't think about
the people costs, they just go "I wouldn't pay for that so forget that".
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Whats the point of switching licences, YOU CAN make money from support, Mandrake makes a mint.
Cheers, Dean.
On Mon, 7 Oct 2002 16:24:00 -0400 (EDT) Nicolas Pitre <[email protected]> wrote:
Hi,
On Mon, 7 Oct 2002, David S. Miller wrote:
> (as it stands you want $5000 for any bk-using developer inside
> RedHat and SuSE).
>
> Stop spreading crap and fud. I, and nobody else at Red Hat, give or
> need to give Larry one dime to use BK for kernel work.
Actually RedHat does support subversion development, so RedHat must have
some special agreement with BM, so you can legally use BK for free.
bye, Roman
On Monday, October 7, 2002, at 03:44 PM, Pavel Machek wrote:
> Hi!
>
>> O Please! As the person that started this thread this is way way way
>> way out there and quite frankly I find offensive.
>>
>> I do NOT honestly think that Larry made the change to the license that
>> he did for the express purpose of milking some set of companies out of
>> $$$$. That's just dumb.
>
> Maybe it is doing for purpose of slowing down subversion/CVS/arch
> development. Thats about as bad.
Bah!
>> Granted it's a different kind of license, (IE Microsoft doesn't have a
>> clause in IE that says Netscape developers can't use IE) but hey, it's
>> Larry's company and he's perfectly in his rights to do so. It is
>> truely a good thing that Larry is allowing some set of us in the open
>> source community to use his product without costs.
>
> Good thing for who?
Those developers who can use BitKeeper in their work, regardless if
they paid for it or not.
> Good thing for Larry? I don't know.
Well that's for Larry to decide. I would hope that the benefits would
be there for him.
> Good thing for us? I don't think so.
Don't look a productivity gain in the mouth.
> Good thing for subversion developers? Definitely not.
In this case yes are you correct. It's not good for them or for
related technologies. OTOH, you'll get no break from companies such as
Microsoft. Wanna clone MS Word, well you're buying it to do that.
Course generally there's the reverse engineering clause.
I do not understand in any way shape or form why you THINK it's
reasonable for a company to give a competitor a leg up on putting them
out of business. It's not. While it is normal for open source projects
to cross pollinate, this is not the case here.
BitKeeper is not open source software so you can't subject it to the
same standards that you apply to Open source works.
Regards,
Tom
Marketing plays a huge part...
Cheers, Dean.
On Mon, 7 Oct 2002 18:19:56 -0300 (BRT) Rik van Riel <[email protected]> wrote:
On Mon, 7 Oct 2002, Pavel Machek wrote:
> Good thing for who?
>
> Good thing for Larry? I don't know.
>
> Good thing for us? I don't think so.
>
> Good thing for subversion developers? Definitely not.
Damn you. That thread got me to download subversion source and read it -
mistake I won't repeat any time soon. I've spent several months wading
through fairly disgusting code - block device drivers are not pretty,
ditto for devfs. I had more than once found myself grabbing Lovecraft
to read something that would be less nightmare-inducing. But _THAT_ takes
the fscking cake - I don't _care_ what Larry (or anybody else for that
matter) does to people who had excreted that code. No, wait - I _do_ care.
I want video of the... event.
I don't use BK, but you can be damn sure that I won't touch SVN. Ever.
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
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/
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
On Tuesday 08 October 2002 11:32 am, Rik van Riel wrote:
> On Tue, 8 Oct 2002, Roberto Peon wrote:
> > Good thing Linus was attached to the "Its amazing what you can do when
> > you don't know you can't do it" philosophy instead of the "If it could
> > have been done, it would have been done" POS philosophy.
>
> It all depends on how much risk you want to take and how
> much you have to lose.
>
> If all you can lose is some of your own time and energy
> there's nothing wrong with attempting something where
> everybody else has failed over the last 15 years.
>
> On the other hand, I wouldn't take that risk if I were
> running a business and had to make money to live...
I agree with this. The only thing I was disagreed with was your statement
which basically came down to:
If it could have been done, it would have been done.
Hell, the risks of starting up an open-source/service based company *are*
high, which is precisely why I won't try to start one up anytime in the
immediate future.
-Roberto JP
[email protected]
On Monday 07 October 2002 02:19 pm, Rik van Riel wrote:
> On Mon, 7 Oct 2002 [email protected] 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.
Good point, however:
> Hint: if the support model worked for source control software,
> surely somebody would have gotten rich off it already ?
Eh? huh?
Good thing Linus was attached to the "Its amazing what you can do when you
don't know you can't do it" philosophy instead of the "If it could have been
done, it would have been done" POS philosophy.
e.g:
I find a 100$ note on the ground. I don't pick it up since: If it existed,
someone would have already picked it up.
-Roberto JP
[email protected]
On Tue, 8 Oct 2002, Roberto Peon wrote:
> Good thing Linus was attached to the "Its amazing what you can do when
> you don't know you can't do it" philosophy instead of the "If it could
> have been done, it would have been done" POS philosophy.
It all depends on how much risk you want to take and how
much you have to lose.
If all you can lose is some of your own time and energy
there's nothing wrong with attempting something where
everybody else has failed over the last 15 years.
On the other hand, I wouldn't take that risk if I were
running a business and had to make money to live...
regards,
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://distro.conectiva.com/
"I was disagreed with"?
should have been:
"I disagreed with"
Seems I should proofread a bit more, hmm?
-Roberto JP
[email protected]
[email protected] 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:[email protected]:/home/cvs
grep -q $CVSROOT ~/.cvspass || ( echo "$CVSROOT Ay=0=h<Z" >> ~/.cvspass )
cvs -d $CVSROOT co bkexport
--
dwmw2
From: David Woodhouse <[email protected]>
Date: Tue, 08 Oct 2002 22:13:48 +0100
[email protected] 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.
On Tue, 8 Oct 2002, David Woodhouse wrote:
> [email protected] 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:"[email protected]">[email protected]</a>
[email protected] 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
[email protected] 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
From: Dave Jones <[email protected]>
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?
Rik van Riel wrote:
> On Tue, 8 Oct 2002, David Woodhouse wrote:
> > [email protected] 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
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
[email protected] 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
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
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
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:"[email protected]">[email protected]</a>
I've created:
[email protected]
[email protected]
(note: no "period" between the 2 and the 4)
Have at it.
David S. Miller wrote:
>
> I've created:
>
> [email protected]
> [email protected]
>
> (note: no "period" between the 2 and the 4)
> Have at it.
Does this list need to allow posting as it does now? Only one address
needs write permission, or maybe a few addresses as backup. Discussion
should still happen on lkml.
--
Skip
From: Skip Ford <[email protected]>
Date: Wed, 9 Oct 2002 07:49:32 -0400
Does this list need to allow posting as it does now? Only one address
needs write permission, or maybe a few addresses as backup. Discussion
should still happen on lkml.
I can set this up once I know what the feeder's From addrss
looks like.
From: David Woodhouse <[email protected]>
Date: Wed, 09 Oct 2002 13:17:58 +0100
Can we make it accept mail only with an envelope sender of
dwmw2@.*.kernel.org?
Any particular reason why the ".*." part can't be constant?
[email protected] said:
> I can set this up once I know what the feeder's From addrss looks
> like.
Well I was thinking of using `bk changes -d:USER:@:HOST:`
Can we make it accept mail only with an envelope sender of
dwmw2@.*.kernel.org?
--
dwmw2
A couple of suggestions for the output...
The BitKeeper header is unfortunately less than useful at times -- often
multiple cset descriptions wind up in the header -- so I would suggest
exporting the patch with "-hdu" instead of "-du", and then manually
adding the changeset info and description at the top.
Also, diffstat output prepended would be nice too.
[email protected] said:
> Just please make sure that the changeset info where it describes all
> the files in the delta. I.e. the ones that are moved, deleted, new.
> There's no way to deduce moves from the patch.
This bit?
# This patch includes the following deltas:
# ChangeSet 1.713 -> 1.714
# arch/i386/math-emu/poly.h 1.3 -> 1.4
#
Any idea how to get it other than 'bk export -tpatch | sed' ?
I need to do some real work... play with ths script and sort it out between
yourselves :)
--
dwmw2
On Wed, Oct 09, 2002 at 10:11:55AM -0400, Jeff Garzik wrote:
> A couple of suggestions for the output...
>
> The BitKeeper header is unfortunately less than useful at times -- often
> multiple cset descriptions wind up in the header -- so I would suggest
> exporting the patch with "-hdu" instead of "-du", and then manually
> adding the changeset info and description at the top.
>
> Also, diffstat output prepended would be nice too.
Just please make sure that the changeset info where it describes all the
files in the delta. I.e. the ones that are moved, deleted, new. There's
no way to deduce moves from the patch.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Wed, Oct 09, 2002 at 03:55:00PM +0100, David Woodhouse wrote:
>
> [email protected] said:
> > Just please make sure that the changeset info where it describes all
> > the files in the delta. I.e. the ones that are moved, deleted, new.
> > There's no way to deduce moves from the patch.
>
> This bit?
>
> # This patch includes the following deltas:
> # ChangeSet 1.713 -> 1.714
> # arch/i386/math-emu/poly.h 1.3 -> 1.4
> #
Yeah, that's it.
> Any idea how to get it other than 'bk export -tpatch | sed' ?
Probably some sort of "bk changes" output. Try checking the -d spec
options.
> I need to do some real work... play with ths script and sort it out between
> yourselves :)
I can't. Requires using BK :)
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
Actually, after subscribing to bk-commits-* and seeing the output, I
really think the only addition needed is to pipe the output through
diffstat.
On Wed, 2002-10-09 at 15:48, Jeff Garzik wrote:
> Actually, after subscribing to bk-commits-* and seeing the output,
> I really think the only addition needed is to pipe the output
> through diffstat.
I think this would be cool, too.
I think simplicity is important, but more information is always helper.
I also like Daniel's suggestion of having the sender's _name_ by the
name attributed with the patch (or at least "BK Commit" or something).
But nothing _needs_ to be done. This works great. Good job, Dave and
Co.
Robert Love
On Wed, Oct 09, 2002 at 03:48:58PM -0400, Jeff Garzik wrote:
> Actually, after subscribing to bk-commits-* and seeing the output, I
> really think the only addition needed is to pipe the output through
> diffstat.
Without the info concerning the file revs being affected, it's pretty
useless for me. I can actually just use that info and pull diffs
locally from my repo via sccs.
But I guess the point of the list is for diffs to kernel devs. Guess
I'll get my info elsewhere.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
Robert Love wrote:
> But nothing _needs_ to be done. This works great. Good job, Dave and
> Co.
Indeed: kudos and thanks.
Robert Love wrote:
> On Wed, 2002-10-09 at 15:48, Jeff Garzik wrote:
>
> > Actually, after subscribing to bk-commits-* and seeing the output,
> > I really think the only addition needed is to pipe the output
> > through diffstat.
>
> I think this would be cool, too.
>
> I also like Daniel's suggestion of having the sender's _name_ by the
> name attributed with the patch (or at least "BK Commit" or something).
>
> But nothing _needs_ to be done. This works great. Good job, Dave and
> Co.
I agree. Thanks to David Woodhouse for feeding it and DaveM for
creating it.
I'd like to suggest that once Linus makes a release and all of the
changeset diffs are wiped out on kernel.org, that a message be sent to
bk-commits indicating that. Nothing fancy, just an empty message with a
subject of "--MARK--" would be nice. But either way, it's a great
list.
--
Skip
[email protected] said:
> Actually, after subscribing to bk-commits-* and seeing the output, I
> really think the only addition needed is to pipe the output through
> diffstat.
Er, I did that last time you asked. Maybe it'll work better if I cvs update
on hera after committing the change? :)
--
dwmw2
[email protected] said:
> Without the info concerning the file revs being affected, it's pretty
> useless for me. I can actually just use that info and pull diffs
> locally from my repo via sccs.
We can do that. Worst case, someone needs to teach me enough sed to grok
the 'bk export -tpatch' output, find the line matching
'^# This patch contains the following deltas:$' and spew output from that
till the first line matching '^#$'. Ideally, there'll be an easier
way of getting the info from bitkeeper though.
Oh, and would anyone mind if, after feeding the mail through diffstat and
seeing zero lines of change, I aborted sending the mail?
Further criticism of the scripts will only be accepted in diff -u form
unless you have an excuse at least as good as having been told personally
by Larry that you're not allowed to use BitKeeper.
CVSROOT=:pserver:[email protected]:/home/cvs
grep -q $CVSROOT ~/.cvspass || ( echo "$CVSROOT Ay=0=h<Z" >> ~/.cvspass )
cvs -d $CVSROOT co bkexport
--
dwmw2
On Wed, 2002-10-09 at 16:52, David Woodhouse wrote:
> Oh, and would anyone mind if, after feeding the mail through diffstat and
> seeing zero lines of change, I aborted sending the mail?
You mean so we did not see empty emails (usually those of the form
"merge from x into y")?
Not only do I not mind, I encourage... please do so.
Robert Love
On 2002-10-09, "David S. Miller" <[email protected]> wrote:
> I've created:
> [email protected]
> [email protected]
FYI, I added these to the MARC list archives:
http://marc.theaimsgroup.com/?l=bk-commits-head&r=1&w=2
http://marc.theaimsgroup.com/?l=bk-commits-24&r=1&w=2
...Sometime last night, so they've got all of today's traffic.
--
Hank Leininger <[email protected]>
Larry McVoy <[email protected]> writes:
>On Mon, Oct 07, 2002 at 08:51:16PM +0200, Mike Galbraith wrote:
>> At 12:11 AM 10/7/2002 +0200, Pavel Machek wrote:
>> >Hi!
>> >
>> > > We're a business. We're a business which happens to be committed to
>> > > helping the kernel team because we think that the kernel is vital to
>> > > the world at large. Helping the kernel absolutely does not translate
>> > > to helping people who happen to be our competitors. By your own
>> >
>> >Stop lying. Your job is to make lots of money and you are using Linux
>> >as cheap advertising. You are trying to make people pay *you* to do
>> >kernel development (as it stands you want $5000 for any bk-using
>> >developer inside RedHat and SuSE).
>>
>> More info on $5k assertion please?
>Let's clear this one up right away. The commercial licenses can be
>perpetual (you bought it, you own that version forever) or annual lease.
>The lease includes the right to use, support, and upgrades for as long as
>you maintain the lease. The buy includes a year of support & upgrades;
>after that you can buy support or not as you so choose. So you have the
>buy vs buy+support vs lease options.
>We vary our prices based on volume and everyone gets the same price.
>We don't publish the prices because engineers will reject the product
>based on any price more than $100/seat. Management is far more
Let's insert some fact in this discussion:
--- cut ---
Annual lease:
< 5 seats, $2490/seat/year.
5-15 seats, $1920/seat/year.
Lifetime Purchase:
< 5 seats, $5220/seat.
5-15 seats, $4230/seat.
--- cut ---
Basically you charge a small(-ish) company about $25k for any
reasonable license. This is about as much as we spent for Software in
the last seven years (we do own a few Windows and Office licenses).
bk might be interesting for larger companies with software budgets in
the six figure range and for open source. For the vast number of three
to five developers enterprises, it's simply unreasonably priced. For
25k$ I get about six man months from a really good developer to work
on <insert your SCM here>.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
> Let's insert some fact in this discussion:
OK.
> Basically you charge a small(-ish) company about $25k for any
> reasonable license. This is about as much as we spent for Software in
> the last seven years (we do own a few Windows and Office licenses).
>
> bk might be interesting for larger companies with software budgets in
> the six figure range and for open source. For the vast number of three
> to five developers enterprises, it's simply unreasonably priced. For
> 25k$ I get about six man months from a really good developer to work
> on <insert your SCM here>.
Sure. And if you have 3-5 developers there is no reason to not use CVS,
it works well enough. Or Subversion after it matures, or Arch, or Aegis,
or tarballs+diff+patch.
We can't, and won't, compete at that level. You're comparing free against
what we charge. We're infinitely expensive in that comparison.
OK, now let's look at it as you grow. Most of our customers are in the
25-100 developer range. They move very quickly and have lots of parallelism
in the code. So things like work flow and merging are critical, if that
doesn't work, the whole team slows down. Let's say we have a 60 seat sale.
That's $90K/year for BK. Let's say the engineers cost $100K/each (it
may be lower where you are but it's more like $180-220 here when you add
in building/mgmt/all the other overhead). So that's $6M/year in engineers.
The BK cost is 1.5% of that. You say that your guys are $50K/year? OK,
so we're at 3% of that. The point is that if BK makes your team 3% more
productive, it costs zero.
And none of that includes the hardware costs, which are dramatically
cheaper for BK, it works on a laptop. Clearcase doesn't.
Whatever, I know that BK doesn't make sense for a 3 man shop. And I
know you think it is way too expensive. Your opinion is not universally
shared because the costs start to make more and more sense as you get
larger. I am sorry if you don't agree but that's the way it is. You
are welcome to use Perforce or CVS instead, we encourage it in fact.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: "Henning P. Schmiedehausen" <[email protected]>
Date: Wed, 9 Oct 2002 23:34:25 +0000 (UTC)
For the vast number of three to five developers enterprises, it's
simply unreasonably priced.
Larry is trying to tell you that BK isn't for you.
It costs too much to support small numbers of groups
which is why he can't price it the way you want.
Henning P. Schmiedehausen wrote:
> bk might be interesting for larger companies with software budgets in
> the six figure range and for open source. For the vast number of three
> to five developers enterprises, it's simply unreasonably priced. For
> 25k$ I get about six man months from a really good developer to work
> on <insert your SCM here>.
Larry's point is that six man months won't get you anywhere near as
good as BK. I'm not sure how much effort Larry and his team put in,
but a hand waving guess puts it at 200 or so man months (5 years times
3 developers, I am just guessing), minus the overhead of running a
business (need to hunt for sales, follow the market etc.) which you
wouldn't have. Let's call that 80% overhead, another hand waving
guesstimate from my experience with working in a company.
Assuming you miraculously would have no developer overhead, not even
the cost of office space, admin, accountants etc. for employing
someone, then at your really good developer rates, the correct price
is 166k$ :-)
For a small enterprise both prices are unreasonable. Which is
precisely why you cannot afford to develop something like BK yourself
from scratch -- and unfortunately you can't afford to buy it either.
Oh you can probably _clone_ BK in 6 months though; programming's much
less work than developing the concepts behind the program. Good luck,
btw I'd appreciate if you GPL it, thanks :)
-- Jamie
ps. From my limited experience, the hard part in writing a program
like BK isn't quantifiable in $$. One talented and motivated
programmer probably _could_ develop BK in 6 months given all the right
environment, input, skills, motivations and history. But their salary
is the smallest part of that. How likely are you to _find_ a person
who's specifically interested and skilled in developing high quality
SCM systems, and who's been refining the ideas for the last 10 years?
If it's the right person, you probably don't even need to pay them,
just keep them fed and housed for the time it takes :-)
Larry McVoy <[email protected]> wrote:
> if you have 3-5 developers there is no reason to not use CVS,
> it works well enough. ...
> OK, now let's look at it as you grow. Most of our customers are in the
> 25-100 developer range. They move very quickly and have lots of parallelism
> in the code. So things like work flow and merging are critical, if that
> doesn't work, the whole team slows down. Let's say we have a 60 seat sale.
> That's $90K/year for BK. Let's say the engineers cost $100K/each (it
> may be lower where you are but it's more like $180-220 here when you add
> in building/mgmt/all the other overhead). So that's $6M/year in engineers.
> The BK cost is 1.5% of that. You say that your guys are $50K/year? OK,
> so we're at 3% of that. The point is that if BK makes your team 3% more
> productive, it costs zero.
>
> And none of that includes the hardware costs, which are dramatically
> cheaper for BK, it works on a laptop. Clearcase doesn't.
Larry is spot on. I evaluated Clearcase, Bitkeeper, and Perforce
recently
for an 80 developer shop currently suffering with SourceSafe.
Clearcase was ridiculously expensive and complex; I would never use it.
Bitkeeper appeared to have *exactly* the features we wanted,
and the price was not out of our range. We eventually settled on trying
Perforce for a while because we know it could do most of what we needed,
but it was a really tough call. Larry took the time to make sure we
understood the issues, and I have a lot of respect for him.
Anyone who says Larry is evil is smoking crack. He's good people.
- Dan
On Wed, Oct 09, 2002 at 04:50:03PM -0700, David S. Miller wrote:
> From: "Henning P. Schmiedehausen" <[email protected]>
> Date: Wed, 9 Oct 2002 23:34:25 +0000 (UTC)
>
> For the vast number of three to five developers enterprises, it's
> simply unreasonably priced.
>
> Larry is trying to tell you that BK isn't for you.
> It costs too much to support small numbers of groups
> which is why he can't price it the way you want.
One of the other BitMover founders, Andrew Chang, told me a few months
ago that he realized that CVS was our "low end entry level product".
He's right. Much like I suck at public relations (and boy do I suck,
smacks head for Nth time), we also could be better at sales. Our sales
pitch is "does anything hurt? No? Go use CVS. Come back when it hurts.
If it never hurts you should never pay for BK".
I learned this the one time we ever did any marketing, which was way back
in 1999 or 1998 at Linux Expo. I was program chair for the technical
conference and Red Hat kindly gave us a booth. So we printed out the
BK logo on a big sheet of paper and sat at a booth and answered questions,
all of which went like this for the first 10 or 15 people:
Random Person: "Why should I use BitKeeper instead of CVS?"
Larry: <insert long winded, rambling answer extolling the BK virtues>
Random Person: <eyes glaze over, walks away>
I'm slow so it took me at least 10 of those to realize that I just wasn't
getting through these people. And in true "larry form" I got pissed off.
So with the next guy it went like this:
Random Person: "Why should I use BitKeeper instead of CVS?"
Larry: "If you have to ask that stupid question, you haven't
suffered enough. Go away, come back when it hurts."
Random Person: "Well, actually, renames under CVS really hurt, do
you fix that?"
Larry: "You bet we do, it works like ...."
Very important lesson. People don't give a rats ass about how cool your
technology is, how elegant it is, or any other thing that makes engineers
get excited. What they care about is pain or the lack thereof.
So these days we bill ourselves as "Novacaine for source management". If
you are suffering then we may be able to help and the price will look cheap.
If you aren't suffering you should stay with what you have.
The same thing applies to the Linux Kernel team. It's an absolute
fact that the BK license isn't what you want, it's not open source,
it's evil corporate software, at least in the view of any open source
fanatic and a lot of fairly reasonable people. If you are using it,
it's because it makes your pain go away. Or at least partially go away.
If I could have figured out a way to do that with a GPLed license I would
have done so, but I couldn't, so the license is what it is. The bad
news is that the license isn't what you want. The good news is that
*all* of us at BitMover are hackers just like you and we hate tools that
cause pain, so we are very motivated & committed to make BK an even more
effective tool. We want you to do what you can do what you do best: code.
The less than ideal license is, in our opinion, what allows us to help
you do that. It's entirely possible that there is a better licensing
answer, we just don't see it. On the other hand, I swear to you that
there is no development team anywhere on the planet more committed to
making your work pleasant. If you can look past the license, we're the
best thing that has ever happened to you, we are here to make you happy.
The license sucks, we can't help that. The software doesn't suck a lot
and we are trying to make it not suck at all. To steal a line from Mutt,
"All SCM systems suck, BK just sucks less".
I'm really sorry the license has caused this much fuss. We'll try
to make it more acceptable to the extent that we can. On the other
hand, those of you who are flaming should be ashamed of yourselves
for attacking a group of engineers doing everything they can to help
make things better for the kernel. We've been here for a long time;
throwing stones at us and saying we're just out to make a quick buck
is nonsense, we're here to help and our track record speaks for itself.
I do understand that our choices aren't popular with the GPL fans, but
that doesn't make us evil. We're doing what we need to do in order to
help. This market space, as Henning has pointed out, is very cost
sensitive and there is no hope, in our opinion, that a GPLed answer
could do what we are doing. If it could, we'd be doing it that way.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, 9 Oct 2002 18:08:34 -0700,
Larry McVoy <[email protected]> wrote:
>"does anything hurt? No? Go use CVS. Come back when it hurts.
>If it never hurts you should never pay for BK".
<plug>
For single users or a small team on a LAN, PRCS is much better than CVS
Change sets, branching, merging, easy extraction from any version ...
What is missing from PRCS is the distributed repository. Even Larry
thinks that PRCS is good for single users.
http://prcs.sourceforge.net/
</plug>
prcs info linux-2.4 | wc -> 1179 changesets.
On Wed, Oct 09, 2002 at 04:55:00PM -0700, Larry McVoy wrote:
> And none of that includes the hardware costs, which are dramatically
> cheaper for BK, it works on a laptop. Clearcase doesn't.
ClearCase does work on lap tops. Even if you mean disconnected,
ClearCase allows work to continue with snapshot views... :-)
Hardware costs are nothing really. The true killer with ClearCase is
the support costs. Not only do you need several full time people to
deal with user problems, you need several full time people to
customize your solution such that it meets your needs, several full
time people to baby the servers, and a whole management structure on
top to ensure that the full time people talk to each other, and the
actual users.
$3000/head really is nothing to large companies. CVS developers don't
understand, but for companies with several hundred designers, using
CVS would end up costing a heckuvalot more. I have become so
accustomed to features that are available in higher level systems such
as ClearCase that I find it difficult to use CVS. It is the difference
between black and white and colour.
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/
On Sun, Oct 06, 2002 at 11:10:48PM -0300, Rik van Riel wrote:
> People can grab the repository for use with CSSC from:
>
> ftp://nl.linux.org/pub/linux/bk2patch/
>
> Or using rsync:
> rsync -rav --delete nl.linux.org::kernel/linux-2.4 linux-2.4
> rsync -rav --delete nl.linux.org::kernel/linux-2.5 linux-2.5
>
> Currently these repositories are updated every two hours, but if
> there is a large demand I could update it every hour or even every
> 30 minutes. Don't feel ashamed to put the above rsyncs into your
> crontabs, grab the source and use it ;)
>
> have fun,
I just might. Although a straight tree (instead of
repository) would suit me better.
Like many i haven't been folowing the BK license thread. I
only found out about this message because of a kernel trap
headline. Rik you might get a better exposure if you
announced this outside of the BK license thread.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At some point hitherto, Mark Mielke hath spake thusly:
> Hardware costs are nothing really. The true killer with ClearCase is
> the support costs. Not only do you need several full time people to
> deal with user problems, you need several full time people to
> customize your solution such that it meets your needs, several full
> time people to baby the servers, and a whole management structure on
> top to ensure that the full time people talk to each other, and the
> actual users.
I'd have to disagree... though it probably depends on your environment
a great deal, and possibly how braindead your development team and/or
your sysadmin team is. At a previous job, I was one of two system
administrators that supported ClearCase in our Solaris environment for
about 100 engineers. That is, there were two of us, and I never
touched it. My coworker spent maybe an hour a week on it, discounting
time spent migrating to new hardware and a new config when our
environment changed (drastically). I think that, like most
applications that aren't inherently broken, once you have it set up
PROPERLY for your environment, it doesn't require much maintenance.
Nor should it. OTOH like I said, I didn't touch it, so for all I know
it could have been a horrid mess that the developers just weren't
inclined to complain about. But I tend to doubt that...
Oh, and we never really saw our manager much... ;-) Actually most of
the time, the engineers appreciated that. For the most part, when
they had problems, they just came to us directly, and we took care of
them. The only time management got involved was when each of our
visions of how things were supposed to work were miles apart, and we
each felt strongly about our own vision. It was, in many ways, an
ideal job. Unfortunately, as in most cases, circumstances change...
I have no comment about whether or not BK is evil... ;-)
- --
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9pP8vdjdlQoHP510RAjFyAKC+LnSfXgaju5u0ujc+ZRgoLZcgwwCff3hU
jiGSLgbERQ2QALdx4MRO4CI=
=hfSD
-----END PGP SIGNATURE-----
On Thu, Oct 10, 2002 at 12:16:48AM -0400, Derek D. Martin wrote:
> At some point hitherto, Mark Mielke hath spake thusly:
> > Hardware costs are nothing really. The true killer with ClearCase is
> > the support costs. Not only do you need several full time people to
> > deal with user problems, you need several full time people to
> > customize your solution such that it meets your needs, several full
> > time people to baby the servers, and a whole management structure on
> > top to ensure that the full time people talk to each other, and the
> > actual users.
> I'd have to disagree... though it probably depends on your environment
> a great deal, and possibly how braindead your development team and/or
> your sysadmin team is. At a previous job, I was one of two system
> administrators that supported ClearCase in our Solaris environment for
> about 100 engineers. That is, there were two of us, and I never
> ...
I may be talking about a company with 5000+ designers using ClearCase
with many sites around the world... :-)
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/
On Wed, Oct 09, 2002 at 04:55:00PM -0700, Larry McVoy wrote:
> Sure. And if you have 3-5 developers there is no reason to not use CVS,
> it works well enough. Or Subversion after it matures, or Arch, or Aegis,
> or tarballs+diff+patch.
>
> We can't, and won't, compete at that level. You're comparing free against
> what we charge. We're infinitely expensive in that comparison.
> [at 25-100 developers, BK makes sense]...
Larry,
Why do you "give away" BK for single-user use? That's to make
people familiar with the product so that they will know about it
when they DO need it in the case that they end up in a situation
where it does make sense. right?
Now you're saying that you don't want the market of 2-10 developers:
the other version control systems don't hurt enough.
Would it make sense to allow these people to use BK for free under
these circumstances, so that WHEN they grow, they are already
using BK, and know exactly how to use it?
My company with 2 developers will survive on tar&diff if you want
money for BK from us. We might decide that "tar&diff" still works
when we cross the 25 developer line..... You might want us to be
using BK by that time.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currenly in such an *
* excursion: The stable situation does not include humans. ***************
On Thu, Oct 10, 2002 at 01:03:55AM +0100, Jamie Lokier wrote:
> ps. From my limited experience, the hard part in writing a program
> like BK isn't quantifiable in $$. One talented and motivated
> programmer probably _could_ develop BK in 6 months given all the right
> environment, input, skills, motivations and history. But their salary
> is the smallest part of that. How likely are you to _find_ a person
> who's specifically interested and skilled in developing high quality
> SCM systems, and who's been refining the ideas for the last 10 years?
Ehmmm. I think your're talking about BitMover. The talented guy with the
vision is called Larry, and he's still using over 200 man-months to
develop the b*tch...
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currenly in such an *
* excursion: The stable situation does not include humans. ***************
Hi all.
I'm currently working like a ClearCase admin and configuration manager in a
world-wide company. And I can say the CC (ClearCase) is unbelievable
expensive. In my country 1 developer on-site license costs about $6500. And
another $6500 for multi-site license to share the same source code between
two or more sites or countries. You have to have both of them to access
multi-sited source database. It means $13000 !!!! for single developer.
> > At a previous job, I was one of two system
> > administrators that supported ClearCase in our Solaris environment for
> > about 100 engineers. That is, there were two of us, and I never
I am one of two administrators too. Configuration of the fully automated
multi-sited with synchronisation of replicas system took us about 6 moths.
But now a year after it works fine and without significant troubles.
> I may be talking about a company with 5000+ designers using ClearCase
> with many sites around the world... :-)
So this is my point of wiew from CC admin of CC network with cca 1000
developers. CC is milk cow for Rational and is totaly unusable for the linux
kernel developers. In this time I know nothing about BK, but who knows the
future ... :o)
Jiri
On Thu, 2002-10-10 at 01:50, David S. Miller wrote:
> From: "Henning P. Schmiedehausen" <[email protected]>
> Date: Wed, 9 Oct 2002 23:34:25 +0000 (UTC)
>
> For the vast number of three to five developers enterprises, it's
> simply unreasonably priced.
>
> Larry is trying to tell you that BK isn't for you.
> It costs too much to support small numbers of groups
> which is why he can't price it the way you want.
Guess what,
I did understand this in Larrys' mail. I didn't need you to figure it
out for me. :-)
But I didn't know this when we first asked for a price quote about six
month ago. I found no boiler plate sign saying "we're going for the big
guys. If you don't have a yearly cash flow well into seven figures, go
away".
BitMover Inc. pushes its lead product (which seems to be quite nice,
unfortunately it's not for _us_) aggressivly into the market by tackling
the 2nd most successful open source product ever [1]: the Linux Kernel.
I'd guess that 90% of the Linux kernel developers are either individuals
(and I count people like you or Alan still as "individuals", though
you're working for bigger companies. Is RedHat using bk internally on a
regular base?) or working for very small companies which develop a
specific part of the kernel (Driver, network protocol, name it) which is
needed in a product based on Linux.
So there is a discrepancy that is a thorn at least in my side: If I do
"fun work" on the Linux Kernel, I get to play with the "big boys' tools"
but I must not use them in my daily-bread work. (BTW: There I use CVS).
What I envision (Larry, are you listening?) would be a sort of "small
company license". Let's say "three to five seats, not expandable, if you
need a bigger license, you have to pay the full step up to the regular
bk prices even for the first seats" with a limited support (or support
contract at additional costs) for one version on one unix platform [2]
from a limited choice (Let's say Linux, BSD). Bundle this at about Euro
1k. Now you can whine about "you tailored a license just for yourself".
Right. Selfish me :-)
One point that BitMover shouldn't underestimate is the "familiarity with
tools". All of our developers came with "CVS pre-knowledge". So we
didn't have to train them from the start; we showed them the tools and
they were set. If you get a larger user base using bk, you IMHO would
get a "grass roots movement" into bigger companies.
BTW: Anyone using bk for Java development?
Regards
Henning
[1] #1 is IMHO still the GNU C Compiler suite.
[2] Everyone who can afford Windows XP Professional edition for five
developers can pay bk regular pricing too. :-)
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
The solution, as I see it, is to wait for a couple of years until
Larry drops his asking price of $12,000,000 to GPL it, and then ask a
few of the large Linux distros to help raise that money.
Think about it - there will be more competition against BK in a couple
of years time, so GPLing it to get more market share would make
sense. That way it could compete against, E.G. Subversion, if
Subversion becomes a viable competitor.
Larry - what are your thoughts on this?
John.
> Now you're saying that you don't want the market of 2-10 developers:
> the other version control systems don't hurt enough.
>
> Would it make sense to allow these people to use BK for free under
> these circumstances, so that WHEN they grow, they are already
> using BK, and know exactly how to use it?
If and only if letting them do so is zero cost to us. Otherwise what you
are asking is that we spend money and not take in money. Doesn't make
sense. And I don't think the BK docs are good enough that it would cost
us zero dollars to roll out a new customer.
> My company with 2 developers will survive on tar&diff if you want
> money for BK from us. We might decide that "tar&diff" still works
> when we cross the 25 developer line..... You might want us to be
> using BK by that time.
When you cross the 25 developer line, if tar+diff are working for you
then there is no price where BK makes sense for you.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, Oct 09, 2002 at 04:55:00PM -0700, Larry McVoy wrote:
> > Let's insert some fact in this discussion:
>
> OK.
>
> > Basically you charge a small(-ish) company about $25k for any
> > reasonable license. This is about as much as we spent for Software in
> > the last seven years (we do own a few Windows and Office licenses).
The historical expense for software
in your company has absolutely no relation to the cost-effectiveness of
a new purchase as far as I can see.
But it is interesting that you can hire a full time "really good"
programmer for total cost of $50K/year. Salaries are dropping.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
[email protected] writes:
>But it is interesting that you can hire a full time "really good"
>programmer for total cost of $50K/year. Salaries are dropping.
For small and medium companies (such as Siemens...), $50k (or the
rough aequivalent of EUR 50k) are already good developers salary.
The time of the "I can do Visual Basic and start at EUR 70k/year and
expect 5% raise every year" developers are gone. Thank goodness for
that.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Henning P. Schmiedehausen wrote:
> [email protected] writes:
>
>
>>But it is interesting that you can hire a full time "really good"
>>programmer for total cost of $50K/year. Salaries are dropping.
>
>
> For small and medium companies (such as Siemens...), $50k (or the
> rough aequivalent of EUR 50k) are already good developers salary.
You consider Siemens a medium company? ;-) They're friggin huge... 42
companies under their umbrella when I worked for them 10 years ago...
Siemens AG was one of the world's largest conglomerates...
Jeff
On Thu, Oct 10, 2002 at 04:14:03PM +0000, Henning P. Schmiedehausen wrote:
> [email protected] writes:
>
> >But it is interesting that you can hire a full time "really good"
> >programmer for total cost of $50K/year. Salaries are dropping.
>
> For small and medium companies (such as Siemens...), $50k (or the
> rough aequivalent of EUR 50k) are already good developers salary.
But that $50K is not the whole story. That's *unburdened*, it doesn't
include any of the associated costs such as benefits, taxes, office space,
expenses, etc. When I was at SGI I was making around $130K and I was
pretty high up in the salary curve. At the time, their *average* burdened
cost was $180K/engineer/year. There is no way that $130K was the average
engineer salary, it was quite a bit lower than that, my guess would be
around 90 or 100.
You're looking at all this from the typical engineer perspective.
That's not a reasonable perspective at a company of any size. Management
cares how much the tools cost if they make the engineers significantly
more productive. The human costs dwarf the tools cost. So the real
question is how much more do you get out of a team who is using BK than
you would get out of a team who is using CVS or whatever. If the answer
isn't at least the cost of BK then BK is obviously the wrong choice.
My personal feeling is that the absolute lowest point that would make
sense is a 2x difference. The reality is that for a company of any
size, it's way bigger than that. If it wasn't, we'd have no customers.
Times are tough. People aren't giving us money because they like us, they
do it because the tool gives value in excess of the costs. One customer,
when asked if we could tell people about their use of BK, refused to let
us because they believe that BK was a competitive advantage, it helped
them get to market faster than anyone else.
Everyone has to decide for themselves what make sense. I tend to agree
that paying for BK for a small number of seats doesn't make sense,
with a small number of people you can get by easily with CVS or one of
the other free tools. Eventually that will cause you problems and once
those problems are costing you money, then you may see that spending
that money on BK is actually a net reduction of cost.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Thu, 10 Oct 2002, Jeff Garzik wrote:
> Henning P. Schmiedehausen wrote:
> > [email protected] writes:
> >
> >
> >>But it is interesting that you can hire a full time "really good"
> >>programmer for total cost of $50K/year. Salaries are dropping.
> >
> >
> > For small and medium companies (such as Siemens...), $50k (or the
> > rough aequivalent of EUR 50k) are already good developers salary.
>
>
> You consider Siemens a medium company? ;-) They're friggin huge... 42
> companies under their umbrella when I worked for them 10 years ago...
> Siemens AG was one of the world's largest conglomerates...
>
> Jeff
>
...and they own and control more of the world than anything else,
including the world's major armies, ever has during recorded history.
If they were to abuse their power, Siemens could control the ultimate
destiny of mankind. Scarey!
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
On Thu, 2002-10-10 at 17:52, Richard B. Johnson wrote:
> ...and they own and control more of the world than anything else,
> including the world's major armies, ever has during recorded history.
> If they were to abuse their power, Siemens could control the ultimate
> destiny of mankind. Scarey!
Siemens to take over redmond using transferrable power from the
barvarian illuminat..
Oh wait wrong mailing list
Can well kill the BK thread now please ?
Larry McVoy wrote:
[snip]
> Everyone has to decide for themselves what make sense. I tend to agree
> that paying for BK for a small number of seats doesn't make sense,
> with a small number of people you can get by easily with CVS or one of
> the other free tools. Eventually that will cause you problems and once
> those problems are costing you money, then you may see that spending
> that money on BK is actually a net reduction of cost.
Ok, honest question for you Larry:
Assume for the moment that I'm not eligible for the free BK license (I
don't think that's the case, but for the question...).
Assume that I plan a project that is going to start at 1 person and grow.
Assume that at some point in the future, that project will grow large
and complex enough to need BK.
What source control should I use _now_ so that I can grow into BK over
time? Bonus question: Why?
(The answer may be something like 'CVS -> Subversion -> ... -> BK', but
I don't know.)
A little bit of background: In college I didn't know of source control.
CVS was a godsend for me when I found it. But renames, copies,
directories, dealing with multiple files in a change, those kinds of
things "hurt" in CVS, even with just me. I want better tools, ideally
open-source, but I suspect that I don't know what I'm looking for.
TIA,
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
> What source control should I use _now_ so that I can grow into BK over
> time? Bonus question: Why?
CVS. It's the most widely used system in the world, it has problems but you
can work around those problems, the FreeBSD guys are all in CVS and so is
Mozilla.
When the day comes that you want to move out, we can import your history
perfectly, you can't see the boundary where CVS stopped and BK started.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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?
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:"[email protected]">[email protected]</a>
I made a typo in the message below. The partitioning issue appears
in linux 2.5.43. (NOT 2.4.3 ..)
On Thu, Oct 17, 2002 at 10:52:05AM -0700, Dave Olien wrote:
>
> Al,
>
> I'm working on the Mylex DAC960 device driver, bring in up to date
> with the new block and dma interfaces. I've been posting patches on
> occasion. I've also noticed you updating the driver when you make changes
> to the gendisk kernel interfaces. Those updates are very helpful.
>
> I've noticed in 2.4.3 at least, that some changes to disk partitions
> aren't noticed until you reboot. The same problem is seen with aacraid.
> I don't THINK this is a driver issue. But, I might have missed something.
>
> I tried repartitioning two disks. On the first disk, I used fdisk
> to split a single large partition into four smaller ones. Afterwards,
> the first partition on that drive was still accessible. But I couldn't
> access the three new partitions. I didn't test to see if the first
> partition had been reduced in size. Rebooting made the new partitions
> accessible.
>
> In the second case, I split an unpartitioned drive into four partitions.
> None of the new partitions were accessible until I rebooted.
>
> Is this still a work in progress, or is there some driver hook I've missed?
>
> Thanks!
>
> Dave Olien
> Open Source Development Lab
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Al,
I'm working on the Mylex DAC960 device driver, bring in up to date
with the new block and dma interfaces. I've been posting patches on
occasion. I've also noticed you updating the driver when you make changes
to the gendisk kernel interfaces. Those updates are very helpful.
I've noticed in 2.4.3 at least, that some changes to disk partitions
aren't noticed until you reboot. The same problem is seen with aacraid.
I don't THINK this is a driver issue. But, I might have missed something.
I tried repartitioning two disks. On the first disk, I used fdisk
to split a single large partition into four smaller ones. Afterwards,
the first partition on that drive was still accessible. But I couldn't
access the three new partitions. I didn't test to see if the first
partition had been reduced in size. Rebooting made the new partitions
accessible.
In the second case, I split an unpartitioned drive into four partitions.
None of the new partitions were accessible until I rebooted.
Is this still a work in progress, or is there some driver hook I've missed?
Thanks!
Dave Olien
Open Source Development Lab
On Thu, 17 Oct 2002, Dave Olien wrote:
> I'm working on the Mylex DAC960 device driver, bring in up to date
> with the new block and dma interfaces. I've been posting patches on
> occasion. I've also noticed you updating the driver when you make changes
> to the gendisk kernel interfaces. Those updates are very helpful.
>
> I've noticed in 2.4.3 at least, that some changes to disk partitions
> aren't noticed until you reboot. The same problem is seen with aacraid.
> I don't THINK this is a driver issue. But, I might have missed something.
Linux has always read the partition table at first use AFAIK. So if you
have never used a drive you can repartition it and then use it, but once
you use any one partition the table is not reread.
I *think* if you unmount all partitions (including swapoff swaps) you can
see changes, but that's from memory, I haven't tried it in a long time.
Don't believe it's a bug, it's a design decision.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Bill,
Hmm.
The disks I'm working with aren't mounted and are not being used for
swap. There are no applications holding any partitions open.
At the time I'm modifying a disk's partition tables, there are no users
of any partitions on that disk.
I experimented removing and adding partitions in 2.4.18, and repeating
those experiemnts in 2.5.43. The two versions of OS definately
behave differently.
Dave
On Fri, Oct 18, 2002 at 03:45:50PM -0400, Bill Davidsen wrote:
> On Thu, 17 Oct 2002, Dave Olien wrote:
>
> > I'm working on the Mylex DAC960 device driver, bring in up to date
> > with the new block and dma interfaces. I've been posting patches on
> > occasion. I've also noticed you updating the driver when you make changes
> > to the gendisk kernel interfaces. Those updates are very helpful.
> >
> > I've noticed in 2.4.3 at least, that some changes to disk partitions
> > aren't noticed until you reboot. The same problem is seen with aacraid.
> > I don't THINK this is a driver issue. But, I might have missed something.
>
> Linux has always read the partition table at first use AFAIK. So if you
> have never used a drive you can repartition it and then use it, but once
> you use any one partition the table is not reread.
>
> I *think* if you unmount all partitions (including swapoff swaps) you can
> see changes, but that's from memory, I haven't tried it in a long time.
>
> Don't believe it's a bug, it's a design decision.
>
> --
> bill davidsen <[email protected]>
> CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Fri, 18 Oct 2002, Dave Olien wrote:
> Hmm.
>
> The disks I'm working with aren't mounted and are not being used for
> swap. There are no applications holding any partitions open.
> At the time I'm modifying a disk's partition tables, there are no users
> of any partitions on that disk.
>
> I experimented removing and adding partitions in 2.4.18, and repeating
> those experiemnts in 2.5.43. The two versions of OS definately
> behave differently.
Okay, just wanted to clarify, since the stable 2.4 kernels do hold the
partition table once they use it. Of course recent ones only use the first
one in any case, but hopefully that's going to be fixed (or may have in
2.5.43-mm2, don't remember).
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
