Re: RFC - tarball/patch server in BitKeeper

Tupshin Harper
2003-12-15T19:52:38Z

Larry McVoy wrote:

>On Sun, Dec 14, 2003 at 10:07:46PM -0800, Tupshin Harper wrote:
>
>
>>>Great, glad you understand that you are crossing the legal line.
>>>
>>>
>>??? what line am I crossing? Or do you mean that I would be if I were
>>to do something, and if so, what is that something? I informed you the
>>day that decided I was interested in exploring the internals of other
>>SCM products, and deleted the bk binaries from my machine at the same
>>time.
>>
>>
>Tupshin, the BK license makes it clear that BK doesn't want to be reverse
>engineered, we've been over this and over this. Furthermore, reverse
>engineering for interoperability has a prerequisite that there is no other
>way to get at the data and we give you tons of ways to get at the data.
>
>
But not all data. That's the point. The bk2cvs process is lossy...you
can't gloss over that point.

>You keep wanting more and more information about how BitKeeper manages
>to do what it does and that certainly falls under reverse engineering.
>
>
No...I keep wanting free (speech) access to all (current and historical
information) that is part of the kernel. You ignored the question of who
owns the changesets. Or maybe, more appropriately, what license do the
changesets have?

>Getting at the raw information is just another way to figure out how
>BitKeeper manages that data, it's exactly the same as running a compiler
>and looking at the assembly language it produces.
>
Is there some implication here that is a license violation for a bk
(free license) user to make available full changesets for non-bk users
to user for *any* purpose?

-Tupshin