ACPI builder re-licensing

ACPI builder re-licensing

[Boris Ostrovsky]

Starting a new thread on ACPI code re-licensing, continuing from
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01245.html

Summary
======

While working on refactoring ACPI builder code from
tools/firmware/hvmloader/acpi/ and making it available to both hvmloader
and libxl/libxc (and possibly, in the future, to the hypervisor) we
realized that these two components use different licenses: the former is
licensed under GPLv2 and the latter uses LGPL.

The proposal is to re-license the builder to LGPL which should allow us
to have it linked against both GPLv2 and LGPL code (and possibly other
licenses?)


Details
=====

Currently we have:
ostr@workbase> ls -l tools/firmware/hvmloader/acpi/
total 116
-rw-rw-r-- 1 ostr ostr 11388 Sep  1  2015 acpi2_0.h
-rw-rw-r-- 1 ostr ostr 21010 Jun 22 10:51 build.c
-rw-rw-r-- 1 ostr ostr 16856 Jun 22 10:51 dsdt.asl
-rw-rw-r-- 1 ostr ostr  2023 Sep  1  2015 Makefile
-rw-rw-r-- 1 ostr ostr 15452 Jun 22 10:51 mk_dsdt.c
-rw-rw-r-- 1 ostr ostr   618 Feb  3  2015 README
-rw-rw-r-- 1 ostr ostr 12694 Sep  1  2015 ssdt_pm.asl
-rw-rw-r-- 1 ostr ostr   999 Sep  1  2015 ssdt_s3.asl
-rw-rw-r-- 1 ostr ostr   999 Sep  1  2015 ssdt_s4.asl
-rw-rw-r-- 1 ostr ostr   978 Sep  1  2015 ssdt_tpm.asl
-rw-rw-r-- 1 ostr ostr  5474 Sep  1  2015 static_tables.c

All these files are under GPLv2

The idea is to make code that lives in tools/firmware/hvmloader/acpi
available to
* hmloader (GPLv2)
* libxl/libxc (LGPL)
* possibly the hypervisor (although that's not on the table at the moment)

No static or dynamic library will be created. Just like in the case of
libelf, each component will link object files from tools/libacpi
directory. Specifically, they will link:
* build.o static_tables.o
* dsdt_*.o, which is compiled from dsdt_*.c, which is generated from
dsdt.asl by iasl and mk_dsdt.

The C files (corresponding to the objects above) will include acpi2_0.h,
ssdt_*.h (generated by iasl from ssdt_*.asl).

In addition, chunks of acpi2_0.h and build.c (structure definitions)
will be excised into newly created libacpi.h and that file will be
included by consumers (i.e. libxl/libxc and hvmloader). libacpi.h will
also include acpi2_0.h. dsdt.asl will be broken into two files, both of
which will be used by iasl.

It's probably worth noting that the builder does not make any further
calls with the exception of:
* standard C utilities such as printf and strcmp
* callbacks into the caller (libxl/libxc or hvmloader) via function
pointers provided by the caller.


Who needs to be notified
===============

Assuming that S-o-b and From are a good indication of who needs to be
notified of the change (and needs to ack it):

ostr@workbase> git log tools/firmware/hvmloader/acpi | egrep
"Signed|From" | sed -e 's/.*@/ /g' | sort | uniq -c
      1  citrix.com
     73  citrix.com>
      1  debian.org>
      5  eu.citrix.com>
     18  intel.com>
      2  jp.fujitsu.com>
      1  net-space.pl>
      1  novell.com>
      1  oracle.com>
      1  redhat.com>
      1  sun.com>
      8  suse.com>
      1  us.ibm.com>
      6  verge.net.au>
      4  xen.org>
     25  xensource.com>


which indicated major contributions (and therefore a required ack) from
Citrix/Xensource, Suse/Novell, Oracle/Sun, Intel.

For the rest ("trivial" or "simple" is, of course, a matter of opinion):

* debian.com is a single trivial patch to a Makefile
   
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=83f34fdcdd26c3dcc793c571e7b75c705bd92e7a
 
* Fujitsu provided two patches, one trivial the other not completely trivial
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e451db15ef6198f5d21b84618c833ac276087d70
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ab438874b6a8ae955b337c36e7b3204e29b8d407

* net-space.pl is Daniel Kiper's (now, but not at the patch's time, at
Oracle) ISP. The patch is
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=37fddaa5fe1a7e369827e4b9e25cdae5df9b3d7d

