Re: [RFC] Linux Kernel Subversion Howto

[Nicolas Pitre]

On Wed, 9 Feb 2005, Larry McVoy wrote:

> On Wed, Feb 09, 2005 at 12:17:48PM -0500, Nicolas Pitre wrote:
> > On Tue, 8 Feb 2005, Larry McVoy wrote:
> > > You know, you could change all this.  Instead of complaining that we
> > > are somehow hurting you, which virtually 100% of the readers know is
> > > nonsense, you could be producing an alternative answer which is better.
> > 
> > IMHO something is flawed in this whole argument.  Why would someone be
> > interested into any alternative answer for working on the Linux kernel
> > tree if the whole thing can't be imported into it with the same
> > granularity as can be found in BK?  IOW what's the point to alternatives
> > if you can't retrieve the entire workset?
> 
> Please explain to me where the data is being lost.  100% of the patches
> are available on bkbits.net with no license agreement required.  They
> always have been.

Are you saying that it is now OK to write scripts that would bit bang on 
the bkbits http interface to fetch patches/comments with the purpose of 
populating an alternate scm?  Andreas tried that a while ago but you 
threatened to shut the service down entirely if he was to continue.

> The problem is that you want us to tell you how BK manages those patches.
> That was never part of the agreement, in fact we made it clear in the
> license that that information was considered to be IP and could not be
> distributed.  How BK does that is our business, not yours.

I completely agree here.  But just to be on the same page, let me quote 
Stelian's proposal here again:

On Tue, 8 Feb 2005, Stelian Pop wrote:

| What you could make available in the bkcvs export would be, for each
| changeset (both for the changesets and for the merged changesets),
| include three BKRevs:  the changeset's one, the changeset's parent one,
| and the changeset's merge parent one.
|
| That information could be used to reconstruct the entire tree,
| using either bk-commit-head (preferred) or bkbits, provided you
| put the BKRev: tag into the bk-commit-head posts too.
|
| Technicaly speaking this should be very easy for you to implement.

Is the above actually part of the protected BK IP?  Can anyone run with 
such information and clone BK in a smooth breeze with that?  I don't see 
how such info can tell how BK manages it.

> If you want
> to know how BK does it you must go figure it out without the benefit
> of BK itself or metadata managed by BK.

I think what people want here is the tree structure representation in 
whatever form, not necessarily in the BK format.  One example of that 
was provided above. You can't deny others access to the whole of the 
Linux kernel development history even if their purpose is to import it 
into a competing system (more on that below).

> While I understand that you don't like it, is there no sense of fairness
> left?  We did the hard work to create BK.  Some of us worked for *years*
> without pay to create this product.  Some of us put our life savings
> into the product.  It's our IP, we paid heavily to create this, is it
> so unreasonable of us to want to protect our work?  I believe we are
> within our legal rights, or so our legal team tells us, but that should
> be beside the point.  It's our work.  We paid for it.  We certainly
> don't have any obligation to tell you how we did it and to us it seems
> pretty unreasonable that you don't just go off and do the work yourself.

Again I wholeheartedly agree with you above.  But that's not exactly the 
point.  You certainly have the right to protect your work.  But please 
admit that the Linux kernel developers own the right to move (100% not 
96%) of the development tree with all its branches _they_ produced.  In 
other words, the product of the current Linux BK repository is the 
result of those Linux developers not yours.  Of course BK is the 
indispensable tool that made it possible, but BK could have been 
developed even without the Linux BK repository.

So what people are asking for again and again is a way to represent in 
alternate form to BK internal metadata the Linux development tree 
structure but without you to give away the BK IP, be that in XML, plain 
text, or just with BK refs attached to patches like suggested above.  
Unless I'm completely dumb, this won't reveal anything about BK itself 
and how you did it?

Now obviously enough some people will run away with that raw data and 
try to import the Linux kernel source tree in their own scm of choice.  
That's why I'm asking you "and so what?"  Granted all the efforts you 
put into BK as you say above, do you really expect the alternative scm 
to suddenly be as functional and scalable as BK in a single swoop just 
because they can import the Linux BK tree with the same patch 
granularity as BK does?  If you worked so hard on BK for many years it 
means the competition should be far behind.  Therefore what do you fear?

Note that if someone actually needs a big tree to test bench an 
alternate scm there are alternatives to the kernel -- gcc is a good 
example.  So allowing the Linux kernel tree to be imported into another 
scm is not really a requirement for developing on said scm.

> And pretty unadmirable as well, don't you have any faith in your own
> abilities?

Do you have faith in your own work?  If so allowing others to import the 
complete Linux development tree into alternative scm shouldn't scare you 
so much.  You probably know already that they won't be able to scale as 
well as BK, and we're not even talking about the ability to perform push 
and pull type operations here.  So what do you actually fear?  I'll be 
fully on your side once I grasp the actual threat to BK.

Note I'm trying to understand what the actual problem is here.  I'm not 
concerned by the non-free nature of BK at all.  It is the best tool for 
distributed development available, and it's been applied to Linux 
development with no $ cost.  I'm just wondering why providing some 
additional info which would allow for rebuilding the tree with all 
changeset relationships (into whatever alternate inferior scm that's not 
the point) would uncover your IP.  It's just a graph with patches 
attached to it in the end.  No need to tell us how BK manages it.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/