--On Wednesday, October 16, 2002 10:04 AM -0400 Paul Lussier
<pll@lanminds.com> wrote:
> There is no conflict if you are using the free BK license and *not*
> working on a competing project. Additionally, if you are working
> on both a competing project *and* a non-competing project which
> use BK as their revision control system, there is no conflict if
> you use BK on the non-competing project but something else on the
> competing project.
Nope, that is incorrect. If you work on a competing project, you can
not use BK under the free license no matter what. You must purchase
BK.
I'm not really sure where you got that misinterpretation. Larry's
been pretty clear on this. His intent is for these people not to
ever use BK without paying.
> sense, but is perfectly fair. Besides, you don't *need* BK to work
> on the Linux Kernel, it's just a nicety (many people have refused
> to use BK on moral grounds and are apparently getting on fine
> without it!).
I disagree that they are getting along fine. Eventually, Linus will
start taking longer to process diff-style patches and might
eventually drop support for it due to time constraints - perhaps
relegating merging of the diff-style patches to someone else.
Think of it like contributors on this list submitting patches versus
people who have commit access to the SVN repository. No matter what
you (or Larry say) there *is* a difference - *you* have to work that
much harder to get the code into the tree if *you* don't use the
preferred SCM system. This is not to mention the extra headache for
the person who has to merge the changes in. There's a good reason
why Linus moved away from diff-style patches - it doesn't scale.
And, as Greg pointed out, the Linux development model is incredibly
unique. BK fits Linus's way to a T. It just so happens that a lot
(99.9%?) of other projects don't share that model - that 99% is the
target audience for 1.0. We can try to target the Linux-like model
post-1.0. World domination one release at a time...
I can't believe I'm replying to this thread. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 16 19:32:33 2002