From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7xXg-0003Nk-UF for qemu-devel@nongnu.org; Wed, 14 Mar 2012 19:23:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7xXe-0002Pf-AI for qemu-devel@nongnu.org; Wed, 14 Mar 2012 19:23:40 -0400 Received: from mail-pz0-f47.google.com ([209.85.210.47]:43409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7xXe-0002PL-48 for qemu-devel@nongnu.org; Wed, 14 Mar 2012 19:23:38 -0400 Received: by dado14 with SMTP id o14so3896147dad.34 for ; Wed, 14 Mar 2012 16:23:36 -0700 (PDT) Message-ID: <4F612874.3040303@codemonkey.ws> Date: Wed, 14 Mar 2012 18:23:32 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1330893156-26569-1-git-send-email-afaerber@suse.de> <1331689198-11076-1-git-send-email-afaerber@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 0/7] QOM'ify UniCore32 CPU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Guan Xue-tao , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , qemu-devel@nongnu.org On 03/14/2012 03:02 PM, Blue Swirl wrote: > On Wed, Mar 14, 2012 at 01:39, Andreas Färber wrote: >> Hello, >> >> Based on qom-cpu v4 and object_class_get_list() v2, this series converts >> the UniCore32 CPU to QOM. Code-wise, target-unicore32 is pretty close to >> target-arm and faces a similar issue of CPU-dependent init code, so let's >> tackle it next. >> >> Patch 1 adds a UniCore32 CPU guest core (TCG) section to MAINTAINERS, >> so that the target-unicore32 author gets notified of patches against his code. >> >> Patch 2, based on feedback from Guan Xuetao, changes the license of most >> target-unicore32 files from GPLv2 to GPLv2+. Anthony had contributed a >> qemu_malloc() -> g_malloc() substitution that he can't relicense at this time, >> so leave that as GPLv2 and declare my following patches explicitly as GPLv2+. > > Perhaps g_malloc() patch could be partially reverted and a new GPLv2+ > patch applied which uses g_new()? This is a bad idea IMHO. We need clear rules about changing licenses. I personally will not sign off on anything involving reverting code that cannot be relicensed. Copyright law is just too complex when it comes to derivative works. Just have some patience and let's collect the necessary SoBs. Regards, Anthony Liguori