Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 12:45 PM, Andreas Färber wrote: Could we please draft some policy on this? This is not a GDB issue, it's very general. Whether we like it or not, there is GPLv3-licensed code and there will probably be a GPLv4 one day. IMO having old GPLv2-only code is one thing. But there's a lot of new GPLv2-only code cooking and occasionally pouring in, especially from qemu-kvm. Device assignment is a current example I encountered. If we could make checkpatch.pl detect new GPLv2-only code, then I would hope, given the dynamic QEMU development of the last few years, that the GPLv2-only portions become so small (both in relation and absolute) that they can either be replaced or the authors' permission be obtained to change the license to GPLv2-or-later. That is close to impossible, you usually ask permission for all the authors in the history to avoid bigger problems. Paolo
Re: [Qemu-devel] GPLv3 troubles
Am 17.10.2011 12:47, schrieb Paolo Bonzini: > On 10/17/2011 12:45 PM, Andreas Färber wrote: >> Could we please draft some policy on this? This is not a GDB issue, it's >> very general. Whether we like it or not, there is GPLv3-licensed code >> and there will probably be a GPLv4 one day. >> >> IMO having old GPLv2-only code is one thing. But there's a lot of new >> GPLv2-only code cooking and occasionally pouring in, especially from >> qemu-kvm. Device assignment is a current example I encountered. >> >> If we could make checkpatch.pl detect new GPLv2-only code, then I would >> hope, given the dynamic QEMU development of the last few years, that the >> GPLv2-only portions become so small (both in relation and absolute) that >> they can either be replaced or the authors' permission be obtained to >> change the license to GPLv2-or-later. > > That is close to impossible, you usually ask permission for all the > authors in the history to avoid bigger problems. I did refer to authors in history, in case that was unclear. I was thinking of how much code we rewrote for TCG, qdev, etc. In the end it'll depend on which files are affected, and I don't have a list - hard to grep due to varying formulations and line breaks. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 01:07 PM, Andreas Färber wrote: > That is close to impossible, you usually ask permission for all the > authors in the history to avoid bigger problems. I did refer to authors in history, in case that was unclear. Authors in history (unlike authors in git blame, but you cannot trust that) almost never disappear, no matter how much you rewrite. Even dyngen->TCG kept a lot of the target-* code unchanged. Making a list of GPLv2 files would be a start, though. Paolo
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 05:45 AM, Andreas Färber wrote: Am 15.10.2011 11:02, schrieb Blue Swirl: On Mon, Oct 10, 2011 at 2:26 AM, Max Filippov wrote: diff --git a/target-xtensa/core-fsf/gdb-config.c b/target-xtensa/core-fsf/gdb-config.c new file mode 100644 index 000..6705d9c --- /dev/null +++ b/target-xtensa/core-fsf/gdb-config.c @@ -0,0 +1,152 @@ +/* Configuration for the Xtensa architecture for GDB, the GNU debugger. + + Copyright (C) 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. + + This file is part of GDB. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or Nack. GPLv3 is by design incompatible with GPLv2only (but not with GPLv2+ or IIRC BSD-like) licenses. Please only use code from GDB before v3 switch. As a side note, a quick grep shows that GPLv2only is a small minority in QEMU. In theory it should be possible to agree to switch from GPLv2only to some GPLv3 compatible license for all of QEMU code, or in a theory with alternative universes, even get FSF to relicense GDB under GPLv2only compatible way. Or, with the aid of infinite number of monkeys of Internet waiting to waste their time, rewrite incompatible but interesting parts of GDB or QEMU under The One True License of the day. Could we please draft some policy on this? This is not a GDB issue, it's very general. Whether we like it or not, there is GPLv3-licensed code and there will probably be a GPLv4 one day. I don't see anything wrong with GPLv2 only. While I don't think there's anything wrong with GPLv3, I think that "or later" is a dangerous clause to add. Regards, Anthony Liguori IMO having old GPLv2-only code is one thing. But there's a lot of new GPLv2-only code cooking and occasionally pouring in, especially from qemu-kvm. Device assignment is a current example I encountered. If we could make checkpatch.pl detect new GPLv2-only code, then I would hope, given the dynamic QEMU development of the last few years, that the GPLv2-only portions become so small (both in relation and absolute) that they can either be replaced or the authors' permission be obtained to change the license to GPLv2-or-later. Andreas
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 02:38 PM, Anthony Liguori wrote: Could we please draft some policy on this? This is not a GDB issue, it's very general. Whether we like it or not, there is GPLv3-licensed code and there will probably be a GPLv4 one day. I don't see anything wrong with GPLv2 only. While I don't think there's anything wrong with GPLv3, I think that "or later" is a dangerous clause to add. License fragmentation with respect to the de facto standard toolchain (binutils) is wrong. Until llvm includes support for as many obscure targets as we support in QEMU, some level of pragmatism might be necessary. Paolo
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 07:50 AM, Paolo Bonzini wrote: On 10/17/2011 02:38 PM, Anthony Liguori wrote: Could we please draft some policy on this? This is not a GDB issue, it's very general. Whether we like it or not, there is GPLv3-licensed code and there will probably be a GPLv4 one day. I don't see anything wrong with GPLv2 only. While I don't think there's anything wrong with GPLv3, I think that "or later" is a dangerous clause to add. License fragmentation with respect to the de facto standard toolchain (binutils) is wrong. Fragmentation with respect to the de factor standard kernel (Linux) is wrong. We currently pull in code (mostly headers, although not exclusively) from Linux too. That puts us between a rock and a hard place. Regards, Anthony Liguori Until llvm includes support for as many obscure targets as we support in QEMU, some level of pragmatism might be necessary. Paolo
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 04:17 PM, Anthony Liguori wrote: License fragmentation with respect to the de facto standard toolchain (binutils) is wrong. Fragmentation with respect to the de factor standard kernel (Linux) is wrong. We currently pull in code (mostly headers, although not exclusively) from Linux too. That puts us between a rock and a hard place. We are a userspace package, though, and kernel headers are not copyrightable. Unlike perf we do not define APIs, we're just a consumer even for KVM (by design!). And when something we pull in is not headers (no example comes to mind), the copyright holder is quite often one of two well-known employers. Paolo
Re: [Qemu-devel] GPLv3 troubles
Am 17.10.2011 16:17, schrieb Anthony Liguori: > On 10/17/2011 07:50 AM, Paolo Bonzini wrote: >> On 10/17/2011 02:38 PM, Anthony Liguori wrote: Could we please draft some policy on this? This is not a GDB issue, it's very general. Whether we like it or not, there is GPLv3-licensed code and there will probably be a GPLv4 one day. >>> >>> I don't see anything wrong with GPLv2 only. While I don't think there's >>> anything wrong with GPLv3, I think that "or later" is a dangerous clause >>> to add. >> >> License fragmentation with respect to the de facto standard toolchain >> (binutils) >> is wrong. > > Fragmentation with respect to the de factor standard kernel (Linux) is > wrong. Tell that to the GNU and FSF people. :) In my personal opinion, Open Source licenses should preserve our freedom, not make us unnecessarily duplicate code. I'm just asking to not make the situation worse than it is. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg
Re: [Qemu-devel] GPLv3 troubles
Am 17.10.2011 13:10, schrieb Paolo Bonzini: > Making a list of GPLv2 files would be a start, though. grep -r version *.c comes up with these: v2 only: aio.c block-migration.c buffered_file.c compatfd.c error.c iov.c kvm-all.c memory.c migration.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c module.c nbd.c notify.c pflib.c posix-aio-compat.c qemu-nbd.c qemu-sockets.c qemu-tool.c xen-all.c xen-mapcache.c xen-stub.c v2 or v3 only: bt-host.c bt-vhci.c Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg
Re: [Qemu-devel] GPLv3 troubles
On 17 October 2011 17:39, Andreas Färber wrote: > Am 17.10.2011 13:10, schrieb Paolo Bonzini: >> Making a list of GPLv2 files would be a start, though. > > grep -r version *.c comes up with these: Your rune needs tweaking -- it isn't looking inside any subdirectories. -- PMM
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 11:47 AM, Peter Maydell wrote: On 17 October 2011 17:39, Andreas Färber wrote: Am 17.10.2011 13:10, schrieb Paolo Bonzini: Making a list of GPLv2 files would be a start, though. grep -r version *.c comes up with these: Your rune needs tweaking -- it isn't looking inside any subdirectories. Including binutils code is just a bad idea. I know noone wants to hear that but it's unfortunately true. The FSF does copyright assignment which means it's easy for them to relicense. Since we don't do copyright assignment, it's much, much harder for us to relicense. We'd waste huge amounts of man hours trying to chase binutils license. We need to stick with the v2 version of binutils and perhaps work toward an alternative in the future. Relicensing is just not practical. Regards, Anthony Liguori -- PMM
Re: [Qemu-devel] GPLv3 troubles
Am 17.10.2011 18:47, schrieb Peter Maydell: > On 17 October 2011 17:39, Andreas Färber wrote: >> Am 17.10.2011 13:10, schrieb Paolo Bonzini: >>> Making a list of GPLv2 files would be a start, though. >> >> grep -r version *.c comes up with these: > > Your rune needs tweaking -- it isn't looking inside any > subdirectories. I know. I didn't claim it was complete. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg
Re: [Qemu-devel] GPLv3 troubles
Am 17.10.2011 18:47, schrieb Anthony Liguori: On 10/17/2011 11:30 AM, Andreas Färber wrote: Am 17.10.2011 16:17, schrieb Anthony Liguori: On 10/17/2011 07:50 AM, Paolo Bonzini wrote: On 10/17/2011 02:38 PM, Anthony Liguori wrote: Could we please draft some policy on this? This is not a GDB issue, it's very general. Whether we like it or not, there is GPLv3-licensed code and there will probably be a GPLv4 one day. I don't see anything wrong with GPLv2 only. While I don't think there's anything wrong with GPLv3, I think that "or later" is a dangerous clause to add. License fragmentation with respect to the de facto standard toolchain (binutils) is wrong. Fragmentation with respect to the de factor standard kernel (Linux) is wrong. Tell that to the GNU and FSF people. :) In my personal opinion, Open Source licenses should preserve our freedom, not make us unnecessarily duplicate code. I'm just asking to not make the situation worse than it is. It's not something that any one person can really change. It would require a very large effort. To give you an idea of the scope, I ran the following command: $ grep GPL *.c hw/*.c | grep -v 'or later' | cut -f1 -d: | sort -u | while read i; do echo $i; git log --format=" %an <%ae>" $i | sort -u; done Here's the results. All of these people would have to explicitly SoB a relicense of that specific file to include a "v2 or later" clause. In some cases, there's code from Thiemo which cannot be relicensed due to his untimely passing. So let's start. For any of my contributions, I agree to GPL v2 or later. Later generations should have the possibility to replace GPL v2 by something which matches future requirements. I'd appreciate if no new files were published with GPL v2 only. Stefan W. PS. I no longer use my old email address because Berlios will be closed on 2011-12-31, see http://www.berlios.de/.
Re: [Qemu-devel] GPLv3 troubles
Am 17.10.2011 18:47, schrieb Anthony Liguori: > It's not something that any one person can really change. It would > require a very large effort. To give you an idea of the scope, I ran > the following command: > > $ grep GPL *.c hw/*.c | grep -v 'or later' | cut -f1 -d: | sort -u | > while read i; do echo $i; git log --format=" %an <%ae>" $i | sort -u; done This fires on "or (at your option) any later version" and variations thereof, including line breaks after "or" (e.g., blockdev.c). Also for older files the SVN usernames appear as duplicates. For SVN and CVS commits we'd additionally have to check the commit message for whether the committer received the code from another author. Of the list, 90% seem regular contributors. I didn't say resolving the issue would be possible in a day. Introducing more GPLv2-only code will make it even more work though. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg
Re: [Qemu-devel] GPLv3 troubles
Am 17.10.2011 18:51, schrieb Anthony Liguori: > Including binutils code is just a bad idea. Do you see a real alternative? Would it be possible to pipe machine code from QEMU into an external disassembler? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 12:58 PM, Andreas Färber wrote: Am 17.10.2011 18:51, schrieb Anthony Liguori: Including binutils code is just a bad idea. Do you see a real alternative? Would it be possible to pipe machine code from QEMU into an external disassembler? Sure. This is only used in the monitor for interactive debugging, right? Regards, Anthony Liguori Andreas
Re: [Qemu-devel] GPLv3 troubles
On 17 October 2011 19:16, Anthony Liguori wrote: > On 10/17/2011 12:58 PM, Andreas Färber wrote: >> Do you see a real alternative? Would it be possible to pipe machine code >> from QEMU into an external disassembler? > > Sure. This is only used in the monitor for interactive debugging, right? Also in the -d logs for non-interactive debugging. -- PMM
Re: [Qemu-devel] GPLv3 troubles
Am 17.10.2011 20:16, schrieb Anthony Liguori: On 10/17/2011 12:58 PM, Andreas Färber wrote: Am 17.10.2011 18:51, schrieb Anthony Liguori: Including binutils code is just a bad idea. Do you see a real alternative? Would it be possible to pipe machine code from QEMU into an external disassembler? Sure. This is only used in the monitor for interactive debugging, right? The disassembler is also used with -d in_asm or -d out_asm to write qemu.log. I expect that a pipe to an external disassembler would slow down execution with -d significantly. Regards, Stefan Weil
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 01:20 PM, Stefan Weil wrote: Am 17.10.2011 20:16, schrieb Anthony Liguori: On 10/17/2011 12:58 PM, Andreas Färber wrote: Am 17.10.2011 18:51, schrieb Anthony Liguori: Including binutils code is just a bad idea. Do you see a real alternative? Would it be possible to pipe machine code from QEMU into an external disassembler? Sure. This is only used in the monitor for interactive debugging, right? The disassembler is also used with -d in_asm or -d out_asm to write qemu.log. I expect that a pipe to an external disassembler would slow down execution with -d significantly. How difficult would it be to add tracing to tcg-target.c such that you could get out_asm that way? At least with i386, there's just a few instruction forms so it should just be a matter of a few trace points with a table of opcode names. Likewise, we could add tracing to translate.c to achieve the same affect as in_asm. Tracing's probably a far better approach for debugging as you would be able to do some very interesting things with SystemTap and such a mechanism. Regards, Anthony Liguori Regards, Stefan Weil
Re: [Qemu-devel] GPLv3 troubles
On 17 October 2011 19:29, Anthony Liguori wrote: > Likewise, we could add tracing to translate.c to achieve the same affect as > in_asm. Having the code you're trying to debug be also doing the printing out of the disassembly seems like a recipe for confusing yourself (because you lose the independent crosscheck of what's actually going in). I'd rather have the logging dump plain hex to postprocess with objdump... -- PMM
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 01:34 PM, Peter Maydell wrote: On 17 October 2011 19:29, Anthony Liguori wrote: Likewise, we could add tracing to translate.c to achieve the same affect as in_asm. Having the code you're trying to debug be also doing the printing out of the disassembly seems like a recipe for confusing yourself (because you lose the independent crosscheck of what's actually going in). I'd rather have the logging dump plain hex to postprocess with objdump... Fair enough. Regards, Anthony Liguori -- PMM
Re: [Qemu-devel] GPLv3 troubles
On Mon, Oct 17, 2011 at 5:46 PM, Stefan Weil wrote: > Am 17.10.2011 18:47, schrieb Anthony Liguori: >> >> On 10/17/2011 11:30 AM, Andreas Färber wrote: >>> >>> Am 17.10.2011 16:17, schrieb Anthony Liguori: On 10/17/2011 07:50 AM, Paolo Bonzini wrote: > > On 10/17/2011 02:38 PM, Anthony Liguori wrote: >>> >>> Could we please draft some policy on this? This is not a GDB issue, >>> it's >>> very general. Whether we like it or not, there is GPLv3-licensed code >>> and there will probably be a GPLv4 one day. >> >> I don't see anything wrong with GPLv2 only. While I don't think >> there's >> anything wrong with GPLv3, I think that "or later" is a dangerous >> clause >> to add. > > License fragmentation with respect to the de facto standard toolchain > (binutils) > is wrong. Fragmentation with respect to the de factor standard kernel (Linux) is wrong. >>> >>> Tell that to the GNU and FSF people. :) >>> >>> In my personal opinion, Open Source licenses should preserve our >>> freedom, not make us unnecessarily duplicate code. >>> >>> I'm just asking to not make the situation worse than it is. >> >> It's not something that any one person can really change. It would >> require a very large effort. To give you an idea of the scope, I ran the >> following command: >> >> $ grep GPL *.c hw/*.c | grep -v 'or later' | cut -f1 -d: | sort -u | >> while read i; do echo $i; git log --format=" %an <%ae>" $i | sort -u; done >> >> Here's the results. All of these people would have to explicitly SoB a >> relicense of that specific file to include a "v2 or later" clause. In some >> cases, there's code from Thiemo which cannot be relicensed due to his >> untimely passing. > > > So let's start. For any of my contributions, I agree to GPL v2 or later. > Later generations should have the possibility to replace GPL v2 by > something which matches future requirements. Me too, I'd also accept any other GPL v2 or v3 compatible licenses. > I'd appreciate if no new files were published with GPL v2 only. This could be more difficult. > Stefan W. > > PS. I no longer use my old email address because Berlios > will be closed on 2011-12-31, see http://www.berlios.de/. > >
Re: [Qemu-devel] GPLv3 troubles
On Mon, Oct 17, 2011 at 6:29 PM, Anthony Liguori wrote: > On 10/17/2011 01:20 PM, Stefan Weil wrote: >> >> Am 17.10.2011 20:16, schrieb Anthony Liguori: >>> >>> On 10/17/2011 12:58 PM, Andreas Färber wrote: Am 17.10.2011 18:51, schrieb Anthony Liguori: > > Including binutils code is just a bad idea. Do you see a real alternative? Would it be possible to pipe machine code from QEMU into an external disassembler? >>> >>> Sure. This is only used in the monitor for interactive debugging, right? >> >> The disassembler is also used with -d in_asm or -d out_asm to write >> qemu.log. >> I expect that a pipe to an external disassembler would slow down execution >> with -d >> significantly. > > How difficult would it be to add tracing to tcg-target.c such that you could > get out_asm that way? > > At least with i386, there's just a few instruction forms so it should just > be a matter of a few trace points with a table of opcode names. > > Likewise, we could add tracing to translate.c to achieve the same affect as > in_asm. > > Tracing's probably a far better approach for debugging as you would be able > to do some very interesting things with SystemTap and such a mechanism. Disassembly could be moved offline, so performance would also be better and *_asm generation could be toggled dynamically. > Regards, > > Anthony Liguori > >> Regards, >> Stefan Weil >> >> > > >
Re: [Qemu-devel] GPLv3 troubles
On Mon, Oct 17, 2011 at 4:51 PM, Anthony Liguori wrote: > On 10/17/2011 11:47 AM, Peter Maydell wrote: >> >> On 17 October 2011 17:39, Andreas Färber wrote: >>> >>> Am 17.10.2011 13:10, schrieb Paolo Bonzini: Making a list of GPLv2 files would be a start, though. >>> >>> grep -r version *.c comes up with these: >> >> Your rune needs tweaking -- it isn't looking inside any >> subdirectories. > > Including binutils code is just a bad idea. I know noone wants to hear that > but it's unfortunately true. Some targets like Alpha, m68k and Sparc32 are not evolving anymore, so binutils from 2007 will be fine forever. In other cases, the manufacturers are adding new instructions (x86, ARM and Sparc64), then a modern disassembler would be more and more useful over time. > The FSF does copyright assignment which means it's easy for them to > relicense. Since we don't do copyright assignment, it's much, much harder > for us to relicense. We'd waste huge amounts of man hours trying to chase > binutils license. Even with copyright assignment, our relicensing could conflict with theirs. > We need to stick with the v2 version of binutils and perhaps work toward an > alternative in the future. Relicensing is just not practical. > > Regards, > > Anthony Liguori > >> >> -- PMM >> > > >
Re: [Qemu-devel] GPLv3 troubles
On 10/17/2011 07:46 PM, Stefan Weil wrote: > > So let's start. For any of my contributions, I agree to GPL v2 or later. > Later generations should have the possibility to replace GPL v2 by > something which matches future requirements. I expect Red Hat contributions can be relicensed to v2+ as well. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] GPLv3 troubles
Avi Kivity writes: > On 10/17/2011 07:46 PM, Stefan Weil wrote: >> >> So let's start. For any of my contributions, I agree to GPL v2 or later. >> Later generations should have the possibility to replace GPL v2 by >> something which matches future requirements. > > I expect Red Hat contributions can be relicensed to v2+ as well. Plenty of precedence for that.
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 03:01 AM, Markus Armbruster wrote: Avi Kivity writes: On 10/17/2011 07:46 PM, Stefan Weil wrote: So let's start. For any of my contributions, I agree to GPL v2 or later. Later generations should have the possibility to replace GPL v2 by something which matches future requirements. I expect Red Hat contributions can be relicensed to v2+ as well. Plenty of precedence for that. Okay, let's get serious about it. I set up the following wiki page for coordination: http://wiki.qemu.org/Relicensing Please get the appropriate approval at Red Hat, and follow the instructions on the wiki. I'm in the process of getting approval at IBM. Between RH, IBM, and Blue, there's a pretty large chunk of files that can be relicensed immediately. It's probably best to tackle this incrementally. Regards, Anthony Liguori
Re: [Qemu-devel] GPLv3 troubles
Am 18.10.2011 15:03, schrieb Anthony Liguori: > Okay, let's get serious about it. I set up the following wiki page for > coordination: > > http://wiki.qemu.org/Relicensing > > Please get the appropriate approval at Red Hat, and follow the > instructions on the wiki. I'm in the process of getting approval at > IBM. Between RH, IBM, and Blue, there's a pretty large chunk of files > that can be relicensed immediately. It's probably best to tackle this > incrementally. Sounds like a plan, thanks. The file list still has some false positives. Might edit later. In block/ I noticed sheepdog.c and rbd.c that are GPLv2, too. A few files are completely lacking a license btw. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 09:33 AM, Andreas Färber wrote: Am 18.10.2011 15:03, schrieb Anthony Liguori: Okay, let's get serious about it. I set up the following wiki page for coordination: http://wiki.qemu.org/Relicensing Please get the appropriate approval at Red Hat, and follow the instructions on the wiki. I'm in the process of getting approval at IBM. Between RH, IBM, and Blue, there's a pretty large chunk of files that can be relicensed immediately. It's probably best to tackle this incrementally. Sounds like a plan, thanks. The file list still has some false positives. Might edit later. In block/ I noticed sheepdog.c and rbd.c that are GPLv2, too. Yes, please edit the wiki. I just attempted to post a strawman to get us started. A few files are completely lacking a license btw. Yes, we'll have to list those separately, contact the original author to add a copyright statement+license, and get every contributor to SoB the change. Regards, Anthony Liguori Andreas
Re: [Qemu-devel] GPLv3 troubles
Some files are not even listed, such as hw/vexpress.c, which seem to be GPL v2 (only).. > Message du 18/10/11 16:37 > De : "Anthony Liguori" > A : "Andreas Färber" > Copie à : "Stefan Weil" , qemu-devel@nongnu.org, "Markus Armbruster" , "Blue > Swirl" , "Max Filippov" , "Avi Kivity" , "Paolo Bonzini" > Objet : Re: [Qemu-devel] GPLv3 troubles > > On 10/18/2011 09:33 AM, Andreas Färber wrote: > > Am 18.10.2011 15:03, schrieb Anthony Liguori: > >> Okay, let's get serious about it. I set up the following wiki page for > >> coordination: > >> > >> http://wiki.qemu.org/Relicensing > >> > >> Please get the appropriate approval at Red Hat, and follow the > >> instructions on the wiki. I'm in the process of getting approval at > >> IBM. Between RH, IBM, and Blue, there's a pretty large chunk of files > >> that can be relicensed immediately. It's probably best to tackle this > >> incrementally. > > > > Sounds like a plan, thanks. > > > > The file list still has some false positives. Might edit later. > > In block/ I noticed sheepdog.c and rbd.c that are GPLv2, too. > > Yes, please edit the wiki. I just attempted to post a strawman to get us > started. > > > A few files are completely lacking a license btw. > > Yes, we'll have to list those separately, contact the original author to add a > copyright statement+license, and get every contributor to SoB the change. > > Regards, > > Anthony Liguori > > > Andreas > > > > > Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
Re: [Qemu-devel] GPLv3 troubles
On 18 October 2011 15:03, Anthony Liguori wrote: > Okay, let's get serious about it. I set up the following wiki page for > coordination: > > http://wiki.qemu.org/Relicensing The bottom section with "some SVN authors" has a bunch of files by me that are "GPLv2". Most of them were probably meant to be GPLv2+ but the header had been copy&pasted. Where I'm the copyright owner I agree for them to be put under any later GPL version. Other SVN contributors need to be looked up in the svn commit messages. (that section's heading is missing a "not"?) Cheers
Re: [Qemu-devel] GPLv3 troubles
On 18 October 2011 14:03, Anthony Liguori wrote: > Okay, let's get serious about it. I set up the following wiki page for > coordination: > > http://wiki.qemu.org/Relicensing This says: use the following git command to get a list of authors: git log --format:"%an <%ae>" -- file.c which (apart from having a typo) only lists the people who were the git commit authors. This isn't the same as everybody who might have copyright on the change. There are certainly commits in the omap support which have gone through several people (listed in the Signed-off-by: lines) who all have copyright-authorship even if they're not git-commit-authors. -- PMM
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 05:19 PM, Peter Maydell wrote: On 18 October 2011 14:03, Anthony Liguori wrote: Okay, let's get serious about it. I set up the following wiki page for coordination: http://wiki.qemu.org/Relicensing This says: use the following git command to get a list of authors: git log --format:"%an<%ae>" -- file.c which (apart from having a typo) only lists the people who were the git commit authors. This isn't the same as everybody who might have copyright on the change. There are certainly commits in the omap support which have gone through several people (listed in the Signed-off-by: lines) who all have copyright-authorship even if they're not git-commit-authors. Yes, also just to get it written somewhere: the list of copyright holders is merely indicative. Anyway, unfortunately this is, I think, a lost battle. For linux-user there's too much Linux kernel code. It would still be nice to not introduce more GPLv2-only code, but don't hold your breath... Paolo
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 10:19 AM, Peter Maydell wrote: On 18 October 2011 14:03, Anthony Liguori wrote: Okay, let's get serious about it. I set up the following wiki page for coordination: http://wiki.qemu.org/Relicensing This says: use the following git command to get a list of authors: git log --format:"%an<%ae>" -- file.c which (apart from having a typo) only lists the people who were the git commit authors. This isn't the same as everybody who might have copyright on the change. There are certainly commits in the omap support which have gone through several people (listed in the Signed-off-by: lines) who all have copyright-authorship even if they're not git-commit-authors. Sure, but the Author shouldn't Signed-off-by on a copyright change if there are other copyright owners that also need to approve. SoB is stating that you are entitled to submit the patch which in case of copyright change means you own the copyright or got permission from the copyright owner. That's why we should have all authors include a SoB. It provides the paper trail of anyone who may have touched the file. Regards, Anthony Liguori -- PMM
Re: [Qemu-devel] GPLv3 troubles
On 18 October 2011 16:56, Anthony Liguori wrote: > On 10/18/2011 10:19 AM, Peter Maydell wrote: >> which (apart from having a typo) only lists the people who were >> the git commit authors. This isn't the same as everybody who might >> have copyright on the change. There are certainly commits in the >> omap support which have gone through several people (listed in >> the Signed-off-by: lines) who all have copyright-authorship even >> if they're not git-commit-authors. > > Sure, but the Author shouldn't Signed-off-by on a copyright change if there > are other copyright owners that also need to approve. SoB is stating that > you are entitled to submit the patch which in case of copyright change means > you own the copyright or got permission from the copyright owner. Yes, you need "permission from the copyright owner", but that only amounts to "permission from the copyright owner to submit under this license", not "permission to relicense the code as you feel like later". (cf clause (b) of the "Developer's Certificate of Origin".) That document also says later that you can modify the change as you pass it up providing you add your signed-off-by too, so the whole set of people who signed-off-by some patch are potentially copyright-authors, which was my original point. -- PMM
Re: [Qemu-devel] GPLv3 troubles
On 18 October 2011 17:01, Anthony Liguori wrote: > Ah, linux-user... hadn't thought about that. Perhaps it's a lost cause. > > Unless we split linux-user off into a separate repository. The only real > code sharing is TCG. ...and the binutils disassembly code, which is the reason we wanted to move to GPLv3 in the first place, right? -- PMM
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 10:31 AM, Paolo Bonzini wrote: On 10/18/2011 05:19 PM, Peter Maydell wrote: On 18 October 2011 14:03, Anthony Liguori wrote: Okay, let's get serious about it. I set up the following wiki page for coordination: http://wiki.qemu.org/Relicensing This says: use the following git command to get a list of authors: git log --format:"%an<%ae>" -- file.c which (apart from having a typo) only lists the people who were the git commit authors. This isn't the same as everybody who might have copyright on the change. There are certainly commits in the omap support which have gone through several people (listed in the Signed-off-by: lines) who all have copyright-authorship even if they're not git-commit-authors. Yes, also just to get it written somewhere: the list of copyright holders is merely indicative. Anyway, unfortunately this is, I think, a lost battle. For linux-user there's too much Linux kernel code. Ah, linux-user... hadn't thought about that. Perhaps it's a lost cause. Unless we split linux-user off into a separate repository. The only real code sharing is TCG. I can imagine a world where TCG lived in a separate repo along with qemu-system and linux-user. Both repos could pull in TCG as a submodule. Regards, Anthony Liguori It would still be nice to not introduce more GPLv2-only code, but don't hold your breath... Paolo
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 06:15 PM, Peter Maydell wrote: > On 18 October 2011 17:01, Anthony Liguori wrote: > > Ah, linux-user... hadn't thought about that. Perhaps it's a lost cause. > > > > Unless we split linux-user off into a separate repository. The only real > > code sharing is TCG. > > ...and the binutils disassembly code, which is the reason we wanted > to move to GPLv3 in the first place, right? > That code is packaged in libopcodes.so, so if that is LGPLv3 we can link it in. However, it may not be available on all systems, and I don't think cross-disassemblers are installed by default. Perhaps we can make it an optional component loaded with dlopen()? Most users will never use the integrated disassembler. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 11:15 AM, Peter Maydell wrote: On 18 October 2011 17:01, Anthony Liguori wrote: Ah, linux-user... hadn't thought about that. Perhaps it's a lost cause. Unless we split linux-user off into a separate repository. The only real code sharing is TCG. ...and the binutils disassembly code, which is the reason we wanted to move to GPLv3 in the first place, right? TCG can have a debug mode that makes it GPLv3 (using the binutils code). You wouldn't be able to consume this debug mode with linux-user. Probably safest thing is to put disas only in qemu-system. linux-user would have to log hex. Regards, Anthony Liguori -- PMM
Re: [Qemu-devel] GPLv3 troubles
On 18 October 2011 17:30, Anthony Liguori wrote: > > TCG can have a debug mode that makes it GPLv3 (using the binutils code). > You wouldn't be able to consume this debug mode with linux-user. > > Probably safest thing is to put disas only in qemu-system. linux-user would > have to log hex. Yuck. Please don't make linux-user a second class citizen like that. -- PMM
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 06:01 PM, Anthony Liguori wrote: Unless we split linux-user off into a separate repository. The only real code sharing is TCG. I can imagine a world where TCG lived in a separate repo along with qemu-system and linux-user. Both repos could pull in TCG as a submodule. Nah, the simplest thing to do is to really implement a binary format to store (or pipe) in_asm and out_asm traces. Then the trace dumper could use all the binutils code it wants to, and would be the only thing requiring a v3 license. in_asm/out_asm traces are so huge that this thing does have some actual benefit if somebody wants to write it. That said, it is still nice if we can get people to agree on relicensing what they own, if only to help sharing code with other GPL programs. With the obvious exception of MIPS and linux-user, it does not seem impossible, though indeed hard, and it is also a good occasion to clean up files without a license. Paolo
Re: [Qemu-devel] GPLv3 troubles
On Tue, Oct 18, 2011 at 4:37 PM, Paolo Bonzini wrote: > On 10/18/2011 06:01 PM, Anthony Liguori wrote: >> >> Unless we split linux-user off into a separate repository. The only >> real code sharing is TCG. I can imagine a world where TCG lived in a >> separate repo along with qemu-system and linux-user. Both repos could >> pull in TCG as a submodule. > > Nah, the simplest thing to do is to really implement a binary format to > store (or pipe) in_asm and out_asm traces. Then the trace dumper could use > all the binutils code it wants to, and would be the only thing requiring a > v3 license. in_asm/out_asm traces are so huge that this thing does have > some actual benefit if somebody wants to write it. This would work for linux-user since the there is no monitor, so linux-user could be left as GPLv2. For the system emulators, it would be a small improvement for in_asm or out_asm logs, but the builtin monitor disassembly command would have to fork and exec this external tool. But if that's the only unsolved case, perhaps that feature could be made conditional to libopcodes.so instead. > That said, it is still nice if we can get people to agree on relicensing > what they own, if only to help sharing code with other GPL programs. With > the obvious exception of MIPS and linux-user, it does not seem impossible, > though indeed hard, and it is also a good occasion to clean up files without > a license. Yes, I'd still try to get other files relicensed.
Re: [Qemu-devel] GPLv3 troubles
Am 25.10.2011 16:34, schrieb Dor Laor: On 10/18/2011 03:03 PM, Anthony Liguori wrote: Okay, let's get serious about it. I set up the following wiki page for coordination: http://wiki.qemu.org/Relicensing Please get the appropriate approval at Red Hat, and follow the ACK for *@redhat.com instructions on the wiki. I'm in the process of getting approval at IBM. Between RH, IBM, and Blue, there's a pretty large chunk of files that can be relicensed immediately. It's probably best to tackle this incrementally. Regards, Anthony Liguori Hi Anthony, maybe I missed a mail, but did you get approval for GPLv2+ at IBM? http://wiki.qemu.org/Relicensing#Commitments_to_Relicense still does not list IBM. Regards, Stefan W.
Re: [Qemu-devel] GPLv3 troubles
Am Montag 17 Oktober 2011, 19:46:11 schrieb Stefan Weil: > So let's start. For any of my contributions, I agree to GPL v2 or later. > Later generations should have the possibility to replace GPL v2 by > something which matches future requirements. I agree to GPL v2 or later. -- Michael
Re: [Qemu-devel] GPLv3 troubles
On 10/18/2011 03:03 PM, Anthony Liguori wrote: On 10/18/2011 03:01 AM, Markus Armbruster wrote: Avi Kivity writes: On 10/17/2011 07:46 PM, Stefan Weil wrote: So let's start. For any of my contributions, I agree to GPL v2 or later. Later generations should have the possibility to replace GPL v2 by something which matches future requirements. I expect Red Hat contributions can be relicensed to v2+ as well. Plenty of precedence for that. Okay, let's get serious about it. I set up the following wiki page for coordination: http://wiki.qemu.org/Relicensing Please get the appropriate approval at Red Hat, and follow the ACK for *@redhat.com instructions on the wiki. I'm in the process of getting approval at IBM. Between RH, IBM, and Blue, there's a pretty large chunk of files that can be relicensed immediately. It's probably best to tackle this incrementally. Regards, Anthony Liguori
Re: [Qemu-devel] GPLv3 troubles (was: [PATCH 6/7] target-xtensa: add fsf core)
Am 15.10.2011 11:02, schrieb Blue Swirl: > On Mon, Oct 10, 2011 at 2:26 AM, Max Filippov wrote: >> diff --git a/target-xtensa/core-fsf/gdb-config.c >> b/target-xtensa/core-fsf/gdb-config.c >> new file mode 100644 >> index 000..6705d9c >> --- /dev/null >> +++ b/target-xtensa/core-fsf/gdb-config.c >> @@ -0,0 +1,152 @@ >> +/* Configuration for the Xtensa architecture for GDB, the GNU debugger. >> + >> + Copyright (C) 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. >> + >> + This file is part of GDB. >> + >> + This program is free software; you can redistribute it and/or modify >> + it under the terms of the GNU General Public License as published by >> + the Free Software Foundation; either version 3 of the License, or > > Nack. GPLv3 is by design incompatible with GPLv2only (but not with > GPLv2+ or IIRC BSD-like) licenses. Please only use code from GDB > before v3 switch. > > As a side note, a quick grep shows that GPLv2only is a small minority > in QEMU. In theory it should be possible to agree to switch from > GPLv2only to some GPLv3 compatible license for all of QEMU code, or in > a theory with alternative universes, even get FSF to relicense GDB > under GPLv2only compatible way. Or, with the aid of infinite number of > monkeys of Internet waiting to waste their time, rewrite incompatible > but interesting parts of GDB or QEMU under The One True License of the > day. Could we please draft some policy on this? This is not a GDB issue, it's very general. Whether we like it or not, there is GPLv3-licensed code and there will probably be a GPLv4 one day. IMO having old GPLv2-only code is one thing. But there's a lot of new GPLv2-only code cooking and occasionally pouring in, especially from qemu-kvm. Device assignment is a current example I encountered. If we could make checkpatch.pl detect new GPLv2-only code, then I would hope, given the dynamic QEMU development of the last few years, that the GPLv2-only portions become so small (both in relation and absolute) that they can either be replaced or the authors' permission be obtained to change the license to GPLv2-or-later. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746, AG Nürnberg
