Licensing conflict with OpenAFS kernel module

Licensing conflict with OpenAFS kernel module

[Sidney Cammeresi]

I recently upgraded two Xen domU instances from 2.6.12.6 to 2.6.16.
Because I am running the OpenAFS client on each of them, I took the
opportunity to upgrade that (from 1.4.0 to 1.4.1) which required building
a new kernel module.  (The AFS client is partly in userspace and partly
in the kernel.)

Loading the new module failed:

		openafs: Unknown symbol force_evtchn_callback
		openafs: Unknown symbol xen_features

Upon inspecting the kernel source, I observed that these functions are
EXPORT_SYMBOL_GPL.  Unfortunately, OpenAFS is licensed under the IBM
Public License, which means that the OpenAFS client will no longer run
on Xen.

This is mostly just an FYI.  I solved my problem by editing the source and
changing OpenAFS's MODULE_LICENSE to GPL, but obviously OpenAFS cannot
distribute that change, so OpenAFS on Xen remains broken for now.

Hopefully I won't get any letters from DMCA enforcement lawyers telling
me I'm running software illegally....

-- 
Sidney CAMMERESI
http://www.cheesecake.org/sac/

Re: Licensing conflict with OpenAFS kernel module

[Anthony Liguori]

Sidney Cammeresi wrote:
> I recently upgraded two Xen domU instances from 2.6.12.6 to 2.6.16.
> Because I am running the OpenAFS client on each of them, I took the
> opportunity to upgrade that (from 1.4.0 to 1.4.1) which required building
> a new kernel module.  (The AFS client is partly in userspace and partly
> in the kernel.)
>
> Loading the new module failed:
>
> 		openafs: Unknown symbol force_evtchn_callback
> 		openafs: Unknown symbol xen_features
>   

I think you should urge OpenAFS to relicense their module under the GPL.

Regards,

Anthony Liguori

> Upon inspecting the kernel source, I observed that these functions are
> EXPORT_SYMBOL_GPL.  Unfortunately, OpenAFS is licensed under the IBM
> Public License, which means that the OpenAFS client will no longer run
> on Xen.
>
> This is mostly just an FYI.  I solved my problem by editing the source and
> changing OpenAFS's MODULE_LICENSE to GPL, but obviously OpenAFS cannot
> distribute that change, so OpenAFS on Xen remains broken for now.
>
> Hopefully I won't get any letters from DMCA enforcement lawyers telling
> me I'm running software illegally....
>
>   

Re: Licensing conflict with OpenAFS kernel module

[Sidney Cammeresi]

On Wed, 26 Apr 2006 at 10.27.42 -0500, Anthony Liguori wrote:
> Sidney Cammeresi wrote:
> >I recently upgraded two Xen domU instances from 2.6.12.6 to 2.6.16.
> >Because I am running the OpenAFS client on each of them, I took the
> >opportunity to upgrade that (from 1.4.0 to 1.4.1) which required building
> >a new kernel module.  (The AFS client is partly in userspace and partly
> >in the kernel.)
> >
> >Loading the new module failed:
> >
> >		openafs: Unknown symbol force_evtchn_callback
> >		openafs: Unknown symbol xen_features
> 
> I think you should urge OpenAFS to relicense their module under the GPL.

Well this is not their decision given that the code came from IBM in
the first place.

I note, however, your ibm.com e-mail address.  Do you perhaps know the
channels in IBM to go through to discuss IBM relicensing their code under
the GPL?

-- 
Sidney CAMMERESI
http://www.cheesecake.org/sac/

Re: Licensing conflict with OpenAFS kernel module

[Anthony Liguori]

Sidney Cammeresi wrote:
> On Wed, 26 Apr 2006 at 10.27.42 -0500, Anthony Liguori wrote:
>   
>> Sidney Cammeresi wrote:
>>     
>>> I recently upgraded two Xen domU instances from 2.6.12.6 to 2.6.16.
>>> Because I am running the OpenAFS client on each of them, I took the
>>> opportunity to upgrade that (from 1.4.0 to 1.4.1) which required building
>>> a new kernel module.  (The AFS client is partly in userspace and partly
>>> in the kernel.)
>>>
>>> Loading the new module failed:
>>>
>>> 		openafs: Unknown symbol force_evtchn_callback
>>> 		openafs: Unknown symbol xen_features
>>>       
>> I think you should urge OpenAFS to relicense their module under the GPL.
>>     
>
> Well this is not their decision given that the code came from IBM in
> the first place.
>
> I note, however, your ibm.com e-mail address.  Do you perhaps know the
> channels in IBM to go through to discuss IBM relicensing their code under
> the GPL?
>   

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.

Regards,

Anthony Liguori

Re: Licensing conflict with OpenAFS kernel module

[Sidney Cammeresi]

On Wed, 26 Apr 2006 at 10.38.45 -0500, Anthony Liguori wrote:
> Sidney Cammeresi wrote:
> >On Wed, 26 Apr 2006 at 10.27.42 -0500, Anthony Liguori wrote:
> >>Sidney Cammeresi wrote:
> >>>I recently upgraded two Xen domU instances from 2.6.12.6 to 2.6.16.
> >>>Because I am running the OpenAFS client on each of them, I took the
> >>>opportunity to upgrade that (from 1.4.0 to 1.4.1) which required building
> >>>a new kernel module.  (The AFS client is partly in userspace and partly
> >>>in the kernel.)
> >>>
> >>>Loading the new module failed:
> >>>
> >>>		openafs: Unknown symbol force_evtchn_callback
> >>>		openafs: Unknown symbol xen_features
> >>>      
> >>I think you should urge OpenAFS to relicense their module under the GPL.
> >
> >Well this is not their decision given that the code came from IBM in
> >the first place.
> >
> >I note, however, your ibm.com e-mail address.  Do you perhaps know the
> >channels in IBM to go through to discuss IBM relicensing their code under
> >the GPL?
> 
> 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.

-- 
Sidney CAMMERESI
http://www.cheesecake.org/sac/

Re: Re: Licensing conflict with OpenAFS kernel module

[Keir Fraser]

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!

  -- Keir

Re: Re: Licensing conflict with OpenAFS kernel module

[Anthony Liguori]

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
>

Re: Re: Licensing conflict with OpenAFS kernel module

[Keir Fraser]

On 26 Apr 2006, at 17:29, Anthony Liguori wrote:

>> 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().

The whole EXPORT_SYMBOL thing is pretty insane anyway. Given that the 
whole kernel is GPL, the concept of non-GPL hooks is a legal nonsense 
(or the GPL itself is a legal nonsense).

  -- Keir