Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries

[George Dunlap <george.dunlap@xxxxxxxxx>]

On Fri, Jun 9, 2023 at 5:07 PM Julien Grall <julien@xxxxxxx> wrote:

Hi Shawn,

On 09/06/2023 16:01, Shawn Anastasio wrote:
> On Fri Jun 9, 2023 at 5:12 AM CDT, Julien Grall wrote:
>> Strictly speaking we can refuse any code. That count for license as
>> well. Anyway, I didn't request a change here. I merely pointed out that
>> any use of GPLv2+ should be justified because on Arm most of the people
>> don't pay attention on the license and pick the one from an existing file.
>
> Hi Julien,
>
> The choice of GPLv2+ for many of the files in this patchset was indeed
> inherited from old IBM-written Xen code that the files in question were
> derived from. I did not realize it was permissible or even desirable to
> relicense those to GPLv2-only.
>
> As for the new files, GPLv2+ was chosen to remain consistent and to open
> the door for future derivations from GPLv2+ licensed code, either from
> the older Xen tree or from the Linux ppc tree, much of which is also
> licensed as GPLv2+. If it would reduce friction, these files could be
> relicensed to GPLv2-only.

(Before someone points out, I know this is already a problem on other
part of Xen. But it would be ideal if we avoid spreading this mess on
new architectures :).

Thanks for the explanations. To clarify, are you saying that all the
files will be GPLv2+ or just some?

If the latter, then my concern would be that if you need to import
GPLv2-only code, then you may need to write your code in a different
file. This may become messy to handle and some developer may end up to
be confused.

I am not a lawyer though, so you may want to check the implications here.

Shawn,

Again sorry that you've sort of bumped a hornet's nest here.

Just to clarify, the situation as I understand it is:

1. Large parts of Xen, being inherited from the Linux Kernel, are GPLv2-only; and the documentation clearly states that code is GPLv2-only unless explicitly stated otherwise.

2. Some individual files in Xen are labelled as GPLv2-or-later; but as they rely on the "only" files, Xen as a whole can only be compiled under a GPLv2 license.

3. New contributions to a file assumed to have the same license as the header of the file; i.e., the code contained in patches to GPLv2-or-later files is assumed to be granted according to a GPLv2-or-later license.

4. In the past, the legal teams of some contributors -- namely ARM -- were wary of the GPLv3; specifically the patent grant.  Since ARM doesn't make anything themselves, their patents are literally their product; they need to be very careful of not accidentally granting them to the world.  I think one thing ARM may have been afraid of at some point is one of their engineers accidentally submitting a patch to a GPLv2-or-later file which would, when taken with a GPLv3 (or GPLv4 license, once it comes out) cause them to lose too much control over their IP.

My understanding is that Julien is afraid that if the "GPLv2-or-later" files start to proliferate, that companies like ARM will start to become more wary of contributing; and so has been generally trying to encourage new files to be labelled "GPLv2-only" unless there's a good reason to do otherwise.  (Other issues like copying code from GPLv2-only are potential pitfalls as well, but probably less important.)

HOWEVER, as Andrew says, there is no official policy at this point; all the document say is that GPLv2-only is the default unless explicitly stated otherwise.

Furthermore, the concerns raised by ARM's legal team were nearly a decade ago; it's not clear to me whether they still care that much.

All that to say: If you don't mind and feel that you can do so legally, then consider switching to GPLv2-only; but if you don't want to and/or feel that you can't do so legally, feel free to leave it as-is.

Additionally, I think it would be good if the community *did* have a discussion about whether we want an official policy; so that either we can point people to the relevant doc (with explanation), or stop bothering about it. :-)

 -George