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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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.

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?

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