From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6090 invoked by alias); 8 Nov 2010 22:47:14 -0000 Received: (qmail 6082 invoked by uid 22791); 8 Nov 2010 22:47:13 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_50,TW_GD,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Nov 2010 22:47:08 +0000 Received: (qmail 21416 invoked from network); 8 Nov 2010 22:47:07 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Nov 2010 22:47:07 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1PFaUS-0006A1-Qv; Mon, 08 Nov 2010 22:47:04 +0000 Date: Tue, 09 Nov 2010 01:14:00 -0000 From: "Joseph S. Myers" To: Walter Bright cc: gcc@gcc.gnu.org Subject: Re: Merging gdc (Gnu D Compiler) into gcc In-Reply-To: <4CD8767B.6030604@digitalmars.com> Message-ID: References: <4CD8767B.6030604@digitalmars.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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-11/txt/msg00185.txt.bz2 On Mon, 8 Nov 2010, Walter Bright wrote: > Who do I need to talk to in order to resolve the various licensing issues so > this becomes possible? The FSF, via the Steering Committee, via this list. The standard assignment and licensing policies are as described in the Mission Statement . Any special arrangement like that for the Go front end (where part providing the GCC interface is assigned to the FSF and maintained in the GCC tree and part that could be used with other back ends is maintained externally with third-party copyright) needs specific approval. (Note that the Go front end does not yet achieve the level of separation achieved by Ada, for example; there are plenty of uses of GCC's tree interfaces in the gofrontend/ directory that mean portability to other back ends is more theory than reality.) In general I'd like to encourage maintainers of separate front ends - not limited to D - to work towards merging them into FSF GCC and maintaining them there; additional front ends help improve the quality of the core language-independent code, and no doubt GNU/Linux distributors would be glad to avoid the complexities of patching out-of-tree front ends into their GCC packages. Front ends do of course need to pass technical review and do things in the ways that are considered current good practice for front ends instead of being gratuitously different, but when maintainers are ready to follow current good technical and licensing practice I think having them in FSF GCC benefits both the front ends and GCC. -- Joseph S. Myers joseph@codesourcery.com