Sidney Cammeresi
2006-Apr-26 14:07 UTC
[Xen-devel] Licensing conflict with OpenAFS kernel module
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/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori
2006-Apr-26 15:27 UTC
Re: [Xen-devel] Licensing conflict with OpenAFS kernel module
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.... > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sidney Cammeresi
2006-Apr-26 15:33 UTC
[Xen-devel] Re: Licensing conflict with OpenAFS kernel module
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/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori
2006-Apr-26 15:38 UTC
[Xen-devel] Re: Licensing conflict with OpenAFS kernel module
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sidney Cammeresi
2006-Apr-26 15:51 UTC
[Xen-devel] Re: Licensing conflict with OpenAFS kernel module
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/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Apr-26 16:24 UTC
Re: [Xen-devel] Re: Licensing conflict with OpenAFS kernel module
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori
2006-Apr-26 16:29 UTC
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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Apr-26 16:40 UTC
Re: [Xen-devel] Re: Licensing conflict with OpenAFS kernel module
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel