Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 20 Jan 2003 16:05:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 20 Jan 2003 16:05:48 -0500 Received: from mail.webmaster.com ([216.152.64.131]:54153 "EHLO shell.webmaster.com") by vger.kernel.org with ESMTP id convert rfc822-to-8bit; Mon, 20 Jan 2003 16:05:47 -0500 From: David Schwartz To: CC: , , X-Mailer: PocoMail 2.63 (1077) - Licensed Version Date: Mon, 20 Jan 2003 13:14:47 -0800 In-Reply-To: <20030120134831.Q1594@schatzie.adilger.int> Subject: Re: Is the BitKeeper network protocol documented? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Message-ID: <20030120211449.AAA797@shell.webmaster.com@whenever> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 20 Jan 2003 13:48:31 -0700, Andreas Dilger wrote: >So, let's say that CVS is the "preferred form" of the Linux kernel >source code, because it is freely available. If BK has everything >in it that CVS does, and also information that is not even POSSIBLE >to store in CVS (i.e. ChangeSet information which links a bunch of >individual file changes and comments into a single change entity) >what happens then? If you had never put the kernel into BK, that >information wouldn't exist at all, yet >it is not possible to extract it without resorting to some >source-of-all- evil >tool like BK (I hope everyone reading here understands the sarcasm, >but the fact that I have to annotate it makes me believe some people >will not). If CVS is the "preferred form", then it is CVS you must distribute. What other tools provide what other information is irrelevant. The GPL is quite clear that the preferred form of the source for making modifications is what you must distribute. >The fact that BK is used creates information which WOULD NOT HAVE >EXISTED >had BK not existed. In fact, until BK was in use by Linus, not even >basic >CVS checkin comments existed, so the metadata was in a format called >linux-kernel mbox (if that). So, the use of a tool like BK makes >more data >available, but people cannot be worse off than when the kernel was >shipped >as a tarball and periodic patches. For the sake of those people who >don't >or can't use BK, just pretend BK doesn't exist and they will not be >any >worse off than a year ago. The GPL doesn't care about whether you're better off or worse off. The GPL just says you have to distribute the source in its preferred form for making modifications. >>I submit that it is impossible to comply with the GPL and >>distribute >>binaries if the preferred form of a work for the purposes of making >>modifications to it is in a proprietary file format. This is >>tantamount to encrypting the source. >Sure, except BK isn't a proprietary file format (see GNU CSSC and or >some >Perl scripts reported on this list), so the issue is purely >hypothetical. It sounds like you and I are in violent agreement. But it's not purely hypothetical -- there are GPL projects today that keep their source in proprietary file formats. (For example, many of the ones using Visual C++.) DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/