Well, now seems like a great time to discuss this. Ha.
It's come to our attention that commercial companies are abusing BK under
the openlogging rules. To avoid paying for the product, they either put
in no comments or obscure comments. That is a violation of the license,
but good luck proving that they are doing it on purpose.
The real issue is that we know from past history that companies make
changes to GPLed software and then delay access to those changes as
long as they can (the GPL allows for a "reasonable" amount of lag,
whatever that is).
The intent of the openlogging requirement was to allow people to work
out in the open on free software, at no charge. The intent was never
to allow people to work on free software without giving their changes
back. I'm not commenting on people's rights to hide their changes,
they can do whatever they want, but I *am* saying that we don't have
support closed use for free.
I'm considering a change to the BKL which says that N days after a
changeset is made, that changeset (and its ancestory) must be available
on a public bk server. In other words, put a hard limit on how long
you may hide.
The time period has to be long enough to cover security fixes, DaveM
raised that issue. I'm thinking 90 days.
Note: public server is not limited to bkbits.net. Any public server is
fine, so long as it is stable, well known, and available ~95% of the time.
I'm well aware that there are a vocal set of people who want complete
freedom to do whatever they want; I don't care to hear from them. For
the rest of you, would this change be a net positive?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, Apr 21, 2002 at 09:57:15AM -0700, Larry McVoy wrote:
> Well, now seems like a great time to discuss this. Ha.
>
> It's come to our attention that commercial companies are abusing BK under
> the openlogging rules. To avoid paying for the product, they either put
> in no comments or obscure comments. That is a violation of the license,
> but good luck proving that they are doing it on purpose.
Heh, I've seen real comments in the past that sure look like "no
comments or obscure comments". This is usually done by people who don't
like to or know how to use checking comments correctly, not them trying
to hide info purposely :)
> I'm considering a change to the BKL which says that N days after a
> changeset is made, that changeset (and its ancestory) must be available
> on a public bk server. In other words, put a hard limit on how long
> you may hide.
One problem might be having access to a public BK server. I know lots
of people who do not want to run BK on a publicly accessible server,
if for no other reason of not likening to run _any_ program they don't
have to on a publicly available server.
Other companies also have restrictions on allowing programs to be run
outside of their firewalls. If they want to use bk on a project, with
this license change, they would have to convince the IT group to set up
a bk server for their repository, which at larger companies is very hard
to do :)
You might have to beef up bkbits.net if this change goes into effect,
just to handle the extra repositories that might show up there.
Personally I don't care about the license change, as all my repositories
are placed on bkbits.net, and I understand your frustrations with people
trying to work around the spirit of your license.
Good luck,
greg k-h
On Sun, Apr 21, 2002 at 09:57:15AM -0700, Larry McVoy wrote:
> Well, now seems like a great time to discuss this. Ha.
>
> It's come to our attention that commercial companies are abusing BK under
> the openlogging rules. To avoid paying for the product, they either put
> in no comments or obscure comments. That is a violation of the license,
> but good luck proving that they are doing it on purpose.
>
> The real issue is that we know from past history that companies make
> changes to GPLed software and then delay access to those changes as
> long as they can (the GPL allows for a "reasonable" amount of lag,
> whatever that is).
>
> The intent of the openlogging requirement was to allow people to work
> out in the open on free software, at no charge. The intent was never
> to allow people to work on free software without giving their changes
> back. I'm not commenting on people's rights to hide their changes,
> they can do whatever they want, but I *am* saying that we don't have
> support closed use for free.
>
> I'm considering a change to the BKL which says that N days after a
> changeset is made, that changeset (and its ancestory) must be available
> on a public bk server. In other words, put a hard limit on how long
> you may hide.
>
> The time period has to be long enough to cover security fixes, DaveM
> raised that issue. I'm thinking 90 days.
>
> Note: public server is not limited to bkbits.net. Any public server is
> fine, so long as it is stable, well known, and available ~95% of the time.
>
Does 'public server' imply that the server is running bkd for
anonymous access? I have several small projects under bk that I keep
in repositories that are accesible to people with an account on my
server, but not to anyone else - would this be a license violation?
(I have no problem with openlogging - it just encourages me to make
/intelligent/ checkin comments, or some approximation thereof)
I'd prefer not to have to run bkd on my server if I don't /have/ to.
Minimising the number of services available to be cracked, and all
that . . .
Simon Fowler
--
PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc
(crappy) Homepage: http://bg77.anu.edu.au
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/
On Sunday 21 April 2002 18:57, Larry McVoy wrote:
> I'm considering a change to the BKL which says that N days after a
> changeset is made, that changeset (and its ancestory) must be available
> on a public bk server. In other words, put a hard limit on how long
> you may hide.
More red tape is usually bad. You want to do it to protect your commericial
interests? Fine. However, the GPL does not need Bitkeeper to be its robocop.
GPL violations have a way of coming to light without this sort of automated
enforcement.
--
Daniel
On Sun, Apr 21, 2002 at 09:57:15AM -0700, Larry McVoy wrote:
> I'm considering a change to the BKL which says that N days after a
> changeset is made, that changeset (and its ancestory) must be available
> on a public bk server. In other words, put a hard limit on how long
> you may hide.
OK, people have been replying in private to this raising various objections
and making good points:
David Mosberger was worried that I was suggesting that not
providing access to changes to GPLed code immediately (or ever,
if you don't redistribute) is a GPL violation. To clarify: people
can make changes to GPLed software and are only required to make
those changes available if they redistribute. That's the rule.
The point I was trying to make is that I wanted BK to be used for
free on work which is done out in the open, not behind closed doors.
Greg KH raised the point that not everyone can have a public
BK server, their IT department may not allow that. He said that
bkbits.net may need beefing up if we force people out into the open
(it needs beefing up anyway, but point is well taken).
Itai Nahshon raised several points about encrypted software, illegal
under the DMCA software, etc.
Jonathan Corbet raised the point of exposing software that isn't
done yet, which may have security holes, and/or other problems.
There were others, but this gives you a feel. In general, I'm getting
the message that forcing everything out into the open isn't always going
to be a good thing.
Yet I still have the problem of people abusing the system (not to mention
the "spirit" of free software). What I'd like is a way to qualify that
"abuse" and put that in the license, and what I'm hearing is that any
blanket statement may be a net negative for someone who should not be
adversely affected.
So that leaves a more selective approach. We can add a clause that says
we reserve the right to insist you either
a) maintain your changes in public within 90 days of making them, or
b) buy closed use seats, or
c) cease to use the product.
and then apply it to the abusers of the system. I understand this is
still a scary thing in that there is no guarentee that we won't knock
on your door, but the reality is that people always find ways to
avoid the intent of licenses and we need some recourse. At least this
way doesn't force this upon everyone, you have to exhibit some bad
behaviour in order for us to notice.
If you have a better idea on how to shut down the abusers without scaring
the legit users, I'm all ears.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Monday 22 April 2002 23:35, Larry McVoy wrote:
> So that leaves a more selective approach. We can add a clause that says
> we reserve the right to insist you either
>
> a) maintain your changes in public within 90 days of making them, or
That's going beyond what the gpl requires. Nobody needs to share their
changes unless they distribute the binaries.
> b) buy closed use seats, or
> c) cease to use the product.
>
> and then apply it to the abusers of the system. I understand this is
> still a scary thing in that there is no guarentee that we won't knock
> on your door, but the reality is that people always find ways to
> avoid the intent of licenses and we need some recourse. At least this
> way doesn't force this upon everyone, you have to exhibit some bad
> behaviour in order for us to notice.
>
> If you have a better idea on how to shut down the abusers without scaring
> the legit users, I'm all ears.
No need to play mall cop.
--
Daniel
On Mon, Apr 22, 2002 at 02:35:27PM -0700, Larry McVoy wrote:
> So that leaves a more selective approach. We can add a clause that says
> we reserve the right to insist you either
>
> a) maintain your changes in public within 90 days of making them, or
> b) buy closed use seats, or
> c) cease to use the product.
A (IMO -- feel free to debunk me :)) troublesome point is dead software.
What do I do if I start a project under BK, code on it for three months,
and abandon the project / slack off / have the manager kill it.
Are they still obligated to make the software public?
Jeff
On Apr 22, 2002 00:14 +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 23:35, Larry McVoy wrote:
> > So that leaves a more selective approach. We can add a clause that says
> > we reserve the right to insist you either
> >
> > a) maintain your changes in public within 90 days of making them, or
>
> That's going beyond what the gpl requires. Nobody needs to share their
> changes unless they distribute the binaries.
But according to the license under which they use BK, they _do_ need to
make them public.
> > If you have a better idea on how to shut down the abusers without scaring
> > the legit users, I'm all ears.
>
> No need to play mall cop.
Isn't that you calling the kettle black? ;-)
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
On Tuesday 23 April 2002 00:29, Andreas Dilger wrote:
> On Apr 22, 2002 00:14 +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 23:35, Larry McVoy wrote:
> > > So that leaves a more selective approach. We can add a clause that says
> > > we reserve the right to insist you either
> > >
> > > a) maintain your changes in public within 90 days of making them, or
> >
> > That's going beyond what the gpl requires. Nobody needs to share their
> > changes unless they distribute the binaries.
>
> But according to the license under which they use BK, they _do_ need to
> make them public.
>
> > > If you have a better idea on how to shut down the abusers without scaring
> > > the legit users, I'm all ears.
> >
> > No need to play mall cop.
>
> Isn't that you calling the kettle black? ;-)
Larry's proposing to turn BitKeeper into an automated GPL enforcement machine,
even poking it's nose into areas the GPL isn't concerned about. This is a
horribly broken reason for adding let more t&c's do the license.
Frankly, I'm finding the whole BitKeeper experience something of a turn-off.
This is clearly not 'just for fun'. OK, I'll make a very serious effort to
stay out of this now.
When I came into this I had a high regard for BitKeeper and every intention
of using/supporting it. That's changed, now that I have a feeling for the
mob mentality behind it.
--
Daniel
On Mon, Apr 22, 2002 at 06:22:14PM -0400, Jeff Garzik wrote:
> On Mon, Apr 22, 2002 at 02:35:27PM -0700, Larry McVoy wrote:
> > So that leaves a more selective approach. We can add a clause that says
> > we reserve the right to insist you either
> >
> > a) maintain your changes in public within 90 days of making them, or
> > b) buy closed use seats, or
> > c) cease to use the product.
>
> A (IMO -- feel free to debunk me :)) troublesome point is dead software.
>
> What do I do if I start a project under BK, code on it for three months,
> and abandon the project / slack off / have the manager kill it.
>
> Are they still obligated to make the software public?
What I had in mind was having BK refuse to build changesets on top of
more than 3 month old changesets. So you would get a 3 month window
in which to play around and either kill it, leave it alone, or
publish it.
I'm not sure it's going to work, I think people have a legit point
that there are legit uses for which this doesn't work.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, Apr 22, 2002 at 12:52:48AM +0200, Daniel Phillips wrote:
> Larry's proposing to turn BitKeeper into an automated GPL enforcement machine,
> even poking it's nose into areas the GPL isn't concerned about. This is a
> horribly broken reason for adding let more t&c's do the license.
You didn't read Larry's initial email very close. He isn't trying to turn
BK into a GPL enforcing machine, he's trying to turn BK into a BK License
enforcing machine. Larry lets certain people (such as linux kernel
hackers) use BK for free. He does that specifically for contributors
to open source projects. Some people are, in essence, signing up to use
the software as though they are working on open source projects but they
are never actually open sourcing their work (or are intentionally
obfuscating parts of it). Since that violates the spirit of what Larry is
trying to do by letting people use BK in a non-commercial manner, he is
trying to find appropriate wording and possibly algorithms that can be put
into BK to enforce the original spirit of the free use license that BK
allows certain people. So, he's not poking his nose into the GPL, he's
trying to find a way to make sure that people who claim to be using BK on
GPL projects (and free of charge as a result) are actually doing so.
That's perfectly within his rights as owner of BK.
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
On Tuesday 23 April 2002 01:12, Doug Ledford wrote:
> On Mon, Apr 22, 2002 at 12:52:48AM +0200, Daniel Phillips wrote:
> > Larry's proposing to turn BitKeeper into an automated GPL enforcement machine,
> > even poking it's nose into areas the GPL isn't concerned about. This is a
> > horribly broken reason for adding let more t&c's do the license.
>
> You didn't read Larry's initial email very close. He isn't trying to turn
> BK into a GPL enforcing machine, he's trying to turn BK into a BK License
> enforcing machine.
He said:
> The real issue is that we know from past history that companies make
> changes to GPLed software and then delay access to those changes as
> long as they can (the GPL allows for a "reasonable" amount of lag,
> whatever that is).
>
> The intent of the openlogging requirement was to allow people to work
> out in the open on free software, at no charge. The intent was never
> to allow people to work on free software without giving their changes
> back.
It looks like GPL enforcement is the pretext for the changes. Ah well, it's
not my concern, he can make BitKeeper as intrusive as he likes, fortunately
I am not going to be annoyed by that because I'm just taking a pass on the
whole thing. Thanks to the recent discussion, which opened my eyes.
I'm glad it's helping Linus to scale, much as Microsoft Office helps office
workers to scale. That's good I suppose. I keep telling myself.
> Larry lets certain people (such as linux kernel
> hackers) use BK for free. He does that specifically for contributors
> to open source projects. Some people are, in essence, signing up to use
> the software as though they are working on open source projects but they
> are never actually open sourcing their work (or are intentionally
> obfuscating parts of it).
Wait. I thought people were perfectly able to do whatever they wanted with
BitKeeper, so long as they use the open logging. I guess I was wrong about
that. This is getting more anal all the time.
> Since that violates the spirit of what Larry is
> trying to do by letting people use BK in a non-commercial manner, he is
> trying to find appropriate wording and possibly algorithms that can be put
> into BK to enforce the original spirit of the free use license that BK
> allows certain people.
It's impossible not to read that as 'add more restrictions'.
> So, he's not poking his nose into the GPL, he's
> trying to find a way to make sure that people who claim to be using BK on
> GPL projects (and free of charge as a result) are actually doing so.
> That's perfectly within his rights as owner of BK.
Indeed. Just one more reason to build a replacement I suppose.
--
Daniel
Hi!
> So that leaves a more selective approach. We can add a clause that says
> we reserve the right to insist you either
>
> a) maintain your changes in public within 90 days of making them, or
> b) buy closed use seats, or
> c) cease to use the product.
>
> and then apply it to the abusers of the system. I understand this is
Heh. According to your license, all you have to do is to get very expensive
disk. Then, put offender's file on that disk, and claim that your costs
exceeded 00000 (or how much you have in the licence) and that means auto
licence termination IIRC.
Oh and btw how can you change licence retroactively? Those "abusers" have
right to continue to use old versions under old licences...
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Pavel Machek <[email protected]> writes:
> Oh and btw how can you change licence retroactively? Those "abusers" have
> right to continue to use old versions under old licences...
BK licenses become invalid as soon as a new BK version is released
which contains bug fixes or behaves differently in any way.
--
Florian Weimer [email protected]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Hello Florian (&all) , BK is (primarily in this community) used
by the kernel maintainers . What happens to the little guy who
may make a once a year contribution & uses BK ? Also what methods
of announcement for New BK versions are there ? Because as soon
as a new version is advertised the copy I am using even if I am
unaware of the newer version I do not have a valid license to use
it . This is per your remarks below .
I'd -really- like to see what would happen if something like this
were placed on the GCC sources . Me thinks linus et-al would be
creating their own compiler . Just some food for thought .
Twyl , JimL
On Sat, 27 Apr 2002, Florian Weimer wrote:
> Pavel Machek <[email protected]> writes:
>
> > Oh and btw how can you change licence retroactively? Those "abusers" have
> > right to continue to use old versions under old licences...
>
> BK licenses become invalid as soon as a new BK version is released
> which contains bug fixes or behaves differently in any way.
>
> --
> Florian Weimer [email protected]
> University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
> RUS-CERT +49-711-685-5973/fax +49-711-685-5898
> -
> 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/
>
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
The best thing would be to stop this egg-dance around open sourceness and
release BK under GPL. This is wasting too much time. Trying to use a
non-free product to make sure other peoples source code is available via
GPL? How imaginative and creative ... Wow...
Major organizations (such as Debian and lots of related projects
committed to free software f.e.) will not use BK with the
current licensing scheme so why bother with this?
I do not even know how BK works and I am not interested ...
just offended by ppl making access to development kernel source code
difficult and offended by someone with a star status apparently being
able to abuse the system.
On Sat, Apr 27, 2002 at 11:13:35AM -0700, Christoph Lameter wrote:
> I do not even know how BK works and I am not interested ...
> just offended by ppl making access to development kernel source code
> difficult and offended by someone with a star status apparently being
> able to abuse the system.
*BEFORE* we start yet another flame war. TAKE IT OFF THIS MAILING LIST.
I'm sick and tired of this BK/anti-BK crap advocates keep bring up.
Create a new list to argue the toss, please. Don't distract the people
actually trying to get some useful kernel work done.
Thanks.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, 27 Apr 2002, Christoph Lameter wrote:
> The best thing would be to stop this egg-dance around open sourceness and
> release BK under GPL. This is wasting too much time. Trying to use a
1001st time, CHOICE OF LICENSE BELONGS AUTHOR OF CODE IN QUESTION, dimwit.
How many times should that be repeated until it sinks down?
> I do not even know how BK works and I am not interested ...
> just offended by ppl making access to development kernel source code
> difficult
... and who the hell would these people be? I _AM_ interested since
I'm not using BK and I'm working on aforementioned development kernel
source. Care to enlighten me?
Until you've got real arguments (ones that would include some proof
if the claims you've made) - fuck off and stop polluting l-k with
your drivel.
Apologies in advance for contributing to this thread, but I think this
is a fairly calm and reasonable response which sums up our position.
You may not like it, but it may help to understand it.
On Sat, Apr 27, 2002 at 11:30:12AM +0200, Florian Weimer wrote:
> Pavel Machek <[email protected]> writes:
> > Oh and btw how can you change licence retroactively? Those "abusers" have
> > right to continue to use old versions under old licences...
>
> BK licenses become invalid as soon as a new BK version is released
> which contains bug fixes or behaves differently in any way.
The license says that you have to upgrade if your version will not pass
the current regressions. In other words, if we have fixed a problem,
written a test case for it, shipped the fixed version and the test case,
then yes, you need to upgrade. If it was important enough that we wrote
a test case for it, it's probably something you'll end up hitting sooner
or later.
This is not directed at Florian, but to the whole list:
Another thing to think about is that we need to get something from the
people who use it for free. We support them, that support costs money,
and if we get nothing back, we're pretty much doomed compared to any
other company. What we are asking back is that you test the latest and
greatest. Our business model is that we give and get to/from everyone.
The free users get an expensive product for free, but they have to
give back by helping shake out the bugs from the current release.
The paying users have the right to sit on an old version, but they give
back by paying.
It's really just an optimization problem. What we've done is to optimize
for the most that we can do for the most people. I'm well aware that
some free software folks hate that it isn't open source, that's just
not realistic for this sort of product.
It seems like every couple of weeks someone says they don't like the BK
license and they are going to rewrite BitKeeper. I have two thoughts
on that: (A) I doubt it will happen, it's more work than it looks like.
If you want to spend a few years working 7 days a week, be my guest.
Most people don't have the stomach for it. (B) If someone did write
a decent open source replacement, that would actually be OK with me.
All of the people who work at BitMover are capable of doing work on much
more lucrative endeavors.
In short: go build a better answer, and until you do it, how about
easing off on the "BK is evil corporate software" mantra a bit? It's
not evil corporate software, it's software built by people from your
community, for your community, in the most acceptable we could find
which was self sustaining.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Uz.ytkownik Alexander Viro napisa?:
>
> On Sat, 27 Apr 2002, Christoph Lameter wrote:
>
>
>>The best thing would be to stop this egg-dance around open sourceness and
>>release BK under GPL. This is wasting too much time. Trying to use a
>
>
> 1001st time, CHOICE OF LICENSE BELONGS AUTHOR OF CODE IN QUESTION, dimwit.
> How many times should that be repeated until it sinks down?
Anton please please let this discussion going on. It is *very*
good at pointing at the people who need an permanent personal
entry in my killfile for lkml ;-).
Martin Dalecki writes:
> Uz.ytkownik Alexander Viro napisa?:
> > 1001st time, CHOICE OF LICENSE BELONGS AUTHOR OF CODE IN QUESTION, dimwit.
> > How many times should that be repeated until it sinks down?
>
>
> Anton please please let this discussion going on. It is *very*
> good at pointing at the people who need an permanent personal
> entry in my killfile for lkml ;-).
*Cough*! Martin: I've seen you flame quite a few times as well. I
don't think you can claim the moral high ground.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Hi!
> > > Oh and btw how can you change licence retroactively? Those "abusers" have
> > > right to continue to use old versions under old licences...
> >
> > BK licenses become invalid as soon as a new BK version is released
> > which contains bug fixes or behaves differently in any way.
>
> The license says that you have to upgrade if your version will not pass
> the current regressions. In other words, if we have fixed a problem,
> written a test case for it, shipped the fixed version and the test case,
> then yes, you need to upgrade. If it was important enough that we wrote
> a test case for it, it's probably something you'll end up hitting sooner
> or later.
...
> The free users get an expensive product for free, but they have to
> give back by helping shake out the bugs from the current release.
...and ability to change license under their backs any time you want comes
as nice bonus, eh?
> It's really just an optimization problem. What we've done is to optimize
> for the most that we can do for the most people. I'm well aware that
Its really you with very nice ability to blackmail anyone using BK. "We
don't like you, so we are changing licence under your back. Either pay 000,
or you have just lost access to your revision histories." [Oh and oone
promissed it can not be .000.000 per seat in next version.]
> In short: go build a better answer, and until you do it, how about
> easing off on the "BK is evil corporate software" mantra a bit? It's
BK *is* evil corporate software, with unique trapdoor capabilities, and
with unique ability to take away rights from user any time it wants.
Pavel
PS: No need to reply, but I just could not stand "you have no rights because
we can change licence anytime" and "we are not evil" in one mail.
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Fri, 26 Apr 2002, Pavel Machek wrote:
> > In short: go build a better answer, and until you do it, how about
> > easing off on the "BK is evil corporate software" mantra a bit? It's
>
> BK *is* evil corporate software, with unique trapdoor capabilities, and
> with unique ability to take away rights from user any time it wants.
BK is made available to us at no cost; BK is saving Linus and
Marcelo a lot of work, making it possible for them to merge more
patches into the kernel.
If you only spent 10% of the energy you spent complaining on
making a bitkeeper replacement, maybe you'd realise that Larry
is making a very useful contribution.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
FYI - You won't see me replying to this because he's joined some others in
my procmail filter, enabling me to get more work done. I love procmail.
Besides, Rik is doing a great job, thanks Rik!
To underscore Rik's point: it took 4 years of at least 6 day/week efforts
by a team that varied in size from 3-8 engineers to get BitKeeper where
it is today. Pavel is welcome to try and do better, but he sure as
hell isn't going to do it in his spare time. Nobody is, it's a much
harder problem than it looks like. I really wish people would try it
and find out. Maybe I'm wrong, in which case we can all get on to doing
something more fun.
On Mon, Apr 29, 2002 at 04:34:30PM -0300, Rik van Riel wrote:
> On Fri, 26 Apr 2002, Pavel Machek wrote:
> > > In short: go build a better answer, and until you do it, how about
> > > easing off on the "BK is evil corporate software" mantra a bit? It's
> >
> > BK *is* evil corporate software, with unique trapdoor capabilities, and
> > with unique ability to take away rights from user any time it wants.
>
> BK is made available to us at no cost; BK is saving Linus and
> Marcelo a lot of work, making it possible for them to merge more
> patches into the kernel.
>
> If you only spent 10% of the energy you spent complaining on
> making a bitkeeper replacement, maybe you'd realise that Larry
> is making a very useful contribution.
>
> regards,
>
> Rik
> --
> Bravely reimplemented by the knights who say "NIH".
>
> http://www.surriel.com/ http://distro.conectiva.com/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Larry McVoy <[email protected]>
Date: Mon, 29 Apr 2002 12:45:14 -0700
Larry,
> it is today. Pavel is welcome to try and do better, but he sure as
> hell isn't going to do it in his spare time. Nobody is, it's a much
> harder problem than it looks like. I really wish people would try it
> and find out. Maybe I'm wrong, in which case we can all get on to doing
> something more fun.
you are not wrong. You have your `truth'. Pavel has his one. Pavel prefers
free software and its freedom. Some people here prefer using BK instead of
using (objectively worse) similar GPLed software. They have the right to
think that and they have the right to say so.
Yes, I too think that using BK for kernel development is politically wrong
decision and in the long run it will have bad effects on free software
(generally, Linux kernel and the community specially).
Do not take it as a critique. I do not want to criticize you or your
colleges. You did a great job!
But releasing BK under free software license would be (for me) much
better. Of course, I can not force you to change the license or something
similar. You are the creator and you have the right to release your work
under license you find the best! I (or anyone else) can not tell you what
should be done. But we all can tell you our opinion.
But I do not think that having different `truth' qualifies people to be
blackholed. Sorry, but I think you are like small child...
--
Pavel Jan?k
Keep it simple to make it faster.
-- The Elements of Programming Style (Kernighan & Plaugher)