From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263876AbTLOTwi (ORCPT ); Mon, 15 Dec 2003 14:52:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263913AbTLOTwh (ORCPT ); Mon, 15 Dec 2003 14:52:37 -0500 Received: from adsl-67-114-19-185.dsl.pltn13.pacbell.net ([67.114.19.185]:1257 "EHLO bastard") by vger.kernel.org with ESMTP id S263876AbTLOTwe (ORCPT ); Mon, 15 Dec 2003 14:52:34 -0500 Message-ID: <3FDE10FA.4040305@tupshin.com> Date: Mon, 15 Dec 2003 11:52:26 -0800 From: Tupshin Harper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry McVoy Cc: linux-kernel@vger.kernel.org Subject: Re: RFC - tarball/patch server in BitKeeper References: <20031214172156.GA16554@work.bitmover.com> <3FDCEF70.5040808@tupshin.com> <20031214234348.GA15850@work.bitmover.com> <3FDCFE17.5010309@tupshin.com> <20031215034627.GB16554@work.bitmover.com> <3FDD4FB2.8020607@tupshin.com> <20031215160246.GA3947@work.bitmover.com> In-Reply-To: <20031215160246.GA3947@work.bitmover.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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