* redhat is one trivial patch by Paolo Bonzini that has been reversed later:
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e4fd0475a08fda414da27c4e57b568f147cfc07e

* IBM one patch from Stefan Berger
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9fd9787b0e7995ac5f2da504b92723c24d6a3737

  (plus what seems to inclusion of his work in
   
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=883236e49a86a0174c6df61cac995ebf16d72b35)

  Also, ssdt_tpm.asl is explicitly copyrighted by IBM

* A bunch of patches from from Simon Horman at Verge

* xen.org are S-o-b by Keir, all from 2011.



-boris


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

Re: ACPI builder re-licensing

[Ian Jackson]

Boris Ostrovsky writes ("[Xen-devel] ACPI builder re-licensing"):
> Who needs to be notified
> ===============

NB that what is required is not notification, but permission.

> which indicated major contributions (and therefore a required ack) from
> Citrix/Xensource, Suse/Novell, Oracle/Sun, Intel.
> 
> For the rest ("trivial" or "simple" is, of course, a matter of opinion):
> 
> * debian.com is a single trivial patch to a Makefile
>    
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=83f34fdcdd26c3dcc793c571e7b75c705bd92e7a

You mean debian.org.  Of course debian.org is not the author here and
would not be the copyrightholder; Bastian Blank would be.  But I agree
that this patch is trivial.

> * Fujitsu provided two patches, one trivial the other not completely trivial
>  
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e451db15ef6198f5d21b84618c833ac276087d70
>  
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ab438874b6a8ae955b337c36e7b3204e29b8d407

This second patch is nontrivial and therefore we need approval from
Fujitsu.

> * net-space.pl is Daniel Kiper's (now, but not at the patch's time, at
> Oracle) ISP. The patch is
>  
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=37fddaa5fe1a7e369827e4b9e25cdae5df9b3d7d

This patch is not trivial in copyright terms, so we need Daniel
Kiper's approval.

> * redhat is one trivial patch by Paolo Bonzini that has been reversed later:
>  
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e4fd0475a08fda414da27c4e57b568f147cfc07e

If the patch has been reverted then we are not proposing to relicence.
We need to be careful not to re-apply it without getting a new signoff
from Red Hat.

> * IBM one patch from Stefan Berger
>  
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9fd9787b0e7995ac5f2da504b92723c24d6a3737
> 
>   (plus what seems to inclusion of his work in
>    
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=883236e49a86a0174c6df61cac995ebf16d72b35)

The latter is rather sloppy practice :-/.

>   Also, ssdt_tpm.asl is explicitly copyrighted by IBM

So we need approval from IBM.

> * A bunch of patches from from Simon Horman at Verge

So we need approval from Verge.

> * xen.org are S-o-b by Keir, all from 2011.

I think those were work-for-hire by Keir with his XenSource/Citrix hat
on and are now owned by Citrix.  We should reconfirm with Keir.

Ian.

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

Re: ACPI builder re-licensing

[Lars Kurth]

Boris,

I can't remember how we managed this process the last time round (see for https://patchwork.kernel.org/patch/9172431/), but in that case we already had a patch. As far as I can see, we don't have the complete patch yet.

Thus, the question I would have to you is whether you want to prepare the complete patch first or get the approvals of all stake-holders first?

I also think we should establish two groups of people regardless of approach
A) A list of individuals with e-mails we need to get approval from 
B) A list of company reps which can provide approval on behalf of a companies contribution

What we did in https://patchwork.kernel.org/patch/9172431/ was to get ACKs from people in group A, and e-mail confirmation from people in group B.

