WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Licensing conflict with OpenAFS kernel module

Keir Fraser wrote:

On 26 Apr 2006, at 16:51, Sidney Cammeresi wrote:

I'd suggest bringing this up within the OpenAFS community.  If they are
making direct use of Xen-specific functions, then they can potentially
find a work around.

If we've made it so that a non-GPL symbol depends on one of our GPL'd
symbols, then that may be a problem on our part.  I don't know whether
this is an acceptable thing to do.  Sounds like an issue that needs to
be discussed on LKML.

These functions do not appear in the OpenAFS source code, so the latter
possibility seems more likely.  I made some cursory examinations of the
source trees, but not knowing a lot about either, I didn't find anything.
If there's something I can do to help (like sending over my compiled
kernel module), let me know.

Those symbols are used by some extremely primitive and ubiquitous kernel macros (e.g., local_irq_enable(), local_irq_restore(), pagetable macros, page_to_phys(), ...).

I think the obvious course of action is to make those two EXPORT_SYMBOL() and add a comment to explain why. There's not exactly a lot of GPL'ed goodness hidden behind them!

Agreed, and in general, my suspicion is that for upstream merge, we have to make sure that we're not changing the license constraints of any existing EXPORT_SYMBOL().

Regards,

Anthony Liguori

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel