Re: [Xen-devel] [PATCH] xen/arm: Bring (c) headers in line with COPYING file

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 27/09/2016 16:35, "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx>
wrote:

>On Tue, Sep 27, 2016 at 03:16:50PM +0100, Lars Kurth wrote:
>> The COPYING file in the main xen.git tree applies to most files in the
>> xen tree, including the ones in this patch. It states:
>> 
>> [1]
>>  * Note that the only valid version of the GPL as far as the files in
>>  * this repository are concerned is _this_ particular version of the
>>  * license (i.e., *only* v2, not v2.2 or v3.x or whatever), unless
>>  * explicitly otherwise stated.
>> 
>> We do not have any GPLv3+ files in the Xen source, with the exception of
>> Bison generated files, which have a Bison exception and are thus safe.
>> 
>> However, there are a minority of files that are specifically GPL-2.0+,
>> stating
>> 
>> [2]
>>  * This program is free software; you can redistribute it and/or modify
>>  * it under the terms of the GNU General Public License as published by
>>  * the Free Software Foundation; either version 2 of the License, or
>>  * (at your option) any later version.
>> 
>> I could not find a single instance in our code base, which states
>> 
>> [3]
>>  * This program is free software; you can redistribute it and/or modify
>>  * it under the terms of the GNU General Public License as published by
>>  * the Free Software Foundation; either version 2 of the License, or
>>  * any later version.
>> 
>> It is impossible to know, what the intention of the contributor was
>> when a (c) header of form [2] was used. There are two possibilities
>> a) The contributor chose [2] intentionally
>> b) The contributor copied a header file from elsewhere (e.g. the FSF)
>>    without understanding all the implications
>> The latter is more likely, which is also why we recently introduced
>> the CONTRIBUTING file with correct (c) headers
>> 
>> In all cases in our code base, code with a (c) header of form [2] is
>> linked against pure GPLv2 files, which in practice means that the
>> resulting binaries are always GPLv2. In addition, [1] clarifies this.
>> 
>> [2] allows the Xen Project to specifically choose GPLv2 and to modify
>> the (c) headers to that effect without express permission of the (c)
>> holders. This proposed patch makes use of this property. It also gives
>
>This patch hinges on the 'allow' part. That is that the Xen Project
>community
>can choose to modify its headers without express permission of the holders
>on removing the '(at your option)' statement from the license headers.
>Now it is not a relicense, nor changing the license but clarifying the
>semantics
>of how the code can be used in future.

That is correct. 

>Later in the description (see 'annotated' tags) are saying the same
>thing - that the community can decide this based on 'common practices'.
>
>Could you please point me to the 'common practices' and the 'allow'
>property?
>I would naively assume that this had happend in the past with other
>projects?
>Or perhaps the GPL had helpfully put a statement on their website giving
>clarification on this?

Unfortunately, the FSF FAQ does not cover this explicitly.

However, https://copyleft.org/guide/comprehensive-gpl-guidech3.html
Section 2.6, bullet point 3 does.

<quote>
2.6 The Innovation of Optional “Or Any Later” Version

An interesting fact of all GPL licenses is that there are ultimately
multiple choices for use of the license. The FSF is the primary steward
of GPL (as discussed later in § 8.1 and § 9.17). However, those who wish
to license works under GPL are not required to automatically accept
changes made by the FSF for their own copyrighted works. Each licensor may
chose three different methods of licensing, as follows:

* explicitly name a single version of GPL for their work (usually
  indicated in shorthand by saying the license is “GPLvX-only”), or
* name no version of the GPL, thus they allow their downstream recipients
  to select any version of the GPL they choose (usually indicated in
  shorthand by saying the license is simply “GPL”), or
* name a specific version of GPL and give downstream recipients the
  option to choose that version “or any later version as published
  by the FSF” (usually indicated by saying the license is
  “GPLvX-or-later”)


</quote>

As for the process, I don't know of a precedent. Maybe someone on the
list does have an example though.

Our community consists of both downstream recipients and (c) holders
and we don't know how downstream recipients use the code. If for example
a downstream recipient makes use of the GPLv2+ property, by copying
some files into a GPLv3 codebase, then we would restrict their freedom
and force them to fork the code. Older versions of those files in git
would still have that GPLv2+ property, but once we change the (c)
headers, inbound changes to those files would be made under the GPLv2
only from that point onwards.


My understanding was that legally, we don't need to follow this process,
but we don't want to unintentionally hurt any user making use of this
property. And as a community, we may not want to restrict an existing
freedom. Thus, it's fundamentally just common sense to deal with
such an issue through a consultation.

I don't expect this patch to go into Xen 4.8. I just needed to make
a start on this discussion, and get some views as this has been on
my TODO list for a while.


If this is not sufficient, the Advisory Board may need to pay for
a legal counsel to settle that question. But there is little point
in doing so, if there are major objections on the principle.


Best Regards
Lars

>Thanks!
>
>> anyone the right, to copy files from the Xen Project into a another
>> codebase and to explicitly choose GPLv3 or a later version without
>> obtaining the permission of the (c) holders.
>> 
>> When large vendors go through their internal approval process to
>> decide whether to allow their employees to contribute to projects, they
>> tend to perform a license and/or patent review. Depending on the
>>company,
>> that process can be very different for L/GPLv2 versus L/GPLv3 codebases
>> (which contains a broad expressed patent license and a "patent defense"
>> provision).
>> 
>> We had a concrete instance, where the approval process took excessively
>> long due to the use of [2] in a large number of files. The intention
>> of this patch is to avoid such delays in future, when other potential
>> contributors perform a license/patent review.
>> 
>> There is no downside to the project regarding this change, as our
>> codebase is primarily GPLv2. The change does however restrict the
>> freedom of people to copy files into other codebases which are not
>> GPLv2 or not GPLv2 compatible (such as GPLv3 codebases).
>> 
>
><annotate>
>> Common practice for changes like this, is to invite the community to
>> provide input and to execute the change, if there are no unresolvable
>> objections.
></annotate>
>
>> 
>> Note that I will prepare some more patches of this type, by functional
>> area to make it easier to add all the right maintainers to the CC
>> list, once we have a decision on this one.
>
><snip>

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