Regardless of the approach, we also ought to write an explanation that is easily consumable for people in group B which may not be very involved in Xen.
- A short introduction outlining what see are trying to do and why (maybe refer back to this thread)
- Explain why we sent the explanation to person X (that would probably need to contain some boilerplate what (c) they and/or their orgs hold and why we contacted them)
- End with a question which they clearly can answer (and which we can copy as evidence into the changelog)

Would you be able to draft something? We can then distribute some of the activities based on existing personal relationships.

> On 12 Jul 2016, at 18:09, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> 
> Boris Ostrovsky writes ("[Xen-devel] ACPI builder re-licensing"):

>> Who needs to be notified
>> ===============
> 
> NB that what is required is not notification, but permission.
> 
>> which indicated major contributions (and therefore a required ack) from
>> Citrix/Xensource, Suse/Novell, Oracle/Sun, Intel.

This is group B stuff
- Citrix/Xensource can be James Bulpin or me
- Suse/Novell can be arranged by Jan or Juergen 
- Intel ought to be Susie Li 
- Oracle/Sun can be arranged by Konrad or you

Could you double check whether any of these maybe should go into group A? 

>> 
>> For the rest ("trivial" or "simple" is, of course, a matter of opinion):
>> 
>> * debian.com is a single trivial patch to a Makefile
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=83f34fdcdd26c3dcc793c571e7b75c705bd92e7a
> 
> You mean debian.org.  Of course debian.org is not the author here and
> would not be the copyrightholder; Bastian Blank would be.  But I agree
> that this patch is trivial.

ACK

> 
>> * Fujitsu provided two patches, one trivial the other not completely trivial
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e451db15ef6198f5d21b84618c833ac276087d70
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ab438874b6a8ae955b337c36e7b3204e29b8d407
> 
> This second patch is nontrivial and therefore we need approval from
> Fujitsu.

The second patch was signed off by Kouya Shimura <kouya@jp.fujitsu.com>
I did see him post something on LKLM in Feb 2016 using the above e-mail address. 
So probably this could go into group A. If not, Kouya probably would know who can make the call on behalf of Fujitsu. 

> 
>> * net-space.pl is Daniel Kiper's (now, but not at the patch's time, at
>> Oracle) ISP. The patch is
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=37fddaa5fe1a7e369827e4b9e25cdae5df9b3d7d
> 
> This patch is not trivial in copyright terms, so we need Daniel
> Kiper's approval.

We have Daniel's e-mail address, so this should go into group A. Not sure whether Daniel uses his old address still, which would be preferable.

>> * redhat is one trivial patch by Paolo Bonzini that has been reversed later:
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e4fd0475a08fda414da27c4e57b568f147cfc07e
> 
> If the patch has been reverted then we are not proposing to relicence.
> We need to be careful not to re-apply it without getting a new signoff
> from Red Hat.

We ought to check that. If not true, Paolo Bonzini should go into group A.

>> * IBM one patch from Stefan Berger
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9fd9787b0e7995ac5f2da504b92723c24d6a3737
>> 
>>  (plus what seems to inclusion of his work in
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=883236e49a86a0174c6df61cac995ebf16d72b35)
> 
> The latter is rather sloppy practice :-/.
> 
>>  Also, ssdt_tpm.asl is explicitly copyrighted by IBM
> 
> So we need approval from IBM.

Stefan still seems to work for IBM, with stefanb@us.ibm.com as e0-mail address. So Group A.

>> * A bunch of patches from from Simon Horman at Verge
> 
> So we need approval from Verge.

Group A: horms@verge.net.au

>> * xen.org are S-o-b by Keir, all from 2011.
> 
> I think those were work-for-hire by Keir with his XenSource/Citrix hat
> on and are now owned by Citrix.  We should reconfirm with Keir.

Group A. Should be straightforward.

Best Regards
Lars


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

Re: ACPI builder re-licensing

[Boris Ostrovsky]

On 07/13/2016 09:21 AM, Lars Kurth wrote:
> Boris,
>
> I can't remember how we managed this process the last time round (see for https://patchwork.kernel.org/patch/9172431/), but in that case we already had a patch. As far as I can see, we don't have the complete patch yet.
>
> Thus, the question I would have to you is whether you want to prepare the complete patch first or get the approvals of all stake-holders first?

