From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27441 invoked by alias); 14 Mar 2012 11:11:32 -0000 Received: (qmail 27421 invoked by uid 22791); 14 Mar 2012 11:11:30 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Mar 2012 11:11:12 +0000 Received: by wera1 with SMTP id a1so1767572wer.20 for ; Wed, 14 Mar 2012 04:11:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.139.129 with SMTP id c1mr1329945wej.48.1331723471478; Wed, 14 Mar 2012 04:11:11 -0700 (PDT) Received: by 10.216.162.66 with HTTP; Wed, 14 Mar 2012 04:11:11 -0700 (PDT) In-Reply-To: <1331721811.2573.0.camel@ladybug.local> References: <1331721811.2573.0.camel@ladybug.local> Date: Wed, 14 Mar 2012 11:11:00 -0000 Message-ID: Subject: Re: Which library implementation to use/work on? From: Mike Hearn To: Chris Burdess Cc: java@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00044.txt.bz2 >> I understand the reasons for this policy. However, as you are planning >> on (eventually) replacing Classpath with OpenJDK completely, an >> exception in this case would seem to make logical sense. The code will >> end up not owned by the FSF no matter what. > > Well, no. The FSF will still own Classpath. Yes. But drawing a line in the sand and saying "after this point, we no longer have the ability to relicense as we wish, but that's OK because we don't care about this codebase anymore" seems prudent as a migration strategy. My basic issue is, given license compatibility, reimplementing things purely so the FSF has the option of relicenseing a codebase that it probably never will is not a good use of time. In practice it just means people won't submit patches because unless they're working on AWT or some other library where copy/pasting code is hard, it never makes sense to upstream patches. That in turn makes it harder for people to benefit from those patches.