> On Dec 21, 2015, at 12:55 PM, Clebert Suconic <[email protected]> > wrote: > >> >> Actually, this is more serious than that. If I’m reading correctly, libaio >> is LGPL. Thus, we cannot use it from an Apache release unless its: >> > We are not redistributing libaio.. libaio is a Kernel functionality > from Linux. We have an implementation that is just using a kernel > functionality available on any Linux Kernel. you need to install the > libaio header but the functiionality is part of the linux kernel. > > Saying so would be the same as saying you can't use any OS that's > LGPL.. which is not the case.
But the parts of the “OS” that is used generally has some sort of “classpath exception” or similar or there is another implementation that is completely usable that is not LGPL (example: the stdc++ runtimes). libaio does not. It is specifically LGPL. In particular, in org_apache_activemq_artemis_jlibaio_LibaioContext.c, I see right at the top: #ifndef _GNU_SOURCE // libaio, O_DIRECT and other things won't be available without this define #define _GNU_SOURCE #endif That’s in direct conflict with the license header. >> 2) Not be part of the default build - in our case, we’d need a maven >> profile to build it and that profile would need to not be activeByDefault. >> >> Thus, I think this release cannot be released as is. > > I disagree.. the release should include it... our implementation is > apache licensed. …linked to libraries that are LGPL and only LGPL, which is not allowed per ASF policy. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