I certainly can (and should) prepare and post the patch but I thought we
should first come up with (A) list at the least. OTOH, we can at least
review the patch first here on xen-devel without bothering people from
that list with revisions. So yes, I will.

>
> I also think we should establish two groups of people regardless of approach
> A) A list of individuals with e-mails we need to get approval from 
> B) A list of company reps which can provide approval on behalf of a companies contribution
>
> What we did in https://patchwork.kernel.org/patch/9172431/ was to get ACKs from people in group A, and e-mail confirmation from people in group B.
>
> Regardless of the approach, we also ought to write an explanation that is easily consumable for people in group B which may not be very involved in Xen.
> - A short introduction outlining what see are trying to do and why (maybe refer back to this thread)
> - Explain why we sent the explanation to person X (that would probably need to contain some boilerplate what (c) they and/or their orgs hold and why we contacted them)
> - End with a question which they clearly can answer (and which we can copy as evidence into the changelog)
>
> Would you be able to draft something? We can then distribute some of the activities based on existing personal relationships.


Will do and post as the preamble to the patch for review.


>
>> On 12 Jul 2016, at 18:09, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
>>
>> Boris Ostrovsky writes ("[Xen-devel] ACPI builder re-licensing"):
>>> Who needs to be notified
>>> ===============
>> NB that what is required is not notification, but permission.
>>
>>> which indicated major contributions (and therefore a required ack) from
>>> Citrix/Xensource, Suse/Novell, Oracle/Sun, Intel.
> This is group B stuff
> - Citrix/Xensource can be James Bulpin or me
> - Suse/Novell can be arranged by Jan or Juergen 
> - Intel ought to be Susie Li 
> - Oracle/Sun can be arranged by Konrad or you

Konrad is already doing this for Oracle.

>
> Could you double check whether any of these maybe should go into group A? 

Changes from those companies came from multiple submitters so it seems
that getting a single ACK from a rep would be easier?


...

>>> * net-space.pl is Daniel Kiper's (now, but not at the patch's time, at
>>> Oracle) ISP. The patch is
>>>
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=37fddaa5fe1a7e369827e4b9e25cdae5df9b3d7d
>> This patch is not trivial in copyright terms, so we need Daniel
>> Kiper's approval.
> We have Daniel's e-mail address, so this should go into group A. Not sure whether Daniel uses his old address still, which would be preferable.

I spoke with Daniel and he is fine ACKing this.

>
>>> * redhat is one trivial patch by Paolo Bonzini that has been reversed later:
>>>
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e4fd0475a08fda414da27c4e57b568f147cfc07e
>> If the patch has been reverted then we are not proposing to relicence.
>> We need to be careful not to re-apply it without getting a new signoff
>> from Red Hat.
> We ought to check that. If not true, Paolo Bonzini should go into group A.

In principle we could in the future decide to do exactly what Paolo's
patch originally did (which was to remove the 'if' condition). There is
no way to do it any differently than how Paolo's patch did it.

-boris



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

Re: ACPI builder re-licensing

[Lars Kurth]

On 13/07/2016 15:22, "Boris Ostrovsky" <boris.ostrovsky@oracle.com> wrote:

>On 07/13/2016 09:21 AM, Lars Kurth wrote:
>> Boris,
>>
>> I can't remember how we managed this process the last time round (see
>>for https://patchwork.kernel.org/patch/9172431/), but in that case we
>>already had a patch. As far as I can see, we don't have the complete
>>patch yet.
>>
>> Thus, the question I would have to you is whether you want to prepare
>>the complete patch first or get the approvals of all stake-holders first?
>
>I certainly can (and should) prepare and post the patch but I thought we
>should first come up with (A) list at the least.

It's basically in this thread already and is
- Kouya Shimura <kouya@jp.fujitsu.com>
- Daniel's old private e-mail address, if still active.
- Stefan Berger <stefanb@us.ibm.com>
- Simon Horman <horms@verge.net.au>
- Keir <keir@xen.org>
 
