This two links are helpful in understanding the restrictions on non-ALv2 compatible components, which I assume IBM DFDL is:
https://www.apache.org/legal/resolved.html#prohibited https://www.apache.org/legal/resolved.html#optional So we cannot have any mandatory or build time dependencies to IBM DFDL, and we cannot distribute any helper binaries that contain on IBM DFDL jars. Additionally, any wrapper code you write must be ALv2. As long as the sources and binaries only contain ALv2 compatible components, you can keep things in the Daffodil repo (if you'd like). I think the standard way to do this is to have the IBM DFDL wrapper that you write be ALv2 licensed and in the Daffodil repo, but just make its build optional. If someone wanted to build the the wrapper, they would need to manually modify a flag in the build to enable the dependencies and the wrapper build. We can provide instructions on how to do that and just make it clear that by doing so, the build is not fully ALv2 and may have additional restrictions based on the IBM DFDL license. As long as this isn't the default and requires the builder to take an action to enable, it's acceptable. We cannot distribute anything that contains the IBM DFDL dependencies, and since the wrapper has a dependency on it, we cannot distribute it. If someone wants it, they must build it. I think another ASF acceptable option is to create the ALv2 wrapper so that it uses reflection to find the IBM DFDL jars at runtime and disable itself if they are not on the classpath. This way, the wrapper could be built and distributed by default as part of Daffodil, since it does not have any build time dependencies. And the wrapper is only enabled if a user takes action to put the IBM DFDL jars on the runtime classpath at on their system. By doing so, they should be aware of the licensing restrictions of IBM DFDL. Reflection is a bit more fragile though. I think we could probably have it in a separate repo as you mention, as long as it's clear that it is not ASF affiliated (e.g. the package namespace would have to be something other than org.apache), but the IBM DFDL license restrictions would still apply. In each of cases, the IBM DFDL wrapper isn't core functionality of Daffodil (i.e. vast majority of people will not need this feature), so an optional dependency on non-ALv2 compatible components is fine, with the caveat that we do not distribute any non-ALv2 compatible components, either in source or binary form, and the user must take action to enable it. On 10/18/18 10:07 PM, Mike Beckerle wrote: > I am working on enhancing the TDML Runner to enable cross testing against > both Daffodil and IBM DFDL, or really any DFDL implementation. > > > So I need to build a dynamically-loading module that provides a TDMLRunner > friendly API, but calls the IBM DFDL implementation underneath. > > > The module will depend on Daffodil, implementing a new specific trait that > defines the TDML Runner's API by which it drives a DFDL implementation, which > is tentatively called > org.apache.daffodil.tdml.processor.TDMLDFDLProcessorFactory > > > The dynamically-loading module will depend on IBM DFDL libraries, and will be > compiled against them. > > > Not everyone should have those. In fact only people performing > cross-validation testing should install it. > > > Hence, the module *cannot* be part of daffodil. It has to be an entirely > separate jar. Packaged and delivered separately. Perhaps it's not even > "delivered" in the sense of a maven-central thing. Perhaps we just build it > and propagate it around to the relevant parties doing this testing ourselves. > > > So... I'm inclined to just create a repo on github for this, perhaps under > the openDFDL project. > > Still with the ASF v2 license. > > > But I'm not sure. Is that the right thing to do, or is there some other idea? > > > There are lots of projects (even lots of Apache projects) which are > extensible frameworks and they have adapter components and connectors and the > like which pose a set of similar problems to this. A connector depends on the > framework, and also the native libraries of the software thing being > connected to. > > > So is there an idiom I should be falling into here that is established? > > > ...mikeb > > >
