lkml.org 
[lkml]   [2005]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BK] upgrade will be needed
I agree with this 100%, and this is exactly the same conclusion we came 
to in our research lab.

Tom Felker wrote:
> I really think the fewer restrictions you put on BK's use, the less likely it
> will be copied. When the open source community copies something, it's not out
> of a desire to screw somebody over. It's because they had an itch, a
> software need that couldn't easily be fulfilled otherwise, a demand.
>
> Apparently there is a demand for good SCM, and BK can satisfy this, and you've
> done the very admirable thing of letting the open source community use BK at
> no cost. But by putting such a heavy restriction on its use, you create a
> large portion of the community who won't or can't use it, and who therefore
> need a "copy" of it, which is exactly what you are trying to prevent.
> ...
> Better for you would be to just not create this segment in the first place, by
> making the license as unrestrictive as you can while still making money. If
> you take the non-compete clause out and leave it at "open repository and
> logs," then BT would be good enough for most everybody, and you wouldn't have
> to worry about a copy until after we're all using the Hurd.

One person (out of 20 or so), refused to use BK because he
occasionally worked on a binary tree-diff in his spare time. He was, of
course, properly following the BK-free license, but it meant the
projects he worked on never got switched from CVS, while everything else
went BK. It also kept us looking for replacements to make everyone
happy. We consider every possible alternative, even though by most
measures they are inferior (There isn't an SCM that I've heard of that
someone in our lab hasn't tried using). The peer pressure, if you will,
also made the holdout *more* involved in SCM development, which is
almost surely *not* a help for BitMover. New projects are not being put
in BK anymore, either.

Maybe this is an overly long and excessively detailed account, but my
interpretation of it is the following: Without the no-compete (1) We'd
all be using BK happily, (2) The holdout would not be working on an SCM
anymore, and (3) Other SCM projects would not get the user testing they
now enjoy from us. I cannot speak for anyone else, but this is the
effect on our lab, and for us, the clause has hurt BitMover's stated
intention, not helped it.

- Jim Bruce

P.S. According to what is now legend, one of the things that drove RMS
to the FSF philosophy was a person at CMU who wouldn't share printer
driver source code with him.
(http://www.catb.org/~esr/writings/rms-bio.html)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.148 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site