Possibly Paolo

>OTOH, we can at least
>review the patch first here on xen-devel without bothering people from
>that list with revisions. So yes, I will.
...
>
>Will do and post as the preamble to the patch for review.

Thanks

Regards
Lars

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

Re: ACPI builder re-licensing

[Boris Ostrovsky]

On 07/13/2016 10:30 AM, Lars Kurth wrote:
>
> On 13/07/2016 15:22, "Boris Ostrovsky" <boris.ostrovsky@oracle.com> wrote:
>
>> On 07/13/2016 09:21 AM, Lars Kurth wrote:
>>> Boris,
>>>
>>> I can't remember how we managed this process the last time round (see
>>> for https://patchwork.kernel.org/patch/9172431/), but in that case we
>>> already had a patch. As far as I can see, we don't have the complete
>>> patch yet.
>>>
>>> Thus, the question I would have to you is whether you want to prepare
>>> the complete patch first or get the approvals of all stake-holders first?
>> I certainly can (and should) prepare and post the patch but I thought we
>> should first come up with (A) list at the least.
> It's basically in this thread already and is
> - Kouya Shimura <kouya@jp.fujitsu.com>
> - Daniel's old private e-mail address, if still active.
> - Stefan Berger <stefanb@us.ibm.com>
> - Simon Horman <horms@verge.net.au>
> - Keir <keir@xen.org>
>  
> Possibly Paolo
>
>> OTOH, we can at least
>> review the patch first here on xen-devel without bothering people from
>> that list with revisions. So yes, I will.


Which LGPL version are we using?

Most libxc and all libxl files say it's strictly 2.1: "... version 2.1
only. with the special exception on linking described in file LICENSE"
(with LICENSE file not provided, which I assume meaning that it's
vanilla 2.1).

However, some files in libxc are less restrictive in this regard:
"either version 2.1 of the License, or (at your option) any later version.".

