[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries



Boris Ostrovsky writes ("[PATCH v4 02/21] acpi: Prevent GPL-only code from 
seeping into non-GPL binaries"):
> Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
> support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
> GPLv2. We want to prevent this code from showing up in non-GPL
> binaries which might become possible after we make ACPI builder code
> available to users other than hvmloader.
> 
> There are two pieces that we need to be careful about:
> (1) A small piece of code in dsdt.asl that implements _PIC method
> (2) A fragment of ASL generator in mk_dsdt.c that describes PCI
>     interrupt routing.
> 
> The cleanest way to deal with this seems to be taking generatedi ASL
> chunk from (2), adding it to dsdt.asl and keeping dsdt.asl GPL-only.

This approach leaves us with the whole of dsdt.asl declared to be
GPLv2.  If you are trying to relicence it as LGPLv2.1 this is not a
good idea.

Using this approach, if at some later point we get the missing ack
from Lenovo, we would have to redo the licence review for the whole of
dsdt.asl.  We would also have to ask Oracle's permission to relicense
bits of the build system etc. !

At the very least we should operate separate inbound/outbound
licensing for this one file.

But as I wrote on IRC, I think it would also be best to split out
_just the troublesome portions_ into their own files, and include them
at build time.  That way we have file-by-file source licensing.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.