Re: Re: Licensing conflict with OpenAFS kernel module

[Anthony Liguori <aliguori@us.ibm.com>]

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
>