[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Jun 10, 2016 at 09:31:25AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 10, 2016 at 02:07:30PM +0100, Ian Jackson wrote:
> > 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].
> 
> Just consistency.
> 
> > 
> > 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.
> 
> That is fine with me!
> 

Can you collect all the acks and submit the updated patch within today?
That's assuming you want this committed for 4.7.

(My understanding is that you don't need to go over and get all the acks
again for the new patch)

Wei.

> > 
> > Ian.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.