From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21347 invoked by alias); 26 Apr 2010 17:15:55 -0000 Received: (qmail 21211 invoked by uid 22791); 26 Apr 2010 17:15:52 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Apr 2010 17:15:48 +0000 Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o3QHFiDB027948 for ; Mon, 26 Apr 2010 19:15:44 +0200 Received: from wyb33 (wyb33.prod.google.com [10.241.225.97]) by kpbe14.cbf.corp.google.com with ESMTP id o3QHFgQU018681 for ; Mon, 26 Apr 2010 10:15:42 -0700 Received: by wyb33 with SMTP id 33so256862wyb.6 for ; Mon, 26 Apr 2010 10:15:41 -0700 (PDT) Received: by 10.216.90.206 with SMTP id e56mr265422wef.167.1272302141764; Mon, 26 Apr 2010 10:15:41 -0700 (PDT) Received: from coign.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) by mx.google.com with ESMTPS id d16sm189531wej.21.2010.04.26.10.15.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 10:15:39 -0700 (PDT) To: Mark Mielke Cc: gcc@gcc.gnu.org Subject: Re: Why not contribute? (to GCC) References: <4BD20EDF.2050102@starynkevitch.net> <4BD49959.5070500@mark.mielke.cc> <4BD55DB2.3080103@mark.mielke.cc> From: Ian Lance Taylor Date: Mon, 26 Apr 2010 17:19:00 -0000 In-Reply-To: <4BD55DB2.3080103@mark.mielke.cc> (Mark Mielke's message of "Mon\, 26 Apr 2010 05\:32\:34 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00839.txt.bz2 Mark Mielke writes: > What are clean room implementations for if not for avoiding copyright > violation? Avoiding contract violations such as promises to keep source code secret. A strict clean room implementation also makes it clear that no copyright violation could have occurred. > At my company, we took things seriously to the point of > dividing the GPL designers from the non-GPL designers to prevent code > fragments from being leaked to one side or the other, even if just a > faint memory that ends up resulting in code that looks just about > exactly like the original, even if the author cannot identify what the > original was. I think that was entirely unnecessary on your part, though of course lawyers, like anybody else, will tend to ask for whatever they can get. I won't respond further on this subthread on the list, it has nothing to do with gcc. Ian