Re: [Xen-devel] [PATCH for 4.7] libxenvchan: Change license of header from Lesser GPL v2.1 to BSD

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [PATCH for 4.7] libxenvchan: Change license of header 
from Lesser GPL v2.1 to BSD"):
> On Thu, 2016-06-09 at 16:43 +0100, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("[PATCH for 4.7] libxenvchan: Change
> > license of header from Lesser GPL v2.1 to BSD"):
> > > 
> > > As the xen/COPYING file says:
> > > "A few files are licensed under both GPL and a weaker BSD-style
> > > license. This includes all files within the subdirectory
> > > include/public, as described in include/public/COPYING. All such
> > > files
> > > include the non-GPL license text as a source-code comment. Although
> > > the license text refers generically to "the software", the non-GPL
> > > license applies *only* to those source files that explicitly
> > > include
> > > the non-GPL license text."
> > I personally think this patch is a good idea.
> 
> To change xen/include/public/io/libxenvchan.h only or both that
> and tools/libvchan/libxenvchan.h?

I hadn't thought about this distinction clearly enough.

> Historically the view of the Xen Project was the hypercall and PV ring
> A[BP]Is should be BSD so that proprietary OSes could be ported to Xen
> or PV drivers could be written for proprietary OSes etc.
> 
> But the view for toolstack libraries (libxenctrl, guest etc) was
> traditionally that the project wanted them to remain copyleft. IIRC
> originally one or both of libxenctrl and libxenguest were full-GPL but
> we decided that was too far and went through a relicensing excercise to
> make it LGPL, which allows for proprietary toolstack applications to be
> built on top of the foundational libraries while still ensuring that
> improvements to those libraries are contributed back.

Yes.

> So, I guess I don't really undertstand the case for / desire to
> relicense tools/libvchan/libxenvchan.h, especially given that the other
> tools/libvchan/*.[ch] files don't appear to be being relicensed in [0].

I agree that it does not make sense to change
tools/libvchan/libxenvchan.h on its own.  We should probably drop that
change from this patch.

Ian.

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