[Xen-devel] [licensing] was: [XTF PATCH 04/16] vvmx: add C wrappers of vmxon/vmread/vmptrld

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/12/16 13:43, Haozhong Zhang wrote:
> diff --git a/include/arch/x86/hvm/vmx/vmcs.h b/include/arch/x86/hvm/vmx/vmcs.h
> new file mode 100644
> index 0000000..e1a6ef8
> --- /dev/null
> +++ b/include/arch/x86/hvm/vmx/vmcs.h
> @@ -0,0 +1,179 @@
> +#ifndef XTF_X86_HVM_VMX_VMCS_H
> +#define XTF_X86_HVM_VMX_VMCS_H
> +
> +/* VMCS field encodings. */
> +#define VMCS_HIGH(x) ((x) | 1)
> +enum vmcs_field {
> +    VIRTUAL_PROCESSOR_ID            = 0x00000000,
> +    POSTED_INTR_NOTIFICATION_VECTOR = 0x00000002,
> +    EPTP_INDEX                      = 0x00000004,
> +#define GUEST_SEG_SELECTOR(sel) (GUEST_ES_SELECTOR + (sel) * 2) /* ES ... GS 
> */

Unfortunately, there is probably a BSD/GPL licensing issue here.

XTF is BSD clause 2 licensed, because a lot of the core microkernel bits
are generally useful to other microkernel projects, and I have specific
plans to contribute improvements back to the likes of Mini-OS and
HVMLoader.  I would specifically like to maintain this property.

Xen, following its Linux heritage, is strictly GPLv2 (other than the
public headers, which are specifically different).


Having XTF use the same naming as Xen is convenient for development, and
I specifically don't want to get caught up in tricks like renaming
constants; these names inherit from the architecture manual and calling
them anything else would be even worse.  If we were to go down this
route, being able to keep the header file in sync would be useful, but
dual licensing it Xen would be complicated and confusing.

BSD and GPL are compatible licenses.  One option Ian suggested would be
to have a GPL subdirectory in XTF which clearly separates GPL content
from BSD content.  The resulting tests would become GPL, but the primary
distribution method is "git clone && make", so there are no issues
there.  I think it is reasonable to take this approach for header file
content like this, describing an external ABI, but I'd certainly like to
avoid doing anything similar for other content, as it complicates
contributing microkernel content back to other projects.

CC'ing various people for opinions.

~Andrew

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