[lkml]   [2003]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: openbkweb-0.0
    On Sat, 15 Feb 2003, Larry McVoy wrote:

    > On Sat, Feb 15, 2003 at 08:44:59PM +0000, Alan Cox wrote:
    > > On Sat, 2003-02-15 at 18:12, Larry McVoy wrote:
    > > > All of this sounds great and is exactly what is already the plan.
    > > > There is one missing item. A consensus in the community that if we
    > > > provide BK, the CVS mirror, bkbits hosting, in return the community
    > > > agrees to leave off using BK to copy BK.
    > >
    > > The community is an amorphous thing so thats tricky to define
    > You're right, I thought of that after I posted. What would probably
    > work best is if someone who was not particularly BK friendly but
    > is acknowledged as a Linux leader were to step forward and agree to
    > represent the community interests.

    Larry, what you ask is impossible.

    This community isn't hierarchized and is unlikely to form a single opinion
    on anything like corporate politics. No one can be authoritative of
    everybody else's opinion.

    It doesn't work in a pull model either where you ask for things. Rather,
    you must push things and see how it goes, how people react.

    > It's clear from the fuss this causes about every three weeks that people
    > don't feel safe, on either side. You're scared that we're going to do
    > some evil thing and we're scared that you are going to do evil thing.

    That might be true, but I think the BK opponents from the community are more
    concerned by preserving their "freedom" (or ability) to access the
    up-to-the-minute changes that appeared in the official kernel reference
    repository, and without being forced to use a proprietary tool with a
    proprietary protocol and with restrictive license terms. I really think it
    has nothing to do with BK itself beside the fact that it's BK that is used
    to handle the data they cherish so much and no "free" path currently exists
    to that data. Even if hourly snapshots do exist, that still makes those
    people sort of second class citizens. They want the changes available to
    them in real time but in the most purist free way too. The best answer is a
    CVS gateway IMHO, and then the true believers, or those who simply can't
    comply with your license for all sort of good and legitimate reasons, won't
    have anything against you from that moment since they won't see BK as an
    obstacle in the way.

    If a real time CVS gateway exists, and is pushing CVS commits to and just to name those few obvious examples among
    others, then individuals within this community will have the choice between
    many tools according to their respective characteristics and not based on the
    quality of service with regards to the kernel repository.

    Only then people won't be able to invoke the BitMover lock-in argument
    against the Linux community (regardless if that was your intention or not),
    and only then will you be able to consider those who try to reverse-engineer
    your "technology" as bad people, since invoking fair use will then be much
    harder to legitimate.

    In other words, if people can have real time change sets to the reference
    kernel and have the possibility of ignoring you and BK entirely at the same
    time, only then the issue will be closed.

    > Maybe it's not possible, but it would be nice if we could, operating in
    > good faith, work out some sort of agreement that made sense. Yeah, I
    > know it isn't binding, that the best you could do on the community side is
    > have a bunch of people stand up and say "hey, leave BitMover alone, they
    > are doing a good service" but I'd take that over the current mess any day.

    You are doing the best you can in the terms you chose, and a lot of people
    including myself are extremely grateful. Your terms are just totally
    incompatible with the view of some people. And many of those people just
    don't like what you do and they _never_ will, that's a simple fact of life.
    Your only way out is to provide a mechanism that will allow them to totally
    ignore you without impairing their access to the kernel development data.
    BK might be way ahead at what it does, but real-time access to the kernel
    repository must _not_ be among the advantages of BK against competitor


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:33    [W:0.034 / U:13.248 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site