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

[Julien Grall <julien@xxxxxxx>]

Hi George,

Thanks for the summary! A couple of comments below.

On 12/06/2023 16:19, George Dunlap wrote:
> 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.
The new contribution here could be code imported from Linux that would 
be GPLv2-only in GPLv2-or-later file. It is not clear to me what would 
be the legal implication.
> 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.)
There is that and also the fact that we now need to be more careful when 
importing code from Linux. In Shawn's case this is mitigated by the fact 
that the license in Xen files should match the one in Linux.
> 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. :-)
+1. Do you think that would be a good topic for Xen Summit?

Cheers,

--
Julien Grall