(I will be out tomorrow and won't respond until Friday)

-boris




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

Re: ACPI builder re-licensing

[Lars Kurth]

> On 13 Jul 2016, at 19:19, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> 
> On 07/13/2016 10:30 AM, Lars Kurth wrote:
>> 
>> 
>>> OTOH, we can at least
>>> review the patch first here on xen-devel without bothering people from
>>> that list with revisions. So yes, I will.
> 
> 
> Which LGPL version are we using?
> 
> Most libxc and all libxl files say it's strictly 2.1: "... version 2.1
> only. with the special exception on linking described in file LICENSE"
> (with LICENSE file not provided, which I assume meaning that it's
> vanilla 2.1).

I think we should pick a specific version, because the COPYING file in xen.git states - although not very clearly - to pick a specific license with a specific version. Given that libxc/libxl is intended to be LGPL 2.1, we should go for 2.1.

It may also make sense to start using SPDX License Identifiers (see http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags#Tag_Format)

alongside the (c) notice for files which do not use GPLv2, as it reduces the scope for mistakes and increases the chances of mistakes being picked up by reviewers.

In this case
SPDX-License-Identifier: LGPL-2.1

> However, some files in libxc are less restrictive in this regard:
> "either version 2.1 of the License, or (at your option) any later version.".

We have a similar issue with some GPLv2 files in Xen, where contributors appear to have forgotten to delete the "or (at your option) any later version", in some files by mistake. 

In xen./git COPYING we state 
   5 Most files in this repository are licensed under the terms of the GNU
   6 General Public License (GPL), a copy of which is attached at the end
   7 of this notice. Note that the only valid version of the GPL as far as
   8 the files in this repository are concerned is _this_ particular
   9 version of the license (i.e., *only* v2, not v2.2 or v3.x or
  10 whatever), unless explicitly otherwise stated.

GPLv2 files where "or (at your option) any later version" is in the file's (c) header contradict the COPYING file. And legally, it is not clear whether the COPYING file or the (c) header has precedence and whether "either version 2 of the License, or (at your option) any later version" is explicit or not. 

For this reason, I have an action to make a proposal to clean up these inconsistencies in the next few weeks. Forgetting to delete "or (at your option) any later version" is a mistake easily made. In particular when the contributor of a new file copies the boilerplate license text from gnu.org and is not aware that "or (at your option) any later version" has to be deleted. 

This has been causing some issues and confusion with new contributors, who have internal policies that prevent them from contributing to projects that contain GPLv3 code.

We don't want to add more such cases that later need to be cleaned up.

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

Re: ACPI builder re-licensing

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] ACPI builder re-licensing"):
> I think we should pick a specific version, because the COPYING file in xen.git states - although not very clearly - to pick a specific license with a specific version. Given that libxc/libxl is intended to be LGPL 2.1, we should go for 2.1.

My personal view is that LGPLv2.1+ is better because it's more
flexible - less of a hostage to the future.  But the existing
libraries are LGPLv2.1 and without a community decision to start
moving to LGPLv2.1+ I think it's wrong to have files with that licence
header.

> It may also make sense to start using SPDX License Identifiers (see http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags#Tag_Format)
> 
> alongside the (c) notice for files which do not use GPLv2, as it reduces the scope for mistakes and increases the chances of mistakes being picked up by reviewers.

I don't agree with this.  This ends up stating the same information in
another way which gives more scope for inconsistency and errors.  Eg,
you could write a GPLv2+ copyright notice but a the LGPL-2.1-only SPDX
ID.  And then what would it mean ?

But we do not need to settle that question now.

> We have a similar issue with some GPLv2 files in Xen, where contributors appear to have forgotten to delete the "or (at your option) any later version", in some files by mistake. 

Likewise we should avoid opening this can of worms as part of what
Boris is trying to do here.

So in summary I think Boris should ask people whether they are happy
to relicence from GPLv2-only to LGPLv2.1-only.

Ian.

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

Re: ACPI builder re-licensing

[Lars Kurth]

On 14/07/2016 17:48, "Ian Jackson" <ian.jackson@eu.citrix.com> wrote:

>Lars Kurth writes ("Re: [Xen-devel] ACPI builder re-licensing"):
>> I think we should pick a specific version, because the COPYING file in
>>xen.git states - although not very clearly - to pick a specific license
>>with a specific version. Given that libxc/libxl is intended to be LGPL
>>2.1, we should go for 2.1.
>
>My personal view is that LGPLv2.1+ is better because it's more
>flexible - less of a hostage to the future.  But the existing
>libraries are LGPLv2.1 and without a community decision to start
>moving to LGPLv2.1+ I think it's wrong to have files with that licence
>header.

That was the point I was trying to make: the libraries are LGPLv2.1, and
the instances where the headers say "... either version 2.1 of the
License, or (at your option) any later version" were mistake that were
made unintentionally, as the author did not delete "(at your option)".

Thanks for clarifying.

>> It may also make sense to start using SPDX License Identifiers (see
>>http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags#Tag_Format)
>> 
>> alongside the (c) notice for files which do not use GPLv2, as it
>>reduces the scope for mistakes and increases the chances of mistakes
>>being picked up by reviewers.
>
>I don't agree with this.  This ends up stating the same information in
>another way which gives more scope for inconsistency and errors.  Eg,
>you could write a GPLv2+ copyright notice but a the LGPL-2.1-only SPDX
>ID.  And then what would it mean ?
>
>But we do not need to settle that question now.

Agreed, we don't have to settle this here and now. I guess I will need to
do a bit more groundwork/thinking on this.

>> We have a similar issue with some GPLv2 files in Xen, where
>>contributors appear to have forgotten to delete the "or (at your option)
>>any later version", in some files by mistake.
>
>Likewise we should avoid opening this can of worms as part of what
>Boris is trying to do here.

Agreed. I was just trying to provide some context. I am not trying to open
this can of worms here.

>So in summary I think Boris should ask people whether they are happy
>to relicence from GPLv2-only to LGPLv2.1-only.

Agreed. Sorry for being a little off-topic. I didn't mean to hijack the
thread.

Lars

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